Although I'm pretty much in the MTA == Postoffice functions camp, the
argument Nat makes about the value of change can't be dismissed trivially.
So, let me take a stab at defining our abstract MTA and see where it leads.
The function of an (E-)mail system is to carry messages from one entity
to another. Therefore the sending entity must minimally provide message
data, and addressing information for the receiving entity.
The sending entity may not know anything about the environment of the
receiving entity, including a direct way to it. Therefore we need a mail
system infrastructure.
We choose to impose the following requirements:
1. The sending entity may transmit the message to multiple independent
recipients as a single action.
2. The recipient should have some idea of where the message came from and how
it got to the recipient.
Either of these imply that each message must carry state information with
it as it traverses the mail system infrastructure.
We now have message chunks that satisfy the sender (the message data,
and some specification of the desired action), the recipient (trace
information), and whatever is between them (the mail system infrastructure).
Therefore a message has exactly three basic parts:
1. Body, the message data the sender entity wanted to transmit to the recipient.
2. Header, the other information supplied by the sender entity.
3. Envelope, the mail system (state) information carried with the message.
Note: These terms do not necessarily correspond to common casual usage
specific to any particular protocol.
While traversing the mail system infrastructure, the message Envelope
may change at any time. The Header will not change on a mail "relay"
(by definition), and may change on a mail "gateway" (by definition).
The Body will not change on a mail relay, but may it change on a mail
gateway? (see below)
For a message to be transmitted from a sender [entity] to a recipient [],
the following are requirements:
1. The sender must generate a message.
2. The sender must specify the recipient(s).
3. The sender must demark that the <message,recipients> should be sent.
4. Something must decide what to do with the <message,recipients>.
5. Something must do the appropriate thing with the <message,recipients>.
6. If necessary the message traverses the mail system infrastructure
i.e., go to 4, otherwise continue.
7. The message is made available to the recipient at a demarkation point.
8. The recipient takes delivery of the message.
The lines of communication in the above sequence are very fluid. However
the sequence is clear.
We should now be able to discuss the characteristics of any mail system model
in terms of how its components map to this sequence, what is communicated
between the sequence points, and how what is communicated is acted upon.
Start of Very Subjective Opinion:
To me, the Internet E-mail nomenclature maps to the above as follows:
The User Agent is responsible for pts. 1,2,3,8.
The Message Transfer Agent is responsible for pts. 4,5,6,7.
The message Body corresponds to the RFC822 body, as well as any RFC822
header fields with null semantics (i.e. that communicate data unchanged
from sender to recipient, like the Subject: line et al).
The message Header corresponds to the static RFC822 header fields with
defined non-null semantics supplied at time of entry into the mail system
(between Point 3 and 4).
The message Envelope corresponds to the dynamic information maintained
about the message, including RFC821 sender and recipient route-addrs
and associated information, RFC822 Received: header fields, etc.
End of Very Subjective Opinion.
The way RFC821 and RFC822 and X.400 have defined things are just a few
possible instantiations of the general model.
Hopefully this model will be a useful reference in clarifying what people
are actually thinking and talking about.
Point 5 is where message Body translation might happen. Point 4
is where something decides that it should happen. The separation and
sequence of these is occasionally ignored by some of the comments on
features people want added to Point 5. What such comments are really
asking is that 4 and 5 and 6 be mandated to be a single very tightly
integrated step that hides the underlying structure.
We can now get back to the lossy message conversion issue.
The only thing in the general model that bears on this issue is that
the sender's purpose was to transmit the original "message Body" to the
recipient. If the mail system infrastructure, which is the only thing
between the sender and recipient (and in my opinion the area that
delineates MTAs), cannot ensure that the recipient will get what the
sender wanted, it should give up. It can't do its job. Now the
original message may be protected, hidden, sent by another subsystem or
whatever, but the obligation on the mail system is clear: the sender at
a demarkation point asked for a specific message to be sent, and that
is what should be (isomorphically) received at a demarkation point.
In practical terms, if you want something to do lossy conversion of a message,
that something should be on the non-mail system side of a demarkation point
(before pt. 3 or after pt. 7). It may be done at the end-recipient or may
be an intermediate protocol converter, but in any case its action (if remote
from the sender) must be implicitly requested by the sender's recipient
specification. Note that this argument is independent of where you draw
the UA/MTA boundary, though it happens to coincide nicely with what I
think it should be :-)
"The message Body may change isomorphically on a mail gateway."
rayan