Mark Sapiro writes:
On 7/4/26 6:13 AM, Stephen J. Turnbull wrote:
On the other hand, if Mailman sends mail to your user for any reason, and it does *not* bounce, they will be re-enabled automatically.
I don't think this is correct unless you have some local modification to do this.
Thank you for the correction.
Likely I misremembered that it would be re-enabled. I guess the stock process is the bounce count gets reset to zero after a time period with no bounces, but this isn't immediate and doesn't reenable.
When the bounce count is reset, if it's "disabled by bounce", we could then re-enable. That's like a two-line change. Perhaps with a more complex algorithm (eg, store an indicator of that Address's recent bounce history in the database, and re-disable more quickly if it has a history of bouncing recently). A complex algorithm would be more invasive (database schema addition) and I'm not suggesting that yet.
Even then, how would it work? A bounce might come from downstream MTA and possibly not for days.
Nothing that depends on bounce by DSN is reliable though. Heck, you can't even be sure that that status "250 OK" isn't somebody treating you like a spammer and eating your mail. And if you're heavy on Gmail and Yahoo users, most bounces are likely to come very quickly and reliably. It might work pretty well for some lists and horribly for others. I guess we'd have to do more parsing of the local MTA's DSNs in that case, though. Hmmm. At least we know the stock behavior of the four we support.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan