Ned:
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?
Alexey:
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.
Right, this is the issue I have with Ned's desire to allow use of
other fields: those fields have inconsistent semantics, and
inconsistent and non-standard usage. They're often used to indicate
visual importance of the message to the MUA, rather than anything
related to transmission priority.
That said, I'd have no problem with some sort of MAY-level permission
to *MSAs* to use these fields. I'd feel very uncomfortable allowing
*MTAs* to do it. Ned, would it be adequate to your needs to handle it
that way? Something like this:
OLD
Other message header fields, such as Importance [RFC2156], Priority
[RFC2156] and X-Priority, MUST NOT be used for determining the
priority under this "Priority Message Handling" SMTP extension.
NEW
Other message header fields, such as Importance [RFC2156], Priority
[RFC2156] and X-Priority, are used inconsistently and often with
different semantics from MT-Priority. Message Submission Agents
[RFC6409] MAY use such fields to assign an initial priority in the
absence of an SMTP PRIORITY parameter. Otherwise, such fields
MUST NOT be used for determining the priority under this "Priority
Message Handling" SMTP extension.
Barry
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf