Re: Last Call: <draft-melnikov-smtp-priority-07.txt> (Simple Mail Transfer Protocol extension for Message Transfer Priorities) to Proposed Standard

[Alexey Melnikov <[e-mail]>]

Hi Ned,

On 05/03/2012 15:34, Ned Freed wrote:
>> > That said, I think an important omission in this document is that it
>> > only allows MSA's to change message priorities to conform to site 
>> policy.
>> > MTAs should also be allowed to do this.
>
>> Can you elaborate a bit more on possible use cases?
>
> Nobody is going to simply allow priorities to be set willy-nilly on 
> mail coming
> from random sources outside their administrative domain. That's absurd.
Agreed.
> However, they may be will to make bilateral arrangements with selected
> partners, identified by IP address or whatever, that would allow such a
> setting, perhaps within a restricted range of allowed values.
Right. Not allowing this actually bothered me. So I've reworded to allow 
for that.
>> Would such an MTA
>> only lower the priority or do you think it might also raise it?
>
> I don't see any reason to limit it to lowering it.
>
>> > Another issue is the silly prohibition against using Priority: and 
>> other header
>> > fields to set priority levels. What if is existing site policy is 
>> in fact to
>> > use those fields to determine message priority?
>
>> (Ignoring the question of whether use of MT-Priority header field is a
>> good thing or not for a moment.)
>
>> I actually don't have a strong feeling against usage of other existing
>> header fields.  Some of the existing header fields don't have the exact
>> semantics desired here.
>
> Well, sure. You most definitely don't want to mix in Importance or other
> MUA level priority fields.
>
>> Others (like the MIXER's Priority) have the right semantics but don't 
>> support
>> sufficient number of priorities required by MMHS (6 levels).
>
> I think you're going to have to accept the fact that the overwhelming 
> majority
> of people out there running email systems have never even heard of 
> MMHS and
> even if they have don't give a damn about faithfully retaining it's
> semantics. But they do care that new mechanism be made compatible with
> whatever ad-hoc scheme they are currently using, even if said scheme
> doesn't have the full range of values.
>
> For example, I can easily see a site wanting to map this to and from 
> the field
> used by Microsoft Exchange (sorry, I forget the exact name) even 
> though if
> memory serves that field only accepts three values. And either this is 
> going to
> happen no matter what the specification says, or the specification 
> simply won't
> deploy in any meaningful way.
Ok, I tend to agree. Our implementation will do this kind of mapping in 
absence of MT-Priority anyway.
>> That is why a new header field was introduced.
>
>> But anyway, I am happy for this restriction to be removed/relaxed. 
>> Can you
>> recommend some specific text?
>
> I'll try to do so later this week.
Is the following better:

<t>The Importance <xref target="RFC2156"/> header field MUST NOT be used 
for determining
       the priority under this "Priority Message Handling" SMTP extension.
       In absence of both the PRIORITY MAIL FROM parameter and the 
MT-Priority header field,
       other message header fields, such as Priority <xref 
target="RFC2156"/> and X-Priority,
       MAY be used for determining the priority under this "Priority 
Message Handling" SMTP extension.
</t>
?