this is a german Web-Mirror of MHONARC.ORG powered by Domainunion AG

ietf-smtp
[Top] [All Lists]

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

2011-07-12 12:44:13

Hi Alessandro,
Thank you for your comments.

On 12/07/2011 18:06, Alessandro Vesely wrote:
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.
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.
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.
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.
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.
Yes, but it is a SHOULD level requirement (as opposed to a MUST).
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?
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?

Best Regards,
Alexey