Hi Brad, On Aug 14, 2011, at 8:44 PM, Brad Knowles wrote:
> The majority of the MTA tuning tips that I know of should be applicable > to most any mailing list manager, since they are oriented towards > helping the MTA better deal with large amounts of outgoing mail, and > optimizing certain types of behaviors that are common with most mailing > lists. > > But I'll have to re-fresh my memory of what is written there. > > Generally speaking, if there are any real-time queries being done by > your MTA, you want those done against the message as it comes into your > mail system the first time -- this includes checking black lists, > checking content, or anything else. > > You want to run a separate instance of your MTA for handling your > outbound mail and it should listen only to a special port on the > 127.0.0.1 "loopback" interface where Mailman can speak directly to it, > and that special instance should have pretty much all DNS queries and > real-time checks turned off. After all, those things should have been > done when the message was checked on inbound and shouldn't need to be > checked again on outbound. > Brad, I think we are already accomplishing a lot of this minimalism, since the MTA on the Mailman VM is only accepting the message via SMTP, then handing it off to Mailman via the Postfix aliases. The spam and other checks are done before hand, by another upstream gateway MTA. That gateway then hands mailing list messages off to the Mailman box. > > If Mailman is dealing with tempfails, then you've done something wrong. > The MTA should be blindly accepting whatever Mailman has to send, and > then the MTA should be dealing with tempfails -- it's one step closer to > wherever the problem might be, and it's more likely to be tuned for that > kind of behaviour. > > For example, most modern MTAs give you the ability to set up separate > queues for given outbound targets, which are kept apart from all the > other regular mail being handled. This way you can set up "local" > queues in your MTA that may have different resource handling rules or > different retry algorithms, as compared to queues to external sites that > might be known for being troublesome. > > We were doing this kind of thing at AOL back in the mid-90s, and this > has only gotten easier since. This is true for subscribers which are not part of our organization - the MTA which Mailman relays to accepts the messages, and then deals with any delivery issues. However, accounts for which this MTA is the final destination, will tempfail under certain conditions, like mismatched attributes in an LDAP record, or an issue with the mailstore. For better or worse, we are moving a lot of our mailboxes to mail forwards over the next few months - this will move the rest of these tempfails out of Mailman's SMTP / retry queue, and into the downstream relay (where they belong). Thanks, Ivan. . ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
