[Mailman-Users] Problem/Question Regarding Bounce Processing

[Mark Sapiro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFGhT9jVVuXXpU7hpMRAgoUAKDymAF/J6dmJNO3onu9fMd1FeKZWgCg0F5o
WbNWQ8NlQg3buysOvanjwrw=
=Uo2D
-----END PGP SIGNATURE-----