Skip to main content

Tunneling of SMTP Message Transfer Priorities
RFC 6758

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 steering group member) Yes

Yes (2012-07-09 for -02)
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

Yes (2012-07-19 for -03)
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

Yes (for -03)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-07-18 for -03)
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

No Objection (for -03)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -03)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -03)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (2012-07-17 for -03)

                            

(Robert Sparks; former steering group member) No Objection

No Objection (for -03)

                            

(Ron Bonica; former steering group member) No Objection

No Objection (for -03)

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (for -03)

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-07-16 for -03)

- 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

No Objection (for -03)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (for -03)