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

Freemailer segregation best way? Transports - Instances & IP's

Expand Messages
  • Sam Jones
    Good afternoon, I m looking to get some views and advice on the best way to set Postfix up so I can segregate a large newsletter list up into a semi decent
    Message 1 of 5 , Nov 20, 2012
    • 0 Attachment
      Good afternoon,

      I'm looking to get some views and advice on the best way to set Postfix
      up so I can segregate a large newsletter list up into a semi decent
      working structure.

      Basically my newsletter server has a /29 and I want to set up Postfix to
      (hopefully) do something like this:

      eth0:1 1.1.1.1 GMAIL Subscribers
      eth0:2 2.2.2.2 AoL Subscribers
      eht0:3 3.3.3.3 all others

      I'd like to be able to rate control the Gmail & AoL to complicate issues
      a little. I know how powerful and fast Postfix can be and I don't want
      to exceed the limits set on small scale mailers like us.

      What I'm looking for is the best approach to do this?

      I don't think I can do this with multiple instances as the incoming mail
      stream from the newsletter server (SMTP) has a stream of recipients at
      various domains, so what arrives in the Instance of Postfix will be
      mixed to start with.

      So I guess this means I'll need to simply do this in transports. I think
      I read that it's possible to create transports for specific SMTP
      destinations in the Book of Postfix. I guess I'd need to ask 'can I
      assign a specific interface/IP on a per transport basis?'

      Any suggestions or feedback would be gratefully received.

      Sam
    • Robert Schetterer
      ... perhaps do it like this ( total untested ) master.cf smtpaol unix - - n - - smtp .... -o smtp_bind_address=1.2.3.1 smtpgmail
      Message 2 of 5 , Nov 20, 2012
      • 0 Attachment
        Am 20.11.2012 14:13, schrieb Sam Jones:
        > Good afternoon,
        >
        > I'm looking to get some views and advice on the best way to set Postfix
        > up so I can segregate a large newsletter list up into a semi decent
        > working structure.
        >
        > Basically my newsletter server has a /29 and I want to set up Postfix to
        > (hopefully) do something like this:
        >
        > eth0:1 1.1.1.1 GMAIL Subscribers
        > eth0:2 2.2.2.2 AoL Subscribers
        > eht0:3 3.3.3.3 all others
        >
        > I'd like to be able to rate control the Gmail & AoL to complicate issues
        > a little. I know how powerful and fast Postfix can be and I don't want
        > to exceed the limits set on small scale mailers like us.
        >
        > What I'm looking for is the best approach to do this?
        >
        > I don't think I can do this with multiple instances as the incoming mail
        > stream from the newsletter server (SMTP) has a stream of recipients at
        > various domains, so what arrives in the Instance of Postfix will be
        > mixed to start with.
        >
        > So I guess this means I'll need to simply do this in transports. I think
        > I read that it's possible to create transports for specific SMTP
        > destinations in the Book of Postfix. I guess I'd need to ask 'can I
        > assign a specific interface/IP on a per transport basis?'
        >
        > Any suggestions or feedback would be gratefully received.
        >
        > Sam
        >

        perhaps do it like this ( total untested )

        master.cf

        smtpaol unix - - n - - smtp
        ....
        -o smtp_bind_address=1.2.3.1
        smtpgmail unix - - n - - smtp
        .....
        -o smtp_bind_address=1.2.3.2

        main.cf

        smtpaol_destination_concurrency_limit = 2
        smtpaol_destination_recipient_limit = 5
        smtpaol_destination_rate_delay = 1s
        smtpaol_destination_concurrency_failed_cohort_limit = 100


        smtpgmail_destination_concurrency_limit = 2
        smtpgmail_destination_recipient_limit = 5
        smtpgmail_destination_rate_delay = 1s
        smtpgmail_destination_concurrency_failed_cohort_limit = 100

        transport


        googlemail.com smtpgmail:googlemail.com
        aol.com smtpaol:aol.com


        Best Regards
        MfG Robert Schetterer

        --
        [*] sys4 AG

        http://sys4.de, +49 (89) 30 90 46 64
        Franziskanerstraße 15, 81669 München

        Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
        Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
        Aufsichtsratsvorsitzender: Joerg Heidrich
      • Sam Jones
        That looks like a good starting point, Thank you for the pointers Robert, really appreciated.
        Message 3 of 5 , Nov 20, 2012
        • 0 Attachment
          That looks like a good starting point, Thank you for the pointers
          Robert, really appreciated.


          On Tue, 2012-11-20 at 14:35 +0100, Robert Schetterer wrote:
          > Am 20.11.2012 14:13, schrieb Sam Jones:
          > > Good afternoon,
          > >
          > > I'm looking to get some views and advice on the best way to set Postfix
          > > up so I can segregate a large newsletter list up into a semi decent
          > > working structure.
          > >
          > > Basically my newsletter server has a /29 and I want to set up Postfix to
          > > (hopefully) do something like this:
          > >
          > > eth0:1 1.1.1.1 GMAIL Subscribers
          > > eth0:2 2.2.2.2 AoL Subscribers
          > > eht0:3 3.3.3.3 all others
          > >
          > > I'd like to be able to rate control the Gmail & AoL to complicate issues
          > > a little. I know how powerful and fast Postfix can be and I don't want
          > > to exceed the limits set on small scale mailers like us.
          > >
          > > What I'm looking for is the best approach to do this?
          > >
          > > I don't think I can do this with multiple instances as the incoming mail
          > > stream from the newsletter server (SMTP) has a stream of recipients at
          > > various domains, so what arrives in the Instance of Postfix will be
          > > mixed to start with.
          > >
          > > So I guess this means I'll need to simply do this in transports. I think
          > > I read that it's possible to create transports for specific SMTP
          > > destinations in the Book of Postfix. I guess I'd need to ask 'can I
          > > assign a specific interface/IP on a per transport basis?'
          > >
          > > Any suggestions or feedback would be gratefully received.
          > >
          > > Sam
          > >
          >
          > perhaps do it like this ( total untested )
          >
          > master.cf
          >
          > smtpaol unix - - n - - smtp
          > ....
          > -o smtp_bind_address=1.2.3.1
          > smtpgmail unix - - n - - smtp
          > .....
          > -o smtp_bind_address=1.2.3.2
          >
          > main.cf
          >
          > smtpaol_destination_concurrency_limit = 2
          > smtpaol_destination_recipient_limit = 5
          > smtpaol_destination_rate_delay = 1s
          > smtpaol_destination_concurrency_failed_cohort_limit = 100
          >
          >
          > smtpgmail_destination_concurrency_limit = 2
          > smtpgmail_destination_recipient_limit = 5
          > smtpgmail_destination_rate_delay = 1s
          > smtpgmail_destination_concurrency_failed_cohort_limit = 100
          >
          > transport
          >
          >
          > googlemail.com smtpgmail:googlemail.com
          > aol.com smtpaol:aol.com
          >
          >
          > Best Regards
          > MfG Robert Schetterer
          >
        • Wietse Venema
          ... You need to keep the following in mind, if you ever decide to use a per-destination recipient of 1. Wietse default_destination_rate_delay (default: 0s) The
          Message 4 of 5 , Nov 20, 2012
          • 0 Attachment
            Sam Jones:
            > That looks like a good starting point, Thank you for the pointers
            > Robert, really appreciated.

            You need to keep the following in mind, if you ever decide to use
            a per-destination recipient of 1.

            Wietse

            default_destination_rate_delay (default: 0s)
            The default amount of delay that is inserted between individual deliv-
            eries to the same destination; the resulting behavior depends on the
            value of the corresponding per-destination recipient limit.

            o With a corresponding per-destination recipient limit > 1, the
            rate delay specifies the time between deliveries to the same
            domain. Different domains are delivered in parallel, subject to
            the process limits specified in master.cf.

            o With a corresponding per-destination recipient limit equal to 1,
            the rate delay specifies the time between deliveries to the same
            recipient. Different recipients are delivered in parallel, sub-
            ject to the process limits specified in master.cf.
          • Sam Jones
            Appreciated, thanks. I m just installing it to an old bare metal test server so I can get it right before putting it into production. Many thanks to you both -
            Message 5 of 5 , Nov 20, 2012
            • 0 Attachment
              Appreciated, thanks.

              I'm just installing it to an old bare metal test server so I can get it
              right before putting it into production.

              Many thanks to you both - really appreciated.


              On Tue, 2012-11-20 at 09:58 -0500, Wietse Venema wrote:
              > Sam Jones:
              > > That looks like a good starting point, Thank you for the pointers
              > > Robert, really appreciated.
              >
              > You need to keep the following in mind, if you ever decide to use
              > a per-destination recipient of 1.
              >
              > Wietse
              >
              > default_destination_rate_delay (default: 0s)
              > The default amount of delay that is inserted between individual
              > deliv-
              > eries to the same destination; the resulting behavior
              > depends on the
              > value of the corresponding per-destination recipient limit.
              >
              > o With a corresponding per-destination recipient limit >
              > 1, the
              > rate delay specifies the time between deliveries to
              > the same
              > domain. Different domains are delivered in parallel,
              > subject to
              > the process limits specified in master.cf.
              >
              > o With a corresponding per-destination recipient limit
              > equal to 1,
              > the rate delay specifies the time between deliveries to
              > the same
              > recipient. Different recipients are delivered in
              > parallel, sub-
              > ject to the process limits specified in master.cf.
            Your message has been successfully submitted and would be delivered to recipients shortly.