nsb(_at_)thumper(_dot_)bellcore(_dot_)com (Nathaniel Borenstein) writes:
... the nature of the interface between 8-bit and 7-bit mail. I think
this interface will only work right if it is viewed as a gateway
operation, much like the gateways between Internet and Bitnet or
Internet and X.400. This doesn't mean it has to be a *complex* gateway,
but merely that care must be taken, when messages cross the boundaries,
to properly transform them without either losing information or
violating the format standards of the destination system. Is that
notion really a problem?
What a hook you put out there... and how appropriate for some mail I've
been exchanging with John Klensin about my misgivings. I think I'll
say it in public:
----
The way I read the winds, people are starting to converge on a scheme where
the MTA must understand the internal semantics of message bodies and at a
7/8-bit boundary the MTA must do the translation of the message body.
If this impression is wrong, please correct me.
Furthermore, there are 2 possible ways of determining the boundary condition:
1. You can "find out" what an MTA's type is at low cost and in real time
(e.g., a table/DNS lookup) before the SMTP session. Routing and body
protocol translation can be done at any time.
2. During the SMTP session, you "discover" that the remote server is of the
non-native type. Routing and body protocol translation must be done
(or arranged) during the SMTP session.
Method 1 is completely hopeless in a heterogeneous internet. It is
natural only in the situation of N-bit enclaves or islands in a sea of
M-bit MTAs and assuming that N-bit enclaves need not communicate with each
other using pure-N-bit protocols.
Method 2 makes strong assumptions about the design of an MTA, namely that
the SMTP client is supposed to orchestrate rerouting and translation functions.
My MTA isn't intended to work that way, though of course, it can. I consider
it unacceptable for an inter-system protocol to mandate intra-system design
and implementation issues. That is the basic reason I dislike the SMTP
VRFY and EXPN functions, as well as dynamic mid-protocol "discoveries" as would
be the result of the 8-bit SMTP spec. Consequently I believe that the
essential features of all inter-system protocols should be batch-oriented.
[ Forgive the mild hyperbole, I'm trying to emphasize the point. Remember
the context :-) ]
In other words, since the current proposals imply that a gateway MTA:
i. has to do (complicated) message body protocol translation
ii. cannot predict a-priori when it must perform this translation
iii. must be able to handle rejections due to protocol mismatch
then the situation being faced is *exactly* that of introducing an entirely
new protocol universe, and a very demanding one.
Since that is in effect what is being proposed, why not "do it right"?
The emotions evoked in me, someone with a rather vested interest since I'm
maintaining a from-scratch MTA implementation explicitly intended for
complex gateways, is that I *really* *don't* want to go through all the
hassle of robustly conforming to the proposals at hand since the incremental
cost is *just as high as if introducing an entirely new protocol universe*
[ neglecting protocol-specific costs ]. This for a "tweak" to SMTP and to
avoid sensible UA encapsulation.
However, I'd be much more willing to do the work to support a new protocol
that brings with it real long-term benefits instead of patching up a protocol
(SMTP) that has limited potential.
If you mandate that Internet people (especially the guys'n gals in the
trenches who have to maintain the code) do the work required to properly
support nouveau-821/822, then there will be no energy or will left to
add support for any new protocol.
As I understand things (please correct any misunderstandings you detect in
what I wrote), I believe that letting the current proposals go ahead would
be a long-term detriment. That would be a shame.
----
The "new protocol" I'm alluding to would be a generic binary-transparent MTP.
(No, not X.400).
Regards,
rayan