-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julio A. Cartaya wrote: > A customer of mine has a broadcast (i.e. one-way), low-traffic list with > close to 3000 members. The list contains a mix of business and personal > addresses. As usual, the list of member addresses can be seen only by > administrators (private_roster). > > The date of the last message broadcasted to members is July 17(this > year). On Aug 7 we received 2700 messages stating "johndoe at somesite.com > has cancelled his subscription to mylist" (where johndoe at somesite.com > changes - of course - for each cancellation message). > > Other relevant data > > * This list has been stable, hovering around 3000 members for 3 years > * It is unlikely all 2700 decided to drop from the list at the same time > * The host logs show no sign of intrusion > * I am inclined to dismiss vandalism, since there are 300 members > whose suscription was not affected > * There was no obvious pattern on the email addresses that were dropped > > Note this is happening in *Spain*, where the entire country closes > during July and August and flocks to the Mediterranean, so chances are > that many mailboxes are full and rejecting incoming messages. The July > 17th message could have caused an avalanche of bounced messages, and > automated bounce processing may have dropped all of those addresses a > few days later (bounce_score_threshold is 4.0, > bounce_you_are_disabled_warnings is 3). > > In the end, my questions are > > 1. *Is bounce processing a plausible cause (all 2700 addresses at the > same time)?*
Yes. > 2. *I found no way to distinguish user-driven dropout messages, from > dropout messages caused by bounce processing; is there any? > * Look in Mailman's 'bounce' log. > 3. *Is there a way to avoid this from happening again next year? > (other than setting bounce_processing to 'no')* I think there is more going on than a simple bounce of the July 17 message. With bounce_score_threshold = 4.0 and bounce_you_are_disabled_warnings = 3, it would require 4 bounces with no two consecutive bounces separated by more than bounce_info_stale_after days to disable a member, and then the member wouldn't be unsubscribed for another 3 times bounce_you_are_disabled_warnings_interval days. If bounce_you_are_disabled_warnings_interval is 8, that would explain the 24 days from July 17 to Aug 7, but that still doesn't explain why 2700 users would have had non-stale bounce scores of 3 and then got a 4th bounce on July 17. Mailman's 'bounce' log should have more clues. There is also a possible issue with changing bounce_score_threshold. If a member has old, stale bounce info with a score of x, and bounce_score_threshold is reduced from a value greater than x to one less than or equal to x, that member will be disabled even though the score is stale. Could this be a reason? - -- Mark Sapiro <[EMAIL PROTECTED]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) iD8DBQFGyIt1VVuXXpU7hpMRAjCnAJ0aqj2vyWjeQzSIgueQJ3uER4uKHACfQISm Ov4bWB1x4854mRzqvP4h9Ns= =I+f1 -----END PGP SIGNATURE----- ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
