[Top] [All Lists]

More comments on: draft-melnikov-smtp-priority-02

2011-07-12 12:21:40

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.

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
the field.

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
large lists.  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?