Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!decwrl!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!ugle.unit.no!nuug!ifi!enag From: enag@ifi.uio.no (Erik Naggum) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: Date: 15 Feb 91 08:14:16 GMT Article-I.D.: holmenko.ENAG.91Feb15091403 References: <9102111542.AA18194@telesys.ncsc.navy.mil> Sender: enag@ifi.uio.no (Erik Naggum) Organization: Naggum Software, Oslo, Norway Lines: 104 In-Reply-To: mark@TELESYS.NCSC.NAVY.MIL's message of 11 Feb 91 15:42:47 GMT > Erik Naggum, Naggum Software, Oslo, Norway, offered a thoughtful > rebuttal to the idea of certified/registered mailers. However, I > believe that his arguments overlook several issues: Let me try to reply to the overlooked issues. > 1) Many organizations do use registered mail, or some other feedback > mechanism, to verify that deliveries have been made. The absence > of comparable mechanisms in SMTP is perceived as a shortcoming > that must be tolerated, at best. The postal service is paid to deliver your mail. When you buy the service of registered mail, the postal service is required by law to deliver it and record the delivery in a way which you can rely on, legally. You can request return receipts from the postal service as well, and the postal service has a big problem if you don't get a return receipt when the letter was received. There is no one who can assume this responsibility in the Internet. Thus, the "shortcoming" stems from the nature of the service provider involved, and SMTP reflects this. > 2) Many non-SMTP mail systems, especially those running on PCs and > LANs, offer registered mail capabilities, making the absence of > those capabilities in SMTP more obvious and irritating than they > might be otherwise. I've seen systems which do this, but they are in no way legally binding, which registered mail is in its postal implementation they try to mimic. In particular, you can't guarantee that non-delivery of a delivery notification is equivalent to non-delivery of the message, which I spent some time indicating. The other problem is that a confirmed delivery may not be equivalent to confirmed receipt by the intended recipient: the recipient may have elected to "share" his account with somebody else, the mail reading program may have crashed before he had a chance to read the message, he only read the header of your message and accidentally deleted it, he used the editor to read his mailbox and deleted it before any mail reader had a chance to send a delivery notification back. The list goes on. None of these apply to postal registered mail, because the recipient actually has to sign a form which agrees that he has received it, and the person requesting such signature may also request proof that the signer is the intended recipient. Another technicality is that the intended recipient may refuse to accept the letter. Also, registered mail is returned to the sender if the recipient has not been able to receive it within a certain time. To successfully mimic the registered mail option of postal services, a whole new system has to be implemented wherein some special recipient on the target system receives the message, sends a message to the intended recipient informing him of the message, with a copy of the envelope and possibly headers, whereupon the intended recipient has to submit a privacy-enhanced request to receive it, which is construed to be evidence that the message has been received and presumably read by the intended recipient. Some amount of authentication and confirmable action to receive the message is needed. > 3) The ACK/NAK problem can be as troublesome on LANs as it would be > on the Internet. The fact that LANs supporting registered mail > schemes do not typically collapse due to ACK/NAK cascades > indicates that the real world can cope with mail registration > successfully. True, they can. All major protocols also cope with the Three Armies problem, but I've come across unilaterally hung X.25 connections so often that I believe it's a real problem. TCP connections time out after too many retries, but retries is a central part of it all. The question remains that in the absence of confirmable delivery and a confirmed delivery notification, should the sender resubmit the message until such is received? Of course, often it will work, but it's the cases where it doesn't that you really need the services of registered mail. > 4) E-mail is certainly not the only means of communications > available to most Internet users. The lack of a receipt notice > usually prompts our users to call the intended recipient to alert > him/her to the presence of the mail. This feedback opportunity > can assist network administrators in identifying the existence of > network problems if, for instance, the mail was never received. Exactly right! Therefore, since it's intractable to solve the problem of registered mail in the Internet, the services of the telephone, the telefax, and the postal registered mail may be used with more success than that with which we may try to implement registered mail in the Internet. With the advent of Privacy Enhanced Mail, I think we will attain a higher level of certainty with respect to authenticity, but the problem of confirmed delivery remains to be solved. As I alluded to above, a registered mail daemon using PEM may be a viable solution where PEM is available. > Registered mail is certainly no panacea for assuring effective > communications. It can, however, provide important information for > users and is in appreciable demand in some environments. I don't disagree with this, I just think it's technically infeasable at the moment and will remain so for a long time. Especially as long as we don't have a contractual agreement between service provider and service user as to the delivery status of mail. Personally, I call people, or ask them to call me when an important issue has to be resolved. This invariably works well. -- [Erik Naggum] Naggum Software, Oslo, Norway