Simple Mail Transfer Protocol Extension for Message Transfer Priorities
RFC 6710
Yes
No Objection
Note: This ballot was opened for revision 16 and is now closed.
(Barry Leiba; former steering group member) Yes
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
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?
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
I agree with Adrian's comment that 19 priorities may be hard to manage.
(Gonzalo Camarillo; former steering group member) No Objection
(Martin Stiemerling; former steering group member) (was Discuss) No Objection
Thanks for addressing my issues.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) (was Discuss) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
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?
(Stephen Farrell; former steering group member) No Objection
- (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 queues.
(Stewart Bryant; former steering group member) No Objection
I agree with Adrian's comments
(Wesley Eddy; former steering group member) (was Discuss) No Objection