[Mailman-Users] speed up mailman
Stephen J. Turnbull
stephen at xemacs.org
Mon Feb 29 04:00:58 EST 2016
Mark Sapiro writes:
> This is almost certainly your problem. All those [RBL] checks take
> time, especially if DNS is slow.
Also, several of the checks (RBL and otherwise) seem to be in there
repeatedly. ISTR that Postfix does the checks in the order specified,
so they might be done multiple times. That doesn't seem useful. :-(
Ruben Safir writes:
> On 02/29/2016 01:42 AM, Ruben Safir wrote:
> > dig gnutelephony.org
> that does hang. These are OLD mailing lists and it is hard to be
> responsible for 20 years of DNS errors by organizations I have no
> control over.
You don't have to. Mailman will do that for you if you have bounce
processing turned on and configured appropriately. But looking at the
rejected bogus addresses in your Postfix log suggests to me that
you may have been targeted by spammers who are trying to harvest
addresses from your mailflow. It's quite possible that those were
added very recently (within days) by botnets, or that your bounce
processing isn't configured appropriately for the traffic you're
getting. If the latter, the bogus addresses could have been there for
a long time.
Like Carl, I recommend cleaning up your lists. To get one cleaned
quickly, if you don't have the time to do it by hand, Mailman can do a
pretty good job automatically. Go to the administration interface for
each list, select bounce processing, and set
bounce_processing = Yes # Yes
bounce_score_threshold = 0 # 5.0
bounce_you_are_disabled_warnings = 1 # 3
bounce_you_are_disabled_warnings_interval = 1 # 7
bounce_notify_owner_on_disable = No # Yes
bounce_notify_owner_on_removal = No # Yes
Values at the end of the line are defaults.
and wait a day or two (I'm assuming you have traffic on each list
daily, if not, send a test message each day). After the first day,
all the bogus addresses (and most likely a few valid ones) will be
disabled, and no mail will be sent to them, so Postfix will do no DNS
lookups for them.
After the second day, they'll be gone and you'll have clean lists.
You may also have some irate ex-subscribers; if you care about
that, adjust the number of disabled warnings and the disabled warnings
interval upward to give them a better chance to respond that they're
real. 2 and 2 should do, but you'll have to wait a week for the lists
to be actually cleaned. And some will ignore the warnings or not
receive them and get unsubscribed -- if you care about that, you have
to do it by hand.
After that, you should go through and reenable any real subscribers
who got disabled. And you probably want to set the values back to
something closer to the defaults. The defaults should be enough to
clean out any invalid addresses that "just happen" to get added within
a couple weeks. If having done this, you get infested with several
invalid addresses quickly, you probably should tighten up the
subscription policy. :-(
If you have a lot of lists, it's possible to write scripts to do this
kind of configuration automatically for a list of lists, but I haven't
done it so can't help out beyond saying it can be done.
 Yes, gnutelephony.org looks like it's probably something that was
alive and died because it got no love, but check out the others to see
what I mean.
 Mail really is quite unreliable. Occasionally you do run into an
"undeliverable" result for a perfectly good address. If that happens
to a subscriber, they'll get a bounce, and with the aggressive
settings I propose, they get disabled immediately, and unsubscribed if
it happens again the next day.
More information about the Mailman-Users