[apps-discuss] Review of draft-melnikov-smtp-priority-14

[Dave Crocker <[e-mail]>]

This review is at my own initiative.


Document: draft-melnikov-smtp-priority-14
Title: Simple Mail Transfer Protocol extension for Message Transfer
Priorities
Reviewer: D. Crocker
Review Date: May 25, 2012
IETF Last Call Date: May 28, 2012


Summary:



> Abstract
>
>    This memo defines an extension to the SMTP (Simple Mail Transfer
>    Protocol) service whereby messages are sent with a priority to enable
>    receivers to take this into account for onward processing, with the
>    general goal of processing and/or transferring higher priority
>    messages first.

It helps to have text that explains core constructs by using different 
terminology than the title of the construct.  That way, it avoids 
assuming the reader already knows exactly what is meant by the special 
terminology.

So:

    whereby messages are sent with a priority to enable
    receivers to take this into account for onward processing
    ->
    whereby messages are given a label to indicate preferential
    handling, to enable mail handling nodes to take this into account for
    onward processing.

> 1.  Introduction
>
>    Where resources for switching or transfer of messages are constrained
>    (e.g., bandwidth, round trip time or processing capability) it is

might want to add 'transit storage'.


>    desirable to process high priority messages first.  This is

    process high priority messages first
    ->
    give preferential handling to some messages over others, according
    to their labeled priority.


>    particularly important during emergencies for first responders and
>    for environments such as military messaging, where messages have high
>    operational significance, and the consequences of extraneous delay
>    can be significant.
>
>    In order for an SMTP receiver to be able to send higher priority

    send -> relay


>    messages first, there needs to be a mechanism to communicate (during
>    both Message Submission [RFC6409] and Message Transfer [RFC5321]) the
>    priority of each message.  This specification defines this mechanism
>    by specification of an SMTP [RFC5321] extension.
>
>    Implementors of this document might also consider implementing
>    [PRIORITY-TUNNELING] which talks about tunneling of Message Transfer
>    Priority information through Message Transfer Agents (MTAs) that do
>    not support this extension, using a new message header field
>    [RFC5322].

Consider replacing above paragraph with:

    In order to permit end-to-end use of this extension across email 
infrastructure that does not support it, a companion tunneling mechanism 
is defined in [PRIORITY-TUNNELING] through use of a new message header 
field [RFC5322].



> 2.  Conventions Used in This Document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in [RFC2119] when they
>    appear in ALL CAPS.  These words also appear in this document in
>    lower case as plain English words, absent their normative meanings.

"when they appear in ALL CAPS".  sigh. In other words, this document is 
modifying RFC2119.

Does anyone seriously expect this new nuance of usage to be read and 
remembered by average readers of this document?

FWIW, it took me about 3 minutes to make the relevant changes, below. 
Case-sensitivity in semantics invites comprehension problems here. 
Worse, there is absolutely no need or benefit in creating the problem 
for this document.  At a minimum, please do not try to modify IETF 
document writing policy on the fly.


>    The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
>    notation including the core rules defined in Appendix B of RFC 5234
>    [RFC5234].
>
>    In examples, "C:" and "S:" indicate lines sent by the client and
>    server respectively.  Line breaks that do not start with a new "C:"
>    or "S:" exist for editorial reasons and are not a part of the
>    protocol.
>
>    This document uses the term "priority" specifically in relation to
>    the internal treatment of a message by the server: messages with
>    higher priorities may be given expedited handling, and those with

    may -> can


>    lower priorities may be handled only as resources become available.

    may -> can


>
> 3.  Definition of the Priority SMTP Extension
>
>    The Priority SMTP service extension is defined as follows:
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 3]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    1.  The textual name of this extension is "Priority Message
>        Handling".
>
>    2.  The EHLO keyword value associated with this extension is "MT-
>        PRIORITY".
>
>    3.  The EHLO keyword has no parameters.  Parameters are reserved for
>        possible future extensions and MUST be ignored by clients that
>        don't understand them.
>
>    4.  No additional SMTP verbs are defined by this extension.
>
>    5.  One optional parameter ("MT-PRIORITY") is added to the MAIL FROM
>        command.  The value associated with this parameter is a decimal
>        integer number from -9 to 9 (inclusive) indicating the priority
>        of the email message.  The syntax of the MT-PRIORITY parameter is
>        described by the <priority-value> ABNF non-terminal defined in
>        Section 6.  Higher numbers mean higher priority.

As a minor point, the form of -9 to 9 seems more complicated than 
useful.  Is there a need for 19 values?  I'd think that 0 to 9 would be 
sufficient.

For that matter, why are many values needed?  What is the basis for 
choosing to have a range of more than a few values?

This appears to be the only place the provides semantics to the priority 
number.  As such, it should be more thorough.  The critical issue in 
assigning the number, I think, is trying to get independent originators 
to assign numbers according roughly the same criteria.  For example, if 
I label "average" messages I send as as 0 and you label them as 1, then 
your messages get preferential treatment over mine, although that was 
not your intent.  (Assuming you're not trying to game the service...)

This issue goes to the core of the usage model for the feature:  It 
really needs an environment tailored to its use, with all participants 
not only within the same trust system, but sharing the same priority 
assignment model/policy.  It's probably good for this document to permit 
a range of assignment models, but should note that an operational 
requirement for use of the extension is that an assignment policy be 
defined for all participants.

This document might, then, offer a candidate model, to be use by default 
and absent one specific to an environment.


>
>    6.  The maximum length of a MAIL FROM command line is increased by 15
>        octets by the possible addition of a space, the MT-PRIORITY
>        keyword and value.
>
>    7.  The MT-PRIORITY extension is valid for the submission service
>        [RFC6409] and LMTP [RFC2033].
>
> 4.  Handling of messages received via SMTP
>
>    This section describes how a conforming SMTP server should handle any
>    messages received via SMTP.
>
> 4.1.  Handling of the MT-PRIORITY parameter by the receiving SMTP server
>
>    The following rules apply to SMTP transactions in a server that
>    supports the MT-PRIORITY parameter:
>
>    1.  A conforming SMTP server MUST NOT refuse a MAIL FROM command
>        based on the absence of the MT-PRIORITY parameter.

hmmm.   For some operational environments, it will be essential to have 
/all/ handling conform to the priority policy model in force for the 
environment.  In those cases, the absence of the parameter would be a 
violation of the spec.


>    2.  If any of the associated <esmtp-value>s (as defined in Section
>        4.1.2 of [RFC5321]) are not syntactically valid, or if there is
>        more than one MT-PRIORITY parameter in a particular MAIL FROM
>        command, the server MUST return an error, for example "501 syntax
>        error in parameter" (with 5.5.2 Enhanced Status Code [RFC2034]).
>
>    3.  When inserting a Received header field as specified in Section
>        4.4 of [RFC5321], the compliant MTA/MSA SHOULD include the
>        "PRIORITY" clause whose syntax is specified in Section 6.
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 4]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    4.  If the sending SMTP client specified the MT-PRIORITY parameter to
>        the MAIL FROM command, then the value of this parameter is the
>        message priority.
>
>    5.  If no priority has been determined by the above, the server may

    may -> can


>        use its normal policies to set the message's priority.  By
>        default, each message has priority 0.

ouch.  This chooses a particular model for meaning of the numbers, and 
without having defined the model beforehand.

That is, I think the problem with this default is that it really is 
assuming a particular policy for meaning of the values, namely that 
average mail is mid-priority, assuming the numbers have linear semantics.


>    The SMTP server MUST NOT allow upgraded priorities from untrusted
>    (e.g. unauthenticated) or insufficiently trusted sources.  (One
>    example of an "insufficiently trusted source" might be an SMTP sender
>    which authenticated using SMTP AUTH, but which is not explicitly
>    whitelisted to use the SMTP MT-PRIORITY service.)  The server MAY,

It is good that this issue is raised, but it really requires an earlier, 
separate and careful discussion of the need for this extension to be 
used within an administered trust environment.  Given such an 
introductory section, the above text would be sufficient.

In its absence, the reference to a whitelist is based on the very large 
assumption that participants in the extension are whitelisted.  This is 
not document elsewhere.


>    however, allow an untrusted source to lower its own message's
>    priorities -- consider, for example, an email marketer that
>    voluntarily sends its marketing messages at low priority.

To beat the point a bit deader:  this assumes a particular policy for 
the meaning of the priority values.  Worse, it also appears to 
contradict the earlier default of 0, but perhaps I've misunderstood that.


>    The SMTP server MAY also alter the message priority (to lower or to
>    raise it) in order to enforce some other site policy.  For example an
>    MSA might have a mapping table that assigns priorities to messages
>    based on authentication credentials.
>
>    If the SMTP server lowers the priority of a message, it SHOULD use
>    the X.7.TBD3 [RFC2034] enhanced status code.
>
>    Alternatively an SMTP server, which is an MSA, MAY reject a message
>    based on the determined priority.  In such case, the MSA SHOULD use

    case -> cases


>    450 or 550 reply code.  The corresponding enhanced status code MUST
>    be X.7.TBD1 [RFC2034] if the determined priority level is below the
>    lowest priority currently acceptable for the receiving SMTP server.
>    Note that this condition might be temporary, in cases where the
>    server is temporarily operating in a mode where only high priority
>    messages are accepted for transfer and delivery.

Given a range of 0-9, what qualifies as high priority and what qualifies 
as low?

Perhaps:

    Note that this condition might be temporary.  In some environments, 
operational policies might permit periods of operation that relay only 
higher priority messages and defer lower priority ones.  Such handling 
choices need to be specified for that operational environment..


> 4.2.  Relay of messages to other conforming SMTP servers
>
>    The following rules govern the behavior of a conforming MTA (in the
>    role of an SMTP client), when relaying a message which was received
>    via the SMTP protocol, to an SMTP server that supports the MT-
>    PRIORITY SMTP extension:
>
>    1.  A MT-PRIORITY parameter with the value determined by the
>        procedure from Section 4.1 MUST appear in the MAIL FROM command
>        issued when the message is relayed to an MTA/MDA which also
>        supports the MT-PRIORITY extension.  For example, once an MTA
>        accepts a message, the MTA MUST NOT change a (syntactically
>        valid) priority value if that value is not supported by the MTA's
>        implementation of this extension.

I don't understand what it means to not support a particular priority 
value.  This appears to presume some interpretation of the values and 
then some differential model for specific values.  That's probably a 
reasonable model for some environments and unreasonable for others.

Once again, this suggests the need for an environment-specific set of 
operational policies.

The current draft needs to be specified in a manner that supports 
different sets of policies.

Perhaps there should be an appendix with a default set, but 
parameterized so as to make adaptation to other environments easy?


>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 5]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    2.  Further processing of the MT-PRIORITY parameter is described in
>        Section 5.
>
> 4.3.  Relay of messages to non-conforming SMTP servers
>
>    The following rules govern the behavior of a conforming MTA (in the
>    role of an SMTP client), when relaying a message which was received
>    via the SMTP protocol, to an SMTP server that does not support the
>    MT-PRIORITY SMTP extension:
>
>    1.  The relaying MTA MUST NOT use the MT-PRIORITY parameter in the
>        MAIL FROM command issued when relaying the message.

Standing here in isolation, this rule is not sufficient because it does 
not say what the SMTP client is required to then do.  Is this a 
permanent error resulting in a rejection?  Should an alternate MX be 
attempted?  Should tunneling be done?

(Once again I suspect that  this will depend upon the policies of the 
operational environment, since each choice could be reasonable, but a 
consistent choice is needed within the environment.)


> 4.4.  Mailing lists and Aliases
>
>    Several options exist to translate the address of an email recipient

"options"?  Perhaps you mean mechanisms or services?  And they really 
aren't translating an address but are doing a form of message 
transmission (relaying, or the like).


>    into one or more other addresses.  Examples for this are aliases and
>    mailing lists [RFC5321].
>
>    If a recipient address is to be translated and/or expanded when
>    delivered to an alias or a mailing list, the translating or expanding
>    entity (MTA, etc.)  SHOULD retain the MT-PRIORITY parameter value for
>    all expanded and/or translated addresses.

This appears to expect the extension's semantics to survive delivery and 
re-posting via a mailing list.  Remember that a mailing list posts a 
/new/ message.  Offhand, this requirement seems to go considerably 
beyond normal SMTP options and beyond most Internet Mail standards 
services...

At the least, this needs considerably more extensive and careful 
documentation that it is given here.


> 4.5.  Gatewaying a message into a foreign environment
>
>    The following rules govern the behavior of a conforming MTA, when
>    gatewaying a message that was received via the SMTP protocol, into a
>    foreign (non-SMTP) environment:
>
>    1.  If the destination environment is unable to provide an equivalent
>        of the MT-PRIORITY parameter, the conforming MTA SHOULD behave as
>        if it is relaying to a non-conformant SMTP server (Section 4.3).

Given the variable semantics that apply here -- per the different policy 
possibilities -- what does it mean to be an equivalent of the 
MT-PRIORITY parameter, in specific technical terms?


>    2.  If the destination environment is capable of providing an
>        equivalent of the MT-PRIORITY parameter, the conforming MTA
>        SHOULD behave as if it is relaying to a conformant SMTP server
>        (Section 4.2), converting the MT-PRIORITY value to the equivalent
>        in the destination environment.

Is this really enough technical and operational detail to cover 
gatewaying?  Perhaps it is, but it feels to me as if it isn't.  Then 
again, I don't know what more/else to suggest.


> 4.6.  Interaction with DSN SMTP Extension
>
>    An MTA which also conforms to [RFC3461] SHOULD apply the same
>    priority value to delivery reports (whether for successful delivery
>    or failed delivery) it generates for a message.

In many operational environments, control messages get higher priority 
(or lower priority) than payload messages.


>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 6]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
> 5.  The Priority Service Extension
>
>    The priorities of messages affect the order the messages are
>    transfered from the client to the server.  This is largely

    transfered  ->  transferred


>    independent from the order in which they were originally received by
>    the server.
>
>    A message priority is a decimal integer in the range from -9 to 9
>    (inclusive).  SMTP servers compliant with this specification are not
>    required to support all 19 distinct priority levels (i.e. to treat
>    each priority value as a separate priority), but they MUST implement
>    at least the following 6 distinct priority levels: -4, -2, 0, 2, 4,
>    9.

Huh?  This seems overly complicated and lacks any motivation or 
explanation.  Absent very specific semantics for each specific value, it 
makes no sense to authorize differential support of values.


>  I.e. an implementation that only supports the 6 priority levels
>    will internally round up a syntactically valid level that isn't
>    supported to the next higher supported number.  For example, such an
>    implementation will treat priority values below and including -4 as
>    priority -4, priority -3 as priority -2, and all priorities starting
>    from 5 are treated as priority 9.  An SMTP server MAY support more
>    than 6 different priority levels.  Decision about which levels to
>    support in addition to the 6 mentioned above is a local matter.
>
>    Irrespectively of the number of distinct priority levels supported by
>    the SMTP server, when relaying the message to the next hop or
>    delivering it over LMTP, the SMTP server MUST communicate the
>    priority value as determined in Section 4.1.
>
>    Note: 19 possible priority levels are defined by this specification
>    for extensibility.  For example, a particular implementation or
>    deployment environment might need to provide finer-grained control
>    over message transfer priorities.  In such a case, a server
>    implementation might need an extra priority level beyond the 6 levels
>    defined above.

They also might need more than 19 values.  In other words, as always a 
standard can't satisfy all possibilities.  But it needs to make choices 
that are neither arbitrary nor complicated.  The current text seems to 
fail on both counts.  (counts.  pun?)


>    Some SMTP servers MAY impose additional maximum message size
>    constraints for different message transfer priorities, for example
>    messages with priority 6 might not be larger than 4 Kb.  If an SMTP
>    server chooses to reject a message because it is too big for the
>    determined priority, it SHOULD use 552 reply codes, together with the
>    X.3.TBD2 enhanced status code [RFC2034].

Not just message size /might/ relate to priority differences.

This paragraph raises a major and essential point:  Actual operational 
environments will have very different policies for providing 
differential quality of service.

The current specification is hinting at examples of differences, without 
elaborating any of them.

I suggest that, instead, it should identify the points of permitted 
differential behavior and declare them as needing explicit specification 
in an environment-specific policy specification.  As suggested earlier 
in the review:  this will make the current document primarily a 
syntactic shell for the meat of a policy document.  It should then 
supply an appendix that defines a default set of policies.


>    Note that rejections based on priority (see Section 4.1) or priority+
>    message size combination SHOULD only be done by an MSA (i.e. they
>    SHOULD NOT be done by MTAs/MDAs), because the MSA has a link to the

This presumes that an MSA knows the priority-related policies of 
downstream MTAs and MDAs.


>    Mail User Agents (MUAs) which generated the message and is in a
>    position to perform a corrective action, such as resubmission of the

resubmission with lower priority is a big deal but seems to get a rather 
casual reference here.


>    message with lower priority, converting or truncating the message to
>    make it smaller, etc.  Such actions usually require user interaction.
>    For this reason it is also important for MUAs to support enhanced
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 7]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    status codes specified in this document (see Section 9 for the
>    summary).  Any rejection caused by a downstream MTA is going to
>    result in a bounce message.  Such bounce messages are not friendly to
>    users and are frequently removed by antispam software.
>
>    Implementation Note: If the SMTP server also supports the SMTP SIZE
>    extension [RFC1870] then an SMTP client can use both SIZE= and MT-
>    PRIORITY= parameters on the MAIL FROM command.  This allows the
>    server to perform early rejection of a message in case the message
>    size is too big for the specified priority, thus avoiding wasting
>    bandwidth by transferring the message first and then rejecting it due
>    to its size.
>
>    The Priority Service Extension can be combined with DELIVERBY
>    [RFC2852] SMTP service extension, however there is no requirement
>    that both extensions are always implemented together.
>
> 5.1.  Expedited Transfer
>
>    The main service provided by the Priority Message Handling SMTP
>    Service Extension is expedited transfer of emails with a higher
>    priority.  Therefore an SMTP client that has more than one email to
>    send at a given time sends those with a higher priority before those

I believe this is specifying the core behavior semantic for an MSA/MTA, 
but it is buried deep in the document.  I suspect that this entire 
sub-section -- or at leasts its initial paragraphs -- should be moved 
towards the Introduction...


>    with a lower one.  Additionally, the retry interval and/or default
>    timeout before non-delivery report is generated can be lower (more
>    aggressive) for messages of higher priority.

oh?  "can be"?

This sort of language looks like it is specifying something but it 
isn't.  And the reference to what "can be" carries no cautions or 
directions meaningful to implementers.


>    Note that as this SMTP extension requires some sort of trust
>    relationship between a sender and a receiver and thus some for of

    for -> form  (?)

This is treated as a side comment (by introducing it with "Note") but I 
believe it is in fact a core predicate for the extension.


>    authentication (whether using SMTP AUTH, TLS, IP address whitelist,
>    etc.), so senders using this SMTP extension will not be subject to
>    greylisting [GREYLISTING], unless they are unauthorized to use this
>    SMTP extension, due to an explicit policy decision or a
>    misconfiguration error.
>
>    In order to make implementations of this extension easier, this SMTP
>    extension only allows a single priority for all recipients of the
>    same message.

This is quite a good and clear simplification point.  However note that 
a model which permits selective support of priority values winds up 
going counter to that goal of simplification.


>    Within a priority level, the MTA uses its normal algorithm (the
>    algorithm used in absence of this SMTP extension) for ordering for
>    the messages.
>
>    Most current SMTP MTAs are capable of handling several inbound and
>    outbound connections at once.  With this feature it should be
>    possible to start additional outbound connections for emails with
>    higher priorities even if there are already several connections
>    running for other emails.  Two possible ways of implementing
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 8]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    expedited transfer are described in more details in Appendix D.
>
>    This extension provides benefits in networks with limited available
>    bandwidth or long round trip times, when the actual message transfer
>    over the network may create a significant portion of the overall

    may -> can


>    message delivery time from a sender to a recipient.  It is also
>    useful in case of a congestion, for example resulting from an MTA
>    queue build-up.  When neither of the two conditions mentioned above
>    is true, the use of the MT-PRIORITY SMTP extension will not result in
>    a better SMTP service.

This paragraph states the basic value proposition.  It's reasonable text 
for early in the specification, but is hopefully redundant and therefore 
unnecessary this far into the document.


>    Besides the actions taken at the application level it can thus be
>    important to deploy priority or precedence mechanisms offered by the
>    network itself to ensure timely delivery of the emails.  Examples
>    would be the use of DiffServ [RFC2474], RSVP [RFC2205] and the work-
>    in-progress effort extension to RSVP that prioritizes reservations.
>
> 5.2.  Timely Delivery
>
>    An important constraint (usually associated with higher priority
>    levels) is that messages with high priority have some delivery time
>    constraints.  In some cases, higher priorities mean a shorter maximum
>    time allowed for delivery.
>
>    Unextended SMTP does not offer a service for timely delivery.  The
>    "Deliver By SMTP Service Extension" (DELIVERBY Extension) defined in
>    [RFC2852] is an example of an SMTP extension providing a service that
>    can be used to implement such constraints.  But note that use of the
>    DELIVERBY extension alone does not guarantee any priority processing.

It seems as if this section introduces an issue but does not actually 
deal with it.  Perhaps there should be some discussion of the possible 
(or required?) interaction between the two extensions it discusses?


> 6.  Syntax
>
>
>
>       priority-value = (["-"] NZDIGIT) / "0"
>                        ; Allowed values are from -9 to 9 inclusive
>
>       NZDIGIT = %x31-39
>                 ; "1"-"9"
>
>       CFWS = <defined in RFC 5322>
>
>       ; New "clause" that can be used in the Received header field
>       Pri  = CFWS "PRIORITY" FWS priority-value
>                 ; Complies with the <Additional-Registered-Clauses>
>                 ; non-terminal syntax from RFC 5321.
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012               [Page 9]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
> 7.  Example
>
>    An SMTP transaction with 2 recipients.  Note that the example is also
>    making use of the DELIVERBY [RFC2852] and DSN [RFC3461] SMTP
>    extensions, even though there is no requirement that these other
>    extensions are to be supported when the MT-PRIORITY SMTP extension is
>    implemented.
>
>         S: 220 example.net SMTP server here
>         C: EHLO example.com
>         S: 250-example.net
>         S: 250-DSN
>         S: 250-DELIVERBY
>         S: 250 MT-PRIORITY
>         C: MAIL FROM:<[e-mail]> BY=120;R ENVID=QQ314159
>             MT-PRIORITY=3
>         S: 250 <[e-mail]> sender ok
>         C: RCPT TO:<[e-mail]>
>         S: 250 <[e-mail]> recipient ok
>         C: RCPT TO:<[e-mail]> NOTIFY=SUCCESS,FAILURE
>             ORCPT=rfc822;[e-mail]
>         S: 250 <[e-mail]> recipient ok
>         C: DATA
>         S: 354 okay, send message
>         C:  (message goes here)
>         C: .
>         S: 250 message accepted
>         C: QUIT
>         S: 221 goodbye
>
>    If the receiving SMTP server only supports 6 priority levels as
>    described in Section 5, it will use the priority value 4 internally
>    (the next supported priority higher or equal to 3) and will
>    communicate the priority value 3 when relaying it to the next hop (if
>    necessary).
>
> 8.  Deployment Considerations
>
>    If multiple DNS MX records are used to specify multiple servers for a
>    domain in section 5 of [RFC5321], it is strongly advised that all of

"strongly advised"?

This seems the sort of thing that needs normative language yet it is 
carefully avoided.  That is, by saying 'strongly' the issue is moved 
towards the asking why it is not stated normatively.  I'd guess this 
needs a SHOULD, possibly with discussion of permissible exceptions (such 
as the open Internet...?)

However note that the 'strongly advised' presumes instantaneous 
implementation on all hosts within the trust environment.  Since that 
isn't possible, it's not clear how the advice of this section is practical.


>    them support the MT-PRIORITY extension and handles priorities in
>    exactly the same way.  If one or more server behave differently in

    server -> servers


>    this respect, then it is strongly suggested that none of the servers
>    support the MT-PRIORITY extension.  Otherwise, unexpected differences
>    in message delivery speed or even rejections can happen during
>    temporary or permanent failures, which users might perceive as
>    serious reliability issues.
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 10]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
> 9.  IANA Considerations
>
>    This specification requests IANA to add the MT-PRIORITY SMTP
>    extension to the "SMTP Service Extensions" registry (in
>    http://www.iana.org/assignments/mail-parameters).  This extension is
>    suitable for the Submit port.
>
>    This specification requests IANA to add the following new Received
>    header field clause to the "Additional-registered-clauses" sub-
>    registry (in http://www.iana.org/assignments/mail-parameters) to help
>    with tracing email messages delivered using the MT-PRIORITY SMTP
>    extension:
>
>    Clause name: PRIORITY
>    Description: Records the value of the MT-PRIORITY parameter specified
>    in the MAIL FROM command
>    Syntax of the value: See Section 6 of RFCXXXX
>    Reference: [[anchor12: RFCXXXX]]
>
>    This specification requests IANA to add the following Enumerated
>    Status Codes to the "Simple Mail Transfer Protocol (SMTP) Enhanced
>    Status Codes" registry established by [RFC5248] (in http://
>    www.iana.org/assignments/smtp-enhanced-status-codes/
>    smtp-enhanced-status-codes.xml):
>
>    1.
>
>        Code:  X.7.TBD1
>
>        Sample Text:  Priority Level is too low
>
>        Associated basic status code:  450, 550 (other 4XX or 5XX codes
>           are allowed)
>
>        Description:  The specified priority level is below the lowest
>           priority acceptable for the receiving SMTP server.  This
>           condition might be temporary, for example the server is
>           operating in a mode where only high priority messages are
>           accepted for transfer and delivery.
>
>        Reference:  RFC XXXX
>
>        Submitter:  A. Melnikov
>
>        Change controller:  IESG
>
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 11]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    2.
>
>        Code:  X.3.TBD2
>
>        Sample Text:  Message is too big for the specified priority
>
>        Associated basic status code:  552 (other 4XX or 5XX codes are
>           allowed)
>
>        Description:  The message is too big for the specified priority.
>           This condition might be temporary, for example the server is
>           operating in a mode where only high priority messages are
>           accepted for transfer and delivery.
>
>        Reference:  RFC XXXX
>
>        Submitter:  A. Melnikov
>
>        Change controller:  IESG
>
>    3.
>
>        Code:  X.3.TBD3
>
>        Sample Text:  Requested priority was downgraded
>
>        Associated basic status code:  250 or 251
>
>        Description:  The message was accepted for relay/delivery, but
>           the requested priority can't be honoured and was downgraded.
>           The human readable text after the status code contains the new
>           priority, followed by SP (space) and explanatory human
>           readable text.
>
>        Reference:  RFC XXXX
>
>        Submitter:  A. Melnikov
>
>        Change controller:  IESG
>
> 10.  Security Considerations
>
>    Message Submission Agents MUST implement a policy that only allows
>    authenticated users (or only certain groups of authenticated users)
>    to specify message transfer priorities, and MAY restrict maximum
>    priority values different groups of users can request, or MAY
>    override the priority values specified by MUAs.

Presumably the normative MSA language is meant "for those MSAs 
supporting this extension"?


>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 12]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    Similarly, MTAs MUST implement a policy that only allows
>    authenticated and trusted senders (or only certain groups of
>    authenticated senders) to specify message transfer priorities, and
>    MAY restrict maximum priority values different groups of senders can
>    request, or MAY override the priority values specified by them.
>
>    In the absence of the policy enforcement mentioned above an SMTP
>    server (whether an MSA or an MTA) implementing this extension might
>    be susceptible to a Denial of Service attack.  For example, malicious
>    clients (MUAs/MSAs/MTAs) can try to abuse this feature by always
>    requesting Priority 9.
>
> 11.  References
>
> 11.1.  Normative References
>
>    [RFC2033]             Myers, J., "Local Mail Transfer Protocol",
>                          RFC 2033, October 1996.
>
>    [RFC2034]             Freed, N., "SMTP Service Extension for
>                          Returning Enhanced Error Codes", RFC 2034,
>                          October 1996.
>
>    [RFC2119]             Bradner, S., "Key words for use in RFCs to
>                          Indicate Requirement Levels", BCP 14, RFC 2119,
>                          March 1997.
>
>    [RFC3461]             Moore, K., "Simple Mail Transfer Protocol
>                          (SMTP) Service Extension for Delivery Status
>                          Notifications (DSNs)", RFC 3461, January 2003.
>
>    [RFC5321]             Klensin, J., "Simple Mail Transfer Protocol",
>                          RFC 5321, October 2008.
>
>    [RFC5322]             Resnick, P., Ed., "Internet Message Format",
>                          RFC 5322, October 2008.
>
>    [RFC5234]             Crocker, D. and P. Overell, "Augmented BNF for
>                          Syntax Specifications: ABNF", STD 68, RFC 5234,
>                          January 2008.
>
>    [RFC5248]             Hansen, T. and J. Klensin, "A Registry for SMTP
>                          Enhanced Mail System Status Codes", BCP 138,
>                          RFC 5248, June 2008.
>
>    [RFC6409]             Gellens, R. and J. Klensin, "Message Submission
>                          for Mail", STD 72, RFC 6409, November 2011.
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 13]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
> 11.2.  Informative References
>
>    [RFC1845]             Crocker, D. and N. Freed, "SMTP Service
>                          Extension for Checkpoint/Restart", RFC 1845,
>                          September 1995.
>
>    [RFC1870]             Klensin, J., Freed, N., and K. Moore, "SMTP
>                          Service Extension for Message Size
>                          Declaration", STD 10, RFC 1870, November 1995.
>
>    [RFC2156]             Kille, S., "MIXER (Mime Internet X.400 Enhanced
>                          Relay): Mapping between X.400 and RFC 822/
>                          MIME", RFC 2156, January 1998.
>
>    [RFC2205]             Braden, B., Zhang, L., Berson, S., Herzog, S.,
>                          and S. Jamin, "Resource ReSerVation Protocol
>                          (RSVP) -- Version 1 Functional Specification",
>                          RFC 2205, September 1997.
>
>    [RFC2474]             Nichols, K., Blake, S., Baker, F., and D.
>                          Black, "Definition of the Differentiated
>                          Services Field (DS Field) in the IPv4 and IPv6
>                          Headers", RFC 2474, December 1998.
>
>    [RFC2852]             Newman, D., "Deliver By SMTP Service
>                          Extension", RFC 2852, June 2000.
>
>    [RFC4190]             Carlberg, K., Brown, I., and C. Beard,
>                          "Framework for Supporting Emergency
>                          Telecommunications Service (ETS) in IP
>                          Telephony", RFC 4190, November 2005.
>
>    [RFC4412]             Schulzrinne, H. and J. Polk, "Communications
>                          Resource Priority for the Session Initiation
>                          Protocol (SIP)", RFC 4412, February 2006.
>
>    [PRIORITY-TUNNELING]  Melnikov, A. and K. Carlberg, "Tunneling of
>                          SMTP Message Transfer Priorities",
>                          draft-melnikov-smtp-priority-tunneling-00 (work
>                          in progress), 2012.
>
>    [ACP123]              CCEB, "Common Messaging strategy and
>                          procedures", ACP 123, May 2009.
>
>    [STANAG-4406]         NATO, "STANAG 4406 Edition 2: Military Message
>                          Handling System", STANAG 4406, March 2005.
>
>    [GREYLISTING]         Kucherawy, M. and D. Crocker, "Email
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 14]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>                          Greylisting: An Applicability Statement for
>                          SMTP", draft-ietf-appsawg-greylisting (work in
>                          progress), April 2012.
>
>    [RFC4125]             Le Faucheur, F. and W. Lai, "Maximum Allocation
>                          Bandwidth Constraints Model for Diffserv-aware
>                          MPLS Traffic Engineering", RFC 4125, June 2005.
>
>    [RFC4127]             Le Faucheur, F., "Russian Dolls Bandwidth
>                          Constraints Model for Diffserv-aware MPLS
>                          Traffic Engineering", RFC 4127, June 2005.
>
>    [RFC6401]             Le Faucheur, F., Polk, J., and K. Carlberg,
>                          "RSVP Extensions for Admission Priority",
>                          RFC 6401, October 2011.
>
> Appendix A.  Mapping of MT-PRIORITY parameter values for Military
>              Messaging
>
>    Military Messaging as specified in ACP 123 [ACP123] (also specified
>    in STANAG 4406 [STANAG-4406]) defines six priority values.  Where
>    SMTP is used to support military messaging, the following mappings
>    SHOULD be used.
>
>             Recommended mapping of MT-PRIORITY values for MMHS
>
>                       +----------------+-----------+
>                       | Priority value | MMHS name |
>                       +----------------+-----------+
>                       |       -4       | Deferred  |
>                       |       -2       | Routine   |
>                       |        0       | Priority  |
>                       |        2       | Immediate |
>                       |        4       | Flash     |
>                       |        6       | Override  |
>                       +----------------+-----------+
>
>                                   Table 1
>
> Appendix B.  Mapping of MT-PRIORITY parameter values for MIXER
>
>    MIXER [RFC2156] defines the Priority header field with 3 values.
>    Where SMTP is used to support military messaging, the following
>    mappings SHOULD be used.
>
>
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 15]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>             Recommended mapping of MT-PRIORITY values for MIXER
>
>                +----------------------+-------------------+
>                | MIXER Priority value | MT-PRIORITY value |
>                +----------------------+-------------------+
>                | non-urgent           | -4                |
>                | normal               | 0                 |
>                | urgent               | 4                 |
>                +----------------------+-------------------+
>
>                                   Table 2
>
> Appendix C.  Mapping of National Security / Emergency Preparedness
>              (NS/EP) Values
>
>    There are several forms of communication systems used during an
>    emergency or disaster.  The most well known form involves the many-
>    to-one model of the general public contacting a public safety access
>    point via 911/999/112 calls through the public telephone network.
>    Typically, these calls do not require authorization, nor do they
>    invoke any prioritization.
>
>    Another form of emergency communications involves a set of authorized
>    users or nodes that use prioritized services to help established and
>    continue communication given limited available resources.  [RFC4190]
>    includes descriptions of several systems that have been developed to
>    support National Security / Emergency Preparedness (NS/EP).  These
>    deployed systems require a form of authentication and have focused on
>    prioritization of telephony based services.  They have also been
>    designed as a binary form (on/off) of signaled priority
>    communications.
>
>    [RFC4412] includes examples of a more expansive view of NS/EP
>    communications in which priority migrates from a single on/off bit
>    value to one that comprises five priority values.  This is shown in
>    the cases of the ETS and WPS Namespaces.  Given a lack of pre-
>    existing NS/EP values assigned for email, we follow the paradigm of
>    the ETS and WPS Namespaces and recommend five ascending values shown
>    in the table below.
>
>                    +----------------+------------------+
>                    | Priority value | Relational Order |
>                    +----------------+------------------+
>                    |       -2       | Lowest Priority  |
>                    |        0       | ----------       |
>                    |        2       | ----------       |
>                    |        4       | ----------       |
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 16]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>                    |        6       | Highest Priority |
>                    +----------------+------------------+
>
>    As in the case of Appendix A and B, the gap in numeric values listed
>    in this table provides room for future changes to expand the set of
>    priorities at a future date, or in a local and non-standardized
>    manner.
>
> Appendix D.  Two possible implementation strategies
>
>    This appendix suggest some implementation strategies to implement the
>    SMTP extension defined in this document.  The list is not exhaustive.
>
>    This appendix and its subsections are Informative.
>
> D.1.  Probability
>
>    As the name suggests, probability involves increasing the chances of
>    obtaining resources without adversely affecting previously
>    established connections.  One example would involve requesting
>    resources set aside for specific priority levels.  If these
>    additional resources are exhausted, then the desired connection is
>    denied.  Queues, new timers, or combinations thereof can be used to
>    facilitate the higher priority requests, but the key is that
>    mechanisms focus on increasing the probability of message transfer.
>
> D.2.  Preemption of sessions or transactions
>
>    Preemption is a type of action that focuses only on a comparison of
>    priorities to determine if previously established transactions must

    must -> need to


>    be displaced in favor of higher priority requests.  If no additional
>    connection is possible, the client aborts a running session for
>    emails with lower priority no later than directly after the current
>    transaction.  The client even can interrupt an active transaction and
>    should do so, if other constraints such as delivery time (as

    should -> ought to


>    specified in the DELIVERBY SMTP extension [RFC2852]) would be
>    violated for the email with higher priority.  When interrupting an
>    active transaction, the client should take the total message size and

    should -> ought to


>    the size of the transferred portion of the message being interrupted
>    into consideration.  This preliminary termination of sessions or
>    transactions is called preemption.
>
>    If preemption of running transactions occurs, the client must choose

    must -> needs to


>    a transaction with the lowest priority currently processed.
>
>    If the client has an option (i.e. it is supported by the next hop
>    MTA) to interrupt transactions in a way that it can be restarted at
>    the interruption point later, it should deploy it.  An example for a

    should -> ought to


>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 17]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
>    mechanism providing such a service is the "SMTP Service Extension for
>    Checkpoint/Restart" defined in [RFC1845].
>
>    If a client opts for the preemption of sessions instead of
>    transactions, it must preempt the next session that reaches the end

    must -> needs to

>    of a transaction.
>
> D.3.  Resource Allocation Models
>
>    Adding prioritization to a design moves the subject away from
>    strictly best effort (and a first-come-first-served model) to one
>    that includes admission control and resource allocation models.  Over
>    the years, a variety of work has been done within the IETF in
>    specifying resource allocations models.  Examples include the Maximum
>    Allocation Model [RFC4125], the Russian Dolls Model [RFC4127], and
>    the Priority Bypass Model (Appendix A.3 of [RFC6401]).
>
>    While we recognize that these various models have been designed for
>    other protocols (i.e., MPLS and RSVP), an understanding of their
>    design characteristics may be beneficial in considering future
>    implementations of a priority SMTP service.
>
> Appendix E.  Acknowledgements
>
>    This document copies lots of text from
>    draft-schmeing-smtp-priorities-04.txt and
>    draft-schmeing-smtp-priorities-05.txt.  So the authors of this
>    document would like to acknowledge contributions made by the authors
>    of draft-schmeing-smtp-priorities: Michael Schmeing and Jan-Wilhelm
>    Brendecke.
>
>    Many thanks for input provided by Steve Kille, David Wilson, John
>    Klensin, Dave Crocker, Graeme Lunt, Alessandro Vesely, Barry Leiba,
>    Bill McQuillan, Murray Kucherawy, SM, Glenn Parsons, Pete Resnick,
>    Chris Newman, Ned Freed and Claudio Allocchio.
>
>    Special thanks to Barry Leiba for agreeing to shepherd this document.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 18]
> 
> Internet-Draft  Message Transfer Priority SMTP Extension        May 2012
>
>
> Authors' Addresses
>
>    Alexey Melnikov
>    Isode Ltd
>    5 Castle Business Village
>    36 Station Road
>    Hampton, Middlesex  TW12 2BX
>    UK
>
>    EMail: [e-mail]
>
>
>    Ken Carlberg
>    G11
>    1601 Clarendon Blvd, #203
>    Arlington, VA  22209
>    USA
>
>    EMail: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 19]
> 


-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net