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

remark on postscreen behavior in case of big MTA pool - CIDR list needed

Expand Messages
  • Maciej Uhlig
    We found the following in postfix log while expecting test mail delivery: 2012-03-29T13:32:41+02:00 services/192.168.10.210 postfix/postscreen[1697]: [ID
    Message 1 of 5 , Mar 30, 2012
      We found the following in postfix log while expecting test mail delivery:

      2012-03-29T13:32:41+02:00 services/192.168.10.210 postfix/postscreen[1697]: [ID 197553 mail.info] NOQUEUE: reject: RCPT from [74.125.83.53]:56421: 450 4.3.2 Service currently unavailable; from=<sender@theirdomain>, to=<recipient@ourdomain>, proto=ESMTP, helo=<mail-ee0-f53.google.com>

      2012-03-29T13:40:33+02:00 services/192.168.10.210 postfix/postscreen[1697]: [ID 197553 mail.info] NOQUEUE: reject: RCPT from [74.125.82.43]:35504: 450 4.3.2 Service currently unavailable; from=<sender@theirdomain>, to=<recipient@ourdomain>, proto=ESMTP, helo=<mail-wg0-f43.google.com>

      So, google.com got 450 from postscreen and repeated delivery from _other_ IP and then got another 450. It's possible the mail would not be delivered at all if google.com had sent it from different 60 thousands :-) IP addresses every time.

      The cure could be DNS whitelisting but we know it's not applicable in postscreen's permanent whitelist. We added then IP subnet 74.125.0.0/16 to permanent whitelist. But we know there are other ISPs who could send mail in a similar way.

      Does somebody have CIDR whitelist file of mail ISPs (a la postgrey whitelist clients) perhaps?

      Thanks,

      MU
    • Peter
      ... I ve only seen this issue from google. You can get a list of possible IPs for them by checking their SPF record, after adding all the networks from their
      Message 2 of 5 , Mar 30, 2012
        On 30/03/12 21:02, Maciej Uhlig wrote:
        > So, google.com got 450 from postscreen and repeated delivery from
        > _other_ IP and then got another 450. It's possible the mail would not be
        > delivered at all if google.com had sent it from different 60 thousands
        > :-) IP addresses every time.
        >
        > The cure could be DNS whitelisting but we know it's not applicable in
        > postscreen's permanent whitelist. We added then IP subnet 74.125.0.0/16
        > to permanent whitelist. But we know there are other ISPs who could send
        > mail in a similar way.

        I've only seen this issue from google. You can get a list of possible
        IPs for them by checking their SPF record, after adding all the networks
        from their SPF record I stopped having this issue.


        Peter
      • Wietse Venema
        ... The after 220 greeting tests re turned off by default. Don t turn on the after 220 greeting tests if you don t want to live with the consequences of
        Message 3 of 5 , Mar 30, 2012
          Maciej Uhlig:
          > We found the following in postfix log while expecting test mail delivery:
          >
          > 2012-03-29T13:32:41+02:00 services/192.168.10.210
          > postfix/postscreen[1697]: [ID 197553 mail.info] NOQUEUE: reject: RCPT
          > from [74.125.83.53]:56421: 450 4.3.2 Service currently unavailable;
          > from=<sender@theirdomain <mailto:uhlig@...>>,
          > to=<recipient@ourdomain <mailto:nikto@...>>,
          > proto=ESMTP, helo=<mail-ee0-f53.google.com>
          >
          > 2012-03-29T13:40:33+02:00 services/192.168.10.210
          > postfix/postscreen[1697]: [ID 197553 mail.info] NOQUEUE: reject: RCPT
          > from [74.125.82.43]:35504: 450 4.3.2 Service currently unavailable;
          > from=<<mailto:uhlig@...>sender@theirdomain
          > <mailto:uhlig@...>>,
          > to=<<mailto:nikto@...>recipient@ourdomain
          > <mailto:nikto@...>>, proto=ESMTP,
          > helo=<mail-wg0-f43.google.com>
          >
          > So, google.com got 450 from postscreen and repeated delivery from
          > _other_ IP and then got another 450. It's possible the mail would not be
          > delivered at all if google.com had sent it from different 60 thousands
          > :-) IP addresses every time.

          The "after 220 greeting" tests re turned off by default.

          Don't turn on the "after 220 greeting" tests if you don't
          want to live with the consequences of doing so.

          Wietse
        • Maciej Uhlig
          ... Actually we wanted to have greylisting active knowing the consequences, which is mail delay. However, _infinite_ mail delay by google.com showed up as a
          Message 4 of 5 , Mar 30, 2012
            Wietse Venema:

            > Don't turn on the "after 220 greeting" tests if you don't want to live
            > with the consequences of doing so.

            Actually we wanted to have "greylisting" active knowing the
            consequences, which is mail delay. However, _infinite_ mail delay by
            google.com showed up as a side effect...

            Thanks,

            MU
          • /dev/rob0
            ... It s possible. In practice it is a minor issue. As a site hosting a Linux community project, mine has lots of contact with gmail. Every month or so we
            Message 5 of 5 , Mar 30, 2012
              On Fri, Mar 30, 2012 at 10:02:28AM +0200, Maciej Uhlig wrote:
              > So, google.com got 450 from postscreen and repeated delivery from
              > _other_ IP and then got another 450. It's possible the mail would
              > not be delivered at all if google.com had sent it from different 60
              > thousands :-) IP addresses every time.

              It's possible. In practice it is a minor issue. As a site hosting a
              Linux community project, mine has lots of contact with gmail. Every
              month or so we might see a delay. At any given time I probably have
              almost all the gmail outbounds whitelisted.

              I also use the MX policy test, with two prioritized MX IP addresses
              listening on the same host. This does not help with gmail, which
              doesn't retry the secondary after being deferred on the primary.

              > The cure could be DNS whitelisting but we know it's not applicable
              > in postscreen's permanent whitelist. We added then IP subnet
              > 74.125.0.0/16 to permanent whitelist. But we know there are other
              > ISPs who could send mail in a similar way.

              My cure was to do what some say I do best: nothing! :)

              I am not aware of any permanent failures nor any delays beyond a
              minor inconvenience.

              > Does somebody have CIDR whitelist file of mail ISPs (a la postgrey
              > whitelist clients) perhaps?

              Postgrey does! :)
              --
              http://rob0.nodns4.us/ -- system administration and consulting
              Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
            Your message has been successfully submitted and would be delivered to recipients shortly.