Tunneling of SMTP Message Transfer Priorities
draft-melnikov-smtp-priority-tunneling-04
Yes
(Sean Turner)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 02 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2012-07-09 for -02)
Unknown
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 IESG member
(was Discuss, Yes)
Yes
Yes
(2012-07-19 for -03)
Unknown
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 IESG member
Yes
Yes
(for -03)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-07-18 for -03)
Unknown
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 IESG member
No Objection
No Objection
(for -03)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2012-07-17 for -03)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(for -03)
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
(for -03)
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(for -03)
Unknown
Stephen Farrell Former IESG member
No Objection
No Objection
(2012-07-16 for -03)
Unknown
- 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 IESG member
No Objection
No Objection
(for -03)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -03)
Unknown