Loading ...
Sorry, an error occurred while loading the content.

Re: Bounce Processing "Best Practices?"

Expand Messages
  • Andrew Beverley
    ... ... I don t see why that wouldn t get them all, but I personally pipe the bounces straight into a perl script from Postfix and remove them using
    Message 1 of 3 , Jan 2, 2011
    • 0 Attachment
      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
      > Postfix to send email to large opt-in mailing lists.
      >

      <snip>

      > So with all that explained, I have few questions:
      >
      > 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?

      I don't see why that wouldn't get them all, but I personally pipe the
      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 for
      > 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?

      Just processing all the undeliverables should capture everything.

      > 3) Would we be better off using VERP instead of our custom Return-Path? I've
      > 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.

      I can't think of any specific advantages that it would give you, but the
      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 see
      > any additional steps (general or specific) that we're NOT doing but should
      > be?
      >

      All looks good to me. The other things that you might want to consider
      are:

      - 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
      initial mailing)

      - Use a whitelisting agent SuretyMail

      Andy
    Your message has been successfully submitted and would be delivered to recipients shortly.