[Mailman-Users] Mailman Stalls for Outgoing Emalis

Brad Knowles brad at stop.mail-abuse.org
Wed Aug 9 07:42:40 CEST 2006


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, <brad at stop.mail-abuse.org>

"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/>.



More information about the Mailman-Users mailing list