David Andrews via Mailman-Users writes: > We are currently being blocked by Microsoft -- working to reverse. [...] > People are put on hold after there is non-delivery for a period of > time. I go in to lists and take off the B hold,
If they're bouncing enough to get a hold, something is wrong. Maybe your site or content looks suspicious. But that usually doesn't generate a bounce, recipients normally discard very suspicious mail and accept the rest. The other possibility is that the recipient systems are unreliable. This could be user-specific (for example, they've let their mailbox get full), or system-specific (the system's mail spool is full). > This takes some time and is tedious. You shouldn't need to do that. Normal bounce processing requires several bounces (typically three) in a short period (say a week), only counting one bounce per day, before holding normal delivery of posts. The bounce count is reset to zero if several posts go by without a bounce, or there is a confirmed delivery (see the "VERP" options in personlization to get such confirmations). After delivery is disabled, Mailman continues to send so-called "probes" at intervals. With normal settings it takes a few weeks before the user is unsubscribed, and I believe there is a setting that allows them to persist indefinitely in the subscribed but disabled state. Finally, there are two kinds of bounces. There are temporary failures, such as "mailbox full", and there are permanent failures, such as "we've tried to deliver the mail 10 times so we're giving up". Mailman does not count a temporary failure as a bounce. If users are accumulating that many bounces, Mailman has repeatedly given them a chance to reset their bounce count. The fact that it hasn't been reset indicates that there's a real problem somewhere. > because I don't want them unsubscribed for something that isn't > their fault. It's not a question of fault. It's a question of "who can do something about it." There are a number of common issues (such as reporting your list as spam) that users cause. Some are caused by their provider. For example, Gmail claims not to enforce DMARC From alignment, but in fact they do for Gmail-source email. For this reason, with conditional DMARC mitigation Gmail -> list -> Gmail posts *will bounce*. In my experience, most lists have several frequent posters with Gmail addresses, so this could explain why you have many bounces. Mailman 3 mitigates this by treating Gmail-source email with the selected DMARC mitigation unconditionally, but I don't think Mailman 2 has such Gmail mitigation, and if it doesn't have it already, I expect it won't get it. (That's up to Mark, though.) > Is there a command, or set of commands that will go through a list, > or all lists, and remove the bounces? Mark has reset_bounce.py (enables delivery) and clear_bounce_info.py (disables delivery) at https://www.msapiro.net/scripts/. But these scripts were intended for a situation where you know why bounces were accumulating rapidly, and you don't expect it to continue. Repeatedly resetting and reenabling blindly isn't a good idea. If there are permanent failures, such as a user deleted their account, your system will never find out. It will get a bad reputation with recipient systems. Providers like Google and Microsoft do correlate reputation across the domains they serve. Steve -- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan ------------------------------------------------------ Mailman-Users mailing list -- mailman-users@python.org To unsubscribe send an email to mailman-users-le...@python.org https://mail.python.org/mailman3/lists/mailman-users.python.org/ Mailman FAQ: http://wiki.list.org/x/AgA3 Security Policy: http://wiki.list.org/x/QIA9 Searchable Archives: https://www.mail-archive.com/mailman-users@python.org/ https://mail.python.org/archives/list/mailman-users@python.org/ Member address: arch...@mail-archive.com
