You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Axb <ax...@gmail.com> on 2012/03/21 11:17:51 UTC
remove MSGID_MULTIPLE_AT rule
the MSGID_MULTIPLE_AT hits mostly ham using newish MS MUAs and seems
like pointless bloat.
Hits every other message and give a recipient a fuzzy feeling when rcpt
see this hit so often
(sic: all my messages are spam because of MSGID_MULTIPLE_AT !!)
http://ruleqa.spamassassin.org/20120320-r1302798-n/MSGID_MULTIPLE_AT/detail
The few spam hits from the axb corpus don't warrant this to be kept.
Many moons ago it was a usefull spam trait, but that was way before
Microsoft started using it in their MUAs
Could we remove this rule?
Comments?
+1 for removal?
-1 for removal?
Axb
Re: remove MSGID_MULTIPLE_AT rule
Posted by Axb <ax...@gmail.com>.
On 03/21/2012 02:31 PM, John Hardin wrote:
> On Wed, 21 Mar 2012, Axb wrote:
>
>> the MSGID_MULTIPLE_AT hits mostly ham using newish MS MUAs and seems
>> like pointless bloat.
>> Hits every other message and give a recipient a fuzzy feeling when
>> rcpt see this hit so often
>> (sic: all my messages are spam because of MSGID_MULTIPLE_AT !!)
>>
>> http://ruleqa.spamassassin.org/20120320-r1302798-n/MSGID_MULTIPLE_AT/detail
>>
>>
>> The few spam hits from the axb corpus don't warrant this to be kept.
>>
>> Many moons ago it was a usefull spam trait, but that was way before
>> Microsoft started using it in their MUAs
>>
>> Could we remove this rule?
>>
>> Comments?
>>
>> +1 for removal?
>> -1 for removal?
>
> Part of me says "the corpus über alles" and +1 for removal.
>
> Another part of me says "it violates the standards" and -1 for removal.
>
> But most of me says "+1 for driving down to Redmond and beating the
> ignorance out of the MSFT mail dev group using bronzed copies of RFC5322".
>
> Seriously, I think we've agreed long since that SA is not a
> standards-compliance audit tool regardless of how much some of us wish
> it to be, so if the corpus says it's performing poorly then +1 for
> removal as a scored rule.
>
> We may want to convert it to a subrule. I'd have to perform a
> combination analysis to see whether it's useful with other rules.
>
> My final vote: +1 for converting it to a subrule.
My main aim is to get rid of rules which just bloat/take/time/cycles..
and a subrule is still a pointless rule getting parsed.
If ppl need it, they can add it themselves.
If a sandbox needs it, it will only be published if required
my +1 to kill and leave buried
Re: remove MSGID_MULTIPLE_AT rule
Posted by John Hardin <jh...@impsec.org>.
On Wed, 21 Mar 2012, Axb wrote:
> the MSGID_MULTIPLE_AT hits mostly ham using newish MS MUAs and seems like
> pointless bloat.
> Hits every other message and give a recipient a fuzzy feeling when rcpt see
> this hit so often
> (sic: all my messages are spam because of MSGID_MULTIPLE_AT !!)
>
> http://ruleqa.spamassassin.org/20120320-r1302798-n/MSGID_MULTIPLE_AT/detail
>
> The few spam hits from the axb corpus don't warrant this to be kept.
>
> Many moons ago it was a usefull spam trait, but that was way before Microsoft
> started using it in their MUAs
>
> Could we remove this rule?
>
> Comments?
>
> +1 for removal?
> -1 for removal?
Part of me says "the corpus über alles" and +1 for removal.
Another part of me says "it violates the standards" and -1 for removal.
But most of me says "+1 for driving down to Redmond and beating the
ignorance out of the MSFT mail dev group using bronzed copies of RFC5322".
Seriously, I think we've agreed long since that SA is not a
standards-compliance audit tool regardless of how much some of us wish it
to be, so if the corpus says it's performing poorly then +1 for removal as
a scored rule.
We may want to convert it to a subrule. I'd have to perform a combination
analysis to see whether it's useful with other rules.
My final vote: +1 for converting it to a subrule.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
North Korea: the only country in the world where people would risk
execution to flee to communist China. -- Ride Fast
-----------------------------------------------------------------------
468 days since the first successful private orbital launch (SpaceX)
Re: remove MSGID_MULTIPLE_AT rule
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 3/21/2012 6:17 AM, Axb wrote:
> the MSGID_MULTIPLE_AT hits mostly ham using newish MS MUAs and seems
> like pointless bloat.
> Hits every other message and give a recipient a fuzzy feeling when
> rcpt see this hit so often
> (sic: all my messages are spam because of MSGID_MULTIPLE_AT !!)
>
> http://ruleqa.spamassassin.org/20120320-r1302798-n/MSGID_MULTIPLE_AT/detail
>
>
> The few spam hits from the axb corpus don't warrant this to be kept.
>
> Many moons ago it was a usefull spam trait, but that was way before
> Microsoft started using it in their MUAs
>
> Could we remove this rule?
>
> Comments?
>
> +1 for removal?
> -1 for removal?
First, for the sake of debate, I think using any of the current QA in a
debate with such a low corpus is a bit unscientific.
Second, checking my corpus, I only have the following emails with
Message-Id headers:
grep -E ^Message-?id * | wc -l
Corporate: 166
Personal: 1933 (much larger corpus)
All inboxes on a server with 400+ users: 2929
This is a VERY small percentage of total emails.
Checking the above for those that hit the rule and we get:
grep -E ^Message-?id * | grep -E "<[^>]*\@[^>]*\@"
Corporate: 4 all HAM (4 from the same Verizon user)
Personal: 21 all HAM (17 from Verizon and 4 from non verizon with a lot
of overlapping users and all but 4 from August of last year.)
All Inboxes: Only 15 (14 from Verizon)
Overall, I'm wondering what is adding the Message-ID for you? I am not
sure it's an MUA. I think it's an MTA in the chain. I rarely see a
Message-ID header and use Sendmail.
However, the rule is scored as a test rule: score MSGID_MULTIPLE_AT
0.001 so this is an efficiency issue not a scoring/FP issue.
We have enough votes to kill it so I've moved it to a demoted sandbox.
svn commit rulesrc/sandbox/kmcgrail/20_demoted_tests.cf
rules/20_head_tests.cf rules/30_text_pt_br.cf rules/50_scores.cf -m
'Demoted MSGID_MULTIPLE_AT from default rules to sandbox'
Sending rules/20_head_tests.cf
Sending rules/30_text_pt_br.cf
Sending rules/50_scores.cf
Adding rulesrc/sandbox/kmcgrail/20_demoted_tests.cf
Transmitting file data ....
Committed revision 1303397.
regards,
KAM