On 1/4/2012 10:54 PM, /dev/rob0 wrote:
> You could consolidate all of your restrictions into
> smtpd_recipient_restrictions. Unless you need complex whitelisting,
> it's usually easier that way, to only maintain one set of
> restrictions.
I recommend this as well. For me it's much easier to work with and
debug. I find it actually works better for complex whitelisting.
> Zen has superceded sbl-xbl.spamhaus.org, which both below and above,
> you say you are using.
It appears none of your current dnsbls target snowshoe spam. I'd
recommend adding Spamhaus' DBL to your config:
smtpd_recipient_restrictions =
...
reject_rhsbl_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.org
reject_rhsbl_helo dbl.spamhaus.org
...
> I could suggest signing up for the Barracuda BRBL and using Spam-
> eating Monkey, and could nitpick some of the postconf, but overall
> it's not that bad, you have sane and strong antispam controls in
> place. Maybe share logs and samples of the spam you got?
BRBL seems to be pretty effective these days so I 2nd that rec. A few
log snippets of the spam connections are always helpful as different
types of spam sources requires different countermeasures.
> One WAG I came up with: are you using a DNS forwarder which is
> probably blocked by Spamhaus? Try testing, from the Postfix host:
> $ dig 2.0.0.127.zen.spamhaus.org. any
> This should return their test records. Compare with NXDOMAIN here:
> $ dig 2.0.0.127.zen.spamhaus.org. any @8.8.4.4
This is one of many reasons it's usually best to run your own caching
resolver on a single MX mail host, such as pdns recursor or unbound.
Having your own resolver makes troubleshooting dns related issues much
easier, and avoids problems such as Rob mentions here. On a single MX
host the resolver eats miniscule resources. Tons of upside to running
one, zero downside.
http://doc.powerdns.com/built-in-recursor.html
http://unbound.net/
I'm not an OSX or *BSD user, but I can say that one or both of these are
provided as binary packages in most, if not all, Linux distributions.
You could use bind as well but these are typically easier to work with.
> (Stan, UUOG, that can be simply "postconf mail_version" :) )
Heh, thx Rob. Already pointed out to me off list. 99/100 times my use
of postconf is with -q option to test new pcres or other tables. I
rarely use postconf for anything else, as I simply haven't needed to,
and it shows. :)
--
Stan
