-----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----- |
* 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. +49 (0)30-450 570-155 http://www.arschkrebs.de DRM is Theft |
-----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----- |
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 |
-----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----- |
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 > |
In reply to this post by Jack Raats
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. |
Free forum by Nabble | Edit this page |