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.

And Mark Sapiro <msapiro@value.net> replied:

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.

I am sorry that I was not clear in my posting. In a "normal" list, where persons subscribe and unsubscribe, I am content with the Mailman bounce processing, where Mailman will set "nomail" for addresses that continually bounce.

When there is a bad e-mail address in our HR Database, that address needs to be corrected so that future mailings to that address, either via a Mailman list or via an ad-hoc mailing list derived from the HR Database, will reach the intended recipient. With the Mailman lists, I (as Mailman admin) do not see the rejection message; neither do the individual list owner(s). So, without my daily report I do not know that a bounce has occurred, and I do not know the nature of the bounce. As I did this morning, I had to send test mail to the address to get a rejection message to see what the failure was. If there is a bounce, can I be assurred that the bounce was due to the mailbox not existing?

Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone: +1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 222, Room D209 Internet: BSFinkel@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994