Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!NSF.GOV!mmorse From: mmorse@NSF.GOV (Michael Morse) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: <9102111609.aa03681@Note.NSF.GOV> Date: 11 Feb 91 21:09:47 GMT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The Internet Lines: 83 > We have recently installed a new NOVELL mail system called PMAIL. One of the > features allows you to request a confirmation once the mail message is > delivered. I think this is an EXCELLENT idea. I had previously thought of this > before, so when I saw it I was happy. > This is accomplished by putting a line in the headers that only PMAIL > recognizes.Now to the point. What would other people think of making some sort > of standard header line that other mailers can act on? It's not hard to > understand, and is easy to implement. Despite the popularity of this feature in the commercial world, and in commercial (proprietary) mail systems, it is surprisingly difficult to implement in SMTP/Unix based mail systems. Here are just some of the reasons: 1. Most Unix mail systems do not really have the concept of "when the user *reads* the mail." If you talk to people who want this feature it turns out that they're not really interested that some machine has accepted responsibility for the message, they want to know that the recipient "got it" which means, "has looked at it." Unix mail systems tend to stick mail in a file and let the user get to it by whatever method they choose. If you're actually talking about accepting responsibility, then most Unix systems that run sendmail already do this (just add "return-receipt-to: your_name" to the message header and send it to a Unix box). Again, this is *not* what most people mean by certified mail, but if it is what you mean, I suggest you just use the sendmail convention (and skip the rest of this message). 2. In SMTP, the header of the message is really not much more than text. That makes it difficult to implement a "when read" receipt. The reason is that you only want to send the receipt once. That means you must modify the header after you read it once. Technically this is difficult to do in a relatively robust fashion on current Unix mail systems. One of the reasons is that a large number of messages are usually contained in a single file, meaning you have to completely re-write the file, keeping it locked the whole while. 3. There is a problem with mailing lists. If someone addresses mail to a mailing list (such as this one) and requests certified mail, do they want a receipt from the list maintainer, or from everyone that receives a copy of the message? Depending on how you answer this question, many other problems result, since it's very difficult to determine when a message has reached its final destination. If you don't choose final destination as the point to generate the certified mail, then you must design a method of specifying where to generate the receipt. 4. However, the real problem is social: there are many people on the Internet that consider this concept an invasion of their privacy (I should send you the flames I received when I proposed it a couple of years ago.) The reasoning is that "my mail is my mail" and you have no right to know when I read it, if I read it, and you certainly can't use CPU resources on my machine to send a receipt. The existance of this large group of people means that given the technical limitations listed above, a lot of people will subvert the feature, making it *much* less useful to the senders. This attitude is not limited to the Internet, but it is rare in the commercial world, where everything is considered by many to be the property of the company or organization. However, my experience is that it is a common attitude in the U.K. This attitude resulted in the bizarre implementation of All-In-One for DEC, in which a user could configure things so that all mail he sent asked for a return receipt, but could also configure his mailbox so that no return receipts were ever sent to incoming mail. Allowing a user to "turn off" receipts makes the feature less useful to an organization since users never know why they didn't get a receipt. Again, in the commercial world you can simply decree "It's illegal to turn off receipts". You just can't decree that in the Internet. The bottom line is that this feature will be easy to implement in a closed, proprietary mail system, and almost impossible in SMTP. I believe it is a feature of X.400, so it'll be interesting to see how it is implemented (or not implemented) in the Internet/Unix world. --Mike Michael Morse Internet: mmorse@note.nsf.gov National Science Foundation BITNET: mmorse@NSF 1800 G St. N.W. Room 401 Telephone: (202) 357-7659 Washington, D.C. 20550 FAX: (202) 357-7663