Subject: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-13

From: S Moonesamy <[email-masked]>
Date: Mon, 21 May 2012 15:05:25 -0700

I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on AppsDir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

The comments in this review do not bear more weight than comments 
submitted by an individual during a Last Call.  It is suggested that 
the author ask the document shepherd for guidance about any changes 
suggested in a review.

Please note that this is a follow-up to a previous review.

Document: draft-melnikov-smtp-priority-13
Title: Simple Mail Transfer Protocol extension for Message Transfer Priorities
Reviewer: S. Moonesamy
Review Date: May 21, 2012
IETF Last Call Date: May 28, 2012

Summary:  This draft is ready for publication as a Proposed Standard.

This memo defines an extension to the SMTP service whereby messages 
are sent with a priority to enable receivers to take this into 
account.  The draft is well-written.

Major issues: None

Minor issues:

In Section 10:

I could have classified this under nits.  The authors already 
understand that it is not really an issue.

   "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."

I would have used a "SHOULD only allow authenticated users" and 
explain that there is a policy override.  It's to get around the 
"MUST implement a policy".  I think what you want to say here is to 
implement a setting that is customizable.  You also get a default 
where SMTP clients cannot abuse the feature.  I am ok with a "no text change".

Nits:

I recommend taking anything beyond this point off-list if feedback is 
desired.  Nits do not have to be addressed as it is an editorial decision.

In the Abstract:

   "This memo defines an extension to the SMTP (Simple Mail Transfer
    Protocol) service"

You don't really need to expand SMTP.

In Section 1:

   "This specification defines this mechanism by specification of
    an SMTP [RFC5321] extension."

The term "service extension" is generally used.

In Section 2:

   '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.'

I suggest "upper case" instead of "ALL CAPS".

In Section 3:

   "The maximum length of a MAIL FROM command line is increased by 15
    characters by the possible addition of the MT-PRIORITY keyword
    and value."

RFC 5321 uses the term "octets" instead of "characters".

In Section 4.1:

   "The SMTP server MAY also alter the message priority (to lower or to
    raise it)"

I suggest: (lower or raise it)".

The specification specifies that the service extension is valid on 
the Submission port.  I don't see this mentioned in the IANA 
Considerations Section.  It can be done during the interaction with IANA.

Appendix C:

  "Communication systems used during an emergency or disaster are
   realized in several forms."

I'll suggest:

   There are several forms of communication systems used during an emergency
   or disaster.

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 May 2012 19:39:23 -0400

> I could have classified this under nits.  The authors already understand
> that it is not really an issue.

Understood also.  Still, opinion:

>>  Message Submission Agents MUST implement a policy that only allows
>>  override the priority values specified by MUAs.
>
> I would have used a "SHOULD only allow authenticated users" and explain that
> there is a policy override.  It's to get around the "MUST implement a
> policy".

I think I actually prefer it the way it is, because it highlights the
key point that this is all a policy decision.  If, in fact, an
implementation should allow a policy that everyone's considered
authenticated, and some deployment should choose that policy, I'd be
fine with it... because they have chosen their policy.

>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>> appear in ALL CAPS.

As this is my text, which I gave Alexey, I clearly prefer "ALL CAPS".
I like that it's demonstrative.  On the other hand, the discussion on
ietf.org about whether this is a wise idea or not brings up other
issues of more substance.

> RFC 5321 uses the term "octets" instead of "characters".

I'd put this as a minor issue, rather than a nit, and strongly suggest
that it be changed.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 21 May 2012 19:41:36 -0400

[Re-sending this with the correct draft alias (without the version number).]

Barry

---

From: S Moonesamy <[email-masked]>
Date: Mon, 21 May 2012 17:05:37 -0700

Hi Barry,
>[Re-sending this with the correct draft alias (without the version number).]

Thanks.  I preferred not resend the message to avoid generating mail traffic.

>fine with it... because they have chosen their policy.

Ok.

>issues of more substance.

I'll stay out of that discussion.

>I'd put this as a minor issue, rather than a nit, and strongly suggest

That was my first thought.

I consider the comments were addressed.

Regards,
S. Moonesamy

---

From: t.petch <[email-masked]>
Date: Tue, 22 May 2012 10:49:50 +0100

----- Original Message -----
From: "S Moonesamy" <[email-masked]>
To: "Barry Leiba" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Tuesday, May 22, 2012 1:05 AM

> I'll stay out of that discussion.

Mmm ... I think it worth noting that CAPS (or caps) is a proper English
term but not the one which is meant here:-(  What is meant here is ALL
CAPITALS which, when abbreviated, should have a period inserted; I find
it ironic that the attempt to be more precise should in fact be less so.

And yes, I am being serious.  As expert English speakers, you and I have
no problem with equating CAP with capital as opposed to cap (on your
head - or not, as the case may be) but these documents are being written
for a world-wide audience, whose English may not be expert and of whom
we should be considerate.

Tom Petch

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 22 May 2012 08:55:18 -0400

> it ironic that the attempt to be more precise should in fact be less so.

That's just silly.  It's a term of art, it's in every dictionary, and
a wikipedia search gives a nice, lengthy explanation.  And, no, it
does not and should not have a period.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 24 May 2012 09:30:17 +0100

Hi SM,
Thanks for the review.

On 21/05/2012 23:05, S Moonesamy wrote:
> I have been selected as the Applications Area Directorate reviewer for 
> this draft (for background on AppsDir, please see 
> explain that there is a policy override.  It's to get around the "MUST 
> implement a policy".  I think what you want to say here is to 

I tend to agree with Barry that this should remain MUST.

> I suggest "upper case" instead of "ALL CAPS".

I leave it to Barry and others to decide :-).

> RFC 5321 uses the term "octets" instead of "characters".

Changed.

> I suggest: (lower or raise it)".

If you don't mind, I leave this sort of stuff to RFC Editor.
>
> The specification specifies that the service extension is valid on the 
> Submission port.  I don't see this mentioned in the IANA 

This is the default (IANA's web page says that all extensions are 
suitable for Submission port, unless specified otherwise). But I will 
add a clarifying sentence.
>   There are several forms of communication systems used during an 

Changed in my copy.

Thanks,
Alexey

---

From: S Moonesamy <[email-masked]>
Date: Thu, 24 May 2012 02:29:54 -0700

Hi Alexey,

Ok.

Ok.

>suitable for Submission port, unless specified otherwise). But I 
>will add a clarifying sentence.

Ok.

For information, Section 7 of RFC 6409 mentions that "future SMTP 
extensions SHOULD explicitly specify if they are valid on the 
Submission port".  The draft specifies that in item 7 of Section 3.

Thanks for addressing the comments.

Regards,
S. Moonesamy

---

From: Pete Resnick <[email-masked]>
Date: Tue, 29 May 2012 10:04:20 -0500

> fine with it... because they have chosen their policy.

But then the "MUST implement a policy that only allows authenticated 
users" would be bogus, because they didn't do that.

> I tend to agree with Barry that this should remain MUST.

To agree with SM to an extent: If it needs to be a MUST, why is it not 
"Message Submission Agents MUST only allow authenticated users..."? 
What's with the "implement a policy" thing?

I think you have to make a decision here: If you think that it harms 
things to have unauthenticated users specifying priorities, say "MUST 
only allow authenticated users". If you think that it's OK to set policy 
to allow anyone, say, "SHOULD only allow authenticated users" and 
explain that policy can change that. I have no idea how the current text 
is reasonably actionable.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Tue, 29 May 2012 10:11:25 -0500

[*Mumble* Wrong draft address again.]

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Tue, 29 May 2012 12:30:00 -0400

--On Tuesday, May 29, 2012 10:04 -0500 Pete Resnick
<[email-masked]> wrote:

>...
> I think you have to make a decision here: If you think that it
> harms things to have unauthenticated users specifying
> priorities, say "MUST only allow authenticated users". If you
> think that it's OK to set policy to allow anyone, say, "SHOULD
> only allow authenticated users" and explain that policy can
> change that. I have no idea how the current text is reasonably
> actionable.

Yes.

This may just be saying what Pete said in a different way but,
fwiw, it seems to me that the recipient is free to ignore a
priority specification (or (almost ?) any other header field or
piece of the envelope that tells it to do something) and to
apply whatever criteria it likes in deciding whether or not to
do so.  We don't even say "the final deliver server MUST deliver
the message to the RCPT address specified in the envelope" and
that is only in part because local aliases and a whole
collection of delivery system choices might affect that choice.
Even if the sender is authenticated, the relevant server might
decide to ignore priorities specified by anyone with an odd
number of characters in the local-part of the MAIL command or to
accept them if some other information --which we would not
consider authentication-- is present.

Given that issue, it seems to me that specifying a MUST both
implies a requirement on the recipient system that we can't
enforce and possibly creates unreasonable expectations for the
facility.

Ultimately, if one argues that having unauthenticated senders
specify priorities is harmful, one could also argue that it
causes harm to allow unauthenticated users to specify "From:"
fields.  Probably true; not helpful; clearly undesirable if
coupled with the logically-consequent "MUST not accept" such
main requirement on the recipient server.

Maybe this should be a SHOULD.  Maybe it should only be a
careful note in Security Considerations indicating that taking
action on a priority request that might have any disruptive
consequences is a really bad idea unless the sender is
authenticated and possibly even a bad idea unless the sender is
specifically authorized.  It seems to me that it is connected to
another issue, which is whether or not it makes sense to reject
a message for too low a priority when almost no semantics beyond
ordinality are specified for the priority model.  So the server
is forbidden to reject a message because no MT-PRIORITY is
specified (Section 4.1 (1)); the default priority in the absence
of

More generally, we seem to be examining and adding extensions
and headers that are actually useful only within particular
communities that share out-of-band information.  This draft is
sensitive enough to the issue that I don't see a need to
complain, but we should figure out how we want to handle them.
Specifically, one could see the conformity clauses being
organized as (I'm going to write more generally than this spec
requires):

1.  If originator, current hop client, current hop server, and
maybe destination address are all part of the same community,
then there are a bunch of rules that might reasonably include:

	(i) Current hop client, current hop server and, if
	relevant, destination server, must be authenticated and
	identified as part of the same community ("identified"
	is chosen rather than "authorized" because they might
	not be the same).
	
	(ii) Current hop server MUST support the extension.  If
	it doesn't, it is bogus and the message MUST NOT be
	passed to it.
	
	(iii) Current hop client SHOULD specify MT-PRIORITY.  If
	it doesn't, it is retarded and better have specified why
	(perhaps via some out of band related to community
	membership).
	
	(iv) Semantics for priorities are precisely specified
	within the community so there is no need for hand waving
	in the spec about ordinal matching or servers making up
	their own rules.

"Community" is not equivalent to "administrative domain" even
though many administrative domains will be communities.  So will
protected intra-organizational mail whether an administrative
domain exists or not.

(2) If, by contrast, no such community membership exists, then
this extension is pretty close to "this is what the sender might
try, but this is ultimately a "what you get is what you get"
service.

In theory, we would write a spec like that by specifying that
WYGWYG service and conformance to it in the protocol, then
providing a separate Applicability Statement that provides
different definitions and conformance rules for the XYZ
community.

I think it is possible, but hard, to mix the two within a given
draft.  The current draft provides a better approximation than
I'd normally expect.  But I think this "MUST.. authenticated"
issue is just a special case of confusion between the two.

   john

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 May 2012 18:07:44 +0100

On 29/05/2012 16:04, Pete Resnick wrote:
>>> explain that
> only allow authenticated users". If you think that it's OK to set 
> policy to allow anyone, say, "SHOULD only allow authenticated users" 
> and explain that policy can change that. I have no idea how the 
> current text is reasonably actionable.

I mostly used the current wording to avoid discussing what is 
authentication. I didn't mean "authentication with SMTP AUTH", because 
authentication by IP address is quite common (and sufficient in some 
environments).

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 May 2012 13:30:19 -0400

> authentication by IP address is quite common (and sufficient in some

Indeed, and how we used to use "pop-before-smtp".

Maybe the best thing to do is to change this to say something like this:

 Message Submission Agents ought only accept message transfer
 priorities from users (or groups of users) who are authenticated in some
 way that's acceptable to the MSA.  As part of this policy, they can also
 restrict maximum priority values that different groups of users can
 request, and can override the priority values specified by MUAs.

Note also the shift from normative language here, because it's
entirely a policy decision.  If you want to let the inmates run your
asylum, well, knock yourself out.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 May 2012 13:31:47 -0400

ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRGH!
WE HAVE TO STOP REPLYING TO THE ONE WITH THE WRONG ALIAS !!!!!

Barry

---

From: S Moonesamy <[email-masked]>
Date: Wed, 30 May 2012 11:17:46 -0700

Hi Alexey,

[fixed incorrect alias]

At 10:07 30-05-2012, Alexey Melnikov wrote:
>authentication. I didn't mean "authentication with SMTP AUTH", 
>because authentication by IP address is quite common (and sufficient 
>in some environments).

For context, Section 10 of draft-melnikov-smtp-priority-14 states that:

And in the last paragraph of that section:

   "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."

You have "authenticated and trusted senders" in the second paragraph; 
you could use that.  Barry mentioned that authenticated does not mean 
SMTP AUTH [1].  Section 3.3 if RFC 6409 discusses about authorized 
submission.  I could argue that MSAs usually enforce authorized 
submission.  The second sentence suggested by Barry might capture 
some of your intent in my opinion:

   "As part of this policy, they can also restrict maximum priority values
    that different groups of users can request, and can override the priority
    values specified by MUAs."

The alternatives, as I see it, for the first sentence are:

  (a) Do you want people to go and write code so that the site administrator
      can enforce such a policy?

  (b) Do you want people to "think" about this as a security consideration?

  (c) Do you want to enjoy the summer weather instead of generating more
      mail traffic?

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06056.html

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 May 2012 09:39:55 +0200

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
>
>    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:<[email-masked]> BY=120;R ENVID=QQ314159
>             MT-PRIORITY=3
>         S: 250 <[email-masked]> sender ok
>         C: RCPT TO:<[email-masked]>
>         S: 250 <[email-masked]> recipient ok
>         C: RCPT TO:<[email-masked]> NOTIFY=SUCCESS,FAILURE
>             ORCPT=rfc822;[email-masked]
>         S: 250 <[email-masked]> 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
>

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
>    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: [email-masked]
>
>
>    Ken Carlberg
>    G11
>    1601 Clarendon Blvd, #203
>    Arlington, VA  22209
>    USA
>
>    EMail: [email-masked]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melnikov & Carlberg     Expires November 25, 2012              [Page 19]
> 

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Thu, 31 May 2012 09:49:54 +0200

So:

    send -> relay

    may -> can

    may -> can

    may -> can

    case -> cases

Perhaps:

oh?  "can be"?

    for -> form  (?)

    may -> can

"strongly advised"?

    server -> servers

    must -> need to

    should -> ought to

    should -> ought to

    must -> needs to

    should -> ought to

    must -> needs to

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 31 May 2012 16:22:55 +0100

On 30/05/2012 19:17, S Moonesamy wrote:
> you could use that.

I am not entirely sure what you are suggesting.

> Barry mentioned that authenticated does not mean SMTP AUTH [1].  
> Section 3.3 if RFC 6409 discusses about authorized submission.  I 
> could argue that MSAs usually enforce authorized submission.  The 
> second sentence suggested by Barry might capture some of your intent 
> in my opinion:
>

I want server developers to take this into consideration and expose any 
possible management knobs to administrators.

Yes.

>  (c) Do you want to enjoy the summer weather instead of generating more

Most certainly, yes :-).

> Regards,
> S. Moonesamy
>
> 1. 
> http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06056.html
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 31 May 2012 13:10:58 -0700

Hi Alexey,
>I am not entirely sure what you are suggesting.

"authenticated or trusted senders" allows you to cover the range of 
cases such as POP3-before-SMTP, SMTP AUTH, IP-based authorization, etc.

>Most certainly, yes :-).

As you picked (b) and (c), I'll suggest text (I reused some text from Barry):

   Allowing authenticated or trusted senders, or only certain groups of
   senders, to specify a message transfer priority when a message is
   submitted through a MSA or relayed through a MTA is a matter of site
   policy.  As part of this policy, they can restrict maximum priority values
   that different groups of senders can request and can override the priority
   values specified.

   In the absence of such a policy an SMTP server (whether a MSA or a MTA)
   implementing this SMTP extension is 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.

I removed the second paragraph of Section 10.

Regards,
S. Moonesamy