Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!rutgers!usc!samsung!munnari.oz.au!mel.dit.csiro.au!smart From: smart@manta.mel.dit.csiro.au (Robert Smart) Newsgroups: comp.protocols.tcp-ip Subject: Come on guys, we've got to improve e-mail Message-ID: <1990Jul20.122658.23729@mel.dit.csiro.au> Date: 20 Jul 90 12:26:58 GMT Sender: smart@mel.dit.csiro.au (Robert Smart) Organization: CSIRO DIT (Melb.) Lines: 112 Some time in the later 70s I installed a mail system from NIH on a DECsystem-10. It included all sorts of wonderful things: you could tell if mail you had sent had been read, and you could recall mail if it hadn't been read. It had the advantage of being a standalone system mail package. [My boss got me to rip it out: electronic mail was not a suitable activity for computers!]. The fact is that we haven't made a lot of progress. Before the flood starts again on the desirability of the sender knowing if the recipient has read a message: When a mail message goes through a gateway to a mail system that does not support read-receipt a message will go back to the sender saying "mail has parsed to an MTA or UA that will not give a read receipt". If the user chooses to configure his user agent to not give read receipts then the sender will get the same message. You can conceal your activities as much as you like. To make mail work properly there has to be a User Agent to User Agent protocol. The user should be able to look at the mail he has sent and see which items have been read. We are trying to use mail to build protocols between people and the picture currently looks like this: human - - - - - - - human | | user-agent user-agent | | MTA - - - - - - - - MTA | | etc The lack of a user-agent to user-agent protocol limits the sort of protocols that humans can build with this tool. The options are protocols of the "I hope you get this (but don't much care)" type and ones where the humans have to try to do by hand things that the UA could do for them (e.g. say "Please let me know when you've read this"). Mail can disappear for a variety of reasons: disk crashes, software problems or because the recipient doesn't check his mail box. The effect of this is twofold: some rely on e-mail to a dangerous extent; and most look for other mechanisms for important communication. The second thing we need to do is allow mail messages to contain non-text information: graphics and sound in a standard form; and attached files which will only be meaningful to the sender and recipient systems but which intermediate systems will allow to pass. Minor things that would be nice include encryption and unforgeable signatures. There are two ways to go: 1) Get X.400 working. 2) Upgrade the RFC standards. There are problems with X.400. Does it cover the ground? Does it in fact allow me to send my Macwrite document to another Mac? The protocol has so many options that the chances of frequent interoperability seem slight. Also X.400 is just the bones of a mail system. I have yet to see a convincing description of how it will be administered. Even when it works it seems almost impossible to make it user friendly. And when it goes wrong it is a major headache. I have configured a few X.400 systems but none recently. Perhaps all this is changing? Conversely I really like RFC822 and SMTP. When things go wrong you can poke you head in and have a look and easily understand what is going on. It is really not hard to extend the RFCs to make a proper mail system. As George Michaelson pointed out a while ago: all we need is a few extra optional headers, allow lines starting with a "." in the body of the text to introduce sections of binary data in btoa format: .sound ...junky looking stuff... .end sound Or something like that. SMTP can handle the Telnet equivalent of will/won't do/don't by just issuing new commands and seeing if the receiver understands them. MAIL From: 250 x@y.z ok RWRA To: [RWRA means RCPT with Read Acknowledge] 500 Command unrecognized RCPT To: 250 a@b.c ok DATA ...etc Since the receiving MTA didn't know about read-return requirements the sending MTA can no longer guarantee that a read-return will come back, and so will send back a neutral acknowledgement at this point. Though the final user agent may actually obey the Read-acknowledge: header in the message. ------------------------------------------------------------------- So what should we do, 1 or 2? Well, this is the age of competition (ask Mikhail Gorbachev) so lets do both, and may the best solution win. Since X.400 is out of the control of sensible people, it is important that the extensions to SMTP/RFC822 be done in such a way as to maximize interoperability with X.400. We want gateways where sound and pictures and attached files if possible will go across. Alternatively if we are definitely going X.400 then I would like to see a description of how we are going to administer the monster. Bob Smart or