I am catching up on some old mail, since I have been traveling too
much again, and I found this very interesting message and I want to
reply to clarify some very fundamental issues in the MTA/UA conceptual
model.
First, the model, like most models, is only an abstraction, which may
or may not ever be fully implemented in any instantiation. There is
no concern about whether the code in any INTERNET MTA or UA, or
co-located MTA/UA pair is actually written with full separation of
functions, and access with a visible and accessible service boundary
between them.
The only thing in this regard that is important is that from the
outside, it should not be detectable that the MTA and UA are not
separate modules.
Beyond this, the abstract model makes it much easier to discuss the
issues, with regard to who has the right (authority) and
responsibility to do or not do certain things. hence we talk about
"messing with the content" requiring "UA level authority", as compared
to "transferring a message according to its recipient address routing
implications" which is clearly an MTA responsibility.
Now, given the usefulness of this abstract model MTA/UA to help us
sort out some issues of responsibility and authority, it would be a
very bad thing if we were forced to write code rigidly match the
model. This is not necessary in order to meet the abstract demands of
the model, so we should not insist on it.
Further, when RFC822/821 were created as a "matched pair", this model
was not yet well articulated, and RFC821/822 do not enjoy having two
separate real envelopes to carry the two separate kinds of
information. There is only the RFC822 headers in which we can place
trace information, and any other kind of MTA-information, like maybe
Return-Path, which is intended to record the SMTP MAIL FROM value from
the last transfer action. There may be other headers that are really
"MTA envelope information", and it might even be useful to identify
these and write an RFC that distinguishes which are MTA and which are
UA, just to end the arguments (which already have consumed too much
time and energy).
Now, lest you think that this is a problem only for RFC821/822, you
should know that the X.400 community has had to recently sort this all
out again. The point is that we (in X.400-land) had to rethink the
whole point about whether implementations had to have visible and
accessible interfaces between the MTA and UA in the case of
co-location on a single system.
The answer turned out to be the same. There is no requirement in the
standards or in any implementor agreements to force such a visible and
accessible interface between such a UA/MTA pair. The only requirement
is that no violations of the model may be visible at the protocol or
user access points of the UA or the MTA.
So, ther eis a general rule, which says that when two layers are
co-located in a box, such that you cannot access the protocol/service
definition boundaries, the only thing that matters is that there are
no detectable errors generated within the box, as visible by tests
performed outside the box.
So, applying the same rule, there is no violation of RFC822/821 by any
internet system that combines them, as long as no violations of
RFC822/821 are visible at the protocol or user access points.
Now, when an MTA (e.g., SENDMAIL) messes up the addresses, this is
visible outside the SENDMAIL system, and thus it can be called a
violation of the standards. Or if it messes up the object encodings
in the body, in ways that are prohibited in RFC822, then it is a clear
violation.
So, I have not been arguing about implementation issues in any of my
comments. I have only been arguing that the abstract model is very
helpful in explaining some things, and that I want our standards to be
clear about who has and does not have authority and responsbility to
mess with the body of an INTERNET message, no matter how the
implementation is done.
Thus, I don't see how the defacto implementation facts of existing
software or future software should be seen as the cause of our
stadards setting process problem, unless our new standards will be
violating the base standards as they are written or may be written in
the future.
Hence, I am very interested in keeping the conceptual service boundary
between the "MTA" and the "UA" in RFC-XXX, YYYY, and ZZZZ.
Best...\Stef