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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Argonne, IL 60439-4828 IBMMAIL: I1004994 ------------------------------------------------------ Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
