On 3/3/12 7:07 PM, ned+ietf@xxxxxxxxxxxxxxxxx wrote:
This draft also defines the MT-Priority header field. �It is quite unusual
for a SMTP extension specification to define a mail header field. ...
This is my major concern about this protocol as well, as I note in the
PROTO writeup (which, unfortunately, can't be seen publicly because of
a limitation in the datatracker; perhaps I should post it here). I'm
interested in hearing whether others share this concern, and what the
community consensus is about it.
I have no problem logging stuff from the SMTP session into a message
header, we've been doing that since forever. But I have a lot of
problem turning a header back into SMTP for a subsequent relay, for
two reasons.
One is just that it's ugly. There were good reasons to separate the
envelope from the body back in the 1970s, and I think those reasons
are just as good now. Over in the EAI group, there was a valiant
effort to tunnel EAI messages through non-EAI SMTP servers via
downgrades, and we eventually gave up. Now, if you want to send an
EAI message, there has to be an EAI path all the way from the sender
to the recipient. This isn't exactly analogous, but it's instructive.
The other reason is that I think it's too ill-specified to
interoperate. The theory seems to be that the relay server notices an
MT-Priority: header, and (vigorous waving of hands) somehow decides if
the message has sufficient virtue to promote the header back into the
SMTP session. The hand-waving is not persuasive; the suggestion of
S/MIME, which obviously won't work, is not encouraging.
Both good points. While I personally am indifferent to header modification
being an issue - I believe we've long since crossed that bridge - I will also
note that simply changing this proposal to always insert the MT-Priority: field
at submission time and leave it unchanged throughout message transit would
leave most of the functionality intact and eliminate the header modification
issue entirely.
But the upleveling of header to envelope would remain. John is quite correct in
his assertion that these are mostly uncharted waters: The only remotely
comparable case I can think of is the mapping of some X.400 fields to the
NOTARY extension, but in that case the mapping was from X.400 envelope material
to SMTP envelope material. Additionally, the mapping was precisly specified
with no wiggle room for "site policy".
+1
And there's another issue, I think. As there is 'upleveling of header to
envelope', the draft also describes the reverse process. In par. 4.4 an
SMTP client that talks to a non-confirming SMTP server MUST add it's own
MT-Priority header with a priority determined by the process described
in par. 4.2. This means an MTA can receive a mail with priority
determined by envelope information and sends the message using header
information. Those of us who wrote SMTP client software are in a better
position to comment on this than I am. But having dealt with different
MTA's it strikes me as fairly unusual for an SMTP client to add
headerlines to the message-in-transit at such a late stage during
transmission of the message to the SMTP server.
/rolf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf