[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