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

Re: performance problems

Expand Messages
  • Stan Hoeppner
    ... smtpd_client_connection_count_limit tends to only slow down bulk mailers and not normal non-bulk mailers, which is why I recommended it.
    Message 1 of 19 , Apr 2, 2012
    • 0 Attachment
      On 4/2/2012 1:51 AM, Jeremie CEINTREY wrote:
      > Thank you very much for your explanations.
      >
      > I'm going to test with smtpd_client_connection_count_limit = 1
      >
      > Three days ago I added smtpd_client_connection_rate_limit = 10, wich limit the number of connection by a client to 10 by time unit; a time unit equal to 60s by default.
      > I noticed that it works well and permit to slow down big mailers. As you write it, when a mailing list campain was in progress, I was able to see hundreds of mails arriving from a domain with tail -f /var/log/mail.log | grep cleanup
      >
      > tail -f /var/log/mail.log | grep 'postfix/cleanup.*@domain_of_big_mailer
      >
      > Yet, i'm going to test with smtpd_client_connection_count_limit = 1, wich looks like smtpd_client_connection_rate_limit and smtpd_client_message_(rate|count)_limit parameters.

      smtpd_client_connection_count_limit tends to only slow down bulk mailers
      and not 'normal' non-bulk mailers, which is why I recommended it.

      smtpd_client_connection_rate_limit and
      smtpd_client_message_(rate|count)_limit will delay delivery from
      'normal' mailers on occasion, possibly very frequently. This is a
      negative side effect most would want to avoid. This type of restriction
      should be configured only on a domain or IP subnet basis so you only
      affect the bulk mailers. Postfix doesn't have an inbuilt way to do so.
      These settings are global. Thus, if you want to use this type of rate
      delay you would want to use an add on policy daemon. The policy daemon
      method has a downside: it requires an smtpd process for each connection
      to be delayed, eating extra system resources.

      Setting smtpd_client_connection_count_limit also sets
      postscreen_client_connection_count_limit if you're using postfix 2.8 and
      postscreen. Thus the limit is enforced before connections are handed to
      smtpd processes, so you don't needlessly eat up additional smtpds.

      Thus, it's much simpler and more effective to use
      smtpd_client_connection_count_limit to achieve your goal, without
      multiple unwanted side effects.

      --
      Stan
    • Wietse Venema
      ... Note that postscreen either blocks a client or hands it off to a Postfix SMTP server process. The connection count limit in postscreen applies only to the
      Message 2 of 19 , Apr 3, 2012
      • 0 Attachment
        Stan Hoeppner:
        > Setting smtpd_client_connection_count_limit also sets
        > postscreen_client_connection_count_limit if you're using postfix 2.8 and
        > postscreen. Thus the limit is enforced before connections are handed to
        > smtpd processes, so you don't needlessly eat up additional smtpds.

        Note that postscreen either blocks a client or hands it off to a
        Postfix SMTP server process. The connection count limit in postscreen
        applies only to the SMTP clients that are (not yet) handed off to
        an SMTP server process. Once the hand-off is done, postscreen does
        not know when an SMTP session ends, so the session no longer counts
        towards the postscreen connection count limit. The code was tricky
        enough that I did not want to introduce a postscreen-to-anvil
        dependency.

        The postscreen connection count limit is still effective for "hit
        and run" spambots that make a burst of connections at approximately
        the same time. Such clients will exceed the connection limit while
        waiting for the pregreet timer to expire, or for DNS[BW]L lookups
        to complete.

        Wietse
      • Stan Hoeppner
        ... Ahh, thanks for the clarification Wietse. The smtpd_client_connection_count_limit is still enforced against post hand off client connections though,
        Message 3 of 19 , Apr 3, 2012
        • 0 Attachment
          On 4/3/2012 10:27 AM, Wietse Venema wrote:
          > Stan Hoeppner:
          >> Setting smtpd_client_connection_count_limit also sets
          >> postscreen_client_connection_count_limit if you're using postfix 2.8 and
          >> postscreen. Thus the limit is enforced before connections are handed to
          >> smtpd processes, so you don't needlessly eat up additional smtpds.
          >
          > Note that postscreen either blocks a client or hands it off to a
          > Postfix SMTP server process. The connection count limit in postscreen
          > applies only to the SMTP clients that are (not yet) handed off to
          > an SMTP server process. Once the hand-off is done, postscreen does
          > not know when an SMTP session ends, so the session no longer counts
          > towards the postscreen connection count limit. The code was tricky
          > enough that I did not want to introduce a postscreen-to-anvil
          > dependency.

          Ahh, thanks for the clarification Wietse. The
          smtpd_client_connection_count_limit is still enforced against post hand
          off client connections though, correct?

          > The postscreen connection count limit is still effective for "hit
          > and run" spambots that make a burst of connections at approximately
          > the same time. Such clients will exceed the connection limit while
          > waiting for the pregreet timer to expire, or for DNS[BW]L lookups
          > to complete.

          So the postscreen connection limit is good for slowing bots, no surprise
          since bots are the postscreen target, but the smtpd connection limit is
          still appropriate/needed for slowing legit bulk mailer clients, assuming
          one chooses to use it vs the other anvil based restrictions.

          --
          Stan
        • Wietse Venema
          ... Correct. postscreen by design has no effect on known, non-bot, clients. Wietse
          Message 4 of 19 , Apr 3, 2012
          • 0 Attachment
            Stan Hoeppner:
            > So the postscreen connection limit is good for slowing bots, no surprise
            > since bots are the postscreen target, but the smtpd connection limit is
            > still appropriate/needed for slowing legit bulk mailer clients, assuming
            > one chooses to use it vs the other anvil based restrictions.

            Correct. postscreen by design has no effect on known, non-bot, clients.

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