> >> 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". I think this will likely lead to interoperability problems. Now, in the case of message processing priority the chance of such problems causing significant trouble seem pretty slim, but "it doesn't work well but it also doesn't matter much" is not a justification I feel comfortable embracing. > 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. I have to say I strongly prefer the latter, especially if it also includes eliminating the prohibition on using other sources of priority information to set the envelope priority level on submission. In fact given that prohibition I see little point in implementing this, at least not in a fashion that conforms to the specification. Ned
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf