Recently, Somebody Somewhere wrote these words > Hi Declan, Did you see this on BLFS Dev?
Nope, and thenks for forwarding it. I'm not on blfs-dev > >> > >>> may I suggest you add the ruleset 70_sare_spoof.cf to trusted > >>> rulesets on your spamassassin installation, as that will catch the > >>> forged ebay and forged paypal spam causing so much annoyance these > >>> days. Vipul's Razor also catches about 50% of them. It should > >>> also be possible to blacklist paypal and ebay adresses > >>> (*.paypal.com, *.ebay.*, *.ebay.*.*). > >> I use Mozilla as my spam catcher so I am not in a position to test > >> this out. Randy, what do you think? > > > > > > I already forwarded this to Gerard. He's away for a couple of days, > > but should be able to get around to this when he gets back. > > Alternatively, if someone can hand-hold me I'll update the > > spamassasin configuration myself, though said person will also have > > to deal with forwarded support requests if things go belly-up. > > grab it from http://www.rulesemporium.com/rules/ and drop it into > /etc/mail/spamassassin for all lists, but it might be better to create > a high scoring body test just for ebay and paypal mails in the > local.cf...actually better in it's own cf file (if something goes > wrong, just rename it without the .cf extension and restart SA). > Something to the effect of this: I always drop the rules in /usr/local/share/spamassassin (or /usr/share/s[pamassassin), as /etc/mail/spamassassin is for the config & bayes, IIRC. I have never bothered dropping the .cf but it sounds like you guys have done more reading on this than me > > body LOCAL_EBAY_DROP /\bebay\b/i score LOCAL_EBAY_DROP 10.0 > describe LOCAL_EBAY_DROP Case insensitive regex for 'ebay' > > body LOCAL_PAYPAL_DROP /\bpaypal\b/i score LOCAL_PAYPAL_DROP > 10.0 describe LOCAL_PAYPAL_DROP Case insensitve regex for > 'paypal' > > That said, hi-scoring on any one rule is generally considered a very > very very bad thing to do. For instance, the score for each mail in > this thread would have been increased by 10 points even though they > are legitimate mails, that is why it's a bad idea and you should let > SA build up the score using the multiple rules. I'm also very green > WRT to customizing spamassassin, so hopefully somebody who knows a lot > more than I can step in and comment on the above. What the 70_sare_spoof.cf does is this meta SARE_FORGED_EBAY (__FROM_EBAY && __URI_EBAY && !__RCVD_EBAY) describe SARE_FORGED_EBAY Message appears to be forged, (ebay.com) score SARE_FORGED_EBAY 104.0 These use these 3 regexes, and the __ in front of them assigns a zero score header __FROM_EBAY From =~ /\@(?:email)?ebay\.com/i uri __URI_EBAY /ebay\.com/i header __RCVD_EBAY Received =~ /(?:email)[EMAIL PROTECTED]/i It is a fact that any genuine email from ebay will have a Received header from ebay, and spam apparently doesn't have. So they can and do assign a massive score to it (overcoming any whitelisting that might be in place for ebay or paypal. This isn't a 'lucky guess' regex, this is more like forensics. You can blacklist addresses in /etc/mail/spamassassin/local.cf Also spamassassin has blacklist options. (man spamassassin) > > The default rule sets have worked well for me until recently. > BAYES_00 and AWL have had a major play in a lot of junk slipping > through. I'd like to drop AWL and bayes caches for my vmail user, but > I am unsure of the consequences. Wonder if there is a way to set a > limit on the amount of time data is cached. I see the same tests (AWL > and BAYES_00) droping to negative scores on some of the spam that is > getting through on belgarath. Anyway, hope it helps or give at least > an idea where to start looking. Sombody who knows more, please follow > up as it might be good to clear bayes and auto white lists. Declan, > please add to the above or clarify furthur if you can. I have found limited success with standard rulesets, but the sare rulesets added in (just file 0 or 1 - the safe ones) do help greatly Here's a part listing of my /usr/local/share/spamassassin [EMAIL PROTECTED] ~/spam]# ls *sare* 70_sare_adult.cf 70_sare_header1.cf 70_sare_spoof.cf 70_sare_bayes_poison_nxm.cf 70_sare_header_eng.cf 70_sare_unsub.cf 70_sare_evilnum0.cf 70_sare_html0.cf 70_sare_uri0.cf 70_sare_evilnum1.cf 70_sare_html1.cf 70_sare_uri1.cf 70_sare_genlsubj0.cf 70_sare_html_eng.cf 70_sare_uri_eng.cf 70_sare_genlsubj1.cf 70_sare_oem.cf 72_sare_bml_post25x.cf 70_sare_genlsubj_eng.cf 70_sare_random.cf 72_sare_redirect_post3.0.0.cf 70_sare_header0.cf 70_sare_specific.cf 99_sare_fraud_post25x.cf The evilnumbers and bigevilist are not worth the overhead for a mail server. There is a 'rulesdujour' script on rulesemporium.com and it may help. It's for a cron job to update the rulesets daily. It's really if you are relying on evilnumbers (Known spammer IPs) Further, do not forget the available adjustments and neuclear options available for bayes (man sa-learn) You can forget the learning with spamassassin --forget -- With best Regards, Declan Moriarty. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
