Jesus Cea wrote:
This morning I received this:

Your "cron" job on stargate
/usr/local/bin/python2.5 -S /home/mailman/cron/disabled

produced the following output:

Traceback (most recent call last):
File "/home/mailman/cron/disabled", line 224, in <module>
File "/home/mailman/cron/disabled", line 208, in main
File "/home/mailman/Mailman/Bouncer.py", line 280, in sendNextNotification
msg['Subject'] = 'confirm ' + info.cookie
TypeError: cannot concatenate 'str' and 'NoneType' objects

The problem is, the particular user is marked as "disabled delivery",
but its bounce information is not the responsible for that:

<bounce info for member X
current score: 1.0
last bounce date: (2011, 4, 13)
email notices left: 7
last notice date: (1970, 1, 2)
confirmation cookie: None

So the delivery is disabled because "bounce", but the bounce score is
too low for it (my threshold is 5.0).

I do not see any way in standard GNU Mailman that a user can be
disabled "BYBOUNCE" without appropriate bounce info.

Is your mailman installed from source or a distributer package? Do you
have any local patches? Do you run any local processes?

When the "cron" executes "disabled" to send out the reminders, it tries
to send to this user, but the process fails because the user is marked
as "bounce" but no confirmation cookie is available.

So, the process dies. No more notifications mails are send. PANIC! :).


I think I can solve this particular case, for a while, doing
"m.setDeliveryStatus("X", 0)". But I will wait a couple of days, just in
case you want me to do any kind of test.

Checking the logs, I see this: (email and listname not shown)

bounce:Apr 13 09:17:59 2011 (1567) list: X bounce score: 1.0
bounce:Apr 13 13:56:29 2011 (5194) list: X already scored a bounce for
date 13-Apr-2011
bounce:Apr 14 09:00:03 2011 (24248) Notifying disabled member X for
list: list
bounce:Apr 14 12:05:16 2011 (12355) Notifying disabled member X for
list: list
bounce:Apr 14 12:06:21 2011 (12546) Notifying disabled member X for
list: list
bounce:Apr 14 12:17:09 2011 (14017) list: X residual bounce received
bounce:Apr 14 13:31:00 2011 (20518) Notifying disabled member X for
list: list
bounce:Apr 14 13:31:15 2011 (20554) Notifying disabled member X for
list: list

What are the other entries timestamped at or close to Apr 13 09:17:59

What are the processes with PIDs 1567, 5194 and 14017? These should all
be BounceRunner or perhaps OutgoingRunner if there are also entries in
Mailman's smtp-failure log. Are you running multiple sliced qrunners
or are qrunners being restarted.

See the FAQ at http://wiki.list.org/x/_4A9 for information on
completely stopping Mailman and all qrunners. Then stop Mailman and
all the runners and after everything is stopped, start Mailman just

That may help if there are multiple copies of qrunners processing the
same slices.

So here we have mailman getting a bounce for the address yesterday, and
the original "notification" try and my subsequent tests, today.

Hipotesis: The user set "disable delivery" but we have some bounces
coming back, so the "disable delivery" sets by user is mutated
incorrectly to "user bouncing", causing this problem.

I don't see how that can happen. When a bounce is received for a member
whose delivery is disabled for any reason, we just log the 'residual
bounce received' message and otherwise ignore it.

Some more data:

import time
'Thu Apr 14 12:17:10 2011'

The change date, is consistent with this line on my log:

bounce:Apr 14 12:17:09 2011 (14017) list: X residual bounce received

Yes, and that is very curious, but the member's delivery was already
disabled at 09:00, and unless the cron/disabled command in Mailman's
crontab has some options to process other than disabled BYBOUNCE
members, the member was already disabled BYBOUNCE at that time.

bounce:Apr 14 09:00:03 2011 (24248) Notifying disabled member X for
list: list

Also, a residual bounce does not change or update
DeliveryStatusChangeTime at least with standard Bouncer.py and Old
Style Memberships.py.

This happens from time to time, and it is really painful, since others
users are not getting their reminders, or they are getting them too late
and their token has already expired.

I will keep this state for a couple of days, just in case you need some
more info. Then, I will clean it up. But this is a recurrent issue,
happens from time to time.

You could always patch cron/disabled by finding this:

except Errors.NotAMemberError:
# There must have been some problem with the data
we have
# on this member. Most likely it's that they don't
have a
# password assigned. Log this and delete the
'NotAMemberError when sending disabled
notice: %s',
mlist.ApprovedDeleteMember(member, 'cron/disabled')

and adding immediately following

except TypeError:
'TypeError when sending disabled notice: %s',

This will at least not stop the process for other members.

Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan

Search Discussions

Discussion Posts


Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 2 of 2 | next ›
Discussion Overview
groupmailman-users @
postedApr 14, '11 at 12:06p
activeApr 14, '11 at 10:43p

2 users in discussion

Jesus Cea: 1 post Mark Sapiro: 1 post



site design / logo © 2022 Grokbase