Some of the discussion on the improvements to E-mail message format have
centered upon "what mail gateways do" and what the format has to do to
accommodate and/or compensate for these actions. And sometimes, it has
been suggested that for the purposes of the Internet that there is no
point in separating out the concept of MTA from that of Gateway.
The simple definition of an MTA includes the fact that it deals only with
the envelope and leaves the message intact. Since most Internet thingies
mess with the message format, we have discussions about how the things we
use on the Internet are not exactly REAL MTAs. Under that tight
definition, I can't think of many REAL MTAs on the Internet or what you
would use one for.
The closest official internet thingie to a MTA is an agent which transfers
mail and does exactly one thing to the message itself: add one "Received"
line to the top of the message. We could call this an INTERNET MTA (with
the proviso that it isn't really an MTA). These are also rare.
Many of the things we use also do other things to headers, especially
rewrite address fields.
The Internet, which tries to send mail point-to-point has limited use for
REAL MTAs or INTERNET MTAs. The sender's machine and the receiver's
machine can run one, but in that case, the function of the UA can be mixed
with the MTA and only us protocol people will be upset. The only other
use I can think of is for a "designated sender" or for a "designated
receiver" (the latter would be a "mail exchanger"). These are fairly
common, but clearly unnecessary in a lot of situations.
A mail gateway can be thought of as anything that fools with the message
inside the envelope. This is identical to the idea of a UA attached to a
"daemon" such that it takes messages and does things to them and sends
them out again. Since UAs & their associated users can do anything, it is
impossible to outlaw any sort of gateway anyone wants to write. Maybe you
can coin a term "Official Internet-approved Gateway" or even steal the
term gateway, but you can't stamp out UA/daemon things. You can't
separate the concept from other mail-based services like archive servers
or other mail-based servers that haven't even been invented yet. Perhaps
the best thing you can do is publicize good advice.
Real mail gateways, that move mail between networks basically do one of
two things:
(1) Translate features of the message into corresponding features of
the destination-network's e-mail format. This makes the message
identical to messages in the destination-network, so that the
UAs can handle gatewayed messages exactly as if those
messages originated on the destination-network.
(2) Encapsulate & possibly encode the message so that all the information is
retained. This sort of gateway need know nothing about the features
of the message format--which is left up to the UA or to
a clever user and his favorite data-manipulation utilities. In some
sense, the features of the source-network's mail are projected
into the destination-network and the UA is smart about
the conventions of the source-network.
And actually there is a third thing that real mail gateways do:
(3) Make a half-hearted attempt at (1), then do a half-hearted,
attempt at (2) for anything its not programmed to handle.
As an example of (3), imagine a gateway which recodes all the characters
into EBCDIC and wraps any lines which it finds too long to handle. I
suspect that as message formats are made precise and documented, that (1)
will be more practical, but as it is made more complicated there will be a
further tendency towards (3).
I don't really have any conclusions to draw, but just thought I'd lay out
some more characterization of what a gateway-proof message format must
deal with.
My opinion is that UAs MUST be able to deal with recursive encoding. I
realize that this is bad news for UAs and UA writers, but I think both
gateways AND USERS must be able to simply take an entire message, encode
it, and send it on to someone. A user is sitting there with a multipart
message, and needs to send it to someone else through a gateway. What
does the user do to make sure it can go through the gateway? What
procedure can the UA writer invent that safely encodes a message at the
push of a button? Can it handle future extensions or parts or encodings
which aren't understood?
The result of this might be that the user must run extra routines to
decode portions of messages. So be it--I imagine some decoding will have
to be under user control in any case--e.g. if someone sends me a program,
I don't want the action of reading the message to put a runnable copy of
that program anywhere without my explicit permission.
John Wobus
Syracuse University