From: Clunk Werclick (clunk.werclickwibblywobblyteapot.co.uk)
Date: Sun Aug 02 2009 - 05:24:17 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Sun, 2009-08-02 at 11:56 +0200, Willy De la Court wrote:
> Hi all,
>
> Just a question about spam prevention and resource optimalisation.
>
> What is the best way to go. I have this as spam prevention at the moment.
>
> smtpd_helo_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_non_fqdn_hostname,
> reject_invalid_hostname,
> permit
>
> smtpd_sender_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain,
> permit
>
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_pipelining,
> reject_non_fqdn_recipient,
> reject_unknown_recipient_domain,
> reject_unauth_destination,
> reject_invalid_hostname,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client zen.spamhaus.org,
> reject_unlisted_recipient,
> check_policy_service inet:127.0.0.1:60000,
> permit
>
> This mean that there are a number of tests before the actual recipient
> address is tested, would it not be better to place the
> reject_unlisted_recipient very early in the chain? Or am I wrong here. In
> placing the reject_unlisted_recipient earlier in the chain would I not make
> it easier for dictionary attacks to succeed? The check_policy_server is the
> postgrey implementation of http://postgrey.schweikert.ch/
>
> I added the reject_unlisted_recipient before the postgrey policy test
> because I noticed unknown recipients being passed to the postgrey policy
> test.
>
> Any comments would be welcome.
Hello Willy,

It depends on how aggressive you wish to be. Looking at the last half an
hour in my logs, the statistics show my blocking going on. The big fishy
is 'No PTR' (in words of another no reverse DNS at all) then followed by
spoof attempts (bobexample.com to bobexample.com).

I block both of these types before passing to a big list of dnsbl's -
but they may not be entirely suitable in production and it depends upon
your BOFH mentality/level -v- your users complaining;

************************
      PRE DNSBL 321
........................
         NO PTR 201
       SPOOFING 120
 RELAY ATTEMPTS 0
  BLOCKED OTHER 0
    WHITELISTED 4
************************
  BLOCKED DNSBL 287
........................

smtpd_sender_restrictions =
        permit_mynetworks
        permit_sasl_authenticated
        reject_unauth_destination
        reject_unknown_reverse_client_hostname
        check_sender_access hash:/etc/postfix/nospoof
        reject_rbl_client no-more-funn.moensted.dk
        reject_rbl_client bl.spamcop.net
        reject_rbl_client dnsbl-1.uceprotect.net
        reject_rbl_client dnsbl-2.uceprotect.net
        reject_rbl_client dnsbl-3.uceprotect.net
        reject_rbl_client dnsbl.sorbs.net
        reject_rbl_client bl.spamcannibal.org
        reject_rbl_client spam.dnsbl.sorbs.net
        reject_rbl_client zen.spamhaus.org
        reject_rbl_client b.barracudacentral.org
        permit

This;
/etc/postfix/nospoof

is just a postmapped flat file of our domains that looks like this;

/etc/postfix/nospoof
...
example.com REJECT spoofing go away
example.net REJECT spoofing go away
example.org REJECT spoofing go away
...
Have much fun and remember some spam is nice. Especially in a baguette
with some 'daddies' sauce
--
-----------------------------------------------------------
C Werclick .Lot
Technical incompetent
Loyal Order Of The Teapot.

This e-mail and its attachments is intended only to be used as an e-mail
and an attachment. Any use of it for other purposes other than as an
e-mail and an attachment will not be covered by any warranty that may or
may not form part of this e-mail and attachment.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]