Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!spool.mu.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.protocols.tcp-ip Subject: Re: Certified SMTP mail Message-ID: Date: 12 Feb 91 21:20:42 GMT References: <9102110842.AA02908@holmenkollen.ifi.uio.no> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 41 In-Reply-To: enag@ifi.uio.no's message of 11 Feb 91 08:42:04 GMT 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-WRLD