Re: [Mailman-Users] Problem/Question Regarding Bounce Processing

Barry Finkel wrote:
And Mark Sapiro <msapiro@value.net> replied:
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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Finkel wrote:
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@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)
iD8DBQFGhT9jVVuXXpU7hpMRAgoUAKDymAF/J6dmJNO3onu9fMd1FeKZWgCg0F5o WbNWQ8NlQg3buysOvanjwrw= =Uo2D -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Barry Finkel wrote:
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@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)
iD8DBQFGhT9jVVuXXpU7hpMRAgoUAKDymAF/J6dmJNO3onu9fMd1FeKZWgCg0F5o WbNWQ8NlQg3buysOvanjwrw= =Uo2D -----END PGP SIGNATURE-----
participants (2)
-
Barry Finkel
-
Mark Sapiro