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 <m...@msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

=== modified file 'Mailman/Bouncer.py'
--- Mailman/Bouncer.py  2008-06-20 19:47:28 +0000
+++ Mailman/Bouncer.py  2009-02-16 16:53:20 +0000
@@ -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'
--- NEWS        2009-02-14 22:25:29 +0000
+++ NEWS        2009-02-16 16:53:20 +0000
@@ -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/options/mailman-users/archive%40jab.org

Security Policy: http://wiki.list.org/x/QIA9

Reply via email to