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

[Joseph Touch]

> On Sep 13, 2020, at 9:34 AM, Dave Crocker via Internet-history <internet-history at elists.isoc.org> wrote:
> ...
> On 9/13/2020 8:26 AM, Joseph Touch via Internet-history wrote:
>> On the one hand, that E2E is the composition of a set of applications into a single service that was never implemented as E2E at the mail delivery layer.
> 
> Oh?  Please clarify, with details.

I did; E2E would mean the entire chain of “send the mail to the server” and “server sent the mail out to the list and to the archive”.

My mail client never sends mail to your mail client. There are several steps involved there - SMTP and either IMAP or POP for unicast; SMTP to SMTP via Mailman to IMAP or POP for mailing lists. There is no single E2E signaling mechanism.

>> If it were, your mailer would have let you know that you didn’t receive a copy of the mail 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. 
> 
> 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.

> 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.

>> However, understanding E2E means knowing what the ends are.
> 
> The importance of this observation cannot be overstated.  I used to think that MUAs were the endpoints -- and often, of course, they are.
> 
> Then I met EDI over email.
> 
>> So on the other hand, mail list posters can be considered an endpoint. If they had acted as endpoints, the NACK would have resulted in their retrying posts with varying content until they confirm success by receipt and in the archive. I.e., what I did, using the CS 100 method of binary search. Instead, they did something very un-E2E - they sought assistance from the management plane (me) and took issue with the lack of active feedback from various intermediate layers and hops (smtp, postfix, Mailman, etc.).
> 
> There is a tendency to think that mailing list managers (MLM) are the same as mail transfer agents (MTA).  They aren't.  The latter are relays holding roughly the same architectural role as an IP router.
> 
> However MLMs are actual email endpoints.  They take delivery of mail addressed to them and then generate and post a new message.
> 
> The fact that an original author and final recipients perceive a 'direct' interaction is due to a layer /above/ normal email. And it is a poorly documented and inconsistently implemented and inconsistently operated layer.
> 
> To the extent that someone wants to declare a failure at that level, they need to point to the documentation involved and clarify what, exactly has failed.
> 
> Typically what has actually failed is that their entirely reasonable expectations, which were not documented anywhere, were not met.

I agree; I’m claiming that expecting email to be E2E here is incorrect. It’s one hop in a chain for which there is no E2E system except the user to ensure oversight (at least at present).

>> Over the years, I thought we had learned not to expect active feedback when things fail, for several reasons: security (why ICMPs are blocked), stability (to avoid NACK storms), info theory (you can’t NACK what you didn’t expect), or even the Postel Principle (be liberal in what you [don’t] receive).
> 
> I quite like this summary.
> 
> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history