bounced addresses stays there
hi,
I have the following settings:
bounce_score_threshold: 2.0 bounce_info_stale_after: 7 bounce_you_are_disabled_warnings: 0 - for immediate removal bounce_you_are_disabled_warnings_interval: 7
then I notice that the addresses that have delivery disabled for bounce reason is still in the members list and not completely removed from the list .. which is not good becasue I want them totally removed and know the exact number of active members ..
how can I do that?
thanks..
News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx
faisal anif wrote:
I have the following settings:
bounce_score_threshold: 2.0 bounce_info_stale_after: 7 bounce_you_are_disabled_warnings: 0 - for immediate removal bounce_you_are_disabled_warnings_interval: 7
then I notice that the addresses that have delivery disabled for bounce reason is still in the members list and not completely removed from the list .. which is not good becasue I want them totally removed and know the exact number of active members ..
how can I do that?
The settings you have will do that. If you recently reduced bounce_you_are_disabled_warnings to 0 from some other number, those members whose delivery was disabled by bounce at the time of the reduction will still get the number of warnings they were set to get when their delivery was disabled before they are removed. Also, cron/disabled has to be run in order to send the warnings and ultimately remove the members.
If you don't want to wait for these to be automatically removed, you can always remove them via the admin interface or if you have command line access, do
bin/list_members -n bybounce LISTNAME | bin/remove_members -f - LISTNAME
which will remove all members with delivery disabled by bounce.
In any case any members who in the future bounce on two out of seven days will be immediately removed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
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@example.org". The first two tests were on 1/22. The first one detected the bounce and issued the unsubscribe notification that "bogus@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.
Today (still within the 7 day warning interval), I sent two more test messages with the identical results. Running "/usr/lib/mailman/bin/list_members -n bybounce tsstst" as suggested below produces no output.
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.
Thanks for your help in supporting Mailman!
At 10:49 PM 12/20/2008, you wrote:
faisal anif wrote:
I have the following settings:
bounce_score_threshold: 2.0 bounce_info_stale_after: 7 bounce_you_are_disabled_warnings: 0 - for immediate removal bounce_you_are_disabled_warnings_interval: 7
then I notice that the addresses that have delivery disabled for
bounce reason is still in the members list and not completely removed from the list .. which is not good becasue I want them totally removed and know the exact number of active members ..
how can I do that?
The settings you have will do that. If you recently reduced bounce_you_are_disabled_warnings to 0 from some other number, those members whose delivery was disabled by bounce at the time of the reduction will still get the number of warnings they were set to get when their delivery was disabled before they are removed. Also, cron/disabled has to be run in order to send the warnings and ultimately remove the members.
If you don't want to wait for these to be automatically removed, you can always remove them via the admin interface or if you have command line access, do
bin/list_members -n bybounce LISTNAME | bin/remove_members -f - LISTNAME
which will remove all members with delivery disabled by bounce.
In any case any members who in the future bounce on two out of seven days will be immediately removed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/kjohnson%40pcc.edu
Security Policy: http://wiki.list.org/x/QIA9
Kirke Johnson Internet: kjohnson@pcc.edu Email Administrator, TSS , Sylvania Campus http://www.pcc.edu/ Portland Community College, Portland, OR, USA (503) 977-4368
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@example.org". The first two tests were on 1/22. The first one detected the bounce and issued the unsubscribe notification that "bogus@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@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
At 08:54 AM 1/27/2009, Mark Sapiro wrote:
Kirke Johnson wrote:
(-- snip --)
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?
I have been refreshing the Membership List in the admin GUI for the list.
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)?
The first message bounced and unsubscribed the member, but they did not go away. The second message did not bounce as there was already a bounce that day.
(-- snip --)
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.
YES! This was the problem - thanks!! After changing the configuration, the next test message removed the member very nicely.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Kirke Johnson Internet: kjohnson@pcc.edu Email Administrator, TSS , Sylvania Campus http://www.pcc.edu/ Portland Community College, Portland, OR, USA (503) 977-4368
participants (3)
-
faisal anif -
Kirke Johnson -
Mark Sapiro