Barry Leiba <barryleiba(_at_)computer(_dot_)org> 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(_at_)jlc(_dot_)net>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf