[ih] There is no such thing as an "end-to-end failure"

[Joseph Touch]

> On Sep 13, 2020, at 11:09 AM, Dave Crocker <dhc at dcrocker.net> wrote:
> 
> Note that my primary comment was about terminology.
> 
> I'm going to venture that this exchange demonstrates how unproductive --
> or even counterproductive -- language like "end-to-end failure" is.

Agreed. My version is:

	from user sending a post to a list 
	to user knowing the post arrives on that list

Not all solutions to CS problems involve only computers.


> ...
> In formal architectural parlance, a basic mailing list sequence
> 
>  MUA -> MSA -> MTA -> ... MTA -> MDA -> MLM ->
> 
>      -> MSA -> MTA -> ... MTA -> MDA -> MUA

You’ve omitted the users on both ends of that sequence, which *can* be part of the E2E chain too.

> ...
> It's tempting to think that the issue might be to provide a mechanism
> invoked during 'final' delivery, to the 'ultimate' recipient.  That
> would presume knowing when that occurs.  cf, multiple mailing lists.

Humans do.

>>>> If it were, your mailer would have let you know that you didn’t
>>>> receive a copy of the mail
> 
> My "mailer" would let me know I didn't receive some mail?  Isn't that
> akin to proving a negative?  I don't understand how my "mailer" can be
> expected to know about mail I didn't receive.

A timeout. That’s the only way anyone (or thing) ever knows something is lost.

>> or that your post didn’t appear in the archive. So, at some level,
>> one E2E failure happened in the design and implementation of ALL mail
>> readers.
> 
> Sorry, but I do not understand the control mechanisms you are postulating.

A mail reader COULD know when it’s posting to a list (we don’t currently encode that in either email addresses or the protocols to post to lists, but that could have been done).

A mail reader could then correlate the sent mail to the receipt of matching post to that list, again if email had sufficient unique IDs that were retained through the entire chain from  user to mailing list and back to that user.

> They appear to involve quite a bit of mechanism that hasn't been
> discussed much, over the 45+ years of email, or implemented for Internet
> mail at all.

Right - my (apparently too subtle) point is that this was 
	a) not considered by email designers
	b) not performed by email list users
	c) but appears to be assumed of email list maintainers

I don’t consider (a) the E2E failure; rather it is the combination of (a), (b), and (c).

...
>>> The operational reality of modern Internet mail is that perhaps 95%
>>> of the traffic across the Internet is spam.  This has required
>>> quite a bit of mitigation, of course, where one of the resulting
>>> requirements is to permit essentially no automated feedback to the
>>> author or originating operator.  Sorry.  That's unfortunate, but
>>> it's not a 'failure'.
>> That’s an eventuality an E2E system could have accounted for, e.g.,
>> via a timeout - as is done with TCP when a segment is silently
>> dropped.
> 
> Rubbish.  Such hand-waves about difficult operational challenges that
> develop over time, and at scale, are frequently made as convenient slams
> but they never have the theoretical, experimental or operational basis
> to be valid.
> 
> The basic stance of such rubbish is that all eventualities must be
> anticipated before anything is put into the field.  That was the OSI
> approach.  Besides creating infinite delay, it doesn't work.

One eventuality is that hop by hop mail delivery in a mail sequence does not confer E2E delivery guarantees.

Any mail source could - and should - plan for that. That includes “people” as that source.

> 
>>> To the extent that feedback is essential, please offer a design
>>> that is robust against abuse.  We do not currently have one. Return
>>> Receipt still works, but it's not quite what you are looking for, I
>>> suspect.
>> For a system that involves email distribution, which is another step,
>> the check would have to occur by trying to match list posts to sent
>> mail, not merely expect return receipts.
> 
> Sorry, but I don't know what "matching list posts to sent mail" is,
> since I consider "posts" to equate to "sent".  

If that were true, then Karl’s posts were all successful. They all got sent to ISOC and promptly dropped on the floor after being successfully received.

> Further, there is nothing
> that identifies mail that is sent as specifically going to a list.

As per above, yes. That’s part of the “failure” of the system overall to account for the E2E goal.

> ...
> Your certitude about what is needed for end-to-end mailing list behavior serves as self-nomination to produce something similar for mailing lists.  I look forward to reviewing your first draft.

Here’s the draft, in as much detail as is needed:

	- if you post to a list and don’t see it in the archive or get a copy, 
	then debug it by varying what’s transmitted and who transmits it, i.e., at the endpoints

Not all E2E problems should start by demanding visibility into the middle of a path.

Joe