Hi, I'm sorry for the delay, but I'm very busy in some projects. I continue the discussion with my opinion and some details.
No virtual machines and no multi instance solution: we have more than 10.000 customers, so these solutions are not applicable. We don't want to classify them (in order to have fewer outgoing queues). I'm thinking and trying to found a solution that could respect the indication "Postfix mustn't fail with more than N messages in the queue". I work for an ISP, so I consider "incoming" emails and "outgoing" emails as two separate services. The first is already served in the right way by the existing scheduling algorithm, for the second I think that there could be another separated scheduling algorithm. So I think about the possibility to choose a different algorithm by some configuration parameter (i.e. specifying in master.cf startup different options for different transports). >How does Postfix enforce per-destination concurrency policy, when mail is kept >in per-customer queues? Assuming that we choose the right algorithm for every transport (the default could be the existing one): - with "incoming" algorithm (the existing one): there is no need for "sender round-robin", in fact the current algorithm doesn't use sender information - with "outgoing" algorithm: it should be analogous; in this case we need to do only "sender round-robin", the destination doesn't matter. The "outgoing" scheduling algorithm looks like the "incoming" with the difference in the step of picking up the email (like I wrote in a previous post). How can we implement round-robin by sender ip/authenticated user and to preserve the memory constraint too? - "sender" is the sender's ip address or the authenticated user name (i.e. "80.93.143.50" or "giorgio.luchi") - "rrsender_message_limit" is the max number of messages in the sender queue (i.e. "3") - "rrsender_queue_limit" is the max number of senders actually loaded in RAM (i.e. "6000") - "What happens when Postfix opens a queue file and discovers that this customer's queue is full? Postfix must not open the same files again and again in an infinite loop, and Postfix must not have "foreach job in the queue" knowledge." - "We could move such messages to the deferred queue, but that would make queue management more expensive, replacing rename(incoming, active) +remove() with rename(incoming, deferred) +rename(deferred, active) +remove()": I think the solution should behaves as the second proposal. I know that it costs more in term of IOPS, but in our environment of ISP, we can spend some effort and money for this operation and accepting "lower performance" (we can gain the lost power, balancing the load with several dedicated servers) - so, at any time, in RAM there will be at maximum rrsender_queue_limit queues per rrsender_message_limit messages, it means 6000 different senders that need to send emails simultaneously (I think is a big number) - we could also implement preemption in an analogous way as the current scheduling manager do (if a message is sent to several recipients) I hope this can help in understanding and in finding a solution to what we need. Regards Giorgio Luchi
