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

Alexey Melnikov <> Fri, 01 June 2012 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BF2BC11E8106; Fri, 1 Jun 2012 06:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.914
X-Spam-Status: No, score=-102.914 tagged_above=-999 required=5 tests=[AWL=-0.315, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iE5m5Hkq0pz9; Fri, 1 Jun 2012 06:23:28 -0700 (PDT)
Received: from ( [IPv6:2a00:14f0:e000:7c::2]) by (Postfix) with ESMTP id 64E3611E8089; Fri, 1 Jun 2012 06:23:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338557006;; s=selector;; bh=vkPlyMXzLw7INl3frsCgq7Br3GPg7TwWqXST2FrLFrM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=cu8/o9ICH80O8XfISOdofoG2l07qMqETXALW5GExmPfxfv6aBDRRNxEJUYwphn5jET2JfZ 9zagv6Zzj1lrsA9BOh0kaD+zFt1gpBqe5L+oYMKeSQmPDgFZmXRV7sr2F423NBl92cnVYI AtCOZj+0l+c8xS0Ga+qn8cNKjz4gA2w=;
Received: from [] ((unknown) []) by (submission channel) via TCP with ESMTPSA id <>; Fri, 1 Jun 2012 14:23:25 +0100
Message-ID: <>
Date: Fri, 01 Jun 2012 11:28:01 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 13:23:30 -0000

On 31/05/2012 08:49, Dave Crocker wrote:
> This review is at my own initiative.

Thank you for the review.

I've applied most of your editorial changes (and spelling fixes) as is. 
I've deleted them from my reply.
I will reply to different parts of your review in separate messages.

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

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.

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

Good point. Deleted.

>>    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)?

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

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

Ok. I used a slightly modified version of your suggested text.

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

Suggested replacement?

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

This is the same as for the DSN SMTP extension. So no, this is not the 
first time.
> 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?

The point is that if I am trying to gateway to the Royal Pigeon Mail 
Service and it doesn't support anything similar to priorities at the 
protocol level, then this is treated as relaying to a non-conformant 
SMTP server.

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

I don't know either :-).

>> 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?

Any suggested text?

>>    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?

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

Should have been "MAY 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.

Well, simplification doesn't apply to everything in this extension. Some 
tradeoffs were made....

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

>> 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.
Suggestions for alternatives are welcomed.

> 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 ;-).

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.

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