Re: [Mailman-Users] Mailman repetitively trying to drop addresses

2009-06-22 Thread Mark Sapiro 
Ralph Prichard wrote:
>
>We imported about 1000 addresses from an old mailing list into a new
>Mailman list, and we were hoping Mailman's bounce processing would start
>removing any addresses that are clearly no longer valid.  This is old
>info; if we've got a bad address, we just want it dropped without any
>further resuscitation efforts.  Here are our bounce processing settings:
>
>bounce_processing = Yes
>bounce_score_threshold = 3.0
>bounce_info_stale_after = 21
>bounce_you_are_disabled_warnings = 0
>bounce_you_are_disabled_warnings_interval = 7
>bounce_unrecognized_goes_to_list_owner = Yes
>bounce_notify_owner_on_disable = Yes
>bounce_notify_owner_on_removal = Yes
>
>These settings have been adjusted a few times, but not by any radical
>amount.  I'm sure I also inadvertantly dropped the
>"bounce_score_threshold" from 3.5 to 3.0 while the latest message was
>still being distributed.  However, the previous message exhibited the
>same problematic behavior I'm seeing today, and the values were all left
>alone during that period.
>
>
>After messages went out that resulted in bounce scores over the
>threshold, there were a couple of issues...
>
>
>1) Mailman tried to send a notification to the bad addresses indicating
>that they've been dropped from the mailing list.  It does so despite the
>fact that "send_goodbye_msg" is set to "no".  So my first question is
>almost identical to this one:
>
>http://mail.python.org/pipermail/mailman-users/2006-August/052688.html
>
>Does anyone know how to get the bounce processing system to respect the
>"send_goodbye_msg" value, while still sending the moderators/list owners
>notification that an address has been dropped?


You can modify the code. In the definition of the
sendNextNotification() method, see

self.ApprovedDeleteMember(
member, 'disabled address',
admin_notif=self.bounce_notify_owner_on_removal,
userack=1)

and change userack=1 to userack=0 if you want no notice or to
userack=None (or just remove it) to use the list's send_goodbye_msg
setting.

However, what's the harm? If the address is truly undeliverable, it's
just one more residual bounce. If not, the user may possibly notified
of a problem.



>2) Mailman tried to drop 2 addresses (out of an apparent list of 55 bad
>addresses) over and over again, until after 10 attempts, when the
>BounceRunner stopped.  (Nothing at all seemed to happen to the other 53
>addresses.)  The first notification that the list owners received
>regarding the drop attempts referenced the actual message that a list
>member sent.  But the next 10 notifications referred to the fact that
>the "You have been unsubscribed from the 'somelist' mailing list"
>messages were _also_ bouncing.  (Which is another reason I'd like to
>suppress those messages from ever being sent in the first place.)
>


This is a bug in Mailman 2.1.11 that is fixed in 2.1.12 (it only occurs
if bounce_you_are_disabled_warnings is 0). The attached patch.txt file
contains a patch to Bouncer.py that will fix it.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan

=== modified file 'Mailman/Bouncer.py'
--- Mailman/Bouncer.py  2008-06-20 19:47:28 +
+++ Mailman/Bouncer.py  2009-02-16 16:53:20 +
@@ -1,4 +1,4 @@
-# Copyright (C) 1998-2008 by the Free Software Foundation, Inc.
+# Copyright (C) 1998-2009 by the Free Software Foundation, Inc.
 #
 # This program is free software; you can redistribute it and/or
 # modify it under the terms of the GNU General Public License
@@ -163,8 +163,10 @@
 # We've set/changed bounce info above.  We now need to tell the
 # MemberAdaptor to set/update it.  We do it here in case the
 # MemberAdaptor stores bounce info externally to the list object to
-# be sure updated information is stored.
-self.setBounceInfo(member, info)
+# be sure updated information is stored, but we have to be sure the
+# member wasn't removed.
+if self.isMember(member):
+self.setBounceInfo(member, info)
 
 def disableBouncingMember(self, member, info, msg):
 # Initialize their confirmation cookie.  If we do it when we get the

=== modified file 'NEWS'
--- NEWS2009-02-14 22:25:29 +
+++ NEWS2009-02-16 16:53:20 +
@@ -92,6 +92,9 @@
 
 - Recognize a couple more bounces.
 
+- Fixed a bug introduced in 2.1.11 which would attempt to store bounce info
+  for a member just deleted if bounce_you_are_disabled_warnings is zero.
+
  i18n
 
 - Updated Dutch, Catalan and Polish translations.

--
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe: 
http://mail.python.org/mailman/option

[Mailman-Users] Mailman repetitively trying to drop addresses

2009-06-22 Thread Ralph Prichard 

We imported about 1000 addresses from an old mailing list into a new
Mailman list, and we were hoping Mailman's bounce processing would start
removing any addresses that are clearly no longer valid.  This is old
info; if we've got a bad address, we just want it dropped without any
further resuscitation efforts.  Here are our bounce processing settings:

bounce_processing = Yes
bounce_score_threshold = 3.0
bounce_info_stale_after = 21
bounce_you_are_disabled_warnings = 0
bounce_you_are_disabled_warnings_interval = 7
bounce_unrecognized_goes_to_list_owner = Yes
bounce_notify_owner_on_disable = Yes
bounce_notify_owner_on_removal = Yes

These settings have been adjusted a few times, but not by any radical
amount.  I'm sure I also inadvertantly dropped the
"bounce_score_threshold" from 3.5 to 3.0 while the latest message was
still being distributed.  However, the previous message exhibited the
same problematic behavior I'm seeing today, and the values were all left
alone during that period.


After messages went out that resulted in bounce scores over the
threshold, there were a couple of issues...


1) Mailman tried to send a notification to the bad addresses indicating
that they've been dropped from the mailing list.  It does so despite the
fact that "send_goodbye_msg" is set to "no".  So my first question is
almost identical to this one:

http://mail.python.org/pipermail/mailman-users/2006-August/052688.html

Does anyone know how to get the bounce processing system to respect the
"send_goodbye_msg" value, while still sending the moderators/list owners
notification that an address has been dropped?


2) Mailman tried to drop 2 addresses (out of an apparent list of 55 bad
addresses) over and over again, until after 10 attempts, when the
BounceRunner stopped.  (Nothing at all seemed to happen to the other 53
addresses.)  The first notification that the list owners received
regarding the drop attempts referenced the actual message that a list
member sent.  But the next 10 notifications referred to the fact that
the "You have been unsubscribed from the 'somelist' mailing list"
messages were _also_ bouncing.  (Which is another reason I'd like to
suppress those messages from ever being sent in the first place.)

But back to the failure to drop the address...

There are the 11 restarts shown in the qrunner log file:

Excerpt from /var/log/mailman/qrunner:
==
Jun 22 14:58:16 2009 (2047) Master qrunner detected subprocess exit
(pid: 2073, sig: None, sts: 1, class: BounceRunner, slice: 1/1)
[restarting]
Jun 22 14:58:16 2009 (4880) BounceRunner qrunner started.
Jun 22 15:13:16 2009 (2047) Master qrunner detected subprocess exit
(pid: 4880, sig: None, sts: 1, class: BounceRunner, slice: 1/1)
[restarting]
Jun 22 15:13:16 2009 (5102) BounceRunner qrunner started.

...7 more occurrences removed (each BounceRunner startup has a different
PID, if that's what the number in the bracket represents)...

Jun 22 17:13:18 2009 (2047) Master qrunner detected subprocess exit
(pid: 5522, sig: None, sts: 1, class: BounceRunner, slice: 1/1)
[restarting]
Jun 22 17:13:18 2009 (5574) BounceRunner qrunner started.
Jun 22 17:28:18 2009 (2047) Master qrunner detected subprocess exit
(pid: 5574, sig: None, sts: 1, class: BounceRunner, slice: 1/1)
[restarting]
Jun 22 17:28:18 2009 (2047) Qrunner BounceRunner reached maximum restart
limit of 10, not restarting.


There appears to be more interesting information in other files in
/var/log/mailman.  I'll include one excerpt from the "errors" file
below.  If anyone thinks the other information would be handy, please
let me know and I'll try to trim it down a bit before sending a copy
along.


Excerpt from /var/log/mailman/error:

Jun 22 17:28:18 2009 qrunner(5574): Traceback (most recent call last):
Jun 22 17:28:18 2009 qrunner(5574):   File
"/var/lib/mailman/bin/qrunner", line 278, in 
Jun 22 17:28:18 2009 qrunner(5574):  main()
Jun 22 17:28:18 2009 qrunner(5574):   File
"/var/lib/mailman/bin/qrunner", line 238, in main
Jun 22 17:28:18 2009 qrunner(5574):  qrunner.run()
Jun 22 17:28:18 2009 qrunner(5574):   File
"/usr/lib/mailman/Mailman/Queue/Runner.py", line 88, in run
Jun 22 17:28:18 2009 qrunner(5574):  self._cleanup()
Jun 22 17:28:18 2009 qrunner(5574):   File
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 263, in _cleanup
Jun 22 17:28:18 2009 qrunner(5574):  BounceMixin._cleanup(self)
Jun 22 17:28:18 2009 qrunner(5574):   File
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 137, in _cleanup
Jun 22 17:28:18 2009 qrunner(5574):  self._register_bounces()
Jun 22 17:28:18 2009 qrunner(5574):   File
"/usr/lib/mailman/Mailman/Queue/BounceRunner.py", line 125, in
_register_bounces
Jun 22 17:28:18 2009 qrunner(5574):  mlist.registerBounce(addr, msg,
day=day)
Jun 22 17:28:18 2009 qrunner(5574):   File
"/usr/lib/mailman/Mailman/Bouncer.py", line 167, in registerBounce
Jun 22 17:28:18 2009 qrun