ietf-asrg
[Top] [All Lists]

[Asrg] 5.c. message status - Failure Modes

2003-03-25 14:14:09

Kee Hinckley said:

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.

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

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

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.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>