bounce info not updating in MM 2.1.11rc1 + patch
Hi, (always with MysqlMemberships.py) I noticed that my bounce info stays in the database at level 1, even when the logs say "current bounce score: 2.0" In Mailman/Bouncer.py I think that two self.setBounceInfo(member, info) are missing: --- Mailman/Bouncer.save.py 2008-06-16 10:00:17.000000000 +0200 +++ Mailman/Bouncer.py 2008-06-16 10:00:43.000000000 +0200 @@ -137,6 +137,7 @@ class Bouncer: if lastbounce + self.bounce_info_stale_after < now: # Information is stale, so simply reset it info.reset(weight, day, self.bounce_you_are_disabled_warnings) + self.setBounceInfo(member, info) syslog('bounce', '%s: %s has stale bounce info, resetting', self.internal_name(), member) else: @@ -144,6 +145,7 @@ class Bouncer: # score and take any necessary action. info.score += weight info.date = day + self.setBounceInfo(member, info) syslog('bounce', '%s: %s current bounce score: %s', self.internal_name(), member, info.score) # Continue to the check phase below -- Fil
(always with MysqlMemberships.py) I noticed that my bounce info stays in the database at level 1, even when the logs say "current bounce score: 2.0"
In Mailman/Bouncer.py I think that two self.setBounceInfo(member, info) are missing:
--- Mailman/Bouncer.save.py 2008-06-16 10:00:17.000000000 +0200 +++ Mailman/Bouncer.py 2008-06-16 10:00:43.000000000 +0200 @@ -137,6 +137,7 @@ class Bouncer: if lastbounce + self.bounce_info_stale_after < now: # Information is stale, so simply reset it info.reset(weight, day, self.bounce_you_are_disabled_warnings) + self.setBounceInfo(member, info) syslog('bounce', '%s: %s has stale bounce info, resetting', self.internal_name(), member) else: @@ -144,6 +145,7 @@ class Bouncer: # score and take any necessary action. info.score += weight info.date = day + self.setBounceInfo(member, info) syslog('bounce', '%s: %s current bounce score: %s', self.internal_name(), member, info.score) # Continue to the check phase below
Hello, After another day has passed, I can confirm that this patch allows MysqlMemberships.py to be notified of the bounce scores. -- Fil
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jun 16, 2008, at 4:01 AM, Fil wrote:
(always with MysqlMemberships.py) I noticed that my bounce info stays in the database at level 1, even when the logs say "current bounce score: 2.0"
In Mailman/Bouncer.py I think that two self.setBounceInfo(member, info) are missing:
--- Mailman/Bouncer.save.py 2008-06-16 10:00:17.000000000 +0200 +++ Mailman/Bouncer.py 2008-06-16 10:00:43.000000000 +0200 @@ -137,6 +137,7 @@ class Bouncer: if lastbounce + self.bounce_info_stale_after < now: # Information is stale, so simply reset it info.reset(weight, day, self.bounce_you_are_disabled_warnings) + self.setBounceInfo(member, info) syslog('bounce', '%s: %s has stale bounce info, resetting', self.internal_name(), member) else: @@ -144,6 +145,7 @@ class Bouncer: # score and take any necessary action. info.score += weight info.date = day + self.setBounceInfo(member, info) syslog('bounce', '%s: %s current bounce score: %s', self.internal_name(), member, info.score) # Continue to the check phase below
This makes some sense. I don't know anything about the MysqlMembership.py adapter, but unlike the pickle-based standard adapter, it probably needs this call to mark the object as modified so that it will be stored in the db on the next save. The standard adapter doesn't need this, because it's just going to pickle whatever the current state is. The patch is a bit icky, but probably useful and I don't think it can hurt the standard adapter. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAkhXsmwACgkQ2YZpQepbvXE9RQCgnOJ4F5NEfXDA9oPoxhXMK+U5 7uUAnREdrThi0xFV3uFCx27PoiBv6Bvt =w2D7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Warsaw wrote: | On Jun 16, 2008, at 4:01 AM, Fil wrote: | |> (always with MysqlMemberships.py) |> I noticed that my bounce info stays in the database at level 1, even |> when the logs say "current bounce score: 2.0" | |> In Mailman/Bouncer.py I think that two self.setBounceInfo(member, |> info) are missing: | |> --- Mailman/Bouncer.save.py 2008-06-16 10:00:17.000000000 +0200 |> +++ Mailman/Bouncer.py 2008-06-16 10:00:43.000000000 +0200 |> @@ -137,6 +137,7 @@ class Bouncer: |> if lastbounce + self.bounce_info_stale_after < now: |> # Information is stale, so simply reset it |> info.reset(weight, day, |> self.bounce_you_are_disabled_warnings) |> + self.setBounceInfo(member, info) |> syslog('bounce', '%s: %s has stale bounce info, |> resetting', |> self.internal_name(), member) |> else: |> @@ -144,6 +145,7 @@ class Bouncer: |> # score and take any necessary action. |> info.score += weight |> info.date = day |> + self.setBounceInfo(member, info) |> syslog('bounce', '%s: %s current bounce score: %s', |> self.internal_name(), member, info.score) |> # Continue to the check phase below | | This makes some sense. I don't know anything about the | MysqlMembership.py adapter, but unlike the pickle-based standard | adapter, it probably needs this call to mark the object as modified so | that it will be stored in the db on the next save. The standard adapter | doesn't need this, because it's just going to pickle whatever the | current state is. | | The patch is a bit icky, but probably useful and I don't think it can | hurt the standard adapter. This was discussed at length in October, 1985 in the thread that begins at http://mail.python.org/pipermail/mailman-developers/2005-October/018255.html. In particular, see my post at http://mail.python.org/pipermail/mailman-developers/2005-October/018261.html for an alternate patch which I thought was more complete. As I note in that post, I was new to Mailman at that time and was reluctant to commit that patch without additional input. In fact, I think I only acquired commit privileges during the time of that thread. In any case, I'll revisit it now for inclusion in 2.1.11. /Mark - -- Mark Sapiro 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) iD8DBQFIV86sVVuXXpU7hpMRAnKCAKCkih1PjK4zET8zxYVSTd3PLyb/YQCgmAsj yooXIoWOtwqsiJ6FDbf5IPA= =Bnrm -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jun 17, 2008, at 10:48 AM, Mark Sapiro wrote:
This was discussed at length in October, 1985 in the thread that
begins at <http://mail.python.org/pipermail/mailman-developers/2005-October/018255.html.
Wow, it's shocking to realize how long I've been hacking on Mailman
then! :)
In particular, see my post at <http://mail.python.org/pipermail/mailman-developers/2005-October/018261.html
for an alternate patch which I thought was more complete. As I note in that post, I was new to Mailman at that time and was reluctant to
commit that patch without additional input. In fact, I think I only acquired commit privileges during the time of that thread.In any case, I'll revisit it now for inclusion in 2.1.11.
Thanks Mark.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkhX00cACgkQ2YZpQepbvXE4bwCaAo6pZs1+ruYH6uo66hKnw4oT C2AAn2uLa9VcG76EkFZs28wtuChvWI3Z =jUrx -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Warsaw wrote: | On Jun 17, 2008, at 10:48 AM, Mark Sapiro wrote: | |> This was discussed at length in October, 1985 in the thread that begins |> at |> http://mail.python.org/pipermail/mailman-developers/2005-October/018255.html.
| | | Wow, it's shocking to realize how long I've been hacking on Mailman | then! :)
I have trouble with decades and centuries - I guess it's just an unconscious desire to remain young forever ;)
/Mark
Mark Sapiro mark@msapiro.net 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)
iD8DBQFIV+EdVVuXXpU7hpMRAqseAJ9vMdEJMb70AsABIh9dTOZvBeU0yACfXlK0 7pLFHVXdh0EwdxycXVWJISU= =ixUB -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jun 17, 2008, at 4:17 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
Wow, it's shocking to realize how long I've been hacking on Mailman then! :)
Isn't
even more impressive as proof of Barry's longevity, though!
http://mail.python.org/pipermail/python-dev/2008-June/080468.html
Kind of scared me a little too ;)
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAkhYGl0ACgkQ2YZpQepbvXGazQCfVLt/YJpwCC9Q2JBmadHx2yJY ilgAnjMY6TlDFoNiJ9FZcPuA9zBKDn3y =UEoy -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Sapiro wrote: | | In particular, see my post at | http://mail.python.org/pipermail/mailman-developers/2005-October/018261.html | | for an alternate patch which I thought was more complete. As I note in | that post, I was new to Mailman at that time and was reluctant to commit | that patch without additional input. In fact, I think I only acquired | commit privileges during the time of that thread. | | In any case, I'll revisit it now for inclusion in 2.1.11. See the attached Bouncer.patch.txt file for the current patch. I think there are problems with Fil's patch posted here. In particular, I think that when a user is disabled for bounce, the re-enable cookie won't be stored in the bounce_info which I think is not too significant, but I also think that the updated info.noticesleft in the sendNextNotification() method is not saved which, if I am right will mean that no bouncing member is ever unsubscribed - they just keep getting periodic notices forever. I think there was also a problem with my original patch in that it didn't reset bounce info when a probe was sent, but I don't think this is too significant. I have tested this patch with OldStyleMemberships.py and it appears to cause no regression. I also installed it in a production system using OldStyleMemberships.py and will be monitoring that, but of course this doesn't say anything about how it works with MysqlMemberAdaptor.py or any other which saves bounce info outside the list instance. Fil, I would appreciate your trying the attached patch instead of the one you're using and reporting the results. /Mark - -- Mark Sapiro 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) iD8DBQFIWCClVVuXXpU7hpMRAo57AJ9aYDnC+8YrysO3l8ecXvnBfB3lXACgpIqc ERIX3ort5Ky1P1OX/7zCwv4= =4LXA -----END PGP SIGNATURE----- === modified file 'Mailman/Bouncer.py' --- Mailman/Bouncer.py 2005-12-06 22:49:49 +0000 +++ Mailman/Bouncer.py 2008-06-17 19:37:36 +0000 @@ -1,4 +1,4 @@ -# Copyright (C) 1998-2005 by the Free Software Foundation, Inc. +# Copyright (C) 1998-2008 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 @@ -113,7 +113,7 @@ # This is the first bounce we've seen from this member info = _BounceInfo(member, weight, day, self.bounce_you_are_disabled_warnings) - self.setBounceInfo(member, info) + # setBounceInfo is now called below after check phase. syslog('bounce', '%s: %s bounce score: %s', self.internal_name(), member, info.score) # Continue to the check phase below @@ -160,12 +160,20 @@ info.reset(0, info.date, info.noticesleft) else: self.disableBouncingMember(member, info, msg) + # 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) def disableBouncingMember(self, member, info, msg): # Initialize their confirmation cookie. If we do it when we get the # first bounce, it'll expire by the time we get the disabling bounce. cookie = self.pend_new(Pending.RE_ENABLE, self.internal_name(), member) info.cookie = cookie + # In case the MemberAdaptor stores bounce info externally to + # the list, we need to tell it to save the cookie + self.setBounceInfo(member, info) # Disable them if mm_cfg.VERP_PROBES: syslog('bounce', '%s: %s disabling due to probe bounce received', @@ -271,6 +279,9 @@ msg.send(self) info.noticesleft -= 1 info.lastnotice = time.localtime()[:3] + # In case the MemberAdaptor stores bounce info externally to + # the list, we need to tell it to update + self.setBounceInfo(member, info) def BounceMessage(self, msg, msgdata, e=None): # Bounce a message back to the sender, with an error message if
See the attached Bouncer.patch.txt file for the current patch.
Seems to have been functioning as I had this morning this kind of logs
Jun 18 04:15:32 2008 (7299) listname: email@example.tld current bounce score: 2.0 Jun 18 04:15:32 2008 (7299) listname: email@example.tld disabling due to bounce score 2.0 >= 2.0 Jun 18 04:15:32 2008 (7299) listname: email@example.tld deleted after exhausting notices
and those email addresses have been removed from the database
-- Fil
Fil wrote:
See the attached Bouncer.patch.txt file for the current patch.
Seems to have been functioning as I had this morning this kind of logs
Jun 18 04:15:32 2008 (7299) listname: email@example.tld current bounce score: 2.0 Jun 18 04:15:32 2008 (7299) listname: email@example.tld disabling due to bounce score 2.0 >= 2.0 Jun 18 04:15:32 2008 (7299) listname: email@example.tld deleted after exhausting notices
and those email addresses have been removed from the database
That's all good, but we also want to see a score increment.
Ideally, there would be a list with threshold greater than 2 and we would see the score set to 1, increment to 2 and then increment to 3.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
That's all good, but we also want to see a score increment.
Ideally, there would be a list with threshold greater than 2 and we would see the score set to 1, increment to 2 and then increment to 3.
It seems that I have all kinds of results: xxx already scored a bounce for date 18-Jun-2008 xxx current bounce score: 4.0 (and I checked in the database that is it stored as bi_score=4)
on that list where the threshold is set to 2, adresses have been removed
if we follow one address we have
Jun 15 22:51:45 2008 (5324) listname: xxxx.xxxxx@laposte.net bounce score: 1.0 Jun 15 23:21:47 2008 (5324) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 15-Jun-2008 Jun 16 00:22:11 2008 (5324) listname: xxxx.xxxxx@laposte.net current bounce score: 2.0 Jun 16 00:52:16 2008 (5324) listname: xxxx.xxxxx@laposte.net current bounce score: 2.0 Jun 16 14:08:11 2008 (4700) listname: xxxx.xxxxx@laposte.net current bounce score: 2.0 Jun 16 14:23:15 2008 (4700) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 16-Jun-2008 Jun 16 15:23:26 2008 (4700) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 16-Jun-2008 Jun 16 15:53:40 2008 (4700) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 16-Jun-2008 Jun 16 23:40:22 2008 (4700) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 16-Jun-2008 Jun 17 07:15:43 2008 (12778) listname: xxxx.xxxxx@laposte.net current bounce score: 3.0 Jun 17 14:47:12 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 15:32:29 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 16:47:34 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 17:02:34 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 17:02:34 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 17:17:35 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 21:33:23 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 21:48:25 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 22:18:29 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 Jun 17 22:48:37 2008 (12778) listname: xxxx.xxxxx@laposte.net already scored a bounce for date 17-Jun-2008 ** Mark's patch applied ** Jun 18 18:05:53 2008 (7299) listname: xxxx.xxxxx@laposte.net current bounce score: 4.0
that list's bounce_score_threshold is 5.0 so we'll see what happens tomorrow :-)
-- Fil
Fil wrote:
It seems that I have all kinds of results: xxx already scored a bounce for date 18-Jun-2008 xxx current bounce score: 4.0 (and I checked in the database that is it stored as bi_score=4)
Thanks Fil. I'm sure it's good, but keep us posted.
-- Mark Sapiro mark@msapiro.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (4)
-
Barry Warsaw
-
Fil
-
Mark Sapiro
-
Stephen J. Turnbull