You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2014/06/23 18:58:31 UTC
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
Kevin A. McGrail <km...@pccc.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |kmcgrail@pccc.com
Resolution|--- |FIXED
Summary|Allow local criteria for |Allow local criteria for
|blocking <A HREF> URL's |blocking <A HREF> URL's
|based on the hosts ISP, |based on the hosts ISP,
|Country, or CIDR block |Country, or CIDR block -
| |URILocalBL.pm
--- Comment #1 from Kevin A. McGrail <km...@pccc.com> ---
I've added the first version of the URILocalBL.pm plugin to trunk. It's
disabled by default and due to the necessity of Geo::IP, probably will never be
suitable to be enabled by default.
svn commit -m 'Added URILocalBL.pm plugin to trunk for testing, updating
MANIFEST and v341.pre file as well as optional dependencies with
Net::CIDR::Lite and Geo::IP'
Sending MANIFEST
Adding lib/Mail/SpamAssassin/Plugin/URILocalBL.pm
Sending lib/Mail/SpamAssassin/Util/DependencyInfo.pm
Sending rules/v341.pre
Transmitting file data ....
Committed revision 1604881.
Also noting this from the mailing list: why this is good to implement, what
time of spam you use it to block, etc.
As to your last questions: for someone who doesn’t need the complexity of using
an DNSBL, doesn’t want the wide scope of using a DNSBL, want to have to
configure it, or perhaps just wants a significantly more precise tool to solve
a very limited problem, local blacklisting lets you do this.
As an example, we were recently hit by a volley of SPAM from a variety of mail
relays, but they all had something in common. All of them contained HTML with
URL’s pointing to websites hosted by “Solar VPS”, and in particular on the
subnet 65.181.64.0/18 (in some cases, the web hosts had additional A records on
the subnet 192.99.0.0/16).
It took a couple of hours to get URIDNSBL configured, scored appropriately, and
working… and verifying that the ill-behaved hosts had corresponding entries in
multi.uribl.com without prior understanding of the record encoding also took
some time (since the use of DNS RR’s is an overloading of their intended use,
it’s less than intuitive).
When it was all over, it occurred to me that a trivial configuration like:
uri_block_cidr L_BLOCK_CIDR 65.181.64.0/18 192.99.0.0/16
body L_BLOCK_CIDR eval:check_uri_local_bl("L_BLOCK_CIDR")
describe L_BLOCK_CIDR Block URI's pointing to bad CIDR's
score L_BLOCK_CIDR 5.20
would be a lot more of a pinpoint fix to my issue, rather than the overly
generalized approach of using multi.uribl.com. And I didn’t want to score
everyone that was in that DNSBL, just to particular subnets.
After that, it occurred to me that I had never seen a legitimate email with a
URL pointing to Vietnam or Nigeria in my life, and it would be nice to restrict
those as well. So the plugin later evolved to:
uri_block_cc L_BLOCK_CC cn vn ro bg ru ng eg
body L_BLOCK_CC eval:check_uri_local_bl("L_BLOCK_CC")
describe L_BLOCK_CC Block URI's pointing to countries with no CERT
or anti-SPAM laws
score L_BLOCK_CC 5.65
In the case of the 65.181.0.0/16 SPAM which provided this call to action, here
are some subject lines you might recognize:
News alert: you could apply for a CNA education program
Wireless Internet plans online
You've Been Accepted into the Who's Who
Don't overpay for a phone. Try a free* one today
Is your home missing something? How about custom blinds?
Could you study at a CNA education program?
cable service is a possibility
etc. All within a 6 hour spam.
Looking at some recent traffic on the SpamAssassin users mailing list, it
seemed that other people had had a similar idea at the same time to provide
surgical blacklisting locally.
At this point, I’m thinking of adding whitelisting support to the country, ISP,
and CIDR blacklists. For example, we’ve had issues with ServerBeach being
proactive about Spam or even acknowledging complaints in a timely fashion: that
said, we get legitimate traffic with URL’s pointing to a Fedora Project
resource hosted on one of their networks. So we couldn’t blacklist that entire
ISP without “punching a hole” for Fedora build reports.
The whitelisting would either take individual IP addresses and/or host names as
they appear in the URL’s.
--
You are receiving this mail because:
You are the assignee for the bug.