Chris Turan wrote: > Thanks to all for the suggestions so far. I've enabled RBL looks on my > MX gateways using the the tips so far. I have to report an overwhelming > success. Nearly all of my spam is blocked in the SMTP transaction. Very > few spams make it past smtp and spamassassin cleans up the rest. > > I'd like to ask for a few more tips. Here's my config: > > smtpd_helo_restrictions = > permit_mynetworks, > reject_invalid_helo_hostname, > reject_non_fqdn_helo_hostname, > permit > smtpd_client_restrictions = > permit_mynetworks, > reject_non_fqdn_hostname,
This is redundant and deprecated, providing the same functionality as reject_non_fqdn_helo_hostname. > permit > smtpd_sender_restrictions = > permit_mynetworks, > reject_non_fqdn_sender, > reject_unknown_sender_domain, > permit > smtpd_recipient_restrictions = > permit_mynetworks, > reject_unauth_destination, > reject_unlisted_recipient, > reject_non_fqdn_recipient, > reject_rbl_client zen.spamhaus.org, > permit > smtpd_data_restrictions = > permit_mynetworks, > reject_unauth_pipelining, > permit > > Here are the questions I have: One thing you did not ask about is the trailing 'permit' in your set of restrictions; you can safely remove it. > 1) I have permit_mynetworks defined in each of the restrictions. I'm > not entirely sure how these are parsed so I put them in all. Should I > have it in all of them or just pick one. Setting it only in smtpd_client_restrictions should be fine. But for clarity (and aesthetics) you may want to collapse several of these smtpd_mumble_restrictions under smtpd_recipient_restrictions. For example: smtpd_recipient_restrictions = reject_unlisted_sender reject_non_fqdn_sender reject_non_fqdn_recipient reject_unlisted_recipient permit_mynetworks reject_unauth_destination reject_unknown_sender_domain reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_rbl_client zen.spamhaus.org smtpd_data_restrictions = reject_unauth_pipelining The latter should not be listed outside data_restrictions because, as per the postconf(5) manual: reject_unauth_pipelining is not useful outside smtpd_data_restrictions when 1) the client uses ESMTP (EHLO instead of HELO) and 2) with "smtpd_delay_reject = yes" (the default). The use of reject_unauth_pipelining in the other restriction contexts is therefore not recommended. > 2) I stuck a reject_unlisted_recipient in my recipient restrictions to > cut down on unneeded RBL lookups on non-existant addresses. Any other > recommendations to keep from going out to the RBL servers excessively? You could reject dynamic-looking hostnames with a PCRE, use HELO checks to block clients that purport to be you (or localhost), or maintain a database of IP addresses, hostnames and/or networks that appear to be frequent spammers. Then check_client_access lookups can be used to REJECT connections from those locations. > 3) I'd like to turn off rbl lookups on a few specific recipient > addresses. Specifically, I'd like to allow e-mail to postmaster@ and to > abuse@ regardless of who sends it. Any suggestions on a good way to do > this? I'm thinking of using check_recipient_access. Yes, place the reference to check_recipient_access above the reject_rbl_client directive and OK those special recipients. > 4) I'm using both Pyzor and Razor in my spamassassin config. Are there > any other recommended RBL I can consider for use either in postfix or > spamassassin? Obviously a matter of preference; maybe you can try a few, preceding the checks with "warn_if_reject", and monitor your logs for false positives. Some people have reported success with the Barracuda RBL. -- Sahil Tandon <sa...@tandon.net>
