[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: smtp charter (revised)
>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!
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
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
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