Changing the subject to something more descriptive and to follow the
requested format.
-----Original Message-----
From: Kee Hinckley [mailto:nazgul(_at_)somewhere(_dot_)com]
Sent: Tuesday, March 25, 2003 9:35 AM
To: asrg(_at_)ietf(_dot_)org
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg