Simple Mail Transfer Protocol Extension for Message Transfer Priorities
RFC 6710

Note: This ballot was opened for revision 16 and is now closed.

(Barry Leiba) Yes

(Pete Resnick) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-06-07 for -16)
No email
send info
I agree with Adrian's comments

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) (was Discuss) No Objection

(Adrian Farrel) No Objection

Comment (2012-06-04 for -16)
No email
send info
I have no objection to the publication of this document.


Are you sure you have not conflated priority and importance?
High priority messages need to be delivered quickly and an
implementation may want to let them overtake lower priority messages.
High importance messages need to be delivered (eventually) and should
have a lower chace of being dropped.

4.1 with its ability to reject low priority messages appears to be
doing importance.


Appendix E gives some motivations for 19 priorities. It seems like a
very large number to me. Experience with this sort of range of options
and priority levels suggests that it only adds confusion. I suppose my
question is: are you sure?

(Stephen Farrell) No Objection

Comment (2012-06-05 for -16)
No email
send info
- (An almost "discuss"): 4.6 means that anyone who is ok to
send me a prio=9 message can cause me to send a whole bunch of
prio=9 messages (as DSNs). Is that not a new DoS vector? 
Please explain why not.

(The rest are not near-discusses btw.)

- The writeup is somewhat coy about the use-case. Its military
messaging, ala STANAG 4406/ACP 123.

- I don't get why the EHLO keyword has no parameters.  I'd
have thought that a parameter there could be a useful way to
signal some semantics for MT-PRIORITY values. Maybe that was
discussed before though. (I've not kept up with all the mail
on this draft btw.)

- I agree that the "untrusted source" concept in 4.1 seems
broken and that a resolution such as that discussed via email
seems right, that is, that this is down to bilateral agreement
really rather than being tied to SMTP AUTH so directly.

- Is 4.3 really needed? Seems like its not about relaying but
is generally true.

- What exactly does "retain" mean in 4.4? I guess it means
that the MLA MUST forward the mail with the same MT-PRIORITY
value to any next-hop that supports it. But what if only 50%
of the next-hops for a given message support this?

- I don't get what X.3.TBD2 means at the end of p7.  (I even
looked at 2034 and still don't get it.)

- Saying its "important" for MUAs to support this spec seems
over-stated. If you want to keep the term "important" then I
guess it'd be good to specify to whom what is important? (Not
all players in this space have commensurate interests.)

- 5.1, possible nit, possible significant comment. A lower
priority message could be sent first with advantage to all.
If e.g. the sending MTA knows that sending the higher priority
message over a later, but "better", interface, e.g. that is
currently down. This is a familiar concept when dealing with
contacts in DTNs. I think maybe it'd be better to talk about
trying to get the mail delievered earlier rather than the
speciifics of how priorities map to sending things from

(Brian Haberman) No Objection

Comment (2012-06-04 for -16)
No email
send info
I agree with Adrian's comment that 19 priorities may be hard to manage.

(Russ Housley) No Objection

(Robert Sparks) (was Discuss) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2012-06-12 for -18)
No email
send info
Thanks for addressing my issues.

(Sean Turner) (was Discuss) No Objection

Comment (2012-06-06 for -16)
No email
send info
Updated #4 based on some IMs with Alexey:

0) BTW - my initial thought about this draft was "I wish I had of thought of this ten yeas ago."  Really hoped you'd go all the way and have different precedences/priorities for the to and cc recipients ;)

1) App A: Actually ACP123/STANAG 4406 specifies a range from 0-31.  And (this relates to the discuss) if somebody specifies four more values higher than override how will the mapping get done?

2) App A: In 123/4406, there's priority and precedence.  The values you list are from precedence so I assume you're talking about those values and not the urgent, routine, and non-urgent values for priority.  App A says priority though:

   Military Messaging as specified in ACP 123 [ACP123] (also specified
   in STANAG 4406 [STANAG-4406]) defines six priority values.

3) App B contains the following:

   Where SMTP is used to support military messaging, the following
   mappings SHOULD be used.

Should this say mixer instead of military messaging?

4) I'm trying to wrap my head around why if you go from MMHS to SMTP you'd map urgent and flash to different level but if you went through MIXER to get to SMTP you'd get flash and override mapped to the same level (urgent)

And, what do you do if both primary-precedence and mixer priority are there?