You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2005/08/17 03:50:02 UTC

[Bug 4535] New: Content Boundary "--" throws off message parser

http://bugzilla.spamassassin.org/show_bug.cgi?id=4535

           Summary: Content Boundary "--" throws off message parser
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: Other
               URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=288617
        OS/Version: other
            Status: NEW
          Severity: major
          Priority: P5
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: spamassassin@packages.debian.org


From: "H. S. Teoh" <hs...@quickfur.ath.cx>
To: submit@bugs.debian.org
Subject: spamassassin: premature termination of scanned message body
Date: Tue, 04 Jan 2005 09:50:42 -0800

Package: spamassassin
Version: 3.0.2-1
Severity: normal

Hi, I've found a spamassassin bug. Take a look at the attached spam
(compressed to avoid hitting BTS spam filters): the message body
contains a line that starts with '-----', and the text "ancient secret
of life" immediately below this line. I have the following test in my
local.cf:

body      PANACEA_1     /\bancient\s+secret\s+of\s+life\b/i
describe  PANACEA_1     Ancient secret of life
score     PANACEA_1     1.5

Obviously, this rule should match when applied to this spam, right?

Unfortunately, no. It seems that spamassassin doesn't scan the rest of
the message after the '----' line. You can test this yourself, and see
that this rule will never match. However, if you edit the message and
remove the '-----' line, it WILL match.

It appears that SA is trying to ignore the signature part of the
message body in its tests. While I can see the rationale behind this,
I think it's a very bad idea. It's too easy for spammers to add '----'
lines before their message, and all body tests will be bypassed. The
body tests should always be applied to the ENTIRE message body.

Thanks!



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4535] Content Boundary "--" throws off message parser

Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4535


sidney@sidney.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|Libraries                   |Security




------- Additional Comments From sidney@sidney.com  2005-08-16 19:48 -------
This looks like a bug in our MIME parsing. The MIME boundary string in this
message is "--". According to RFC2046 a line should be recognized as a part
boundary if it begins with "--", followed by the boundary string, optionally
followed by whitespace, then a newline.

This is less confusing when I change the boundary string to be "%%" instead of
"--". With that change, here is wnat SpamAssassin does vs what a RFC compliant
MUA like Thunderbird does:

The only line that should be a boundary is the first one, which is "----" in the
example message, or "--%%" with my change.

The line that is "-----------------------------" is not supposed to be a MIME
boundary. I changed it to "--%%-------------------------" for my experiments.

Thunderbird does not see a boundary there, as per RFC2046.

SpamAssassin seems to parse it as a boundary, so treats the next line "The
Ancient Secret of LIFE" as being in the part header. The part is treated as
text, starting after the next blank line.

If you put a blank line before "The Ancient Secret of LIFE" then the body rule
can see it.

If "--%%-------------------------" is changed to "--%%" then Thunderbird also
treats what follows as a separate part, without a valid header to define what is
in it.

So the MIME parsing bug appears to be that it is matching the boundary string as
a line prefix even when it is followed by non-whitespace.

Marking this as a security rule




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4535] Content Boundary "--" throws off message parser

Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4535


sidney@sidney.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Group|                            |security






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4535] Content Boundary "--" throws off message parser

Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4535





------- Additional Comments From spamassassin@packages.debian.org  2005-08-16 18:53 -------
Created an attachment (id=3077)
 --> (http://bugzilla.spamassassin.org/attachment.cgi?id=3077&action=view)
Sample message with problem

This is a message that seems to exhibit the problem. It is impossible to match
on "The Ancient Secret of LIFE" using a body rule. Removing the line of -'s
allows the match.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

[Bug 4535] Content Boundary "--" throws off message parser

Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4535


duncf@debian.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.1.1




------- Additional Comments From duncf@debian.org  2005-08-16 18:56 -------
FWIW I reproduced this on trunk. It seems to be a problem with the MIME boundary
being "--", which throws stuff off? Mutt renders the entire message fine.
Haven't tested others.

(I really don't understand MIME and the RFCs as well as I should!)

Triaging for 3.1.1. Could be really important if we see this (more) in the wild.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.