On 12/Jul/11 19:34, Alexey Melnikov wrote:
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
(I meant before using MSA)
(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.
Yes, that looks right. Then something like
Message Submission Agents /and SMTP servers/ can implement a...
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.
An MTA can also sign a message anew, after changing MT-Priority, if it
knows what it's doing --that is, if downstream agents trust its
signature better than the original one. OTOH, if using PRIORITY
breaks DKIM, people may want to avoid using both at the same time.
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
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?
Thank you for considering this problem. I've seen Bill's observation
on possible starvation at negative priorities, and wandered whether
PRIORITY could solve delayed relaying in general, possibly as a
Of course, there are myriads of full blown solutions for large scale
mailing. Still, some users prefer regular multi-recipient messages,
even at the costs of breaking their recipient list in chunks of
acceptable size, and managing bounces by themselves. As a side
effect, their behavior may delay normal messages that get queued
behind the bunch. For a local solution, a server may handle such
messages using a specific algorithm for scheduling retries, and do a
few recipients only on each retry.
Now, what if the server uses a smarthost? If its connection gets
idle, it is a good moment for transferring anything, even negative
priority messages. But how does it express the difference between a
whole-transfer and a specifically-scheduled partial relay? The latter
has paid its waiting time already, so it would seem fair to reset any
negative priority that might have been imposed on it on submission.