Subject: [Asrg] Protocols

From: Kee Hinckley <[email-masked]>
Date: Tue, 25 Mar 2003 09:34:54 -0500

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 25 Mar 2003 10:51:27 -0800

Kee,

Tuesday, March 25, 2003, 6:34:54 AM, you wrote:
KH> Currently the process of sending email from point a to point b does
KH> not involve any protocols.  Yes, the transport does--but from the MUA
KH> to MUA standpoint there is no back and forth protocol.  You toss 
KH> message over wall.  Sometime later, someone gets it.  This is 
KH> completely one way.

Ahh.  So all those services that use one-way UDP mechanisms are not
protocols?

A protocol does not require closed-loop communication.  A protocol is a
set of rules for exchange.  Nothing requires that the exchange be 2-way.

Anything that involves standardized exchange from an originator to a
recipient is a protocol.

KH>  Yes, there are two exceptions to the 
KH> rule--bounces and return-receipts.

closed-loop issues also include replies.  open-jaw (multi-user)
scenarios include forwarding and redirection.

KH> I've seen a lot of proposals.  But I don't believe I've seen any of
KH> them discuss failure modes.

an extremely point to raise.  thank you.

adoption sequence (and dependencies) and failure behavior are probably
the two most important perspectives to evaluate for any new scheme.  it
is almost always true that the scenario for steady-state operation with
a large-scale set of well-behaved participants is not the challenge.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: [email-masked] (Justin Mason)
Date: Tue, 25 Mar 2003 13:04:13 -0800

> importantly, it introduces a whole new way for things to fail.

FWIW, I *strongly* agree with this.  It totally changes the semantics
of mail.

> - protocol reply is sent return-receipt requested

I'd add

  - protocol reply is sent to an address intended only to receive errors
    (e.g. automated mail generated by notification component of an
    e-commerce system)

--j.