Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: > > Oh, it's absolutely true that if one is to define this sort of thing as a > combination of SMTP protocol and message header fields, that should be done > in a single specification. What I'm interested in community input on is > whether the mechanism of transferring the information back and forth > between the two, and having SMTP protocol get involved in inspecting and > altering header fields is a good thing. Heck, I owe Barry an honest reply... draft-melnikov-smtp-priority-07 states: ] ] This document allows a message priority to be tunneled through MTAs ] which don't support the PRIORITY SMTP extension by specifying how it ] can be represented in the message itself (using the MT-Priority ] header field). Thus it is important to ensure that an MTA receiving ] a message containing the MT-Priority header field can trust that it ] was set by an authorized agent. ROTFL. It could come from literally anywhere, including MTAs you wouldn't think are on-path. However, the draft continues: ] ] Such trust can be realized, for example, by using DKIM Section 12.1 ] to sign the MT-Priority header field value, S/MIME, or by keeping a ] list of trusted senders (e.g. within a close environment) . This at least attempts to make the MT-Priority trustworthy. Myself, I don't think it's worth the trouble. DKIM positively invites replay; I must be missing how S/MIME protects a header field; and lists of trusted senders go out-of-date awfully quickly. I think tunneling like this is clever, but asking for trouble: and I've seen too many instances of getting the trouble -- even without a intentionally-bad actor. As to whether having SMTP protocol get involved in inspecting and altering header fields is a good thing, that horse has left the barn; nonetheless, it's error-prone and very vulnerable to bad-analysis in the presence of known-bad actors. I believe I'd opt-out of paying any attention to MT-Priority. Priority is fine along an unbroken path of trust, but IMHO should stop at the first weak link. (Sorry, Alexey...) -- John Leslie <john@xxxxxxx> _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf