bounces are not disabling accounts
I set "bounce processing" to "on" so that mailman will disable email accounts if they receive just once bounce. However, mailman is not disabling the accounts! Here are the logs from /var/log/mailman/ to show that it DOES "know" about the mail bounce: May 25 11:58:09 2006 (2184) <BounceRunner at -1211098548> processing 1 queued bounces May 25 11:58:09 2006 (2184) isolation-list: john2@tripperjones.com bounce score: 1.0 May 25 11:58:09 2006 (2184) sending isolation-list list probe to: john2@tripperjones.com (score 1.0 >= 0.9)
But shouldn't it automatically disable the account? And should it tell me, the administrator of the bounce? I set all the notifications message options to "yes". Also, the settings I set in bounce processing seem to be correct:
- Should Mailman perform automatic bounce processing? -> yes
- The maximum member bounce score before the member's subscription is disabled -> .9
- The number of days after which a member's bounce information is discarded, if no new bounces have been received in the interim -> 7
- How many Your Membership Is Disabled warnings a disabled member should get -> 0
- The number of days between sending the Your Membership Is Disabled warnings -> 7
The settings seem allright to me, but I see no change in the "Membership list" section. I checked google, the maillists, and the FAQs, but I cannot find the answer to this one, so I'm hoping someone in maillist-land can help me.
- Steve
Patrick Bogen wrote:
Patrick is correct. If
VERP_PROBES = Yes
in mm_cfg.py, when the score reaches threshold, a probe is sent and the score is reset to 0. The user's delivery is only disabled if the probe bounces.
Here too, the notice is only sent for the probe bounce. If the probes don't bounce, there's no notice and no disable.
Probes can fail to bounce for several reasons. If the bounce is full mailbox, the probe may be small enough to fit. The VERP like token in the probe may cause delivery problems. Also, there is the insidious problem that the probe token is a normal 'pending confirmation' with a lifetime of PENDING_REQUEST_LIFE (default 3 days). If the bounce is for some 'retryable' reason like a DNS timeout, server connect time out, etc., the probe may not bounce for say 5 days in which case the token may have expired and the probe bounce will never be recorded.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Patrick Bogen wrote:
Patrick is correct. If
VERP_PROBES = Yes
in mm_cfg.py, when the score reaches threshold, a probe is sent and the score is reset to 0. The user's delivery is only disabled if the probe bounces.
Here too, the notice is only sent for the probe bounce. If the probes don't bounce, there's no notice and no disable.
Probes can fail to bounce for several reasons. If the bounce is full mailbox, the probe may be small enough to fit. The VERP like token in the probe may cause delivery problems. Also, there is the insidious problem that the probe token is a normal 'pending confirmation' with a lifetime of PENDING_REQUEST_LIFE (default 3 days). If the bounce is for some 'retryable' reason like a DNS timeout, server connect time out, etc., the probe may not bounce for say 5 days in which case the token may have expired and the probe bounce will never be recorded.
-- Mark Sapiro <msapiro@value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro -
Patrick Bogen -
Steve Quezadas