Leigh S. Jones, KR6X wrote:
Yeah, but when you've got 200 accounts getting spam from the same
source, you pay the overhead for the first lookup only and then aren't
pounding the remote servers. Gotta be kinder to them, its been a
surprising 100% success.
*******your caching nameserver on the courier server local host should
already prevent this*******
Think she is currently directly implementing the blacklists in courier and
not through a caching nameserver. Does courier cache its dnsrbl lookups?
The usual solution is to make arrangements with your DNSBL's operators
to
let your nameservers do zone transfers, rather than ad-hoc queries.
This
will effectively keep your DNS lookups local, and each check
essentially
translates to a rather fast database dip. You can't expect it to get
faster
than that.
Rsync has been mentioned a few times by the ones I've read. One step
at a time though. Right now I have a highly successful spam block
Some will do zone transfers, others operate rsync, its an incremental thing,
start with migrating to BIND, then migrate those that do zone transfers, and
take it from there with the rsnc efforts.
For those who are interested, the strategy was to use the blacklists
that were pre-loaded into the webadmin system, then look at messages
that got through, put the source ip address into
http://www.mxtoolbox.com/blacklists.aspx to find a dnsbl that would
have caught it, and tweak the setup from that.
Nice service, just be careful that you can see why they blacklisted an
address, the first two hits I put through that produced blacklists blocking
on geographical region "we do not accept mail from china" and "we do not
accept mail from Korea".
I'm sure blanket blocking of email is a highly effective spam prevention
strategy but the primary goal of an email system has to be to receive and
deliver email messages and blanket blocking based on geographical region
flies in the face of that goal IMHO.
-Enda.
2 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Fw: DNS lookup b...
