Mike O'Dell (mo@seismo.CSS.GOV)
Fri, 27 Feb 87 08:22:22 EST
All this discussion about when and why one does what one does with SMTP
leads me to reiterate a viewpoint discussed long ago during the 822 MailWarz.
In my humble opinion,
if a mail system isn't reliable, it isn't a mail system.
This applies to local mail, SMTP, UUCP, X.400, BITNET, or whatever.
(I think I offended everyone!)
An extremely important notion in the design of mail systems is the "transfer
of responsibility" for a message. In my view of the world,
when one mail agent acknowledges a transfer to another, the acknowledging
againt isn't required to specify exactly what that means over and above
the fact that the new agent in charge of the message
is obligated to either (1) deliver the message
to the recipient, (2) reliably transfer responsibility to another
mail agent or (3) start returning the message to the originator,
along with an explanation as two why (1) or (2) wasn't possible.
I say "start returning", because the returned mail is in fact contained
in a new message, originated by the mail agent, and is handled as any
other message - ie, mail agents handing off responsibility for a message
until it is delivered to the recipient (whatever that means).
So, as Mark Crispin points out, to concienciously accept responsibility,
an agent must have committed the message to some (fairly) robust storage
before acknowledging it, lest it be lost in a crash. Whatever else
must be done with the message to accomplish (1), (2), or regretably (3)
can be done after the copy is firmly in hand (disk) and the transfer
of responsibility has happened.
I think this model of transferring responsibility (and only implicitly
the message) is more useful because when one transfers only messages,
it isn't clear who is liable for what in what circumstances. If one
is transferring responsibility for safe conduct of an object, it
becomes much clearer what one's alternatives actually are. Further,
I think this has interesting impacts on protocol design. Anyway...
I hope this sheds some light on things,
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:43 GMT