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 02/03/2012 06:12, Ned Freed wrote:
>> The most significant item that needs to be called out is the issue of
>> tunneling the PRIORITY value through non-conforming MTAs by turning it
>> into a message header field (MT-Priority) and then back again.  This
>> is a problematic technique, but is an important capability for those
>> who need and intend to implement this extension.  It creates a trust
>> issue, wherein a message containing MT-Priority can be originated with
>> a Message Submission Agent that does not know about this extension,
>> and when the message hits a Message Transfer Agent that does support
>> this, the header field will be turned back into a valid PRIORITY
>> value, on the unwarranted assumption that it was authorized.
>> Intermediate MTAs have no way to distinguish this situation from one
>> where the field was tunneled legitimately.
> There may not be substantial experience with doing this sort of thing in SMTP
> relays, but there's plenty of experience doing it in gateways to other mail
> environments, e.g., X.400 and many of the old LAN email systems. In fact one of
> the more common fields that has been mapped this way is message transfer
> priority, so there is considerably experience with fields having more or less
> the same semantics as what is being proposed here.
Exactly.
> I am unaware of any cases where this was abused, probably because increased
> transfer priority doesn't buy you all that much in most cases. Related
> but more user-visible features, e.g., importance (in the X.400 sense)
> have been known to be abused, however.
>
> 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? Would such an MTA 
only lower the priority or do you think it might also raise 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. Others (like the MIXER's Priority) have the right semantics but don't support sufficient number of priorities required by MMHS (6 levels). 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?