Stef writes, as part of a message that I found very helpful...
Now, where I think John and I might disagree, is that I believe that
RFC821/822 come incredibly close in their parallels to X.400 P1/P2 as
abstract functional service definitions.
As I am beginning to think is usual, we don't disagree by much. In
retrospect at least, my comments in that direction were based on four
things:
(1) The RFC821/MTA function tampers with the "message format" headers,
at least to the extent of stuffing in Received fields at relays. IMHO,
in a clearly separated MTA/UA model, it would stamp these on the bakc of
the envelope somehow. As a corollary, there has been a great deal of
discussion in the RFC-XXXX context about non-gateway MTAs looking at,
evaluating, and tampering with headers and message content. I suggest
that, in the presence of a strong separation model and general
understanding of, and agreement about, it, much of that discussion would
be ruled out of order as obscene and an offense to public morality :-).
But, as I am sure you and I (at least) agree, that is precisely why
discussion and consideration of the character of the abstract models we
are trying to work from is critically important.
(2) The fact that I see the local-UA -> remote-MTA operational form as
introducing behavior changes that intrude on the model, especially if it
is combined with a local MTA in a "try UA -> remote-MTA once, then spool
to local MTA" implementation. We agree that, if this is done perfectly
and transparently, it is a local problem that makes no different.
However, to cite one--necessarily trivial--example, the local MTA in
many of those implementations is treated as a relay, such the that
operation becomes
(try once): originating-UA -> remote-MTA
(then): originating-UA -> relay-MTA -> remote-MTA
where the relay-MTA just happens to be local to the originator. These
two models produce different Received fields in the delivered message,
and I suggest that is an externally-visible (and therefore protocol-
visible) difference, however trivial.
(3) My more complex layering is an attempt to create an abstract model
of mail implementations, rather than of mail transport and delivery.
Those two sets of models are consistent but serve slightly different
purposes, so no disagreement there.
(4) Finally, I was backing into what you so precisely and eloquently
stated as
> "If SENDMAIL DOES IT, IT MUST BE AN MTA FUNCTION!"
and its unfortunate, but equally false relative
"IF SENDMAIL DOES IT, IT MUST BE CORRECT AND CONSISTENT WITH THE
PROTOCOLS"
Regardless of the inherent qualities and virtues of sendmail, it is
altogether too easy to configure it in ways that make that statement
false. Indeed, there seems to be a thriving cottage industry in such
unfortunate configurations. :-)
I learned a lot from other things in your note. Thanks.
--john