Tom Moore writes, in part...
Joe User id provided with a UA connected to a mail system. Joe wants to send a
message to a group of addreses. The message includes some discussion, a
binary program, and the supporting documentation. Joe wants the UA to
allow for steps such as:
...
1. Compose discussion text.
2. Attach binary program.
3. Attach supporting documentation.
4. Provide addresses.
5. Send it.
Joe User should not have to know what type of mail systems or gateways this
will go through. Joe should not have to send the message in different
ways to different addresses. Joe does have a problem with the recipient's
UA being unable to handle the message.
OK. This has the makings of an unfortunate situation. You know that
already. Joe is going to get into some situations in which the only
answer is that "life is tough sometimes". Protocols are not going to
solve the problem, and, if the problem is that the remote UA hasn't
implemented a protocol [stack] sufficient to do something useful with
what Joe wants to send, then he can hunt for "a different UA, a
different mail system, or a different administrator" until various warm
places freeze over without being able to get his traffic through. What
do you tell him today?
The question is thus "How do we define a capable, user friendly environment
in which 7-bit and 8-bit UAs and MTAs can coexist?". We must allow
for migration but we cannot abandon the old or the new.
Wrong question, actually. The answer, for you and for Joe, is "what
do you think you need an 8-bit MTA (or UA) for?".
Now, it took us a very good chunk of the winter to arrive at that
answer, but let me try summarizing the pivotal issues as:
-- The bandwidth losses associated with using 7 bit transport as
compared to 8 bit transport are down there in the noise when all of the
other overhead factors of sending any electronic mail, especially highly
structured mail such as you have posited for Joe are considered.
-- There are going to be 7-bit-only transport systems around for A
Long Time, probably until SMTP rusts away and dies and we are all using
X.400.
So...
I want to build a UA that allows Joe to send his message. Joe is currently
connected to a 7-bit mail system. Joe's UA (not Joe himself) must be
aware of this and provide proper transfer encoding for those parts of the
message that are not acceptable to the 7-bit network. It must put the message
in the "native form" of the mail system to which it is connected.
If Joe, and Joe's mail system, are relatively isolated -- i.e., he
is not part of an "enclave" that has decided to adopt 8 bit transport--
then you should build, and he should run, a 7 bit UA that implements
RFC-XXXX and pretends that it has never heard of 8 bit transport. This
would be true even if he were attached to an 8 bit capable network
(e.g., the Internet) or if he were communicating with an 8 bit capable
MTA, even.
The ONLY time that it is sensible to get involved with 8 bit
transport is if you know that the destination can handle it and that all
of the paths between you and the destinate can too. Otherwise, you
forget it.
If Joe's message is leaving his mail system, it passes through a gateway.
The gateway cannot reasonably determine whether this message will be delivered
to a UA in this next mail system or gatewayed further.
Ok, but I'm not quite sure I understand the reason for all of these
mail gateways.
It must therefore
put the message in the "native form" for this mail system.
Again, I may be missing the point here. If this is something that
needs to happen, it needed to happen long before anyone said "RFC-XXXX"
and, presumably, at a time when, if Joe came to you with those
requirements, you could provide anything more than sympathy.
From my point
of view, it must therefore parse the message body and add or remove
any transfer
encoding that is or is not appropriate.
I don't think so. The mail left Joe's system in 7 bit, since it
doesn't do 8 bit transport. So no 8->7 transformations are needed, and
there is never a gateway requirement for a 7->8 transformation unless
you are switching character sets.
No parsing so far.
If you *are* switching character sets at the gateway (e.g., ASCII->
EBCDIC) then you need to understand the implications of the transfer
encodings. And that means parsing to find them. But the encodings that
RFC-XXXX defines for the 7bit transport world are intended to be safe
under normal character set transformations. If they are not, then that
is an issue that should be identified immediately.
You would have an even more serious gateway problem if you used a
message format model that wasn't basically a variation on RFC822. Then
you might have to do all sorts of parsing and interpretation. But you
do without RFC-XXXX, too: the difference is that now the amount of
information and specificity available is such as to raise the odds that
you can get it right. We hope. Again, if that is wrong, I think all of
us need to see where and why.
I agree that this is dangerous
ground and the possibility for errors is great but then nobody said writing
a gateway was easy.
OK. No disagreement here, only some occasional desire to give
senders a way to protect themselves from converters who get it wrong.
The point in all of this is that a UA should be responsible for putting
a message in the format required by the mail system to which it is attached.
The MTAs in said mail system are responsible for delivering the message
within this mail system.
Yep. No disagreement with this either.
A gateway then becomes a MTA or pair of MTAs
connected between two different mail systems.
Nor here, although it is possible that we might disagree about what
constitutes "different mail system".
Joe User is not
going to buy "You can't get there from here".
Speaking as someone who spends a lot of time with info-nets (one of
the places "how to you get there from here" gets worked out), Joe User
has had years to get used to this, and probably has years more to look
forward to. I think things are getting better. I certainly don't want
to do anything that will make them worse. But life is hard, and
sometimes that is the answer.
Providing for 8-bit <-> 7-bit gateways is only part of the problem. I'm
looking at gatewaying mail systems that don't even resemble RFC822 but
have the functionality to do what Joe User wants to do.
RFC-XXXX goes a long way toward providing a standard for implementing
functionality that already exists in many proprietary mail systems. To
cripple it by not allowing a gateway to do message format conversions
does not seem a wise thing to do. Gateways will still exist there will just
be no standard for them. To burden each UA with the tasks that should be
taken care of at a properly implemented gateway also seems unwise.
I think we have a small misunderstanding here as a result of a split
discussion. Again, let me try to review six months or more of history
in a few sentences...
What started as a combined "fix and enhance mail" effort turned,
gradually, into two parallel efforts. One of them has concentrated on
mail format. It produced RFC-XXXX and some other bits and pieces, but
did not get heavily involved in gateway/translation issues. The other
has concentrated on transport and mail system architecture, which
includes some of the "gateway" issues. It has produced something called
RFC-ZZZZ and an architecture document, on which there has been less
convergence as yet, maybe, than on RFC-XXXX. There are two separate
mailing lists.
When the gateway discussion started on this list, some of us who
have been active in the other effort, but following both, injected
arguments here that are a little out of context (maybe a lot out of
context) relative to RFC-XXXX and this list.
There is a perception that there has been an intra-Internet problem
of hosts declaring themselves to be gateways and then messing things up
to suit some peculiar ideas of aesthetics. All of the discussion you
have encountered has had to do with intra-Internet hosts/relays/
whatever, i.e., those which are running 822 (or 822 extended) over 821
(or 821 extended) over TCP. If you have a system that connects two
mail environments one of which is using a different protocol stack, then
that system is a *real* Gateway, and nothing that has been said is
intended to prevent its carrying out whatever conversions are needed.
What we are trying to do is to specify conversion models that avoid
the need to people to go into the [pseudo]gateway business Within The
Internet. And the goal is, precisely, to increase the likelihood of
interoperability, with "interoperability" defined, not merely as "the
bits get through more or less unchanged" but in "zero information loss"
terms.
--john