Mailman 3 stops delivering to a domain after too many bounces
Hi,
We have recently upgraded from Mailman 2 to Mailman 3. Since then I have observed many user reports that mails to mailing lists don't reach all members. My suspicion is that there are too many "dead" members on those lists. This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
Is there a way to globaly ignore bounces and send out mails to all members of a list, no matter what?
Thanks, Julian
Are you sure that’s mailman doing that? What do your MTA logs say? I’ve certainly seen behaviour that looks like that in the past, but usually my MTA logs show that the first few are accepted by the remote site, and then the subsequent messages get rejected, usually as a result of over-zealous spam filtering. My approach to that has usually been to adjust my MTA settings to be a bit friendlier to the sites that tend to do this, and only send a few messages at a time.
Tim
On 12 Jul 2022, at 08:34, Julian Kippels <kippels@hhu.de> wrote:
Hi,
We have recently upgraded from Mailman 2 to Mailman 3. Since then I have observed many user reports that mails to mailing lists don't reach all members. My suspicion is that there are too many "dead" members on those lists. This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
Is there a way to globaly ignore bounces and send out mails to all members of a list, no matter what?
Thanks, Julian
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
(sorry, I did not reply to the list with this at first)
Hi,
I'm quite positive that Mailman 3 is the culprit here. The problem did not exist with Mailman 2 and both versions used the exact same MTA. This MTA is even set up in a way to explicitly circumvent spam filtering (mails are filtered on the way in to mailman, there is no need for an additional check on the way out) . Additionally if the MTA would reject connections from IPs that generate too many errors, then why is Mailman 3 still able to deliver to domain B and C when domain A has already failed?
Currently I am trying to write a script to check if mail aliasses are alive and remove users if that check should fail. I plan to run this as a cron job for every list every night. I don't think that this is a good option, but I don't see anything better right now.
Julian
Am Tue, 12 Jul 2022 10:45:16 +0100 schrieb Tim Cutts <tim@thecutts.org>:
Are you sure that’s mailman doing that? What do your MTA logs say? I’ve certainly seen behaviour that looks like that in the past, but usually my MTA logs show that the first few are accepted by the remote site, and then the subsequent messages get rejected, usually as a result of over-zealous spam filtering. My approach to that has usually been to adjust my MTA settings to be a bit friendlier to the sites that tend to do this, and only send a few messages at a time.
Tim
On 12 Jul 2022, at 08:34, Julian Kippels <kippels@hhu.de> wrote:
Hi,
We have recently upgraded from Mailman 2 to Mailman 3. Since then I have observed many user reports that mails to mailing lists don't reach all members. My suspicion is that there are too many "dead" members on those lists. This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
Is there a way to globaly ignore bounces and send out mails to all members of a list, no matter what?
Thanks, Julian
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
--
| | Julian Kippels | | M.Sc. Informatik | | | | Zentrum für Informations- und Medientechnologie | | Heinrich-Heine-Universität Düsseldorf | | Universitätsstr. 1 | | Raum 25.41.O1.32 | | 40225 Düsseldorf / Germany | | | | Tel: +49-211-81-14920 | | mail: kippels@hhu.de
Julian Kippels writes:
Additionally if the MTA would reject connections from IPs that generate too many errors, then why is Mailman 3 still able to deliver to domain B and C when domain A has already failed?
Because *Mailman* doesn't doesn't handle bounces by domain, only by address. It will send to your MTA every address on the list that is enabled, regardless of whether transmission to other addresses at that domain failed. The *MTA* handles domain-level lossage such as DNS and network outage. Mailman is blissfully unaware of that until the individual addresses start bouncing (which by default in most MTAs takes a week or two of retries), but it doesn't care if they're all from the same domain, it handles each one individually without affecting other addresses at that domain.
Currently I am trying to write a script to check if mail aliasses are alive and remove users if that check should fail.
This isn't straightforward, as most site now disable the SMTP verify command. IIRC you need to open a connection, do the HELO, MAIL FROM, RCPT TO dance, check for error (if so, record as a bounce), and then close the connection before issuing the DATA command.
I plan to run this as a cron job for every list every night.
I find it hard to imagine that's useful. I'm not sure why you would have accumulated large numbers of dead addresses on Mailman 2 lists unless you had bounce processing disabled. Nevertheless, if you do hav dozens per list, running the script once a month should be enough unless you have really mammoth lists (> 10,000 subscriptions), or your subscribers are changing addresses as frequently as spammers do.
I don't think that this is a good option, but I don't see anything better right now.
What version of Mailman 3 are you running? I don't recall the version offhand, but bounce processing was fully implemented only about two or three years ago. Recent versions of Mailman 3 will automatically disable, and eventually remove, subscriptions that bounce "often enough" (ie, the number of bounces and interval until various purges of old bounce information are configurable). If you want to purge a large number of "dead" addresses quickly, just set the disable and delete levels very low, then set them back to default. That should do the trick.
Note that some distros provide rather old versions of Mailman 3, where bounce processing did not work.
Steve
Julian Kippels writes:
This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
"Seems to you"? Do you have logs and empty MTA queues etc as evidence for this, or just mail not arriving at the subscription addresses? What are the configuration settings for the list, most importantly, are messages personalized?
In the default configuration without personalization, I think this is very unlikely to be Mailman's problem. Mailman will send a reasonably large number (specifically, 500) of recipients for the message, and then send the message itself once. In this case, if only a couple dozen recipients of 800 receive the message, it's either the recipient MTA or some interaction between your MTA and theirs, not Mailman. Check the MTA outgoing queue and MTA logs.
If the list has enabled personalization, so that the footer (usually) contains subscriber-specific information, then there is only one recipient per message. However, the interaction you describe is unlikely to be due to Mailman's behavior in that case as well, as Mailman tracks bounces by individual address, not by domain. It's not useful to do so, as almost all bounces that reach are address-specific. If there is a problem in connecting to a remote host, that is almost always handled by the MTA and Mailman never finds out about it. Again, check the queue and the logs for the MTA as well as for Mailman.
On the other hand, I was talking with the postmaster of a rather large site recently, who was complaining about freemail G. What happens is that with a very large list with many bouncing addresses, the sending MTA builds up a backlog of undelivered messages. The MTA tries to resend them at intervals (or for some MTAs the next time a message goes out to that domain). Of course since it's a mailing list, the same addresses bounce, and now you have *twice as many* undelivered messages waiting to be delivered. Pretty soon you have a very large number of attempts within a very short time (in the case of my postmaster acquaintance, an average of 3/second), and freemail G treats that as a DOS attack and starts refusing or delaying connections.
That sounds a lot like what's happening to you. Without the log and configuration information it's not possible to be sure, but your hypothesis isn't very consistent with the way Mailman actually does its work.
Is there a way to globaly ignore bounces and
No. That's one of the better ways I can think of to acquire a reputation as a spammer and generally bad actor.
send out mails to all members of a list, no matter what?
That is what Mailman does. Only after it has received "enough" bounces for a particular user does it disable delivery to that user only. Mailman does not keep records of bounces per domain.
Steve
I agree with this analysis. I have had issues in the past where some big email providers allowed the first few through and then started returning an error for everyone else in the same domain. It was fairly obvious from the MTA logs (postfix in my case) when this was happening — fixing it was rather trickier, since ultimately it’s overzealous anti spam policies at the mail provider which are the cause of the trouble.
Postfix is a bit of a pain for configuring domain-specific delivery behaviours; it has global settings smtp_client_connection_count_limit and smtp_client_connection_rate_limit, which might be helpful, but it’s hard to make them different for different domains. Exim would be much simpler to configure to do that. One day when my bag of round tuits gets bigger I might switch back to Exim.
Tim
On 12 Jul 2022, at 13:52, Stephen J. Turnbull <stephenjturnbull@gmail.com> wrote:
Julian Kippels writes:
This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
"Seems to you"? Do you have logs and empty MTA queues etc as evidence for this, or just mail not arriving at the subscription addresses? What are the configuration settings for the list, most importantly, are messages personalized?
In the default configuration without personalization, I think this is very unlikely to be Mailman's problem. Mailman will send a reasonably large number (specifically, 500) of recipients for the message, and then send the message itself once. In this case, if only a couple dozen recipients of 800 receive the message, it's either the recipient MTA or some interaction between your MTA and theirs, not Mailman. Check the MTA outgoing queue and MTA logs.
If the list has enabled personalization, so that the footer (usually) contains subscriber-specific information, then there is only one recipient per message. However, the interaction you describe is unlikely to be due to Mailman's behavior in that case as well, as Mailman tracks bounces by individual address, not by domain. It's not useful to do so, as almost all bounces that reach are address-specific. If there is a problem in connecting to a remote host, that is almost always handled by the MTA and Mailman never finds out about it. Again, check the queue and the logs for the MTA as well as for Mailman.
On the other hand, I was talking with the postmaster of a rather large site recently, who was complaining about freemail G. What happens is that with a very large list with many bouncing addresses, the sending MTA builds up a backlog of undelivered messages. The MTA tries to resend them at intervals (or for some MTAs the next time a message goes out to that domain). Of course since it's a mailing list, the same addresses bounce, and now you have *twice as many* undelivered messages waiting to be delivered. Pretty soon you have a very large number of attempts within a very short time (in the case of my postmaster acquaintance, an average of 3/second), and freemail G treats that as a DOS attack and starts refusing or delaying connections.
That sounds a lot like what's happening to you. Without the log and configuration information it's not possible to be sure, but your hypothesis isn't very consistent with the way Mailman actually does its work.
Is there a way to globaly ignore bounces and
No. That's one of the better ways I can think of to acquire a reputation as a spammer and generally bad actor.
send out mails to all members of a list, no matter what?
That is what Mailman does. Only after it has received "enough" bounces for a particular user does it disable delivery to that user only. Mailman does not keep records of bounces per domain.
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 7/12/22 12:34 AM, Julian Kippels wrote:
Hi,
We have recently upgraded from Mailman 2 to Mailman 3. Since then I have observed many user reports that mails to mailing lists don't reach all members. My suspicion is that there are too many "dead" members on those lists. This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C.
Is there a way to globaly ignore bounces and send out mails to all members of a list, no matter what?
Mailman's outgoing runner should not be quitting because of bounces at SMTP time. It seems like there may by some issue causing Mailman's outgoing runner to die. What's in Mailman's var/queue/shunt/ and Mailman's var/logs/mailman.log.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 12 Jul 2022, at 16:28, Mark Sapiro <mark@msapiro.net> wrote:
On 7/12/22 12:34 AM, Julian Kippels wrote:
Hi, We have recently upgraded from Mailman 2 to Mailman 3. Since then I have observed many user reports that mails to mailing lists don't reach all members. My suspicion is that there are too many "dead" members on those lists. This was not a problem on Mailman 2, but has become a problem on Mailman 3. It seems to me that for example Mailman 3 sends mails to the first 5 existing member addresses from domain A, then encounters several (20 or so seems to be the threshold) "dead" member addresses from domain A that generate a bounce and then does not even attempt to reach the remaining 800 member adresses from domain A and only sends to members on domain B and domain C. Is there a way to globaly ignore bounces and send out mails to all members of a list, no matter what?
Mailman's outgoing runner should not be quitting because of bounces at SMTP time. It seems like there may by some issue causing Mailman's outgoing runner to die. What's in Mailman's var/queue/shunt/ and Mailman's var/logs/mailman.log.
Good point. Mailman3 needs a great deal more RAM than Mailman2, especially if you’re running the web and core on the same machine. I used to comfortably run my small mailing list server on a 1GB VM, but on Mailman3 I found it often ran out of memory and bits of mailman3 would get shot by the kernel’s OOM killer, and had to move to a larger VM. So I’d check your kernel logs and see if you’ve got OOM messages in there.
Tim
participants (4)
-
Julian Kippels -
Mark Sapiro -
Stephen J. Turnbull -
Tim Cutts