New anti spam approach

[Jack Raats]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi everyone,

After reading http://blog.mailchannels.com/2008/02/spammers-are-less-patient-than.html I tried to implement this in my postfix configuration.

Question: Is the sleep 15 command sufficient to implement this or do I miss something?

main.cf

smtpd_recipient_restrictions =
        reject_non_fqdn_recipient,
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_unauth_destination,
        check_helo_access       hash:/postfix/tables/helo_checks,
        reject_non_fqdn_hostname,
        reject_invalid_hostname,
        check_sender_mx_access  cidr:/postfix/tables/bogus_mx,
        check_helo_access       pcre:/postfix/tables/tld_acl
        check_client_access     pcre:/postfix/tables/tld_acl
        check_sender_access     pcre:/postfix/tables/tld_acl
        check_recipient_access  hash:/postfix/tables/spamtrap,
        reject_rbl_client       zen.spamhaus.org,
        reject_rbl_client       bl.spamcop.net,
        sleep 15,
        check_policy_service    unix:private/spfpol,
        check_recipient_access  hash:/postfix/tables/uce_strong,
        check_policy_service    inet:127.0.0.1:10023,
        permit

ucestrong =     reject_unknown_client_hostname,
                reject_unknown_helo_hostname,
                reject_non_fqdn_helo_hostname,
                reject_invalid_helo_hostname

tables/helo_checks
my ip.number            REJECT You're not in my domain
my domain                REJECT You're not in my domain

tables/bogus_mx
0.0.0.0/8       REJECT Domain MX in broadcast network
10.0.0.0/8      REJECT Domain MX in RFC 1918 private network
127.0.0.0/8     REJECT Domain MX in loopback network
169.254.0.0/16  REJECT Domain MX in link local network
172.16.0.0/12   REJECT Domain MX in RFC 1918 private network
192.0.2.0/24    REJECT Domain MX in TEST-NET network
192.168.0.0/16  REJECT Domain MX in RFC 1918 private network
224.0.0.0/4     REJECT Domain MX in class D multicast network
240.0.0.0/5     REJECT Domain MX in class E reserved network
248.0.0.0/5     REJECT Domain MX in reserved network

tables/uce_strong
domain1            dunno
domain2            ucestrong

tables/spamtrap
spamtrap@mydomain    DISCARD

tables/tld_acl
/\.(com|org|net|info)$/                                 DUNNO
/\.(arpa|local|localdomain|localhost)$/         REJECT


Thanks for your time!
Jack Raats
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959

iD8DBQFIJsc9Ph5RwW/NzC4RAlrjAJ9C89KSx0NhT2qouidxxjniyG3KoACgg0Hg
1vR3rwapKfRE1yor8wuLLgM=
=X1md
-----END PGP SIGNATURE-----

[Ralf Hildebrandt]

* Jack Raats <[hidden email]>:
> Hi everyone,
>
> After reading http://blog.mailchannels.com/2008/02/spammers-are-less-patient-than.html I tried to implement this in my postfix configuration.
>
> Question: Is the sleep 15 command sufficient to implement this or do I miss something?

As far as I know this only works with smtpd_delay_reject = no
and in smtpd_client_restrictions.

--
Ralf Hildebrandt ([hidden email])          [hidden email]
Postfix - Einrichtung, Betrieb und Wartung       Tel. [phone]
http://www.arschkrebs.de
DRM is Theft

[Jack Raats]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


From: "Ralf Hildebrandt" <[hidden email]>
To: <[hidden email]>
Sent: Sunday, May 11, 2008 12:51 PM
Subject: Re: New anti spam approach


>* Jack Raats <[hidden email]>:

>> Hi everyone,
>>
>> After reading
>> http://blog.mailchannels.com/2008/02/spammers-are-less-patient-than.html
>> I tried to implement this in my postfix configuration.
>>
>> Question: Is the sleep 15 command sufficient to implement this or do I
>> miss something?
>
> As far as I know this only works with smtpd_delay_reject = no
> and in smtpd_client_restrictions.

Accoording to postconf.5.html, smtpd_client_restriction, sleep is a generic
restriction, which may be used in smtpd_recipient_restrictions.
I have to study the smtpd_delay_reject = no.
At this moment I donn't use this and mail is coming in, but with a 15 second
delay...
Wietse?

Jack

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959

iD8DBQFIJtMyPh5RwW/NzC4RAla6AJ9Thtbao5EvwalmoGu7fFmTfIOWaACgrIAY
QXmBkrbEfZALrZDB0Sy2YcM=
=fzOS
-----END PGP SIGNATURE-----

[/dev/rob0]

On Sun May 11 2008 06:06:25 Jack Raats wrote:
> From: "Ralf Hildebrandt" <[hidden email]>
> >> http://blog.mailchannels.com/2008/02/spammers-are-less-patient-tha
> >>n.html I tried to implement this in my postfix configuration.
> >>
> >> Question: Is the sleep 15 command sufficient to implement this or
> >> do I miss something?
> >
> > As far as I know this only works with smtpd_delay_reject = no
> > and in smtpd_client_restrictions.

The greet pause is what trips up the spambots and ratware:
        smtpd_delay_reject = no
        smtpd_client_restrictions = sleep 15, reject_unauth_pipelining
This happens before the smtpd_banner is given. I don't have any data
regarding effectiveness of this ploy, but I know many Sendmail
postmasters are very pleased with it.

> Accoording to postconf.5.html, smtpd_client_restriction, sleep is a
> generic restriction, which may be used in
> smtpd_recipient_restrictions.

It is, indeed. But it does nothing beneficial there.

> I have to study the smtpd_delay_reject = no.

It means that each restriction stage is evaluated at that point in the
SMTP dialogue:
1. smtpd_client_restrictions    : initial connection, before banner
2. smtpd_helo_restrictions      : HELO command given by client
3. smtpd_sender_restrictions    : MAIL FROM command
4. smtpd_recipient_restrictions : RCPT TO command

See SMTPD_ACCESS_README.html#timing for a discussion of what this
entails.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header

[Jack Raats]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

From: "/dev/rob0" <[hidden email]>

> The greet pause is what trips up the spambots and ratware:
> smtpd_delay_reject = no
> smtpd_client_restrictions = sleep 15, reject_unauth_pipelining
> This happens before the smtpd_banner is given. I don't have any data
> regarding effectiveness of this ploy, but I know many Sendmail
> postmasters are very pleased with it.

I thought that reject_unauth_pipelining only works in
smtpd_data_restrictions?
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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32) - GPGrelay v0.959

iD8DBQFIJtwfPh5RwW/NzC4RAt4zAJsEZq8vR+48QBi81cRwi1JDlXFNQgCePPh5
DOkJcyy1uMUvpmLydbDd4TQ=
=eEhp
-----END PGP SIGNATURE-----

[mouss-2]

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
>

[Victor Duchovni]

On Sun, May 11, 2008 at 01:44:15PM +0200, Jack Raats wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> From: "/dev/rob0" <[hidden email]>
>
> >The greet pause is what trips up the spambots and ratware:
> >smtpd_delay_reject = no
> >smtpd_client_restrictions = sleep 15, reject_unauth_pipelining
> >This happens before the smtpd_banner is given. I don't have any data
> >regarding effectiveness of this ploy, but I know many Sendmail
> >postmasters are very pleased with it.
>
> I thought that reject_unauth_pipelining only works in
> smtpd_data_restrictions?
> I added
>
> smtpd_delay_reject = no
> smtpd_client_restrictions =
>            sleep 15,
>            reject_unauth_pipelining,
>            permit
> to my main.cf.

This is a really bad idea.

    - Hurts you and legimate senders more than the spammers.

    - Has no whitelist, so applies persistently to good senders creating
    upstream queue congestion.

    - Delays email to your users.

    - Breaks some high volume legitimate senders who can't affort to wait
    that long.

Do NOT do this. If you must, as with greylisting, apply only to systems that
have not previously passed the test using a suitable policy service. Better
yet, just use some good RBLs and a decent content filter.

--
        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:[hidden email]?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.