Where are docs on bounce handling?
I must have missed this somewhere in my reading about SmarList. Could someone tell me where to find the documentation on how SmartList handles email that bounces because of incorrect email addresses, full mailboxes, etc. I'm looking for something more than the schematic overview in section 3m of the Manual. Thanks for your help pointing this out. -Kevin Zembower ----- E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139
"KEVIN ZEMBOWER" <KZEMBOWER@jhuccp.org> writes:
I must have missed this somewhere in my reading about SmarList. Could someone tell me where to find the documentation on how SmartList handles email that bounces because of incorrect email addresses, full mailboxes, etc. I'm looking for something more than the schematic overview in section 3m of the Manual.
The handling of bounces is split between the rc.request rcfile and the procbounce script. The rc.request rcfile ignores bounce messages that look non-fatal (e.g., delay warnings) or that appear to be rejections of a message's _contents_ instead of a bad address (e.g., "eight bit data not allowed"). The rc.request script also sets a flag if the message looks like a DSN (Delivery Status Notification, see rfcs 1892 and 1894). It then hands off bounces to the procbounce script. The procbounce script attempts to extract the bad address from the bounce message. If it comes up with an address, it then tries to generate a hash based on the Message-Id: of the message that _bounced_ (i.e., the message from the list that was rejected), falling back the the current date if can't determine the original Message-Id:. That value is used to name a file, into which procbounce stores the bad address. Having done that, it counts how many such files contain the bad address. If at least $minbounce files contain that address, procbounce tries to unsubscribe it. The purpose of the hash of the Message-Id: is to work around (broken) systems that can send multiple bounce messages regarding a single message/address combo. All those bounces will hopefully contain the original message's Message-Id: header field in them, so that the address will only be stored into a single file and thereby only counted once against $minbounce. Philip Guenther
participants (2)
-
KEVIN ZEMBOWER
-
Philip Guenther