[Bug 6787] New: missing com.zm TLD in RegistrarBoundaries
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6787 Bug #: 6787 Summary: missing com.zm TLD in RegistrarBoundaries Product: Spamassassin Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Libraries AssignedTo: dev@spamassassin.apache.org ReportedBy: axb.li...@gmail.com Classification: Unclassified missing com.zm TLD in RegistrarBoundaries (Zambia) -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
TVD_FROM_1 false positive
Hi
This rule has been mentioned here before by f...@rfc822.org back in 2009,
when it scored a mere 1.0. In the 3.3.1 update channel active.cf has:
##{ TVD_FROM_1
header TVD_FROM_1 From:addr =~
/[^\@0-9]{2}\d{3}\.(?:com|net|org|info|biz)$/i
##} TVD_FROM_1
score TVD_FROM_12.799 2.799 2.799 2.799
I've noticed it hitting the domain of a concerned user. Of the top of
my head, I can think of other reputable domains ending in at least 1 or
2 digits, and don't personally see 3 digits as an essentially spammy
characteristic (although many domains ending 360 or 365 are indeed
associated with spam or dirty lists).
In my humble opinion:
(a) the high and variable score may be a result of an insufficiently
diverse ham corpus for the rescore mass check. (I'd contribute myself
in a small way but am put off more by the fact that it's time-critical
and don't see any announcements than just the amount of work involved.)
(b) it might be better if rules like this, that presumably hit a large
amount of spam over a short period, were associated with other
characteristics of the same spam as a meta rule. They could be
formulated as subrules or held to a score of at most 0.1, but merely
allowing the scorer to choose between the meta rule and its components
could have a similar effect. This might not just reduce the adverse
effect of potential false positives but also, in the absence of a
description, clarify the intention of the rule or type of spam that it's
aimed at.
What's to be done?
--
All best wishes,
Cedric Knight
[Bug 6786] near zero score for TO_EQ_FM*
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6786 Kevin A. McGrail kmcgr...@pccc.com changed: What|Removed |Added CC||kmcgr...@pccc.com --- Comment #2 from Kevin A. McGrail kmcgr...@pccc.com 2012-04-04 12:09:34 UTC --- (In reply to comment #1) A new sa-update hasn't been generated since 2012-02-25, how did your scores change a few days ago? Those rules are ranked pretty terribly. Best rules are ranked 1, worst are ranked 0: MSECSSPAM% HAM% S/ORANK SCORE NAME WHO/AGE 0 0.5257 0.0050 0.9910.540.00 TO_EQ_FM_HTML_ONLY 0 0.3420 0.0017 0.9950.520.00 TO_EQ_FM_DIRECT_MX 0 0.2501 0.0011 0.9960.510.00 TO_EQ_FM_HTML_DIRECT - http://ruleqa.spamassassin.org/?daterev=20120403-r1308758-nrule=%2FTO_EQ_FMsrcpath=g=Change Looks like all the hams hitting those three rules are in llanga's corpus. It still has a nice S/O, though. I recommend a local scoring higher until we can get masscheck chugging along! -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: TVD_FROM_1 false positive
On 4/4/2012 6:14 AM, Cedric Knight wrote:
This rule has been mentioned here before by f...@rfc822.org back in 2009,
when it scored a mere 1.0. In the 3.3.1 update channel active.cf has:
##{ TVD_FROM_1
header TVD_FROM_1 From:addr =~
/[^\@0-9]{2}\d{3}\.(?:com|net|org|info|biz)$/i
##} TVD_FROM_1
score TVD_FROM_12.799 2.799 2.799 2.799
I've noticed it hitting the domain of a concerned user. Of the top of
my head, I can think of other reputable domains ending in at least 1 or
2 digits, and don't personally see 3 digits as an essentially spammy
characteristic (although many domains ending 360 or 365 are indeed
associated with spam or dirty lists).
In my humble opinion:
(a) the high and variable score may be a result of an insufficiently
diverse ham corpus for the rescore mass check. (I'd contribute myself
in a small way but am put off more by the fact that it's time-critical
and don't see any announcements than just the amount of work involved.)
(b) it might be better if rules like this, that presumably hit a large
amount of spam over a short period, were associated with other
characteristics of the same spam as a meta rule. They could be
formulated as subrules or held to a score of at most 0.1, but merely
allowing the scorer to choose between the meta rule and its components
could have a similar effect. This might not just reduce the adverse
effect of potential false positives but also, in the absence of a
description, clarify the intention of the rule or type of spam that it's
aimed at.
What's to be done?
At the moment, I would recommend a ticket in bugzilla. I'm always a fan
of meta tags as well but this does seem to be scored to high.
However, until we get masscheck involved with enough corpora to fire off
rules again, you'll have to score this locally.
Regards,
KAM
[Bug 6787] missing com.zm TLD in RegistrarBoundaries
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6787 AXB axb.li...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from AXB axb.li...@gmail.com 2012-04-04 15:41:25 UTC --- commited (Rev 1309465) Added .com.zm, edu.zm -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 6689] SVN Snapshots Appear to be very out of Date
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6689 Michael Scheidell scheid...@secnap.net changed: What|Removed |Added CC||scheid...@secnap.net --- Comment #13 from Michael Scheidell scheid...@secnap.net 2012-04-04 15:50:48 UTC --- I am (aka scheid...@freebsd.org), the official port maintainer for the FreeBSD spamassassin port. I am also on the development team, and have commit bit. I have had a lot of requests for a -devel branch in ports, for 3.4. I can pull it our of trunk/svn, make a tarball and put it in http://people.freebsd.org/~scheidell/Mail-SpamAssassin-3.4.0.tar.gz, but this is not considered 'best practices'. We like to see it come from an authoritative source. Can I get a snapshot/rc/tarball, either emailed to scheid...@freebsd.org, so I can put it into ~/ or, better yet, can you make a snapshot tarball and send me a link that will survive (until you change it)? Since I have commit bit, I can change sha256 sigs in ports tree, nightly if I have to. thanks, and keep up the good work! -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Rule updates are too old
SpamAssassin version 3.3.0 has not had a rule update since 2012-02-25. SpamAssassin version 3.3.1 has not had a rule update since 2012-02-25. SpamAssassin version 3.3.2 has not had a rule update since 2012-02-25.
