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
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 at 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
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
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
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 at anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994