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

Re: rDNS checks cause delays

Expand Messages
  • Jay Chandler
    ... Interesting, this seems to have sorted out my issue. Is it possible that one of the larger botnets is hanging on to smtp connections longer than they
    Message 1 of 14 , Aug 31, 2007
      Wietse Venema wrote:
      > This seems to be a popular item this week.
      >
      > Start each restriction with reject_unlisted_recipient so you don't
      > waste time on mail you won't accept anyway.
      >
      > smtpd_whatever_restrictions = reject_unlisted_recipient ...
      >
      > Also, put your RBL and other expensive lookups after
      > reject_unauth_destination, so you don't waste time on domains you
      > won't accept anyway.
      >
      > On my server, "smtpd_timeout = 10" is not giving trouble. YMMV.
      >
      > Wietse
      >
      > Run more smtpd processes, or make each session shorter in time.
      Interesting, this seems to have sorted out my issue.

      Is it possible that one of the larger botnets is hanging on to smtp
      connections longer than they reasonably should? Out of the blue, both
      my mx boxes started doing this this week, and the rdns check was all
      that I've changed.
    • John Capo
      ... Started for me last night around 0000 UTC. The spamware ignores 5XX and stays connected till smtpd times out. Aug 31 15:16:55 mxout-01
      Message 2 of 14 , Aug 31, 2007
        Quoting Jay Chandler (chandler.lists@...):
        > Wietse Venema wrote:
        > >This seems to be a popular item this week.
        > >
        > >Start each restriction with reject_unlisted_recipient so you don't
        > >waste time on mail you won't accept anyway.
        > >
        > > smtpd_whatever_restrictions = reject_unlisted_recipient ...
        > >
        > >Also, put your RBL and other expensive lookups after
        > >reject_unauth_destination, so you don't waste time on domains you
        > >won't accept anyway.
        > >
        > >On my server, "smtpd_timeout = 10" is not giving trouble. YMMV.
        > >
        > > Wietse
        > >
        > >Run more smtpd processes, or make each session shorter in time.
        > Interesting, this seems to have sorted out my issue.
        >
        > Is it possible that one of the larger botnets is hanging on to smtp
        > connections longer than they reasonably should? Out of the blue, both
        > my mx boxes started doing this this week, and the rdns check was all
        > that I've changed.

        Started for me last night around 0000 UTC. The spamware ignores 5XX
        and stays connected till smtpd times out.

        Aug 31 15:16:55 mxout-01 postfix/smtpd[45735]: connect from unknown[84.228.208.170]
        Aug 31 15:16:56 mxout-01 postfix/smtpd[45735]: NOQUEUE: reject: RCPT from unknown[84.228.208.170]: 550 5.7.1 blah blah blah
        Aug 31 15:18:56 mxout-01 postfix/smtpd[45735]: timeout after RCPT from unknown[84.228.208.170]

        And sometimes they just do nothing.

        Aug 31 15:24:23 mxout-02 postfix/smtpd[11466]: connect from unknown[200.8.209.59]
        Aug 31 15:26:23 mxout-02 postfix/smtpd[11466]: timeout after CONNECT from unknown[200.8.209.59]

        Most if what I am seeing is comming from 189/8, 190/8 and 200/7.
      • Curt LeCaptain
        ... I had read in a previous post from Viktor that this wasn t RFC compliant, it s supposed to be something like 5 minutes - I m curious as to how
        Message 3 of 14 , Aug 31, 2007
          >On my server, "smtpd_timeout = 10" is not giving trouble. YMMV.
          >
          > Wietse

          I had read in a previous post from Viktor that this wasn't RFC compliant, it's supposed to be something like 5 minutes - I'm curious as to how smtpd_timeout does it's work - is this a timeout after each command, banners, those kinds of things. I'm sure you get attachments and all, during the DATA transaction, if the sending server is actually sending something out, the smtpd_timeout counter isn't running until no data/commands are happening? I'd love to implement this but didn't do so due to having read Viktor's previous post.

          Curt L.
        • Victor Duchovni
          ... The timeout measures idle time (no data in either direction). It is not at this time sensitive to the transaction context, so the same timeout applies
          Message 4 of 14 , Aug 31, 2007
            On Fri, Aug 31, 2007 at 03:19:42PM -0500, Curt LeCaptain wrote:

            > >On my server, "smtpd_timeout = 10" is not giving trouble. YMMV.
            > >
            > > Wietse
            >
            > I had read in a previous post from Viktor that this wasn't RFC
            > compliant, it's supposed to be something like 5 minutes - I'm curious
            > as to how smtpd_timeout does it's work - is this a timeout after each
            > command, banners, those kinds of things. I'm sure you get attachments
            > and all, during the DATA transaction, if the sending server is actually
            > sending something out, the smtpd_timeout counter isn't running until no
            > data/commands are happening? I'd love to implement this but didn't do
            > so due to having read Viktor's previous post.

            The timeout measures idle time (no data in either direction). It is not
            at this time sensitive to the transaction context, so the same timeout
            applies after connect, EHLO, [ STARTTLS, EHLO, AUTH ], MAIL, RCPT, DATA,
            DOT, RSET or NOOP.

            I have raised the idea of a separate lower timeout after DOT or RSET,
            so that clients can't cache connections too aggressively, but this has
            not at this time resulted in any new code from me or anyone else.

            The RFC limit should not be lowered without cause, but if you're under
            attack, by all means lower it with care. Clients generally don't pause
            mid-stream, though it is possible for a client to appear to pause when
            doing generic(5) rewriting of large (many recipient) To/Cc headers via
            LDAP or SQL. The limits should not be too aggressive, 10s is about as
            low as you can set it within the SMTP transaction without running into
            problems (try higher values first and use the highest that gives you
            acceptable process concurrency). Noel's choice of ~40s IIRC is more
            conservative.

            If there were an idle timer before MAIL or after DOT, that could perhaps
            be as low as 5s or so.

            --
            Viktor.

            Disclaimer: off-list followups get on-list replies or get ignored.
            Please do not ignore the "Reply-To" header.

            To unsubscribe from the postfix-users list, visit
            http://www.postfix.org/lists.html or click the link below:
            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

            If my response solves your problem, the best way to thank me is to not
            send an "it worked, thanks" follow-up. If you must respond, please put
            "It worked, thanks" in the "Subject" so I can delete these quickly.
          • Noel Jones
            ... ie. it s OK to violate RFCs to maintain the security and integrity of your system, BUT it s your responsibility to insure that legit clients expecting RFC
            Message 5 of 14 , Aug 31, 2007
              At 03:34 PM 8/31/2007, Victor Duchovni wrote:
              >On Fri, Aug 31, 2007 at 03:19:42PM -0500, Curt LeCaptain wrote:
              >
              > > >On my server, "smtpd_timeout = 10" is not giving trouble. YMMV.
              > > >
              > > > Wietse
              > >
              > > I had read in a previous post from Viktor that this wasn't RFC
              > > compliant, it's supposed to be something like 5 minutes - I'm curious
              > > as to how smtpd_timeout does it's work - is this a timeout after each
              > > command, banners, those kinds of things. I'm sure you get attachments
              > > and all, during the DATA transaction, if the sending server is actually
              > > sending something out, the smtpd_timeout counter isn't running until no
              > > data/commands are happening? I'd love to implement this but didn't do
              > > so due to having read Viktor's previous post.
              >
              >The timeout measures idle time (no data in either direction). It is not
              >at this time sensitive to the transaction context, so the same timeout
              >applies after connect, EHLO, [ STARTTLS, EHLO, AUTH ], MAIL, RCPT, DATA,
              >DOT, RSET or NOOP.
              >
              >I have raised the idea of a separate lower timeout after DOT or RSET,
              >so that clients can't cache connections too aggressively, but this has
              >not at this time resulted in any new code from me or anyone else.
              >
              >The RFC limit should not be lowered without cause, but if you're under
              >attack, by all means lower it with care. Clients generally don't pause
              >mid-stream, though it is possible for a client to appear to pause when
              >doing generic(5) rewriting of large (many recipient) To/Cc headers via
              >LDAP or SQL. The limits should not be too aggressive, 10s is about as
              >low as you can set it within the SMTP transaction without running into
              >problems (try higher values first and use the highest that gives you
              >acceptable process concurrency). Noel's choice of ~40s IIRC is more
              >conservative.
              >
              >If there were an idle timer before MAIL or after DOT, that could perhaps
              >be as low as 5s or so.
              >
              >--
              > Viktor.

              ie. it's OK to violate RFCs to maintain the security and integrity
              of your system, BUT it's your responsibility to insure that legit
              clients expecting RFC behavior can still communicate with you.

              A prime example is the often-suggested rule to reject clients outside
              $mynetworks using your own hostname/domain name as HELO. This is on
              the greatest hits all-spam, all-the-time station, yet it violates RFC
              rules saying you MUST NOT reject based on the HELO hostname received.

              I've used smtpd_timeout = 45s for years, and I don't know of any
              legit hosts ever blocked by that rule. (although I must admit I've
              quit closely following "timeout after..." errors since they are so
              common now from spambots. Which means if any legit hosts are caught,
              I'll never know as long as they are able to send on a subsequent
              try. I would probably notice if that happened frequently).

              --
              Noel Jones
            • Victor Duchovni
              ... I still have enough hosts and process limit (and other defenses) that 300s is not causing significant pain, but there is a definite rise in such timeouts.
              Message 6 of 14 , Aug 31, 2007
                On Fri, Aug 31, 2007 at 04:04:35PM -0500, Noel Jones wrote:

                > I've used smtpd_timeout = 45s for years, and I don't know of any
                > legit hosts ever blocked by that rule. (although I must admit I've
                > quit closely following "timeout after..." errors since they are so
                > common now from spambots. Which means if any legit hosts are caught,
                > I'll never know as long as they are able to send on a subsequent
                > try. I would probably notice if that happened frequently).

                I still have enough hosts and process limit (and other defenses) that 300s
                is not causing significant pain, but there is a definite rise in such
                timeouts. Today on one host 11243 timeouts in 16 hours, this translates
                to an average of 129 concurrent idle sessions. If I drop the timeout to
                45s, the idle session concurrency should drop by a similar factor closer
                to 20 concurrent idle sessions.

                11243 DATA
                7700 MAIL
                3601 RCPT
                1545 CONNECT
                363 END-OF-MESSAGE
                215 EHLO
                88 HELO
                39 RSET
                4 UNKNOWN
                4 NOOP

                Just 10 IP addresses accounted for over 25% of the time-outs:

                871 80.195.131.175
                651 88.236.119.63
                303 122.163.145.128
                237 122.163.139.16
                236 122.163.139.205
                222 148.240.49.251
                125 122.163.144.77
                115 89.138.218.48
                114 122.163.141.240
                112 88.243.224.74

                The recently posted suggestions for RBL reply templates can also help,
                the culrprits are without exception listed on PBL, CBL or both.

                175.131.195.80.zen.spamhaus.org. IN A 127.0.0.4
                175.131.195.80.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=80.195.131.175"

                63.119.236.88.zen.spamhaus.org. IN A 127.0.0.11
                63.119.236.88.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=88.236.119.63"

                128.145.163.122.zen.spamhaus.org. IN A 127.0.0.11
                128.145.163.122.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=122.163.145.128"

                16.139.163.122.zen.spamhaus.org. IN A 127.0.0.4
                16.139.163.122.zen.spamhaus.org. IN A 127.0.0.11
                16.139.163.122.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=122.163.139.16"

                205.139.163.122.zen.spamhaus.org. IN A 127.0.0.4
                205.139.163.122.zen.spamhaus.org. IN A 127.0.0.11
                205.139.163.122.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=122.163.139.205"

                251.49.240.148.zen.spamhaus.org. IN A 127.0.0.11
                251.49.240.148.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=148.240.49.251"

                77.144.163.122.zen.spamhaus.org. IN A 127.0.0.11
                77.144.163.122.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=122.163.144.77"

                48.218.138.89.zen.spamhaus.org. IN A 127.0.0.10
                48.218.138.89.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=89.138.218.48"

                240.141.163.122.zen.spamhaus.org. IN A 127.0.0.11
                240.141.163.122.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=122.163.141.240"

                74.224.243.88.zen.spamhaus.org. IN A 127.0.0.11
                74.224.243.88.zen.spamhaus.org. IN TXT "http://www.spamhaus.org/query/bl?ip=88.243.224.74"

                --
                Viktor.

                Disclaimer: off-list followups get on-list replies or get ignored.
                Please do not ignore the "Reply-To" header.

                To unsubscribe from the postfix-users list, visit
                http://www.postfix.org/lists.html or click the link below:
                <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                If my response solves your problem, the best way to thank me is to not
                send an "it worked, thanks" follow-up. If you must respond, please put
                "It worked, thanks" in the "Subject" so I can delete these quickly.
              Your message has been successfully submitted and would be delivered to recipients shortly.