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

[Alexey Melnikov <[e-mail]>]

Hi Dave,

On 01/06/2012 20:15, Dave Crocker wrote:
> On 6/1/2012 12:28 PM, Alexey Melnikov wrote:
>> On 31/05/2012 08:49, Dave Crocker wrote:
  [...]
>>>> 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.

To clarify I've changed that to "a negative priority". This is good 
enough for this example.

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

Ok, I've used your text.

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

The client can decide to use smaller values. In this case it is up to 
the client to pick them, this is not controlled by the site policy.

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

RFC 3461 is a separate specification, so mentioning it explicitly is, 
IMHO, quite appropriate.