Re: comments on the SMTP session protocol

["Ned Freed, Postmaster" <NED@xxxxxxxxxxxxxxxxxxxx>]

Robert Ullmann writes:

> I think there are a number of aspects of SMTP that have contributed
> to its success, but are poorly understood by most users and
> implementors.

> ...

> This does not necessitate changes to the MTAs (Mail Transfer Agents,
> another ISOmorphism :-). This is crucial in my opinion: we aren't
> going to get any MTA change rolled out anytime in the 1990's to
> anything approaching universality; and the MTA should not care (read
> "MUST NOT interfere with") what is being sent anyway.

Yes! Any change made in all this needs to be transparent to existing SMTP
implementations. They may not know what to do with the new material they are
given, but they should be able to pass it on to the next guy that *does*
know without any trouble. Adhering to this rule means that line lengths cannot
be extended directly, but some encoding can be applied that has the effect
of extending the line length, for those sites that understand the encoding.
BITNET already does this in some BSMTP encoding by placing a major cookie
character in the last available column. I'm not advocating this exact
approach, but it does work.

If changes made here are not transparent to existing SMTP implementations,
I agree that there's little chance of them being widely adopted.

Thus, however tempting it is to extend the HELO command, or add new commands
to the SMTP dialogue, or add new interpretations of the character following
a single dot at the end of the DATA segement, these things should be avoided
because they necessitate too many changes to existing implementations.

In fact, what we're really talking about extending here should be RFC822, not
RFC821.

While I don't especially like RFC1154 because of its use of line counting
(which doesn't survive line wrapping mailers very well -- I prefer RFC934
conventions), I'd much rather see it used than extend SMTP.

> The only useful change I can see making to the MTAs (and to the
> definition of the SPDUs) is to define the character code used as
> ISO8859/1 aka ASCII-8. This will not take as long to roll out: some
> implementations are "compliant" already, while others are trivial to
> fix. ("sendmail" can be fixed by the simple deletion of two lines of
> code.) After all: why clear the "high" bit if you don't have to?

Agreed. This is the right thing to do. It is pretty easy to convert the various
national and vendor-specific character sets to ISO8859, and standardizing on
ISO8859 as a common-denominator on-wire character set makes a lot of sense.
Note that ISO8859 includes 7-bit ASCII as a subset; it would not be appropriate
to use it if it did not.

> This has already been done by some vendors, and has been proven to
> NOT cause interoperability problems. Messages that go through a 7-bit
> mailer get the bit cleared, but get delivered. After a while, such
> mailers will be viewed as broken.

My experience indicates that this is certainly true of PMDF. Removing code to
clear the high bit was requested by various European sites and has caused no
problems that I know of. I also find that a lot of sites either have vendors
that have implemented these changes, or they've hacked them in themselves.

> Encodings that do a complete transform of the input object (uuencode,
> btoa, hex, FS, LZJU90 (see another future message ;-)) produce a 6 or
> 7 bit encoding known to survive various gates and conversions, and
> thus will survive such "broken" mailers.

RFC1113 offers another encoding, but the better of these encodings all share
the basic concept of stuffing 3 8 bit characters of input into 4 6 bit
characters of output. The only minor differences are in the output character
set and the handling of trailing material (because of the 3x chunking implied
by the input processing). Since they are all pretty much equivalent, I don't
really care which ones are eventually used. RFC1113 has the advantage of being
nicely written up already, but that's about it.

> Rob Ullmann

				Ned Freed