David Andrews via Mailman-Users writes: > I know exactly why people are being bounced! It is because > Microsoft has blocked us from all their mail domains and > services.
Then what you want to do is reset the bounces and disable delivery for addresses at those domains, is that right? At least one of those scripts allows you to select the addresses to modify in bulk by domain. > There reason is "irregular mail patterns." Are you saying that at least some of these "irregular mails" are verification emails induced by the subscription attacks? > We will probably enable CAPTSCHA, although that isn't my first > choice, as we have thousands of blind users, many of whom are not > comfortable with CAPTSCHA. I understand you are extremely busy right now, but for when you have the chance and/or funding for a consultant, you should consider fast-tracking an upgrade to Mailman 3 to alleviate the CAPTCHA issue. Perhaps it would alleviate other aspects of the subscription attack but I haven't thought carefully about that. To the extent that legitimate subscription activity is from existing users, they will have personal accounts (rather than per-subscription accounts) that will allow you to CAPTCHA only for new users, and also reduce the number of verification mails sent because a logged-in user will already have verified their address(es). Of course they'll have to get used to "log in and subscribe" vs. "subscribe and verify", but our default templates can surely be streamlined for that use case. > So, I don't want people bounced off lists when this will ultimately > be sorted out. If I understand the code correctly, you can configure the following in mm_cfg.py, and this will be reflected in future bounce processing. I believe you'll still have to reset the current members who have bounce information already (per-subscription records are created using the DEFAULT values when the first bounce is received, and these settings remain until the subscription is reenabled or deleted). But then you should be free of worry about inadvertant unsubscription. Hopefully Mark will confirm. The values are from Defaults.py. DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS = 3 DEFAULT_BOUNCE_YOU_ARE_DISABLED_WARNINGS_INTERVAL = days(7) These two can be used to implement a "never unsubscribe" policy, by setting the WARNINGS count to a very large value. To reduce the number of undeliverable posts that may "irritate" recipient domains filters, you can to increase the INTERVAL as well. Increasing INTERVAL would mean that when Microsoft starts accepting again it will take longer to users to reactivate. You could avoid that by mass-reactivating, but there are probably a number of legitimate bounces. Microsoft would likely perceive a sudden spate of deliveries to them as "irregular email patterns". DEFAULT_BOUNCE_SCORE_THRESHOLD = 5.0 DEFAULT_BOUNCE_INFO_STALE_AFTER = days(7) These two probably aren't very helpful. Decreasing the former and/or increasing the latter will result in more delivery-disabled users and less "irritation" to recipient domains' filters. None of the above can be tuned by list or domain. They are site-wide policies. Regards, 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
