MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager") (02/09/91)
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. So, let's hear what you think. If people choose to reply to me, I will count the votes and summarize to the net and take appropriate action. Thank. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= jerrod t. carter, networking manager | my employer has no opinions rose-hulman institute of technology | MGRJTC@RoseVC.Rose-Hulman.Edu | "may all your faults be soft." MGRJTC@RHIT.BITNET |
imp@Solbourne.COM (Warner Losh) (02/09/91)
In article <C13C5DEE293FE00507@ROSEVC.Rose-Hulman.Edu> MGRJTC@ROSEVC.Rose-Hulman.EDU ("Jerrod T. Carter, Networking Manager") writes: >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? There is a header called Return-Receipt: that various sendmail versions seem to grok. Maybe that is the way to go.... Note that delivering the mail doesn't actually mean that the person will read the mail. Every month or two around here a couple of people loose mail because of a disk crash w/no backup since the incoming mail was sent. I don't know what PMAIL does, but unless return receipt is integrated into the mail reading program, it too would suffer from this problem. Also, I didn't think NOVELL used TCP/IP at all. Don't they use IPX? Warner -- Warner Losh imp@Solbourne.COM We sing about Beauty and we sing about Truth at $10,000 a show.
joe@oilean.uucp (Joe McGuckin) (02/11/91)
I think it's a great idea. But why stop there? Why not have an additional confirmation that informs you when the message was actually read... -- Joe McGuckin oilean!joe@sgi.com Island Software joe@parcplace.com (415) 969-5453
enag@ifi.uio.no (Erik Naggum, the Internet Purist) (02/11/91)
In article <1991Feb10.205047.2217@oilean.uucp>, Joe McGuckin writes: > I think it's a great idea. But why stop there? Why not have an > additional confirmation that informs you when the message was > actually read... I think (yet another) reality check on this topic is needed. It can be exemplified by the question: How often do you send registered mail? If that is every time you send a letter, I sympathize with your need to do the same with e-mail. If not, I claim that you're going to do it every time if it were possible, for a large number of "you". The second, corollary problem is that even for a limited number of users who request receipts on any of the events "message received", "message read", "message understood", "mission completed", etc, on all messages sent, the volume of mail will likely escalate exponentially. Also, see below for a related volume problem. The third problem is the Three Armies problem, where two allies A and B are separated by an Enemy controlled area. A can communicate with B only _through_ the Enemy controlled area. Say A plans to do a two-flank attack on E, and this requires the cooperation of B, since a one-flank attack is close to suicide. A sends B a message: "Will attack from W at 0430. Pls ACK." The following occurs: (1) B doesn't get the message (ordonance caught, shot, drown...) (2) B gets the message, and ACKs, but needs an ACK. (1) A doesn't get the ACK. (2) A gets the ACK, ACKs, but needs an ACK. (1) B doesn't get the ACKed ACK. (2) B gets the ACKed ACK, ACKS, needs ACK. ... As should be obvious, a lack of ACK is not a NAK. An ACK is not guaranteed to be delivered, and thus must be ACKed, ad infinitum. Also, in the absence of an ACK, should A retransmit until an ACK is received? Should each party retransmit ACKs until properly ACKed? What is the terminating condition of this recursion? Consider what options exist in the absence of a "secure" ACK. Either party may not get the message or the ACK, but believe that the other party has got it, for any iteration of the above process. This may be suicide, and may not be a viable option. What would you do? Or rephrased: If you don't get an ACK "message received, read, understood, mission completed", which of the four possible NAK conditions is true, or did the ACK fail to get delivered? The corollary to this third problem is that the network will become saturated with ACKed ACKs, or retransmitted messages. The latter will also occur if the recipient is not equipped to reply, or chooses not to for any number of reasons. So, the summary of this rather elaborate exposition of this one problem of basic network technology, is: You don't want that. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
henry@zoo.toronto.edu (Henry Spencer) (02/12/91)
In article <1991Feb10.205047.2217@oilean.uucp> joe@oilean.uucp (Joe McGuckin) writes: >I think it's a great idea. But why stop there? Why not have an additional confirmation >that informs you when the message was actually read... That would be a good trick. Unless by "read" you mean "displayed on the user's screen, whether he actually read it or not"... -- "Read the OSI protocol specifications? | Henry Spencer @ U of Toronto Zoology I can't even *lift* them!" | henry@zoo.toronto.edu utzoo!henry
rick@uunet.uu.net (Rick Adams) (02/12/91)
> >I think it's a great idea. But why stop there? Why not have an additional confirmation > >that informs you when the message was actually read... > > That would be a good trick. Unless by "read" you mean "displayed on the > user's screen, whether he actually read it or not"... Even thats not good enough. A company I used to work for had an office autmoation system that allowed you to give messages a "confirm on read" status. So many people at the company applied it to everything that I used to run a text editor directly on the mail box to "read" the mail, then within the system, I "deleted unread" the messages. So, no confirmation... (Just my way of playing with their minds I guess.) Message confirmation is a great way to increase revenues if you charge per message. Its a lousy way to run a mail system. It basicaly replicates the received ok handshakes from lower levels and is not necessarily a useful indication. (I.e. what about all of the unacknowledged messages I read?) ---rick
mmorse@NSF.GOV (Michael Morse) (02/12/91)
> 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
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/12/91)
There is a different kind of mail system where return receipts are perfectly natural. All messages are very short, but can be accompanied by one or more files that aren't sent at first but are held on the sender's system. The recipient of the message can retrieve the files---possibly compressed, encrypted, checksummed, whatever---with a command or two. (When the initial message isn't required, this turns into a BITNET-style file transfer system.) The sender is told when the files are picked up, so he can use them as a (voluntary) return-receipt system. ---Dan
bzs@world.std.com (Barry Shein) (02/13/91)
Re: ack'd mail
The hard cases, as has been pointed out, are very hard indeed. The
easy cases, however, are quite easy.
If we assume that these receipts, read and other returns are voluntary
then they belong in the mail user interface. Perhaps the transport
agents would be aware of these to the extent that avoiding loops and
handling errors might be within its purview.
So, we add a field like:
Mail-Options: Reply-When-Read
to request one and
Mail-Options: Read-Reply
To mark one.
and the mail user agent is free to ignore it, send a reply, or even
ask the person what to do at that point. Systems which sell as
"secure" closed systems can assure that this will be handled in some
specified manner. Systems which don't, don't. If it's popular then it
probably will become fairly reliable, if not, then not.
We can standardize a field and string for doing this sort of thing and
just leave it to the implementors to decide how strictly to try to
implement it.
But, at least, we've provided one common way that the concept is
expressed (mechanism, not policy.) The worst case is every mail
subsystem builder deciding this is needed and doing it differently.
-b
--
-Barry Shein
Software Tool & Die | bzs@world.std.com | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDariel@prime.com (Rob Ullmann) (02/13/91)
Hi, there is already a de facto standard for "certified mail". Include a header field Return-Receipt-To: <address> (the exact syntax identical to Reply-To:) You will get a delivery report from the mailer doing final delivery, if it supports receipts. If the user "reads" it with an interface that supports it, you will get a "read receipt". Rob Ullmann Prime Computer, Inc.
leo@unipalm.uucp (E.J. Leoni-Smith) (02/14/91)
have a simple way of sending 'registered' mail. I include in it a line If you recieve this, will you tell me? This enables me to determine that not only has the message got there, but also that a human the other end has actually understood it, and was sufficiently civilised to inform me of the fact. A very powerful protocol indeed! :-)
enag@ifi.uio.no (Erik Naggum) (02/15/91)
> 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] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>
dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) (02/18/91)
Erik Naggum raises a host of interesting points in his comparison of email to the postal service's registered/certified mail. I tend to support his conclusion that "registered" email will be a long time comming, but for social, rather than technical reasons. While I'm not a lawyer, my understanding of the legal status of email is that it does not have any of the protections accorded to paper (Post Office) mail. While it is a crime for the post office to tamper with your letters, there appears to be nothing preventing any mail relay from reading/modifying/deleting your mail at will. A recent case against Epson America, where an employee was fired (and frogmarched out of the building by the police, no less!) for objecting to Epson's policy of reading employee's email, was dismissed because it Epson has not violated either the Electronic Communications Privacy Act or California wiretaping statutes. The judge ruled flat out that wiretaping does not apply to email. (Note that a similar suit has been files against Nissan USA). So what does this mean (rather than don't buy Epson or Nissan products)? Email appears to have absolutely no legal protections, or any standing in a court of law (don't tell me about Ollie North - that was no court, that was the congress). I would suggest that email providers will not venture into this field until the LEGAL status of email is established. Imagine the liability of (for example) MCI if they offer a "Certified" email that can be manhandled by any system administrator on the net ... This may be a case of a solvable (eventually) *technical* problem but an insoluable social one. ------------------------------------------------------------------------------- Ted Doty, Network Systems Corporation | phone: +1 301 596-2270 8965 Guilford Rd./Suite 250 | fax: +1 301 381-3320 Columbia, MD 21046 USA | voice mail: (800) 233-1485 ------------------------------------------------------------------------------- "These views are my own, and do not necessarially represent those of Network Systems Corporation" "The first thing we do, it to kill all the lawyers." -Wm. Shakespeare
pww@bnr.ca (Peter Whittaker) (02/19/91)
In article <9102181435.AA05874@nscultrix1.network.com> dotytr@NSCULTRIX1.NETWORK.COM (Ted R. Doty) writes: >While I'm not a lawyer, my understanding of the legal status of email is that >it does not have any of the protections accorded to paper (Post Office) mail. > >This may be a case of a solvable (eventually) *technical* problem but an >insoluable social one. One solution is to send only encrypted mail, preferably something encrypted using the intended recipient's public key: the recipient is therefore the only person who can decrypt it. (For more information, check out articles or books on Privacy Enhanced Mail (PEM) or Public Key CryptoSystems (PKCS). See also CCITT X.509). The solution ends up being technical rather than social.:-> Of course, an employer might disallow encrypted mail on corporate systems.... -- Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] Open Systems Integration pww@bnr.ca [ ] Bell Northern Research Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C FAX:+1 613 763 3283 [__________________________] Ottawa, Ontario, K1Y 4H7
RAF@CU.NIH.GOV ("Roger Fajman") (02/19/91)
> 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. At least in the US there is something called certified mail, which is less stringent than registered mail. It does not guarantee that the letter will arrive, but simply keeps a record if it does. You can also request a return receipt, which can also get lost along the way back. Even with registered mail, there is no assurance that the return receipt will make it back to you. Only the original letter is safeguarded while enroute. There is no such safeguarding for certified mail. We have email acknowledgements on some of our internal systems. They aren't used extensively, so the extra traffic is minimal. The normal reason for using them is to get some reasonable assurance that the message did make it to the addressee. The idea is to follow up if the acknowledgement is not received in a reasonable time. I don't think that anyone believes that it is legally binding in any way. Regardless of what you think of acknowledgements, they are a feature that many people want. This discussion more properly belongs on the header-people list. Also, there is now an IETF working group considering enhancements to RFCs 821 and 822. Roger Fajman Telephone: +1 301 402 1246 National Institutes of Health BITNET: RAF@NIHCU Bethesda, Maryland, USA Internet: RAF@CU.NIH.GOV