smart@manta.mel.dit.csiro.au (Robert Smart) (07/20/90)
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:<x@y.z>
250 x@y.z ok
RWRA To:<a@b.c>
[RWRA means RCPT with Read Acknowledge]
500 Command unrecognized
RCPT To:<a@b.c>
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 <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz.au!smart>Makey@Logicon.COM (Jeff Makey) (07/21/90)
In article <1990Jul20.122658.23729@mel.dit.csiro.au> smart@manta.mel.dit.csiro.au (Robert Smart) writes: > 2) Upgrade the RFC standards. A user agent with the desired features can easily and properly be implemented as a layer on top of RFC822/SMTP. There is no need to change that which is not broken. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
tep@tots.UUCP (Tom Perrine) (07/21/90)
I couldn't agree more about the lack of progress in SMTP protocol enhancements to handle such things as return-receipt, multi-media mail, etc. I used Multics systems in the mid 70s which had the return-receipt feature, which could of course be disabled by the recipient. Encryption standards and multi-media standards are appearing. I know of RFC1040 (Privacy Enhancements for Internet Electronic Mail) and RFC1049 (A Content-type header field for Internet Messages), but I know of *no* fielded systems that support either. I agree that there is no "official" UA <-> UA protocol, other than, perhaps, that information which is encoded in the header fields. You might want to check out any of the following newsgroups: comp.mail.headers Gatewayed from the Internet header-people list. comp.mail.mh The UCI version of the Rand Message Handling system. comp.mail.misc General discussions about computer mail. comp.mail.multi-media Multimedia Mail. comp.protocols.iso.x400 X400 mail protocol discussions. (Moderated) comp.protocols.iso.x400.gateway X400 mail gateway discussions. (Moderated) I worked on designing some extenstions to SMTP for use over dial-lines, but never took it any further. I like the "RWRA" SMTP extension, but I think most limitiations for multi-media are in the UA side of things. Perhaps we need to take this discussion to one of the above newsgroups, or start a new mailing list, perhaps mail-modernization or somesuch? Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: nosc!hamachi!tots!tep Tactical and Training Systems Division |-or- sun!suntan!tots!tep San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
Craig_Everhart@TRANSARC.COM (07/23/90)
For years I've been using an RFC{821,822}-compliant Internet mail system
that does almost all of what you suggest.
Check out RFC 1049 and its commentators.
Get yourself an Andrew source distribution from the X.V11R4
distribution. There's a mail system that supports automatic
confirmation requests from users, among other things. Its design
sidesteps privacy issues, since return-receipt notices go out only after
explicit confirmation with the receiving human user, and it's understood
that you don't get a NAK from any transport agent.
The Andrew mail stuff uses altered content-type information to embed any
ATK (Andrew ToolKit) object, presently including raster and line
graphics, line animations, styled and marked-up text, simple other-file
references, and so forth.
Soapbox aside, I think there's a lot of current work on improving e-mail
services (PEM, for example) that you're simply ignoring.
Craigtep@tots.UUCP (Tom Perrine) (07/24/90)
In article <QaelKR30BwwOAC9N19@transarc.com> Craig_Everhart@TRANSARC.COM writes: >For years I've been using an RFC{821,822}-compliant Internet mail system >that does almost all of what you suggest. > >Check out RFC 1049 and its commentators. > >Get yourself an Andrew source distribution from the X.V11R4 >distribution. There's a mail system that supports automatic >confirmation requests from users, among other things. Its design >sidesteps privacy issues, since return-receipt notices go out only after >explicit confirmation with the receiving human user, and it's understood >that you don't get a NAK from any transport agent. > >The Andrew mail stuff uses altered content-type information to embed any >ATK (Andrew ToolKit) object, presently including raster and line >graphics, line animations, styled and marked-up text, simple other-file >references, and so forth. > >Soapbox aside, I think there's a lot of current work on improving e-mail >services (PEM, for example) that you're simply ignoring. > > Craig Well, its a little tough for some of us to track every system out there :-) Are any of the Andrew "extensions" documented in RFCs? What I'm getting at is that the Andrew mail system, even though it may be widely/freely available, may not be an *interoperable* mail system, until the extensions and conventions it uses are documented in some place other than the source code (or accompanying system documentation). Don't get me wrong! It sounds *wonderful*, but I can't run Andrew here, but I *would* like to hack some extensions into Emacs RMAIL and mail modes. Specifically I would like to generate (and parse) the headers(?) that I need for return-receipt and any other non-graphical functionality I can find. Sorry to carrty on with this here, but I think that this point goes beyond just mail issues. Tom Perrine (tep) |Internet: tep@tots.Logicon.COM Logicon |UUCP: nosc!hamachi!tots!tep Tactical and Training Systems Division |-or- sun!suntan!tots!tep San Diego CA |GENIE: T.PERRINE "Harried: with preschoolers" |+1 619 455 1330 Home of the _Tower Operator Training System_ as seen in the SunTech Journal.
smart@mel.dit.csiro.au (Robert Smart) (07/25/90)
In article <159@tots.UUCP> tep@tots.Logicon.COM (Tom Perrine) writes: > >Perhaps we need to take this discussion to one of the above >newsgroups, or start a new mailing list, perhaps mail-modernization or >somesuch? > Comp.mail seems to be unused. It would be nice if people working on the problem would let us hoi polloi know where we are headed. This is such a complicated and multi-faceted problem that it can only be solved correctly on the basis of wide public discussion. Three or ten or even thirty experts in a back room are not going to understand all the ramifications. I would like to see wide discussion before we get to draft RFCs. I apologise for being sexist. Come on gals as well. I apologise for suggesting that X.400 designers are not sensible. I meant that they weeren't sensible to the need for backward compatibility with existing Internet mail systems. Even this is not true. Jacob Palme is the only one that posts descriptions of X.400 meetings to the network and those postings show a lot of common sense and good will. I apologise for posting to the wrong newsgroup. Followups are directed to comp.mail. Mail is important to the general workings of a TCP/IP network and I am concerned that the people who care about the TCP/IP suite have written SMTP/RFC822 off prematurely. I think that enhancing SMTP will improve interoperability with X.400 mail and simultaneously provide a backstop in case X.400 is not as successful as many obviously expect. I apologise for ignoring RFC1049 which is a relevant attempt to move things in the right direction. Bob Smart <smart@mel.dit.csiro.au> or <uunet!munnari!ditmela.oz!smart>