Making secret SMTP changes

[KLENSIN@xxxxxxxxxxxxxxx (John C Klensin)]

On 20 Feb 91 21:50:54 PST, Paul A Vixie <vixie@pa.dec.com> wrote...

>I've only touched the surface of the problem.  I'll skip straight to the
>conclusion: don't change SMTP unless you either pick a different port, or
>add backward-compatible negotiation of any changes -- especially if those
>changes are otherwise subtle.
>...
>We're talking about a new mail transport protocol here.  It can look a 
>whole lot like SMTP, but it is not SMTP (note, I said "not").  
  I agree with this.  And most of the rest of Paul's argument.
However, I draw an inference from it that he might not agree with!
There are lots and lots of systems out there that are passing mail that
is more or less RFC822 complaint into the Internet for SMTP transport.
Because RFC822 is so flexible, while some of these things are
"creative", barring on the bizarre, they are valid today.
  No change that we make should invalidate anything that is now valid.
No change that we make should cause the munging, folding, stapling, of
mutilating of anything that now validly passes through the system (this
provision does not apply to the "Prime plan", sending 8bit mail today
is invalid, the only question is how severe the penalty should be for
breaking the rules).
  Unfortunately, the present RFC821 implies, in essence, the present
RFC822.  If significant changes are made in RFC822 to add new fields
with specific meaning and then to incorporate structure or "odd things"
in messages, then something, somewhere, will break.
  My version of Paul's conclusion is...
 ... If you are going to do something radical to the mail body or
format such that its bit patterns or structure are to be given a
special interpretation, then...
  (a) Either define this as a new service on a new port (my personal
preference is the X.400 one at that point)... or...
  (b) Change SMTP, somehow, to indicate that the message body isn't in
RFC822 format (RFC821 assumes that it is, and references RFC822
explicitly at least once, the discussion about adding, changing, and
modifying headers in RFC1123 certainly assumes that what RFC821 is
transporting is RFC822) so that a receiver that is not prepared to deal
with the "new stuff" can adopt a plan.  If all such messages are
rejected, we are really no worse off than we are today.
   
Now, I wish we could do the second without modifying RFC821-- by
assuming that we can design some set of fields or conventions into
RFC822 that won't break something, somewhere.  But the only way to do
that would be to use some form that is prohibited in the RFC822 text
today.  RFC822 prohibits very little, although one might seek syntax
characteristics that would cause any existing RFC822 handler (UA or
otherwise) to reject the message unless it understood it.  But I'd
guess that, in the interests of robustness, someone is accepting almost
anything that one could come up with.

So, while Paul (and others) have said that we have to change RFC822
whether we change RFC821 or not (and I agree), I think one also has to
change RFC821 whether we change RFC822 or not.  One could, in
principle, change RFC821 only by, e.g., making envelope provision for a
different character set, then making no RFC822 changes at all.  That
would mean no structure, no non-ASCII in the header, etc.  I don't make
that as a suggestion.

    ---john
p.s. Greg, please consider this my contribution for March on the
subject of "can we do all this stuff without changing SMTP?"