Re: smtp charter (revised)

[John C Klensin <KLENSIN@xxxxxxxxxxxxxxx>]

>Well John, let me restate my position to see if we are not more in
>agreement than we appear to be. I will admit to not being clear in
>what I tried to say.  I hope that I am clear enough in this message.
   I suspect that we really are--not complete, but close.  I hope so.

>I am mostly trying to avoid the wretched solution!
  Concur.
  Let me try to restate a close variation on your position that I can, 
and do, agree with...
  The architects who surround me would claim that, if one needs fire 
protection between one room and another, there are at least two 
possibilities.  One is a firewall, which is an object that one goes 
around, but is not going to go through.  The other is a fire-door, which 
may be set into a firewall, but is designed to provide passage under 
normal circumstances, while stopping flames--possibly after some 
heavy-duty opening actions, alarms, etc.  Fire-doors, because they are 
designed to open, are inherently more flame-leaky than properly 
constructed firewalls although how much is a function of quality of 
construction and materials.  And the more firedoors you put in, the 
greater the odds that some idiot will have decided to bend the rules and
wedge one open with a stick at the time the fire comes (Murphy's law 
applies).  Consequently, there are circumstances in which building codes 
require solid walls (no doors) and others in which doors are permitted 
only if the become obnoxious if opened or wedged open.

  The "wretched solution" involves hiding gateway functions -- a 
firedoor -- in every receiving MTA, including relay ones.  Hiding 
firedoor functions in the existing SMTP protocol is very complex, prone 
to trouble, and probably not very good at preventing fires.  OK, we 
agree that is a bad plan.

  I think there are two ways out of that bad plan.  Without repeating, 
for the 10,000th time, the details, they are:
  (a) Build the Great Wall of China in miniature (a lovely firewall with 
all that masonry) by forcing all 8-bit transmission onto another port 
and constructing some (still-undefined) ritual involving sending 
messages to selected gateway/firedoors at which they can be converted to 
the other model (protocol, ports, etc.) if needed.  Note that this wall, 
of necessity, contains gateways/firedoors at some selected intervals.
         ("your" proposal, more or less)
  (b) Build a firewall *within* the SMTP environment in which 8-bit 
messages can neither be confused with, nor converted to, 7-bit ones (or 
vice versa) as part of the transport mechanism.  No gateways, or gateway 
functions, at all.  Anywhere.
          ("my" proposal, more or less)

Now, if you want fire protection, I suggest that (b), done well, has
better fireproofing properties than (a), simply because there are no 
fire-doors -- no gateways -- to implement improperly or try to outsmart. 
In any event, if (b) can be done properly, it is no worse than (a).  It 
also has several significant practical advantages, most of which pivot 
on *not* having to figure out such issues as how to address mail to get 
to one protocol or the other (an issue that reaches clear down to the 
UAs and user interfaces) and how to request gateway services for 
conversion.  I'd rather keep these things invisible.  IMHO, (b) also has
significant potential for getting the "ignore the rules and send 8 bits"
community to convert and thereby mend their ways, while I think there is
evidence that (a) would simply be ignored by them.  And I think (b) can 
be deployed very quickly where it is important (everyone else can stay 
safely on the 7-bit side of the wall).

For the record, we agree about everything else--the impact of new port 
numbers, the fact that, if we could get anyone to use a new port, 
defining it as "SMTP but 8 bit transport, with no other changes" would 
be plausible, and about the X.400(84) / X.400(88) relationship.

And a principle that is substantially identical to this...
>  I would much prefer to just do the
>8-bit<->7-bit conversion in my own UA or at my own UA/MTA interface,
>to get it right, than to trust random stray MTAs wherever they are, to
>do it right.  (I am a long standing end-to-end advocate!  If you want
>it always done right, do it at the end points!)
 ... has guided everything I've proposed in the 8 bit transport area 
since this list got started.  As far as I'm concerned, a transport agent 
should have exactly two options wrt a piece of mail: forwarding it as 
specified and returning it.  Transforming, bending, folding, stapling, 
mutilation, and *any* operation other than sneaking in a Received header 
(and, if we were doing this from scratch, I'd want *that* information in 
the envelope so the MTA didn't need to know about message formats) 
should be outside the MTA's province.

>Actually, my FIRST choice is doing it in the confines of my own
>controlled workspace with the 8-bit<->7-bit conversion being done in
>my own UA, or in my UA-attached MTA (but this is an IETF-SMTP
>discussion).
  Mine, too.  And this is the only thing I'm willing to propose.  I 
consider even your second choice to be pretty close to unacceptable due 
to the amount of intelligence that would have to be built into such a 
gateway.  Indeed, if I had a second choice, it would be to define a 
protocol -- and new port -- for a highly specialized SERVER that a UA, 
or first-receipt MTA could send an 8-bit message to and get a 7-bit 
message back.  We wouldn't need a lot of such servers on the network and 
they could be quite complicated and carefully maintained if necessary.  
One could even contemplate models for several of them passing a message 
back and forth looking for one that could convert it, and models for 
updating them every time ECMA registered a new character set, or 10646 
was revised, or RFC-XXXX was updated to support a new content type.  
These are functions I'd prefer to keep out of mail agents, even if they 
were clearly and separately identified as "mail gateways".
  I think such a server would be a very interesting research activity.  
In your model or mine, it would be called upon by something in, or 
acting for, the sending UA to perform a discretionary conversion.  If I 
didn't like what it did, I could not call it--no automatic 
mail-mangling. 

So, as Dave has pointed out, our objectives and most of our reasoning
are the same.   Because I think an actual firewall, with no firedoors, 
can be built into SMTP (current port) and because I am worried about the 
impact of deliberate nonconformance and believe that keeping this within
SMTP is more likely to sweep the non-conforming and questionably-
conforming implementations up than a "new port" model, I'm trying to 
investigate that option.  I expect you will see a specific proposal next 
week.  Maybe you will like it.  Or maybe you will find so many 
engineering impossibilities in it that we can both agree that "separate 
port" is the only remaining reasonable alternative (other than, of 
course, "7 bits forever").  I'm willing to stipulate that is possible.  
I'd like you to wait a few days for a specific proposal to see if I/we 
can justify my claim that a firewall can be built across (or along) the
existing terrain. 
     --john
-------