mo@seismo.CSS.GOV.UUCP (02/27/87)
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!) So... 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, -Mike O'Dell