List Mail User wrote:
>
> These few rules can help a lot (potentially with some possible FPs
> though). And as always, train your BAYES with the ones that get through
> and enable the digest tests (i.e. DCC, Pyzor and Razor).
>
> uridnsbl URI_COMPLETEWHOIS
> combined-HIB.dnsiplists.completewhois.com. A
> body URI_COMPLETEWHOIS
> eval:check_uridnsbl('URI_COMPLETEWHOIS')
> describe URI_COMPLETEWHOIS URI in
> combined-HIB.dnsiplists.completewhois.com
> tflags URI_COMPLETEWHOIS net
> score URI_COMPLETEWHOIS 1.25
<snip>
>
> These rules help to catch brand new domains at the same IP as
> previous spam domains (i.e. they are IP based BLs).
Neat stuff Paul.. I'll have to try it out.
That said, technically, doesn't this really look up the IP address by fetching
the NS record, not the A record of the URI? (this would catch domains hosted at
the same nameserver, not domains hosted at the same server IP address)
Or has SA changed and it looks up both NS and A for uridnsbl?
I know previously there was a strong argument against looking up the A record,
as it provided an opportunity for spammers to poison email with extra URIs that
nobody would normally click on or lookup. These poison URIs could be used to
trigger DNS attacks, or simply generate slow responses to force a timeout.
NS records on the other hand are generally not handled by the spammer's own DNS
servers, but are returned by the TLD's servers.
ie: the NS record for evi-inc.com is stored on my authoritative DNS server, but
it's only there for completeness. Nobody normally queries it from there except
my own server. Most folks find out the NS list from the servers for .com (ie:
a.gtld-servers.net). This makes it impractical to perform poison URIs if SA is
only looking up NS records.
