Re: Postscreen DNSBL Sites
- On Tue, Apr 23, 2013 at 12:41 PM, /dev/rob0 <rob0@...> wrote:With those restrictions, you could just as well raise thecorresponding postscreen_dnsbl_sites scores to 3 for each. ISTM that
you're missing the point of scoring.
Yes, as I mentioned, Zen and (for most domains) BRBL listings are
good enough for outright rejection, but I would not do that for
Spamcop nor PSBL. Both of those are driven by automated processes
which could result in "false positives".Thanks - I see that now. My smtpd_recipient_restrictions now include these as the final config options before "permit":reject_rbl_client b.barracudacentral.org,reject_rbl_client zen.spamhaus.org,reject_rhsbl_client dbl.spamhaus.org,reject_rhsbl_sender dbl.spamhaus.org,reject_rhsbl_helo dbl.spamhaus.org,And based on your excellent article on your site, I've updated my Postscreen settings to:# POSTSCREEN OPTIONS v20130423postscreen_access_list = permit_mynetworks,cidr:/etc/postfix/postscreen_access.cidr,hash:/etc/postfix/postscreen_whitelistpostscreen_blacklist_action = droppostscreen_dnsbl_action = enforcepostscreen_greet_action = enforcepostscreen_dnsbl_threshold = 3postscreen_dnsbl_sites =swl.spamhaus.org*-4,list.dnswl.org=127.[0..255].[0..255].0*-2list.dnswl.org=127.[0..255].[0..255].1*-3list.dnswl.org=127.[0..255].[0..255].[2..255]*-4I've got a few "older" (1994 - 1996) domains running on this server, which some email addresses that I'm sure are in some of those "1MM email addresses!" CD-ROMs from the 90s. So even though this is a "personal" server, there's plenty of spammer action trying to get through. Doing a tail -f on the maillog and watching Postscreen + the smtpd restrictions do their work is always a satisfying feeling!Thanks again, rob0, for your excellent examples and willingness to educate. After monitoring these tweaks on my personal server for a bit, I'm going to deploy these to our production mail servers.SteveJ
- On 5/14/2013 11:45 AM, Steve Jenkins wrote:
> On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <rob0@...> wrote:"permits" always come before "rejects". Thus whitelist type entries
>> On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote:
>>> smtpd_recipient_restrictions =
>>> warn_if_reject reject_non_fqdn_helo_hostname,
>>> warn_if_reject reject_unknown_helo_hostname,
>>> check_helo_access hash:/etc/postfix/helo_access,
>>> check_sender_access hash:/etc/postfix/sender_access,
>>> reject_rbl_client zen.spamhaus.org,
>>> reject_rhsbl_client dbl.spamhaus.org,
>>> reject_rhsbl_sender dbl.spamhaus.org,
>>> reject_rhsbl_helo dbl.spamhaus.org,
>>> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
>> The last two lines are no-op. If you have anything you want to be
>> subjected to the list.dnswl.org whitelist, put it after the
>> permit_dnswl_client. If not, there is no point in querying it.
> Excellent point. If the next step is going to "permit" anyway, then no use
> in the extra query. I've moved the dnswl.org line up so that it's just
> above the three "local" check_* lines.
should always be at the top of the restrictions list. As you are using
(client|helo|sender|recipient) sections any whitelisting in
smtpd_recipient_restrictions should typically be at the very top.
This shows you are explicitly permitting anything/everything listed in
the dnswl. Are you sure that is what you want? I use...
which does not explicitly permit email marketing providers nor any IP
with trustworthiness score of 1. A score of 1 is equivalent to a
SpamAssassin score of -1, which does not merit a direct shot to the
queue. That would typically require an SA score of -5. I want these
clients to go through all of my other restrictions before allowing their
payload into my queue.
Also worth noting, there are currently only 14 categories (3rd octet of
a reply), so specifying 255 is not necessary, and possibly problematic.
Hypothetically, if dnswl decided one day to create categories 16,
political campaigns, and 17, religious newsletters, you are currently
setup to automatically permit such clients.
Remember, the sole purpose of whitelisting is to bypass all of your
other spam checks and get the mail into your queue unmolested. IMO, not
every IP listed by dnswl is deserving of this honor, not even close to
all of them.
See section "Return codes" at: http://www.dnswl.org/tech