FAQ
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 know that I can add an additional address in the

/var/lib/mailman/data/aliases

file to the

listname-bounce:

alias line, but I do not want to do this manually every time I create
a new list.

Are there any suggestions on what I can do? Thanks.
----------------------------------------------------------------------
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

Search Discussions

  • Mark Sapiro at Jun 29, 2007 at 3:51 pm

    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 at value.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • Barry Finkel at Jun 29, 2007 at 4:39 pm

    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 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
    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 at anl.gov
    Argonne, IL 60439-4828 IBMMAIL: I1004994
  • Mark Sapiro at Jun 29, 2007 at 5:20 pm

    Barry Finkel wrote:
    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?
    No. The bounce can be for many reasons, including such things as 'full
    mailbox'.

    You are correct in thinking that you have to see the actual DSN to know
    what the reason is.

    I am still not clear on what happens with the HR based list and whether
    the issue is that you need to see a bounce DSN as soon as possible in
    order to identify problems in the HR database, or if the issue is that
    bouncing members never get disabled.

    As I tried to say in my previous reply, if you need to see the first
    bounce, the only way to do that with Mailman settings is to set
    bounce_score_threshold to 1.0 or less so that everyone is disabled on
    the first bounce and set bounce_notify_owner_on_disable to Yes so that
    the list owner receives a notice which will contain the bounce DSN. Then
    the list owner has to notify HR if the DSN shows the address is no good
    or re-enable delivery if the DSN is for some other reason.

    If the issue is that bouncing members never get disabled, you need to
    revise the way you update the list from the HR database to use a method
    like bin/sync_members so that bounce scores are not reset in this process.

    In the first case, it is a balance between the extra effort to re-enable
    'transient' bounce disables vs. the effort to extract the fact of the
    bounce from the bounce log and send a test email that determines which
    approach is better.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
categoriespython
postedJun 29, '07 at 3:02p
activeJun 29, '07 at 5:20p
posts4
users2
websitelist.org

2 users in discussion

Mark Sapiro: 2 posts Barry Finkel: 2 posts

People

Translate

site design / logo © 2022 Grokbase