Re: New anti spam approach /dev/rob0

From: mouss (no email)
Date: Sun May 11 2008 - 08:47:37 EDT

  • Next message: Sascha Hüdepohl: "Re: queue lifetime"

    Jack Raats wrote:
    >
    > I thought that reject_unauth_pipelining only works in
    > smtpd_data_restrictions?

    - sleep by itself works at any stage.
    - reject_unauth_destination works with "synchronous" commands (commands
    for which the client must read the server response before issuing
    another command). RCPT TO is asynchronous (client can send multiple RCPT
    TO before reading the server responses).

    In the default and recommended setup (smtpd_delay_reject=yes), client,
    helo, sender and recipient restrictions are executed at RCPT TO stage.
    for this reason:
    - reject_unauth_peipelining is useless in this case.
    - if you use multiple sleep commands in client, helo, sender and
    recipient, they will add up, and may possibly lead to client timeout. so
    be careful here.

    If you use smtpd_delay_reject=no (not recommended unless you know what
    you are doing), then reject_unauth_pipelining can be used to reject
    "quick talkers" (this is the "greetpause" technique Rob is talking about).

    The problem with sleep is that it blocks an smtpd process. so if you
    have 100 smtpd processes and you get 100 connections that you sleep on
    for 15 seconds, then your postfix is losing 15 seconds (and since this
    is repeated for future connections, your smtpd processes will be
    spending a lot of time sleeping). This may be considered as a self DoS.

    if you really want this technique, then do sleep selectively (only for
    "suspicious" clients). but even then, your system is still more
    vulnerable to DoS than a standard setup.

    Something like OpenBSD spamd is probably a better way to implement this
    technique.

    > I added
    >
    > smtpd_delay_reject = no
    > smtpd_client_restrictions =
    > sleep 15,
    > reject_unauth_pipelining,
    > permit
    > to my main.cf.
    >
    > > See SMTPD_ACCESS_README.html#timing for a discussion of what this
    > > entails.
    >
    > I'm going to read that in the garden where the sun is shining :-)
    > Thanks
    >
    > Jack
    >


  • Next message: Sascha Hüdepohl: "Re: queue lifetime"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD