-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Barry Finkel wrote:

I have a question/problem with Mailman bounce processing. We have Mailman lists here that are re-built every morning from our Human Resources database. When mail is sent to one of these lists, and one or more of the e-mail addresses therein have problems, I see in my morning report (and/or in the Mailman bounce log) that specific addresses have had bounces. I do not see the rejection messages that are sent to

 listname-bounce

so I do not know what the problem might have been. I assume that the rejection message is discarded after it has been processed, the bounce log appended, and the e-mail address bounce score increased. I would like to be able to correct those bad addresses that come from our HR Database when they are first seen as bad, but I cannot correct them if I do not know what the nature of the bounce was. And I really do not want to have to send test mail to each of the failed addresses in order to get a rejection message.

I'm not sure what the issue is. Do these bad addresses never get removed because you are continuously removing and re-adding them, thus resetting their bounce score every day? Or do you just want to see the 'first' bounce from a new member so you can delete that address faster than normal bounce processing does?

You are correct about what Mailman does. The only actual bounce DSN that is not simply discarded after processing is the one that caused the score to reach threshold and disables delivery. That one is sent to the list owner with the disable notice if bounce_notify_owner_on_disable is Yes.

If the problem is that bad addresses are never getting disabled and removed because you are continuously rebuilding the list and resetting scores, you could try using bin/sync_members to update the list from the HR data. This will not reset scores or options for existing members.

If that is not the issue, and you just want to see the first bounce for a new member, and you don't want to do this in the MTA and you don't want to modify Mailman code, the only way is to set bounce_score_threshold to 1.0 or less so that everyone is disabled on the first bounce and then re-enable those that shouldn't be disabled so soon.

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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)

iD8DBQFGhSp/VVuXXpU7hpMRAuL9AKDp3+Y9vHOgnIP0ZqAopwCStxUpaACgwo4L h+nLERWMfWEEW4RdRm3RkPI= =847S -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Barry Finkel wrote:

I have a question/problem with Mailman bounce processing. We have Mailman lists here that are re-built every morning from our Human Resources database. When mail is sent to one of these lists, and one or more of the e-mail addresses therein have problems, I see in my morning report (and/or in the Mailman bounce log) that specific addresses have had bounces. I do not see the rejection messages that are sent to

 listname-bounce

so I do not know what the problem might have been. I assume that the rejection message is discarded after it has been processed, the bounce log appended, and the e-mail address bounce score increased. I would like to be able to correct those bad addresses that come from our HR Database when they are first seen as bad, but I cannot correct them if I do not know what the nature of the bounce was. And I really do not want to have to send test mail to each of the failed addresses in order to get a rejection message.

I'm not sure what the issue is. Do these bad addresses never get removed because you are continuously removing and re-adding them, thus resetting their bounce score every day? Or do you just want to see the 'first' bounce from a new member so you can delete that address faster than normal bounce processing does?

You are correct about what Mailman does. The only actual bounce DSN that is not simply discarded after processing is the one that caused the score to reach threshold and disables delivery. That one is sent to the list owner with the disable notice if bounce_notify_owner_on_disable is Yes.

If the problem is that bad addresses are never getting disabled and removed because you are continuously rebuilding the list and resetting scores, you could try using bin/sync_members to update the list from the HR data. This will not reset scores or options for existing members.

If that is not the issue, and you just want to see the first bounce for a new member, and you don't want to do this in the MTA and you don't want to modify Mailman code, the only way is to set bounce_score_threshold to 1.0 or less so that everyone is disabled on the first bounce and then re-enable those that shouldn't be disabled so soon.

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

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32)

iD8DBQFGhSp/VVuXXpU7hpMRAuL9AKDp3+Y9vHOgnIP0ZqAopwCStxUpaACgwo4L h+nLERWMfWEEW4RdRm3RkPI= =847S -----END PGP SIGNATURE-----