Re: Bounce Processing "Best Practices?"
- On Sat, 2011-01-01 at 21:36 -0800, Steve Jenkins wrote:
> This is a "best practices" question for other Postfix users who may be using<snip>
> Postfix to send email to large opt-in mailing lists.
> So with all that explained, I have few questions:I don't see why that wouldn't get them all, but I personally pipe the
> 1) What's the optimal way for us to process the bounces? Our plan is to grep
> the catchall file and unsubscribe based on the user ID in the original
> Return-Path. But will that get them ALL?
bounces straight into a perl script from Postfix and remove them using
that. This means that they get removed straight away automatically.
> 2) Should we also be grepping our /var/log/maillog* files and looking forJust processing all the undeliverables should capture everything.
> 5xx errors? Or will those all end up in the catchall eventually, after
> Postfix gives up trying to deliver? Should we be looking in our logs for
> anything else to unsubscribe users?
> 3) Would we be better off using VERP instead of our custom Return-Path? I'veI can't think of any specific advantages that it would give you, but the
> read through http://www.postfix.org/VERP_README.html but can't tell if that
> gives us any advantage over the approach we're using.
technique is already built-in to Postfix and recognised as a fairly
standard way of processing bounces.
> 4) We want to be good netizens and responsible senders, so can anyone seeAll looks good to me. The other things that you might want to consider
> any additional steps (general or specific) that we're NOT doing but should
- Applying for whitelist status from those email providers that operate
one (such as AOL).
- Use different IP addresses for different types of mailings (for
example one IP address for your known good recipients and one for your
- Use a whitelisting agent SuretyMail