Bounce Processing -- Disable/Removal Notification
![](https://secure.gravatar.com/avatar/7208a78d6e886c7579b1fb9e381ef9ea.jpg?s=120&d=mm&r=g)
We have a newsletter type list that has been running for almost two years now. The list currently has 1,100 members who receive one email each morning. The Bounce Configuration page for this list is configured as follows: Yes, 5.0, 30, 2, 7, Yes, Yes, Yes which I believe may be the defaults. The system is running under RedHat V4.
I ran the following command: grep 'score' /var/log/mailman/bounce and received a list of 28 users that have records containing "(score 5.0 >= 5.0)". I can see one duplicate email address in this list of 28 - most of the records appear to be unique email addresses. The dates on the records cover a period of one week.
It appears there are a number of candidates that could have their subscriptions Disabled and/or Removed from the list. I have been the list admin for two years now and I have never received an email saying a list member has been Disabled or Removed. This seems odd based on what I am seeing in the logs. I do receive emails for bounce messages that fail detection regularly.
Is it possible to see in a log (or through the online interface) when a user is placed in Disabled status? I would like to be able to grep this log and see if anyone is being Disabled or Removed - this may confirm if there is actually a problem or not. Let's say looking at the logs reveals that list members are not ever being Disabled or Removed - what is the next step to debugging this problem?
Thank you in advance for your help! Greg Sims
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Greg Sims wrote:
These may be the mm_cfg.py defaults for ne lists at your site, but the Defaults.py defaults are Yes, 5.0, 7, 3, 7, Yes, Yes, Yes, but that doesn't really affect the rest of your question.
Do these entries say "sending listname list probe to: user@example.com (score 5.0 >= 5.0)"?
Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP probes was unconditionally on)?
If so, do you see in the bounce log that a probe was sent but didn't bounce? If so, it is likely that your MTA doesn't recognize the '+' delimiter to separate the VERP probe token from the local part of an address and can't deliver the bounce.
With the settings you have, you should receive disabled notices.
'Disabling' entries will appear in the bounce log if members are actually disabled.
bin/list_members --nomail=bybounce listname
will list all the disabled by bounce members.
If there aren't any, and I suspect there aren't, I suspect that examination of the bounce log will show "sending listname list probe to: user@example.com (score 5.0 >= 5.0)" entries, but no "listname: user@example.com disabling due to probe bounce received" entries.
If this is the case, I suspect it is because the MTA does not know how to deliver mail addressed to listname-bounces+xxxxxx@listdomain or at least doesn't pipe it to the wrapper as it does for mail to listname-bounces@listdomain.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/7208a78d6e886c7579b1fb9e381ef9ea.jpg?s=120&d=mm&r=g)
Mark,
I believe you have the problem narrowed down. Here are the answers to your questions:
Do these entries say "sending listname list probe to: user@example.com (score 5.0 >= 5.0)"?
Yes
Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP probes was unconditionally on)?
2.1.5
If so, do you see in the bounce log that a probe was sent but didn't bounce? If so, it is likely that your MTA doesn't recognize the '+' delimiter to separate the VERP probe token from the local part of an address and can't deliver the bounce.
I believe so. A score of 5.0 is reached, the probe message is sent and the next thing I see is another bounce with a score of 1.0.
'Disabling' entries will appear in the bounce log if members are actually disabled.
There are no Disabling entries in the logs.
bin/list_members --nomail=bybounce listname will list all the disabled by bounce members.
This command returns null.
If there aren't any, and I suspect there aren't, I suspect that examination of the bounce log will show "sending listname list probe to: user@example.com (score 5.0 >= 5.0)" entries, but no "listname: user@example.com disabling due to probe bounce received" entries.
Correct!
If this is the case, I suspect it is because the MTA does not know how to deliver mail addressed to listname-bounces+xxxxxx@listdomain or at least doesn't pipe it to the wrapper as it does for mail to listname-bounces@listdomain.
Thanks again for your help Mark! Greg
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Greg Sims wrote:
OK. The probes aren't bouncing or the bounced probes aren't delivered back to Mailman. It's extremely unlikely that no probes are bouncing, so the most likely thing is the probe bounces aren't getting back to Mailman.
<snip>
There a couple of possibilities. First, I suggest that you verify that mail to user+xyz@example.com is not properly delivered to user where example.com is your mail domain and user is a valid local address. Then we know for sure that this is the problem. Or, you could check qmail's logs from the time a probe bounce was sent to see the return in the log and what happened to it.
If possible, you could upgrade to a later than 2.1.5 Mailman version in which you can set VERP_PROBES = No in mm_cfg.py to avoid the issue.
There is some information on qmail at <http://www.list.org/mailman-install/qmail-issues.html>. It looks like in order to make this recognition work with qmail, you may have to put
VERP_PROBE_FORMAT = '%(bounces)s-+%(token)s' VERP_PROBE_REGEXP = r'^(?P<bounces>.*?)-\+(?P<token>[^@]+)@.*$'
mm_cfg.py (the install manual talks about VERP_FORMAT and VERP_REGEXP, but that is not what we need here). This changes the delimiter from '+' to '-+' and changes the recognizer to recognize it. It looks like you also need and additional .qmail-$i-bounces-default alias file ($i is the list name) for each affected list.
There may be a way to change qmail's VERP delimiter from '-' to '+' which may be enough by itself, but I don't know.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Greg Sims wrote:
These may be the mm_cfg.py defaults for ne lists at your site, but the Defaults.py defaults are Yes, 5.0, 7, 3, 7, Yes, Yes, Yes, but that doesn't really affect the rest of your question.
Do these entries say "sending listname list probe to: user@example.com (score 5.0 >= 5.0)"?
Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP probes was unconditionally on)?
If so, do you see in the bounce log that a probe was sent but didn't bounce? If so, it is likely that your MTA doesn't recognize the '+' delimiter to separate the VERP probe token from the local part of an address and can't deliver the bounce.
With the settings you have, you should receive disabled notices.
'Disabling' entries will appear in the bounce log if members are actually disabled.
bin/list_members --nomail=bybounce listname
will list all the disabled by bounce members.
If there aren't any, and I suspect there aren't, I suspect that examination of the bounce log will show "sending listname list probe to: user@example.com (score 5.0 >= 5.0)" entries, but no "listname: user@example.com disabling due to probe bounce received" entries.
If this is the case, I suspect it is because the MTA does not know how to deliver mail addressed to listname-bounces+xxxxxx@listdomain or at least doesn't pipe it to the wrapper as it does for mail to listname-bounces@listdomain.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/7208a78d6e886c7579b1fb9e381ef9ea.jpg?s=120&d=mm&r=g)
Mark,
I believe you have the problem narrowed down. Here are the answers to your questions:
Do these entries say "sending listname list probe to: user@example.com (score 5.0 >= 5.0)"?
Yes
Is VERP_PROBES = Yes in mm_cfg.py (or is this Mailman 2.1.5 where VERP probes was unconditionally on)?
2.1.5
If so, do you see in the bounce log that a probe was sent but didn't bounce? If so, it is likely that your MTA doesn't recognize the '+' delimiter to separate the VERP probe token from the local part of an address and can't deliver the bounce.
I believe so. A score of 5.0 is reached, the probe message is sent and the next thing I see is another bounce with a score of 1.0.
'Disabling' entries will appear in the bounce log if members are actually disabled.
There are no Disabling entries in the logs.
bin/list_members --nomail=bybounce listname will list all the disabled by bounce members.
This command returns null.
If there aren't any, and I suspect there aren't, I suspect that examination of the bounce log will show "sending listname list probe to: user@example.com (score 5.0 >= 5.0)" entries, but no "listname: user@example.com disabling due to probe bounce received" entries.
Correct!
If this is the case, I suspect it is because the MTA does not know how to deliver mail addressed to listname-bounces+xxxxxx@listdomain or at least doesn't pipe it to the wrapper as it does for mail to listname-bounces@listdomain.
Thanks again for your help Mark! Greg
![](https://secure.gravatar.com/avatar/746f7519ba02fb0d815e59f305c53fa2.jpg?s=120&d=mm&r=g)
Greg Sims wrote:
OK. The probes aren't bouncing or the bounced probes aren't delivered back to Mailman. It's extremely unlikely that no probes are bouncing, so the most likely thing is the probe bounces aren't getting back to Mailman.
<snip>
There a couple of possibilities. First, I suggest that you verify that mail to user+xyz@example.com is not properly delivered to user where example.com is your mail domain and user is a valid local address. Then we know for sure that this is the problem. Or, you could check qmail's logs from the time a probe bounce was sent to see the return in the log and what happened to it.
If possible, you could upgrade to a later than 2.1.5 Mailman version in which you can set VERP_PROBES = No in mm_cfg.py to avoid the issue.
There is some information on qmail at <http://www.list.org/mailman-install/qmail-issues.html>. It looks like in order to make this recognition work with qmail, you may have to put
VERP_PROBE_FORMAT = '%(bounces)s-+%(token)s' VERP_PROBE_REGEXP = r'^(?P<bounces>.*?)-\+(?P<token>[^@]+)@.*$'
mm_cfg.py (the install manual talks about VERP_FORMAT and VERP_REGEXP, but that is not what we need here). This changes the delimiter from '+' to '-+' and changes the recognizer to recognize it. It looks like you also need and additional .qmail-$i-bounces-default alias file ($i is the list name) for each affected list.
There may be a way to change qmail's VERP delimiter from '-' to '+' which may be enough by itself, but I don't know.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Greg Sims
-
Mark Sapiro