ietf
[Top] [All Lists]

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

2012-03-05 21:12:35
   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.

It seems you're complaining about other people doing something they never
wanted to do while actually making that error yourself.

I have no idea what you mean, so perhaps you can be more specific
about what it is that you want to do.

I'm talking about the inclusion of Importance: in both the original and revised
text as a field we're suggesting might make sense to map. It should not be
there - the semantics are not compatible with MTA priority. And even if you
think it makes sense that messages marked "important" in the MUA should receive
an MTA priority boost, allow me to point out that by GOSIP rules (which are
still in effect in some places) elevated MTA priority is used to shorten the
time messages are retained before returning them as undeliverable. That's
really not a good idea to do for all messages marked "important", and some
people with systems that do this are probably unaware of the behavior.

Mind you, I have no problem with someone doing it because it makes sense in
their case. But we should not be suggesting doing it in the text, and getting
into a discussion of the pitfalls of doing it doesn't is unnecessarily
distracting.

The semantics of X-Priority are less clear. It's sometimes used for MTA
priority setting, other times it's been an MUA field. AFAIK it has never had
the problematic semantics I just discussed. Mapping it is therefore a judgement
call implementations should be allowed to make, and that makes it a good
example to include in this sort of text.

                                Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>