See two comments marked thusly: *******

> ----- Original Message ----- 
> From: "Lisa Muir" <[EMAIL PROTECTED]>
> To: "Sam Varshavchik" <[EMAIL PROTECTED]>
> Cc: "courier-users" <[email protected]>
> Sent: Wednesday, January 16, 2008 10:00 PM
> Subject: Re: [courier-users] DNS lookup blacklist
>
>
>> On Jan 16, 2008 11:28 PM, Sam Varshavchik <[EMAIL PROTECTED]> wrote:
>>> Lisa Muir writes:
>>>
>>> > I've been adding dns blacklists through the courier webadmin with
>>> > great results. Wanted to add lashback to the list, and found this in
>>> > their info:
>>> >
>>> > if you wish to check whether 192.168.1.100 is listed in the UBL, you
>>> > would perform a DNS lookup on 100.1.168.192.ubl.unsubscore.com
>>> >
>>> > Is this how the web configured DNS blacklists work or do they simply
>>>
>>> They all work this way.
>>
>> Excellent!
>>
>>> > make a reverse DNS lookup on the IP address? I was hoping to migrate
>>> > the blacklist lookups to a localhost BIND and effectly use it as a
>>> > proxy for courier to make one single rdns lookup on, but if they all
>>> > operate like lashback, then thats not going to work with multiple
>>> > dnsbl's
>>>
>>> Why not? It'll work just fine. Of course, it will get slow. Once you get
>>> beyond 3-4 DNSBLs, the server will spend a noticeable amount of time 
>>> waiting
>>> for remote DNS queries to come back.
>>
>> 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*******
>>
>>> 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
>> (zero hits in 24 hours, woo hoo, haven't had this in years) which puts
>> the burden of false positives straight back on the sender and their
>> choice of ISP, and thats a major step forward. Next up I'll reduce my
>> load on the free lists. Then I'll look at zone transfers or how to
>> make an rsync work with with Bind.
*******also consider enabling SPF fully to add a few more spam rejections --
you need SPF entries for your domains on your name servers with -all in lieu
of ~all; also enable SPF checking in courier; the result is that 100% of the
spammers who try to send e-mail with your own e-mail address as the sending
address will be reject, and many more as well*******
>>
>> 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.
>>
>> Thanks guys,
>>
>> Lisa.
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> courier-users mailing list
>> [email protected]
>> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>>
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to