> -----Original Message-----
> From: ram [mailto:[EMAIL PROTECTED]
> Sent: Saturday, January 19, 2008 11:47 AM
>
> I had read about the whois plugin into SA. But I cant seem to find it
> now Can someone tell me how do I install this
You can get a copy of the uriwhois plugin at:
http://www.tomassoni.biz/download/URIWhois-0.03.tar.bz2
But please read next.
> I beleive that could be a very effective idea to score on domain names
> who have bad registrars
The uriwhois plugin doesn't do that. The thing closest to this, that it
allows to, is to put scores on nameserver addresses used to propagate the
domain entries of spammed uris. In example, if you find that a set of
well-known spams are advertizing uris whose domains are announced always
through 1.1.1.1 and 1.1.1.2 nameservers, then you can put a SA rule to let
all the uris whose domain is announced trough these NSes earn scores.
uriwhois also tests other things as well. In example, a uri gets a score
depending on its domain's registration age. Also, it get scored if the NSes
defined in the whois record differ partially (PARTNSMIS) or fully
(FULLNSMIS) from the ones defined in the DNS zone.
A further test is the RFC1035IGN one, which basically would check compliance
to RFC1035 of the DNS SOA record of the domain. It checks, in example, if
the primary NS defined in the SOA record is among the NSes defined through
NS records. If it isn't, the rule triggers. I found that most sites hosted
by the Akamai's infrastructure do fire this rule, since Akamai puts a master
DNS server in the SOA, which is only used as a replication master for the
other NSes. It is not used as a public DNS server. I believe this behavior
is not RFC-1035 compliant but nevertheless, for the purposes of the uriwhois
plugin, it simply leads to FPs...
Now I would change the RFC1035IGN test to match those domains whose NSes
don't reply to DNS SOA requests, which I see is the "reply" from spammers to
the previous behavior of this test. But this is not currently implemented.
> Every hour hundreds of domains get registered purely for the purpose of
> spamming. That is what I assume because I see so many new one liner
> spams with just a link to a site, and soon the site gets listed in
> URIBL* If I could just block these spammers based on their registrars
> then SA could turn very effective. I could even use this information at
> my MTA and reject mails from spamming domains
Again, no registrar check, sorry. You could eventually use the: "uri_whois
nsname" or the "uri_whois nsaddr" tests to attempt catch these.
> BTW is it allowed to do automated whois queries. I initially though
> this
> was not allowed
Since you're issuing queries to registrar-based whois servers, the policies
may differ.
In my own case, I see that the traffic of my MX servers is so low that no
registrar banned my queries...
However, most gTLD registries don't run a whois server at all...
Please note that the uriwhois plugin is really alpha-code and there are a
number of well-known issues.
One of them is really tough and can occasionally lead your spamd- or
Amavisd-based SA to freeze. It is related to a BDB lock being not released
when amavisd kills a SA processor due to a processing timeout. I see this
happens only when the FuzzyOCR plugin is installed too. When FuzzyOCR takes
too much time to complete its job, amavisd kills the SA process. Somehow,
the kill happens while URIWhois is helding a BDB lock, thereby the lock is
not released. Simply restarting amavisd doesn't help either, since this kind
of lock is shared among processes and is thereby "written" in files. One can
overcame this problem by stopping amavisd, then removing all the __db.???
files in the uriwhois' database directory, finally restarting amavisd. But
this is a hand-made task...
Apart from fixing this problem, there are many other suggestions around to
improve this plugin, mostly by people who are not interested in the plugin
itself, but as a test-case for the asynch pump in SA (thank you, Mark). This
plugin, infact, needs SA 3.2.3 or above since it is completely asynchronous
in its operations.
I'm very busy around something else right now, so I can't devote the time I
would to the URIWhois plugin. This is why the URIWhois plugin didn't
recently improve much...
If you want to give a test drive to it, enjoy.
Giampaolo
> Thanks
> Ram
