Tunneling of SMTP Message Transfer Priorities
RFC 6758
Yes
No Objection
Note: This ballot was opened for revision 02 and is now closed.
(Barry Leiba; former steering group member) Yes
As I noted in the shepherd writeup, I have some concern about the broader applicability of this as a standard, given the trade-offs the proponents have made. That said, some of them had to be made, and there is value in implementing features from proprietary email systems in standardized ways on the open Internet. There does seem to be consensus that it's worth trying this out, and that it's not terribly unsafe to do so. The tunneling of the PRIORITY value through non-conforming MTAs by turning it into a message header field (MT-Priority) and then back again is a problematic technique, but is an important capability for those who need and intend to implement the smtp-priority extension. It creates a trust issue, wherein a message containing MT-Priority could be originated with a Message Submission Agent that does not know about this extension, and when the message hits a Message Transfer Agent that does support this, the header field will be turned back into a valid PRIORITY value, on the unwarranted assumption that it was authorized. Intermediate MTAs have no way to distinguish this situation from one where the field was tunneled legitimately. The counter-argument is that the use case for this specification involves out-of-band trust relationships, and that such situations will be known and dealt with. Only by experimenting with it will we see how (or if) it can extend to other use cases where such trust relationships aren't as clean.
(Pete Resnick; former steering group member) (was Discuss, Yes) Yes
The IESG is fine with moving this to Informational, and that satisfies my concerns. I will work with the author to get this made into Informational.
(Sean Turner; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I have no objection to the publication of this document, and welcome that it is Experimental. As with many Experimental documents I review, I would like the Abstract to note the Experimental status (as, for example, is done in the first line of the Introduction). I should also like to see a little more scoping of the Experiment: - why it is experimental - what nodes participate in the experiment - how the experiment is constrained - how the experiment will be judged It is not mandatory to add such text (hence this is not a Discuss), but I think it really helps people work out how to work with the document.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Stephen Farrell; former steering group member) No Objection
- Section 7, 1st para: How would one use S/MIME to sign the MT-Priority header field? You'd have to encapsulate the message wouldn't you? I think you could omit mention of S/MIME here. - Section 7, 1st para (again:-): DKIM doesn't allow you to know who put this header on, just who signed it (if its included in the signature). So I think what you want to say is something like "DKIM signing allows a recipient to verify that the specified priority value was present when the message was signed, and to verify who signed the message." But the signer might not be the one that "generated" the header. - Same section: Calling for an MUA to use DKIM is a bit of a stretch, but would I guess work, though the key mgmt isn't very well-defined for that use-case really since you end up with per-user keys in the DNS, or have to share private keys.
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection