You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by ji...@jidanni.org on 2008/10/14 22:57:09 UTC
overly harsh against Message only has text/html MIME parts
Gentlemen, it seems spamassassin used full military justice here:
0.0 HTML_MESSAGE BODY: HTML included in message
2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
well of course, because
2.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
OK, then
1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
I dunno, maybe they thought they already said I'm text/html.
0.0 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
Yes.
Gee, all the message did bad was
|Content-Type: multipart/alternative;
| boundary="----=_Part_742221_601951471.1223963124030"
|X-Mailer: HiNet WebMail
|
|------=_Part_742221_601951471.1223963124030
|Content-Type: text/html;charset=utf-8
|Content-Transfer-Encoding: quoted-printable
|
|<DIV>...
|------=_Part_742221_601951471.1223963124030--
Re: overly harsh against Message only has text/html MIME parts
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
On 15.10.08 04:57, jidanni@jidanni.org wrote:
> Gentlemen, it seems spamassassin used full military justice here:
>
> 0.0 HTML_MESSAGE BODY: HTML included in message
> 2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
> well of course, because
> 2.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
> OK, then
> 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
> I dunno, maybe they thought they already said I'm text/html.
> 0.0 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
> Yes.
>
> Gee, all the message did bad was
>
> |Content-Type: multipart/alternative;
> | boundary="----=_Part_742221_601951471.1223963124030"
> |X-Mailer: HiNet WebMail
> |
> |------=_Part_742221_601951471.1223963124030
> |Content-Type: text/html;charset=utf-8
> |Content-Transfer-Encoding: quoted-printable
> |
> |<DIV>...
> |------=_Part_742221_601951471.1223963124030--
Wouldn't it be better to ask HiNet to fix their WebMail?
Simple adding of HTML tag would drop the score below 5 ...
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Atheism is a non-prophet organization.
Re: overly harsh against Message only has text/html MIME parts
Posted by Greg Troxel <gd...@ir.bbn.com>.
Matt Kettler <mk...@verizon.net> writes:
> Greg Troxel wrote:
>> I see your point (the mail is malformed), but
>>
>> mail is multipart/alternative but only has text/html
>>
>> differs from
>>
>> mail is multipart/alternative and text/plain and text/html don't match
>>
>> are different conditions, and it might be useful to have different rules
>> that could have different scores.
>>
> Well, they're different, but are they different enough to be worth
> separate rules in a spam filtering context.
>
> i.e.: would the scores generated be significantly different, or are both
> rules roughly the same strength of spam indicator, and end up with
> more-or-less the same score.
>
> I suppose it could be tested, but this isn't a terribly common false
> positive in the real world. If it were pervasive, I'd be jumping at
> getting it fixed, but I've not seen it FP very often. The set3 S/O for
> this rule was 0.969, which isn't perfect but it's really quite solid.
OK, I see your point - I realize there is finite time to write rules,
and hadn't thought about the notion of directing that energy to rules
with higher FP rates. I had been drinking the SA Kool-Aid a bit too
much about lots of little rules and letting the score-assignment process
sort them out...
> In general it strikes me as a problem with email generated by some
> homebrew tool that isn't working properly. If it was generated by a
> common tool, we'd be seeing a lot of these, but a 3.1% false positive
> rate for the whole rule (not just this case) is pretty low.
>
> I know it's a bit harsh, but I'm not terribly inclined to jump to change
> SA to address rare-case false positives resulting from broken tools that
> aren't in mainstream use and don't have a significant impact on SA's
> global false positive rate.
No worries, That's totally fair. My splitting suggestion was somewhat
driven by curiousity - I have no idea which direction the scores of the
split rules would move.
> Unless someone knows of a mainstream FP case here, I'd be inclined to
> suggest either fixing the generator (best option, as some mail clients
> may barf on that output anyway), or locally zero the rule if you're the
> 1 in a million people who gets badly malformed email on a regular basis.
I'm not the one with the problem - I was just commenting that I thought
the MPART_ALT_DIFF should not have fired on the message in question
because the description says
BODY: HTML and text parts are different
rather than
BODY: HTML and text parts are different or text part is missing
It's certainly reasonable to consider a missing text part in
multipart/alternative as non-matching.
Re: overly harsh against Message only has text/html MIME parts
Posted by Matt Kettler <mk...@verizon.net>.
Greg Troxel wrote:
> Theo Van Dinter <fe...@apache.org> writes:
>
>
>> On Tue, Oct 14, 2008 at 06:55:27PM -0400, Greg Troxel wrote:
>>
>>>> 2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
>>>> well of course, because
>>>>
>>> This rule seems like it should not have fired.
>>>
>> Yes, it should have. If a multipart/alternate mail only has a text/html part,
>> it should be a text/html mail.
>>
>
> I see your point (the mail is malformed), but
>
> mail is multipart/alternative but only has text/html
>
> differs from
>
> mail is multipart/alternative and text/plain and text/html don't match
>
> are different conditions, and it might be useful to have different rules
> that could have different scores.
>
Well, they're different, but are they different enough to be worth
separate rules in a spam filtering context.
i.e.: would the scores generated be significantly different, or are both
rules roughly the same strength of spam indicator, and end up with
more-or-less the same score.
I suppose it could be tested, but this isn't a terribly common false
positive in the real world. If it were pervasive, I'd be jumping at
getting it fixed, but I've not seen it FP very often. The set3 S/O for
this rule was 0.969, which isn't perfect but it's really quite solid.
In general it strikes me as a problem with email generated by some
homebrew tool that isn't working properly. If it was generated by a
common tool, we'd be seeing a lot of these, but a 3.1% false positive
rate for the whole rule (not just this case) is pretty low.
I know it's a bit harsh, but I'm not terribly inclined to jump to change
SA to address rare-case false positives resulting from broken tools that
aren't in mainstream use and don't have a significant impact on SA's
global false positive rate.
Unless someone knows of a mainstream FP case here, I'd be inclined to
suggest either fixing the generator (best option, as some mail clients
may barf on that output anyway), or locally zero the rule if you're the
1 in a million people who gets badly malformed email on a regular basis.
Re: overly harsh against Message only has text/html MIME parts
Posted by Greg Troxel <gd...@ir.bbn.com>.
Theo Van Dinter <fe...@apache.org> writes:
> On Tue, Oct 14, 2008 at 06:55:27PM -0400, Greg Troxel wrote:
>> > 2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
>> > well of course, because
>>
>> This rule seems like it should not have fired.
>
> Yes, it should have. If a multipart/alternate mail only has a text/html part,
> it should be a text/html mail.
I see your point (the mail is malformed), but
mail is multipart/alternative but only has text/html
differs from
mail is multipart/alternative and text/plain and text/html don't match
are different conditions, and it might be useful to have different rules
that could have different scores.
Re: overly harsh against Message only has text/html MIME parts
Posted by Matt Kettler <mk...@verizon.net>.
Theo Van Dinter wrote:
> On Tue, Oct 14, 2008 at 09:32:42PM -0400, Matt Kettler wrote:
>
>> Agreed. However, there are times where it's not worth fixing a FP case
>> because its a rare case caused by a small-scale broken tool that
>> violates the specs.
>>
>
> FWIW, this case is specifically looked for by the rule.
>
>
In general, I'm not advocating dropping this aspect of the rule, just
moving it to a separate test where it can stand alone and be scored on
its own merits.
>> Of course, I lack the time right now to write it, so unless Theo or
>> someone else wants to jump on it, I'm sure patches are welcome.
>>
>
> I'm positive we've gone through this before, but I lack the time to go
> searching for the discussion/bugs. One that came up in a quick bugzilla
> search:
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4234
>
> The results at the time were that spam hits went down by so much, the rule
> became worse. Score generation is expected to deal with the FPs.
>
>
Well, that alone sounds like a good reason to split the rule. Those
results suggest that SINGLEPART_MULTIPART would be a better performing
rule, and probably deserves to be singled out so it can be scored higher.
Of course, the split would have the opposite affect of what the poster
desires, but it would be a good, conclusive point to stand on. This test
shows that this exact property occurs rarely in nonspam, and frequently
in spam. It also would allow the score to readily adapt to changes in
the FP ratio.
Re: overly harsh against Message only has text/html MIME parts
Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Oct 14, 2008 at 09:32:42PM -0400, Matt Kettler wrote:
> Agreed. However, there are times where it's not worth fixing a FP case
> because its a rare case caused by a small-scale broken tool that
> violates the specs.
FWIW, this case is specifically looked for by the rule.
> Of course, I lack the time right now to write it, so unless Theo or
> someone else wants to jump on it, I'm sure patches are welcome.
I'm positive we've gone through this before, but I lack the time to go
searching for the discussion/bugs. One that came up in a quick bugzilla
search:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4234
The results at the time were that spam hits went down by so much, the rule
became worse. Score generation is expected to deal with the FPs.
--
Randomly Selected Tagline:
"Well, today was Valentine's Day. Everybody got into the spirit. Former
President Clinton went by what he hopes will be his new office in Harlem, and
in honor of Valentine's Day he walked the neighborhood trying to pick up a
little chocolate." - Bill Maher
Re: overly harsh against Message only has text/html MIME parts
Posted by Matt Kettler <mk...@verizon.net>.
Joseph Brennan wrote:
>
>
>> Yes, it should have. If a multipart/alternate mail only has a text/html
>> part, it should be a text/html mail.
>
>
> No. The standard allows multipart/alternative to contain only
> one part. See the comment in RFC 2046 5.1.1 :
>
> NOTE: Experience has shown that a "multipart" media type with a
> single body part is useful for sending non-text media types.
>
Interesting, I was unware of that.
>
> At any rate, our job here is to detect spam, not be the RFC police.
Agreed. However, there are times where it's not worth fixing a FP case
because its a rare case caused by a small-scale broken tool that
violates the specs.
And of course, it goes both ways.. just because it's RFC legal, doesn't
mean SA shouldn't penalize it because it smells like spam.
>
> There is legitimate software that creates multipart/alternative
> messages with only one part that is html.
Fair enough, it might be worth splitting the rule to see how that works
out. ie: create a SINGLEPART_MULTIPART rule and see how it fares.
Of course, I lack the time right now to write it, so unless Theo or
someone else wants to jump on it, I'm sure patches are welcome.
Re: overly harsh against Message only has text/html MIME parts
Posted by Joseph Brennan <br...@columbia.edu>.
> Yes, it should have. If a multipart/alternate mail only has a text/html
> part, it should be a text/html mail.
No. The standard allows multipart/alternative to contain only
one part. See the comment in RFC 2046 5.1.1 :
NOTE: Experience has shown that a "multipart" media type with a
single body part is useful for sending non-text media types.
At any rate, our job here is to detect spam, not be the RFC police.
There is legitimate software that creates multipart/alternative
messages with only one part that is html.
Joseph Brennan
Columbia University Information Technology
Re: overly harsh against Message only has text/html MIME parts
Posted by Theo Van Dinter <fe...@apache.org>.
On Tue, Oct 14, 2008 at 06:55:27PM -0400, Greg Troxel wrote:
> > 2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
> > well of course, because
>
> This rule seems like it should not have fired.
Yes, it should have. If a multipart/alternate mail only has a text/html part,
it should be a text/html mail.
--
Randomly Selected Tagline:
"I feel like such a free spirit, and I'm really enjoying this so-called
Iced-Cream." - C. Montgomery Burns, the Simpsons
Re: overly harsh against Message only has text/html MIME parts
Posted by Greg Troxel <gd...@ir.bbn.com>.
jidanni@jidanni.org writes:
> Gentlemen, it seems spamassassin used full military justice here:
>
> 0.0 HTML_MESSAGE BODY: HTML included in message
0 points, so it's just noting.
> 2.5 MPART_ALT_DIFF BODY: HTML and text parts are different
> well of course, because
This rule seems like it should not have fired.
> 2.3 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
> OK, then
> 1.7 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag
> I dunno, maybe they thought they already said I'm text/html.
Perhaps they thought, but the message is malformed.
> 0.0 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts
> Yes.
Just noted, so doesn't count.
> Gee, all the message did bad was
>
> |Content-Type: multipart/alternative;
> | boundary="----=_Part_742221_601951471.1223963124030"
> |X-Mailer: HiNet WebMail
> |
> |------=_Part_742221_601951471.1223963124030
> |Content-Type: text/html;charset=utf-8
> |Content-Transfer-Encoding: quoted-printable
> |
> |<DIV>...
> |------=_Part_742221_601951471.1223963124030--
What it did bad was two things:
text/html without text/plain (poor form)
html without a proper html tag (standards violation)
So 2 of the 3 complaints were accurate.