I agree with you and with the sentence "Postfix is designed to work on a mail queue of any size. This is possible because Postfix works with a fixed memory budget.", and we don't want to break the architecture.
What I'm talking about at this stage, it's if the scheduling algorithm we are asking for could be a good choice for an "only outgoing/relay" SMTP server. I know that the instruction "foreach transport's job (round-robin by ip or auth-user)" is too much superficial to address completely the problem but, if there is interest, I'm sure that we could find a solution to solve the issue. I've saw the idea behind "dead destination", "preemption", "dealing with memory resource limits"; similar ways could be applied to our request: we could limit the size of the customers queue, we could limit the size of each customer queue with a max number of messages, ... (others); it may be that the solution will not be fair at 100%, but a little less could be enough to address the problem. I'd like to know if we can engage someone that works on the core of postfix to implement our feature. We'd like to have this feature on our servers and so we are also glad to pay for someone that can agree with us and that could collaborate with us to implement this request. I'm not so familiar with feature request in open source project, so I apologize if I'm not following the "right procedure". Regards Giorgio Luchi -----Messaggio originale----- Da: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Per conto di Wietse Venema Inviato: sabato 6 aprile 2013 15:01 A: Postfix users Oggetto: Re: R: Scheduling policies for outgoing smtp server If you want to prevent one customer from overtaking the mail queue with a million submissions, then I suggest that you enforce a rate limit on the sender (for example with postfwd). Tell the customers that they can send up to N messages per hour. This also helps to limit the damage when one customer becomes infected with malware. > foreach transport's job (round-robin by ip or auth-user) I see. For your idea to work, Postfix would need to keep knowledge about THE COMPLETE MAIL QUEUE in memory. That would limit the amount of mail that Postfix can handle. (alternatively Postfix could maintain one on-disk queue per customer and examine only the first per-queue work items, but managing lots of queues would degrade I/O performance). Instead, Postfix is designed to work on a mail queue of any size. This is possible because Postfix works with a fixed memory budget. Unlike the solution that you propose, Postfix will not become stuck and require human intervention when a work load becomes larger than anticipated. There must be other solutions that can work with a fixed memory budget and that can push excessive mail to a "low-priority" queue that is processed when it does not interfere with other delivery. Any solution that requires knowledge of THE COMPLETE MAIL QUEUE will be firmly rejected. I will not allow a built-in limitation on the amount of mail that Postfix can handle. Wietse
