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

Dave Crocker <> Fri, 01 June 2012 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BB4A11E80EE; Fri, 1 Jun 2012 12:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HkpGNB23JnpD; Fri, 1 Jun 2012 12:15:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E34C511E810C; Fri, 1 Jun 2012 12:15:45 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q51JFfAr030056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 1 Jun 2012 12:15:43 -0700
Message-ID: <>
Date: Fri, 01 Jun 2012 21:15:39 +0200
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Alexey Melnikov <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Fri, 01 Jun 2012 12:15:45 -0700 (PDT)
Subject: Re: [apps-discuss] Review of draft-melnikov-smtp-priority-14
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jun 2012 19:15:47 -0000

On 6/1/2012 12:28 PM, Alexey Melnikov wrote:
> On 31/05/2012 08:49, Dave Crocker wrote:
>> 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.
> I will let IESG weight in on this. I've implemented what I was told
> earlier. I don't have a strong opinion on this.

So we don't follow IETF consensus documents anymore for process and 
documentation conventions?  The IESG establishes those details at its whim?

>>> 5. If no priority has been determined by the above, the server may
>>> 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.
> Why is this a problem (commenting on the last sentence quoted above)?

It's quite basic.

The document specifies a standard but does not specify it completely. 
First, it periodically relies on undocumented policy assumptions. 
Second, policies will vary from one environment to the next.

As I note in the review, proper operation of a QOS mechanism requires 
all participants to operate according to the same policies.  I gave the 
example of two posters meaning 'average priority' but happening to 
choose different values for that semantic.  To get proper system 
operation, you and I and the other guy all need to choose the same value 
for the same semantic.  That requires a definition of the semantic; in 
this case that means rules for when to assign specific values.

In effect, the current document is a syntax mechanism for expressing 
priority, but it doesn't really specify actual priority semantics for 
making assignments, although it does hint at a particular set of 

So the document is both incomplete and overly rigid, IMO.  That's why I 
suggested providing an explicit and complete policy section as a 
default, but designed to allow alternative policy sections for other 

>>> 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.
> Yes, you misunderstood. The example talking about marketing messages is
> an example of a sender that explicitly requests priority below 0.

But there is no inherent meaning to "low priority", absent a policy 
statement that defines the meaning of values.  Low is relative to other 
values, but which ones?  In some environments -5 is low and in others 0 
is low and I'll bet some others will treat 5 as low.

>>> 4.4. Mailing lists and Aliases
>>> Several options exist to translate the address of an email recipient
>> "options"? Perhaps you mean mechanisms or services?
> Yes.
>> And they really aren't translating an address but are doing a form of
>> message transmission (relaying, or the like).
> Suggested replacement?

      Several types of mechanisms exist to redirect or forward messages 
to alternative or multiple addresses.[RFC5598]  Examples for this are 
aliases and mailing lists [RFC5321].

      If a message is subject to such processing, the Mediator node 
[rfc5598, Sec 2.1] SHOULD retain the MT-PRIORITY parameter value for all 
expanded and/or translated addresses.

>>> 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.
> What is a control message?

Chatter about handling activity is distinct from traffic comprising user 
payload (messages) even if a user is the recipient.  The chatter 
consists of control messages.  A delivery report is a control message.

> Any suggested text?

    Messages concerning email handling, such as delivery reports, 
constitute control information rather than direct message payload.  In 
some environments, control traffic is subject to higher priority 
handling and in others it receives the same priority as the message that 
caused the report to be generated.  Determining the priority to assign 
is a matter for the policy statements applying to the environment in 
which [RFC3461] is supported.

>>> 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.
> I don't think so. Why do you say that?

A rejection means that the message is outside an acceptable range. 
That's a policy for the environment and it does not make sense for an 
MSA to have one set of policies and MTAs to have another.

>>> 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?
> There is no issue and no real interaction in this specific case. A
> client that wants to use both against a server that supports both should
> consider this issue.

Specifications that say an implementer should consider something but 
which gives no guidance about the consideration aren't doing much 
useful, in my view.

As this set of text was proceeding, I thought it was going to provide 
some useful guidance about possible uses of the combined options, since 
it seemed like the combination could be, well, useful.

>>> 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...?)
> This section applies to system administrators. It is quite different
> from the rest of the document which contains mostly protocol level
> requirements. So yes, I avoided usage of RFC 2119 keywords here on purpose.

I think that is merely confusing.  Normative direction to operators is 
an entirely reasonable part of a specification.  Since that's really 
what you are doing, go ahead and use officially normative language.

> Suggestions for alternatives are welcomed.

Just convert to the normative terms that are appropriate.

>> 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.
> Nothing is instantaneous, so I am not very concerned ;-).

So the document is strongly advising something that is impossible to 
achieve, during a transition period.  It's worth considering how to 
handle that.

> Once some servers start supporting this extension a sysadmin can remove
> MXes for servers which don't support it. Upgrading all servers nearly
> simultaneously is another option.

Is it practical?

>>> 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"?
> Of course. I don't think this needs saying.

And yet the document says exactly that sort of qualifier earlier: "An 
MTA which also conforms to [RFC3461]..."


  Dave Crocker
  Brandenburg InternetWorking