mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) (02/15/91)
I dropped off a couple of messages supporting a "return receipt" registration feature for SMTP a while ago. In thinking about the issue some more, and reviewing people's worries about excess flurries of acknowledgements being generated by mailers along the line, it has occurred to me that the return message should not be part of SMTP but rather be part of the user's mail interface. The only thing that SMTP should support is some sort of header line that the mail application can use to determine whether or not a return message should be sent when the user displays (ok, we can't tell whether it's actually READ or not) the received message. I think this approach is more logical; SMTP almost certainly should not get involved in sending "I got it" messages anywhere on its own. Thoughts? BTW, I still think the capability is needed -- it just needs to be identified in the right category. Mark
dd26+@andrew.cmu.edu (Douglas F. DeJulio) (02/16/91)
mark@TELESYS.NCSC.NAVY.MIL (Mark L. Williams) writes: > In thinking about the issue some more, and reviewing people's worries > about excess flurries of acknowledgements being generated by mailers > along the line, it has occurred to me that the return message should > not be part of SMTP but rather be part of the user's mail interface. Two mail interfaces that currently provide this feature are the Andrew Message System and NeXT Mail. Both provide multimedia mail as well. AMS is somewhat better IMHO (and I think it's free), but you need the Andrew Tool Kit to get the multimedia features. -- Doug DeJulio ddj@zardoz.club.cc.cmu.edu (NeXT) dd26+@andrew.cmu.edu (AMS/ATK)
enag@IFI.UIO.NO (Erik Naggum, the Internet Purist) (02/16/91)
In article <9102141624.AA01275@telesys.ncsc.navy.mil>, Mark L. Williams writes: > I dropped off a couple of messages supporting a "return receipt" > registration feature for SMTP a while ago. In thinking about the > issue some more, and reviewing people's worries about excess > flurries of acknowledgements being generated by mailers along the > line, it has occurred to me that the return message should not be > part of SMTP but rather be part of the user's mail interface. The > only thing that SMTP should support is some sort of header line that > the mail application can use to determine whether or not a return > message should be sent when the user displays (ok, we can't tell > whether it's actually READ or not) the received message. I think > this approach is more logical; SMTP almost certainly should not get > involved in sending "I got it" messages anywhere on its own. Mark, SMTP is a protocol. Simple Mail Transfer Protocol. It's not a piece of software. It can't do anything on its own. Neither, might I add, has there ever been any discussion of adding some feature to SMTP to make it do anything differently. You seem to ignore the problems that relate to the semantics of a return receipt, and that this semantics is not supported by the network technology (model) involved. For instance, the "excess acknowledgements" is a real problem, not because you implement it at some layer N, but because ACKs may not get to their intended recipient. That has nothing whatsoever to do with which layer or which program or whatever actually does the ACK'ing. -- [Erik Naggum] <enag@ifi.uio.no> Naggum Software, Oslo, Norway <erik@naggum.uu.no>