don@grc.UUCP (Donald D. Woelz) (10/03/89)
While we are all in the mode of suggesting new features for ELM, I have
a suggestion of my own for the next version. But first some background
so that you might understand why this feature could be important.
We have been using ELM now for several years. Our organization uses ELM
throughout the entire organization. We are a small company with about 40
employees in three offices located in the U.S., the U.K. and Hong Kong.
Literally every employee uses email and hence ELM. We consider ourselves
to be about as close to a paperless office as you can reasonable get and
rely very heavily on email for all corporate communications.
Because the world exists, systems crash and communications get disrupted
on occasion. This means that email doesn't always get where it is
supposed to go. Neither the sender nor the recipient are always aware
that a piece of critical mail is lost.
Now for the proposal: I think that some kind of feature to do the
equivalent of Ceritifed and Registered mail would be very useful to
indicate, at least to the sender, that his email has gone through.
Certified mail would be a piece of email sent back to the originator
indicating that his mail was indeed appended to the recipients
mailbox. Registered email would be a piece or email sent back to
the originator indicating that the recipient has looked at the
piece of mail.
How can this be done? Well, I am not by any means an expert at programming
this sort of stuff, but here are my thoughts. First of all, I realize
that if the recipient is not using ELM, this would probably fall apart,
so let's assume that this will only work if both the sender and recipient
are using ELM. Could one not create a special header field that would
indicate that the mail is either certified or registered? If so, then
when a recipient invokes ELM, ELM scans the mailbox and, if there are
any certified email messages, send a receipt back to the sender. The dates
can be checked to avoid sending a receipt for the same message each time
the mailbox is opened. Similarly, ELM already keeps track of which
messages have been read, so when it finds that the user has read a
registered email message, it sends a receipt to the sender indicated so.
Enough said by me. Anybody else have any comments on this?
--
Don Woelz {ames, rutgers, harvard}!uwvax!uwmcsd4!grc!don
GENROCO, Inc. Phone: 414-644-8700
205 Kettle Moraine Drive North Fax: 414-644-6667
Slinger, WI 53086 Telex: 6717062 or 158279420taylor@limbo.Intuitive.Com (Dave Taylor) (10/04/89)
Donald D. Woelz of GRC writes: > Now for the proposal: I think that some kind of feature to do the > equivalent of Ceritifed and Registered mail would be very useful to > indicate, at least to the sender, that his email has gone through. > Certified mail would be a piece of email sent back to the originator > indicating that his mail was indeed appended to the recipients > mailbox. Registered email would be a piece or email sent back to > the originator indicating that the recipient has looked at the > piece of mail. This is an interesting issue that I've actually put a fair amount of thought into, for various companies... with most Unix configurations, Certified mail should be done at the transport level (e.g. "sendmail"), and indeed currently is, if you include the header "Return-Receipt-To: <address>" in your message. Registered mail is a tougher one with the Elm paradigm of "don't touch the mailbox, just read it" because it then becomes tough to record that the user has read the message. (that is, if I read a message from you, then eX)it Elm, should you receive TWO registered-mail-receipts? One for the first time I read it, and one for the time I re-read the message after having exited Elm) The latter is a fairly complex issue, mostly due to the design principle of Elm not actually modifying any of the mailboxes it looks at (where as Berkeley Mail, for example, adds a "Status:" header to each message so that the program can keep track of just this sort of thing... More interestingly, I think, is the issue of how one would keep track of whether receipts have been received for either of the two types of mail. What about, for example, a special feature of the mail system that would keep a tally of all Certified and Registered email that you send, and would then automatically cross-reference and note when the receipts arrive? Then you could have an easy mechanism to query "what messages haven't yet been received/read?" and so on. Other thoughts on this worthy idea? -- Dave Taylor Intuitive Systems Mountain View, California taylor@limbo.intuitive.com or {uunet!}{decwrl,apple}!limbo!taylor
phil@wubios.wustl.edu (J. Philip Miller) (10/05/89)
In article <340@grc.UUCP> don@grc.UUCP (Donald D. Woelz) writes: >Now for the proposal: I think that some kind of feature to do the >equivalent of Ceritifed and Registered mail would be very useful to >indicate, at least to the sender, that his email has gone through. >Certified mail would be a piece of email sent back to the originator >indicating that his mail was indeed appended to the recipients >mailbox. Registered email would be a piece or email sent back to >the originator indicating that the recipient has looked at the >piece of mail. > Both PROFS and RICE/MAIL in the IBM environment attempt to do this. From time to time on the MAILBOOK LISTSERV group on Bitnet, this proposal is brought up again because MAIL does it by inserting a "hidden record" within the body of the mail message rather than by inserting an actual new header. One of the stumbling blocks was gaining agreement among the "header peopple" on a syntax for defining a new header, adding it to RFC822 (the RFC actually acknowledges the possibility for adding a new standard header, although it has never actually been done :-). It seems silly to implement this in ELM in a way which is incompatible with other systems. Your proposal suggests that an acknowledgement be sent (optionally) both at the first time that ELM sees the message and at the first time that a user actually reads the message. This would be fairly easy to implement in ELM, but others would argue that there should be an acknowledgement sent when it is actually placed in your mailbox, not the first time that ELM sees it, That is I want to know when the message has actually arrived (hopefully safely) at the recepient's machine. This requires changes to the MTA, not to ELM and points out the need for standardization before going off and implementing such a scheme. Another area requiring some coordination with the MTA is that most people who have entered into the discussions previously have indicated that they want to be able to specify a particular address where the acknowledgement is sent, rather than automatically back to the from address. If so, then all gateways and other MTA who mangle the from header also need to be educated about the new header. In short, this is an excellent idea. It has proved to be very useful in other MUA systems, but the experience there suggests that for it to work well, there needs to be a standard developed so that (over time at least) all the relevant software gets changed and we all do our work more productively. -phil -- J. Philip Miller, Professor, Division of Biostatistics, Box 8067 Washington University Medical School, St. Louis MO 63110 phil@wubios.WUstl.edu - Internet (314) 362-3617 phil@wubios.wustl - bitnet uunet!wucs1!wubios!phil - UUCP C90562JM@WUVMD - alternate bitnet
scs@itivax.iti.org (Steve Simmons) (10/05/89)
I won't repeat all the pros and cons of return receipts and registered mail (you're welcome :-), just want to add an opinion. The 'real world' of the RFCs isn't likely to define this in our lifetime, so being 'RFC-compliant' is a non-issue. Let's make this an Elm-to-Elm features, with an XElm-Receipt header (or something similar). If other mailers pick it up (Dan Heller?) great. If not, that's fine too -- we can tout it as a reason for using elm over all them inferior mailers. :-) :-) :-) :-) -- + Steve Simmons scs@itivax.iti.org + + Industrial Technology Institute Ann Arbor, MI. + + "Even a dog can shake hands." -- Warren Zevon +
syd@DSI.COM (Syd Weinstein) (10/05/89)
taylor@limbo.Intuitive.Com (Dave Taylor) writes: >This is an interesting issue that I've actually put a fair amount >of thought into, for various companies... with most Unix >configurations, Certified mail should be done at the transport >level (e.g. "sendmail"), and indeed currently is, if you include >the header "Return-Receipt-To: <address>" in your message. Dave is correct, here, but there is one problem, Return-Receipt-To: sends a receipt from every system that handles the message, and in the uucp world, that could be a lot of receipts. It would be nice if the receipt came from the final system only. Now, of course, with SMTP there is no such problem. [....] >The latter is a fairly complex issue, mostly due to the design >principle of Elm not actually modifying any of the mailboxes it >looks at (where as Berkeley Mail, for example, adds a "Status:" >header to each message so that the program can keep track of just >this sort of thing... Dave is a little out of date here, as Elm also adds status headers now and they could be used to handle the 'read/not read' problem. However, if one exits with 'X',then indeed they are not updated, so more than one time the response could be set. Also, I think this problem needs to be solved outside of Elm, in a more universal fashion. What we need is an RFC specifying the new headers and how all conforming MUA's and MTA's are supposed to handle this. A discussion here followed by a general discussion in the RFC process would handle this, but don't expect it to be a quick process, lets just say it won't make Elm 2.3. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
ignatz@chinet.chi.il.us (Dave Ihnat) (10/06/89)
In article <144@limbo.Intuitive.Com> taylor@limbo.Intuitive.Com (Dave Taylor) writes: > >This is an interesting issue that I've actually put a fair amount >of thought into, for various companies... with most Unix >configurations, Certified mail should be done at the transport >level (e.g. "sendmail"), and indeed currently is, if you include >the header "Return-Receipt-To: <address>" in your message. True. However, if it isn't handled by your MTA, then it could be a function of elm, in the same way that you can choose to have either elm or your MTA attempt to resolve addresses now. It would be, I'd think, a configurable feature. >Registered mail is a tougher one with the Elm paradigm of "don't >touch the mailbox, just read it" because it then becomes tough >to record that the user has read the message. (that is, if I >read a message from you, then eX)it Elm, should you receive TWO >registered-mail-receipts? One for the first time I read it, and >one for the time I re-read the message after having exited Elm) > >The latter is a fairly complex issue, mostly due to the design >principle of Elm not actually modifying any of the mailboxes it >looks at (where as Berkeley Mail, for example, adds a "Status:" >header to each message so that the program can keep track of just >this sort of thing... Again, true. I think that, if we DO want to keep "don't touch the mailbox", then we're talking about a status file. In this, you could keep the status and identifying information concerning the mailbox and mail items of interest such as certified and registered mail, high-priority items, etc. Once you've bitten the bullet and decided to keep this, you could add other features, such as alarms for high-priority items that have aged, etc. >More interestingly, I think, is the issue of how one would keep >track of whether receipts have been received for either of the >two types of mail. What about, for example, a special feature >of the mail system that would keep a tally of all Certified and >Registered email that you send, and would then automatically >cross-reference and note when the receipts arrive? Then you >could have an easy mechanism to query "what messages haven't >yet been received/read?" and so on. Again, quite difficult, unless you include the status datafile. Once you have that, then much of this is easy to implement. Aside from the work involved with the design and implementation, the only other problem I'd worry about is synchronization of the status file with the active mailbox or mailboxes; or rather, lack of synchronization due to corruption, system crashes, or the modification of the mailbox(es) by other mail display agents than elm. This, of course, can be overcome--a resynchronization and validation pass will almost certainly have to be done by elm on startup--but it's probably going to noticably add to the startup time, and we'll have to be sure that it's a robust recovery. But I think the benefits of this type of feature are worth it... Dave Ihnat Analysts International Corporation ignatz@homebru.chi.il.us (preferred return address) ignatz@chinet.chi.il.us
david@wubios.wustl.edu (David J. Camp) (10/07/89)
In article <340@grc.UUCP> don@grc.UUCP (Donald D. Woelz) writes: >Now for the proposal: I think that some kind of feature to do the >equivalent of Ceritifed and Registered mail would be very useful to If anyone is serious about implementing this feature, they should become familiar with existing syntax used by other mail packages, such as the Rice Mail package used on .bitnet . That way, mail between the two networks would support this feature. I would be happy to specify details to anyone who needs them. -David- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University (314) 36-23635 Saint Louis, MO 63110 -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University (314) 36-23635 Saint Louis, MO 63110
darrell@urbana.mcd.mot.com (Darrell McIntosh) (10/09/89)
In article <1989Oct5.143914.9060@DSI.COM> syd@DSI.COM writes: >Dave is correct, here, but there is one problem, Return-Receipt-To: >sends a receipt from every system that handles the message, and in the >uucp world, that could be a lot of receipts. It would be nice if >the receipt came from the final system only. Now, of course, with >SMTP there is no such problem. Actually the receipts are sent from the systems that perform the final mail delivery, i.e., the systems that put the mail into the users' mailboxes. Sites that handle the mail along the way to the destination do not send receipts although they should be attaching Received: headers so that you can determine, more or less, the path the mail took to get to its destinations. The receipts typically include all the mail headers but have the body of the mail deleted. -- Darrell McIntosh, Motorola Microcomputer Division, Urbana [IL] Design Center Phone: +1 217 384 8509 Email: darrell@urbana.mcd.mot.com, udc!darrell, uunet!uiucuxc!udc!darrell
peter@ficc.uu.net (Peter da Silva) (10/09/89)
The mail here has a return receipt capability. The extra header is:
Return-receipt-to: username
I don't know how standard this is.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
'U`
Quote: Structured Programming is a discipline -- not a straitjacket.