https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7060
Kevin A. McGrail <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |[email protected] 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 <[email protected]> --- 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.
