At 11:47 PM -0500 2006-08-08, Brad Knowles wrote: > Moreover, if you're doing any amount of anti-spam processing or > anti-virus scanning, then you'll probably want to run multiple > different instances of your MTA on your machines. The primary > instance would be running on port 25 on all interfaces, with all > scanning intact. The secondary instance would be listening to > some other port only on the loopback (127.0.0.1) interface, and > would be used exclusively for outbound e-mail from that server.
Sorry, I should have been a little more clear -- this second instance does not do any scanning of any sort, and has all checks turned off for things like looking at the reverse DNS for the incoming connections, etc.... In other words, the one and only thing it is good at is accepting mail as quickly as possible from other programs on the system, and then working to deliver that as quickly as possible to the remote recipients. By the time a mail message reaches this second instance of your MTA, all anti-spam processing and anti-virus scanning, etc... should already have been done on input, and there shouldn't be anything else to scan for on output. That's why it can be tuned for maximum acceptance speed. In addition, if you're running a really large mailing list system, you will want to off-load all outgoing e-mail on a cluster of secondary machines at your site (or maybe provided by your ISP), so that your mailing list server can dump things onto other systems as quickly as possible. In that case, you will probably also want to pre-process all the incoming messages on a separate cluster of machines, so that the only thing the mailing list server has to worry about is accepting mail messages from the front-end inbound mail servers, handling web user interface interaction with the subscribers, moderators, and list owners, and transmitting approved messages as quickly as possible to the cluster of outbound mail handlers. Except for the web interaction stuff, pretty much all interaction with the outside world is handled by other machines. You can push this even further, by setting up a reverse-proxy system in front of the web user interface, and the next step would be to completely isolate the back-end mail handling facilities on a completely separate machine, which shares the /usr/local/mailman directory structure (or wherever your OS puts the Mailman files) via NFS to one or more front-end servers. Believe me, you can scale this thing to amazing heights, if you split the functionality correctly onto separate clusters of machines. It does take some knowledge of how to build and configure higher-performance web and mail clusters, but that's not too hard to come by -- we've put as much information as we can into the FAQs, and if there's anything not already covered there, we can try to put in some more. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 Founding Individual Sponsor of LOPSA. See <http://www.lopsa.org/>. ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp