Subject: 5.c. message status - Failure Modes (was RE: [Asrg] Protocols)

From: Paul Judge <[email-masked]>
Date: Tue, 25 Mar 2003 11:06:14 -0500

Changing the subject to something more descriptive and to follow the
requested format.

> -----Original Message-----
> From: Kee Hinckley [mailto:[email-masked]] 
> Sent: Tuesday, March 25, 2003 9:35 AM
> To: [email-masked]
> Subject: [Asrg] Protocols
> 
> 
> A lot of the proposals people have made to this list make a 
> fundamental change to how email works, and I don't mean in the 
> specifics, but at a very high level.
> 
> Currently the process of sending email from point a to point b does 
> not involve any protocols.  Yes, the transport does--but from the MUA 
> to MUA standpoint there is no back and forth protocol.  You toss 
> message over wall.  Sometime later, someone gets it.  This is 
> completely one way.  Yes, there are two exceptions to the 
> rule--bounces and return-receipts.  And it's probably worth 
> considering that neither of those exceptions work very well. 
> Return-receipt is unreliable due to gateway issues, as well as social 
> ones.  And bounces range from no-bounces-but-not-delivered, to 
> did-bounce-but-got-delivered.  In both cases the sending MUA seldom 
> has any knowledge of the even that limited protocol.  (It could link 
> bounces and return-receipts to the original message, but most do 
> not--the protocols are too unreliable.)
> 
> When you propose a change to the mail system that *requires* a 
> protocol (either through two supporting MUAs, or one supporting MUA 
> and one annoyed human :-) you are making a very fundamental change to 
> how email works.  You have introduced a dramatic new level of 
> complexity.  The difference between drop-and-forget and a real 
> protocol with bi-directional communication is huge.  Most 
> importantly, it introduces a whole new way for things to fail.
> 
> I've seen a lot of proposals.  But I don't believe I've seen any of 
> them discuss failure modes.  TCP may guarantee that you deliver a 
> packet or know you didn't--but email most certainly does not.  If you 
> are designing a protocol on top of email, you've got to think about 
> the how things fail.
> 
> Here are a few to consider--independent of whether we're talking 
> hashcash, sender-pays, challenge/response, or anything else.
> 
> - initial message isn't delivered
> - initial message is delivered to wrong person
> -- intentionally (person left company, new person replies)
> -- intentionally (I'm on vacation, forwarded my email to secretary)
> -- unintentionally (something went wrong)
> -- unintentionally (new person at ISP using old email address)
> - protocol reply isn't delivered (gets lost somewhere)
> - protocol reply is delivered late (lost in email)
> - protocol reply is delivered late (back from six month vacation)
> - protocol reply is misdelivered (see above misdelivery cases)
> - protocol reply bounces (no account, mailbox over quota)
> - protocol reply gets temporary bounce (host unavailable)
> - protocol reply bounces without body in reply
> - protocol reply gets on-vacation message
> - protocol reply is sent return-receipt requested
> ...
> 
> When you design two-way communications, you need to deal with 
> failure.  You are building on top of a transport that does not 
> reliably tell you when it fails, or how it failed.  Right now even 
> trying to figure out when an address has permanently failed so that 
> it can be removed from a mailing list is non-trivial.  That is the 
> transport you have to deal with.  All the proposals I've seen so far 
> assume that the underlying email system is reliable.  It's not.
> -- 
> Kee Hinckley
> http://www.puremessaging.com/        Junk-Free Email Filtering
> http://commons.somewhere.com/buzz/   Writings on Technology 
> and Society
> 
> I'm not sure which upsets me more: that people are so 
> unwilling to accept responsibility for their own actions, or 
> that they are so eager to regulate everyone else's. 
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
> 
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg