On Jun 17, 2014, at 9:07 PM, Kevin A. McGrail <kmcgr...@pccc.com> wrote:
> On 6/17/2014 10:49 PM, Philip Prindeville wrote: >> I’ve contributed fixes to Apache itself since 1997 (though not with any >> regularity), but can’t remember if I’ve ever had to furnish a CLA or not. > > Of course. Small fixes don't meet the level of non-trivialness to merit a > CLA but having a CLA on file is a great first step to getting karma in the > meritocracy that is the ASF. If you had a CLA, your name SHOULD be on this > list: http://people.apache.org/committer-index.html#unlistedclas Faxed it in on Tuesday and just got an acknowledgment. > >> Sure, opening a bug is fine. > Thanks. I already did one (7054) to have PerMsgStatus.pm do lookups and cache answers so that plugins don’t have to. I’ll open one for this feature and refer back to #7054. >> 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. > > This is great. I would put ALL of this in the pm file so the perldoc includes > it. Okay, revising… One other change that I realized I needed: certain “legitimate” projects (OpenWRT, Fedora, etc) are hosted (at least in part) by some ISPs which have otherwise been entirely problematic for us. To this end, I decided to add exclusions on hostnames or addresses (hostnames being more useful in the majority of situations) such as: uri_block_exclude L_BLOCK_ISP fedoraproject.org www.antiphishing.org www.spamhaus.org so that a blocking of (for instance) “ServerBeach” wouldn’t also block email containing URL’s for the above hosts. -Philip >> 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. >> >> Hope that answers your questions. >> >>
