Thank you for your comments.
On 12/07/2011 18:06, Alessandro Vesely wrote:
There is no requirement to use SMTP AUTH before using this extension
(althought it would have been a good idea). But in general, I think
emphasizing that priority for unauthenticated messages shouldn't be
trusted is important in the Security Considerations section.
Two comments for section 10, Security Considerations:
First, the phrase
Message Submission Agents can
implement a policy that only allows authenticated users (or only
certain authenticated users) to specify message priorities
seems redundant. Since the message priority can only be specified
during transactions and authentication is implied at such stage, the
parenthesized "only certain" is the working case.
Right. This is indeed a problem. But I am not yet sure what would be
more important - preserving the priority value (in case some downstream
MTA support it), or preserving the DKIM Signature. I need to think a bit
more about that.
Second, protecting MT-Priority by DKIM-signing it results in broken
signatures in case the priority is altered by a conforming server
before relaying to a non-conforming one.
If it has to be signed, I'd
suggest to revise Section 4.4 so as to never formally alter the field
after it has been signed (presumably by the MSA). Further MTAs may
treat the message as if it had a lower priority even without altering
I'd also put a question about section 4.5, Mailing lists and Aliases.
Requiring that the existing priority is retained across expansions
apparently discourages the use of low/negative priority for running
Yes, but it is a SHOULD level requirement (as opposed to a MUST).
I don't think this is prohibited, but can you elaborate on why this
would be desirable? For example, while not keep the priority -3 when
generating multiple messages?
Would it make sense, instead, to have a process that
collects a message with, say, priority -3 and 1000 recipients and
re-queues it as 10 conveniently staggered messages with priority -2
and 100 recipients each?