[Mailman-Users] bounced addresses stays there

[Mark Sapiro]

Kirke Johnson wrote:

>I have been attempting to test out the bounce processing on a test 
>list and am confused by the results so far. We are running Mailman 
>2.1.9 on RHEL, installed with the OS.
>
>The test list (tsstst) has the following settings:
>
>bounce_score_threshold: 1.0 (originally 5.0)
>bounce_info_stale_after: 7
>bounce_you_are_disabled_warnings: 0 - for immediate removal (originally 3)
>bounce_you_are_disabled_warnings_interval: 7
>
>I have sent four test messages thus far, with an invalid list member 
>"bogus at example.org". The first two tests were on 1/22. The first one 
>detected the bounce and issued the unsubscribe notification that 
>"bogus at example.org has been removed from Tsstst". The member was 
>still listed in the membership list, and did not go away when 
>/usr/lib/mailman/cron/disabled ran the next morning. The second 
>message on the 22nd did not yield a bounce.


If bounce_you_are_disabled_warnings is 0, cron/disabled is not involved
in removing the bouncing member. The member should be removed
immediately. The fact that you received an unsubscribed notice and the
subsequent message didn't yield a bounce would seem to say the bogus
address was in fact removed.

What "membership list" are you looking at? Could it be stale?


>Today (still within the 7 day warning interval), I sent two more test 
>messages with the identical results.


The 7 day interval is only meaningful if
bounce_you_are_disabled_warnings is non-zero.

Identical results? You mean the first message bounced and unsubscribed
the member and the second message wasn't sent (or at least didn't
bounce)?

What do your MTA logs say about what was sent and what bounced?


>Running 
>"/usr/lib/mailman/bin/list_members -n bybounce tsstst" as suggested 
>below produces no output.


This only lists members who are still members but whose delivery is
disabled by bounce. With bounce_you_are_disabled_warnings = 0, there
should never be any.


>Is there another way to examine the counters inside the "black box" 
>to see what is going on? I can conceive of this process dragging on a 
>couple more days before the original disabled_warnings threshhold of 
>3 is reached and the disabled cron job has a final chance to run, if 
>that is even worth doing at this point.


If the original bounce_you_are_disabled_warnings = 3 is the issue, the
address will still be a member with delivery disabled by bounce. It
will appear as such on the web admin Membership list and will be
listed by

/usr/lib/mailman/bin/list_members -n bybounce tsstst

What's in Mailman's logs, particularly bounce and smtp-failure.

Do you by chance have

VERP_PROBES = Yes

(or On or True or 1) in mm_cfg.py? If so, when threshold is reached,
score is reset and a VERP like probe is sent. If that doesn't bounce
or if the bounce is not correctly delivered, the member will never be
removed.

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