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 (b...@example.com to b...@example.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.