Subject: smtpupd-09 prohibits uuencode, cron mail, et al.

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Jan 1999 23:28:19 -0000

> the body, if structured, is defined according to MIME

In the real world, there are many widely used non-MIME body structures.
Messages in these formats comply with all existing SMTP standards.

Simple fix, suggested by Philip Hazel: Eliminate all discussion of the
body structure. (Also in section 2.3.9 and section 3.3.)

---Dan

---

From: John C Klensin <[email-masked]>
Date: Sat, 30 Jan 1999 13:46:47 -0500 (Eastern Standard Time)

> body structure. (Also in section 2.3.9 and section 3.3.)

Dan,

For a variety of reasons, I personally agree with your
conclusion here, and would prefer to have the discussion of body
structure taken out, down to the minimum needed to guarantee
that it is possible to prepend timestamp fields.  In particular,
I was once a fan of SEND and SOML for transmission to agents as
well as users, and saw little point in requiring that those
messages contain 822 headers.  

But, back when that text was written the WG (and the IESG)
didn't agree, and their position has some arguments going for it
that didn't apply when we were trying to get SEND/ SOML/ SAML to
work meaningfully.  In particular, the growing tendency to use
8BIT transport extensions and the interactions with
"downgrading" and other types of recoding argue pretty
persuasively for MIME.

We got to where we are today via a slightly strange route.  In
the latter days of the SMTP extension work, and the early days
of the WG, we seemed to be heading toward a consensus that we
should have what I'll call a standard for "contemporary email",
which would imply a strong preference for EHLO and a requirement
for MIME.  A significant fraction of the EHLO-based extensions
really do assume MIME, and making the requirement general seemed
to fall well within the desire to tighten things in ways that
improved infrastructure robustness (I know you don't agree with
that trend, but it is a separate issue).  

Clients and servers who didn't want to use EHLO (or MIME) would
just stick with 821/974/1123 and go merrily on their way.  More
recently, with considerable influence from you and accumulating
experience with what is necessary to deal with "old" servers
(maybe even "broken" ones), we've shifted directions and relaxed
the "send EHLO" requirement.  If it is what the WG wants done, I
can remove the MIME-specifying text.  But I would appreciate
recommendations of suggested replacement text, as things like
transfer-encoding downgrading, which has been defined as an MTA
function clearly require that MIME come in and go out.

    john