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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]