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.
If you want to brave the ugliness and standardize this, the spec needs
to explain how the server decides whether to believe an MT-Priority
header. If it doesn't, it's too vague to interoperate.
So I have two suggestions. One is to leave it as is, and make it
experimental. If it turns out the tunnels all work the same way, you
can come back and add the spec about how they work and rev it as
standards track. The other is to take out the tunnel bit and make it
standards track now, so a compliant implementation needs
priority-aware MTAs from end to end. Even if you take out the tunnel
stuff in the spec, you can still tunnel in your implementations, using
whatever non-standard ad hoc kludges you want. Since the current spec
has gaps that would need to be filled by non-standard ad hoc kludges
anyway, you haven't lost anything.
--
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf