>Sean Hennessey:
> All,
>
> I'm bringing a new sending IP online and need to know if there is
> an easy way to warm it up w/ Postfix.
>
> For those that don't know, warming up is a process where you start
> to send small amounts of mail of the new IP till it's built up a
> good enough reputation.
>
> In a past life I use Port25's powermta software. It has an easy
> config way of doing this where you can say for gmail.com divert
> the first X emails to use this way of sending instead of the normal
> way.
>
> I'm trying to see if there is something similar in postfix.
>
> So basically I need a way to take a configurable amount of mail
> for various domains and send them on smtp endpoint instead of the
> relay that is currently configured.
>
> I searched the list archives and saw the thread of gradual shift
> of traffic from back in February of this year. That gives me some
> ideas, but that seems to be for all traffic, not a subset.
>
> I'd really like a way to send X% of gmail.com traffic to one relay
> and the rest to another relay. Ditto for a couple of other major
> ESP's like Yahoo, MS, etc...
>
> Thanks in advance.

The two examples below support different old/new IP address ratios
for different destinations, as well as the same ratios for all
destinations.

To change the ratios over time, you would have to update main.cf
and rely on Postfix built-in behavior to restart Postfix SMTP server
processes after 100 SMTP client connections.

First, specify master.cf entries with different source IP addresses.
Each entry uses the proper smtp_helo_name that matches the PTR value
for the smtp_bind_address setting.

In /etc/postfix/master.cf:
==========================

smtp1     unix  -       -       n       -       -       smtp
  -o { smtp_bind_address = 1.2.3.1 }
  -o { smtp_helo_name = helo-for-1.2.3.1 }

smtp2     unix  -       -       n       -       -       smtp
  -o { smtp_bind_address = 1.2.3.2 }
  -o { smtp_helo_name = helo-for-1.2.3.2 }

In /etc/postfix/main.cf:
========================

Next an example that supports different warming up ratios for
different destinations. See "Notes" below for a simpler approach
when the warming up ratios can be the same for all destinations.

This example uses a nested table, which requires a restriction class.
smtpd_recipient_restrictions = check_recipient_access
  inline:{
     { gmail.com = class-gmail }
     { yahoo.com = class-yahoo }
  }
  ...other restrictions...

  # To get (90%, 10%), specify one filter 9x and the other filter 1x.
  # The order does not matter.
  restriction_classes = class-gmail, class-yahoo
  class-gmail = check_recipient_access randmap:{filter smtp1:, filter smtp2:}
  class-yahoo = check_recipient_access randmap:{filter smtp1:, filter smtp2:}

Notes:
======

- Instead of inline:{...}, a hash or pcre table could work too. 
  With pcre you can easily specify a catch-all rule at the end.

- If you can use the same randmap:{} settings for all destinations, then
  you can avoid the need for restriction_classes and for the lookup
  table that returns restriction class names. Just select the filter
  action with:

  smtpd_recipient_restrictions =
     check_recipient_access randmap:{filter smtp1:, filter smtp2:}
     ...other restrictions...

- For the future: we could make randmap smarter and support a weight
  factor, like randmap:{{filter smtp1:}*99, {filter smtp2:}*1} where
  a weight of *1 is of course the default.

The examples were not tested...

        Wietse

Reply via email to