On 4/8/2013 12:31 PM, Wietse Venema wrote: > Giorgio Luchi: >> 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. ... > How does Postfix enforce per-destination concurrency policy, when > mail is kept in per-customer queues? > > 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'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.
Isn't this a class of problem that can be fairly easily solved using virtual machines? Dedicate a VM and Postfix per customer, without needing to hack up the MTA. If the issue is "queue fairness" then one virtual machine per customer should address this. Disk space is so cheap today that dedicating a few GB to a queue for each customer isn't a limiting factor. With a sufficiently stripped down custom Linux or FreeBSD image the OS memory footprint should be small enough to pack many VMs/customers onto one machine. In the case of Linux one may be able to use KVM/KSM to consolidate all the like in memory binary images, cutting down the total memory footprint even further. The same can be done with VMWare ESXi, probably more easily in the latter case, but this freebie version probably limits the number of virtual machines to a value lower than what you'd need. A small farm of eight inexpensive 1U single socket quad core servers with 32GB RAM and a couple of 200GB mirrored SSDs could handle quite a few customers. Reserve 2GB RAM and 20GB disk for the hypervisor and assign 512MB RAM and 3GB disk to each customer VM. This allows for 60 customer dedicated servers per box each with a ~2.5GB queue. With 8 such servers that's 480 customer outbound dedicated relay servers in 8U of rack space, for relatively little hardware investment. This could be tweaked to fit even more customer VMs/queues per box depending on per customer queue requirements. -- Stan
