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-13 07:35:37

Alessandro,

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?

Given your description above, my initial reaction would be to not allow (or 
just to heavily discourage) the example that you give above.  I still need to 
think about this some more, but I would have a preference to maintain the 
consistency of the value of the signaled priority.  On the other hand, if there 
was a need for a local decision of how to service the set of prioritized 
messages, then perhaps weights could be set/changed in terms of how to service 
queues.

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
secondary target.

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.

As a side note, Alexey and I had a lengthy discussion of resource utilization, 
and tried to articulate some of this thought in sections 5.1.1 (probability) 
and 5.1.2 (preemption).  There are systems out there today that have a 
requirement for preemptive service -- to the point of indefinitely starving out 
other messages (and clearly, an extreme case).  And other systems have a 
requirement of focusing on probability so that all messages get 
serviced/forwarded, but that some will be treated preferentially over others.

-ken