Bug 2453 - illegal caracteres in base64 false the decoding and not all the test can be performed on the body
Summary: illegal caracteres in base64 false the decoding and not all the test can be p...
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamassassin (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: PC FreeBSD
: P3 normal
Target Milestone: 2.70
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on: 1527
Blocks:
  Show dependency tree
 
Reported: 2003-09-14 01:18 UTC by Jean Th
Modified: 2004-01-25 11:55 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
Spam that can't be totally decoded text/plain None Jean Th [NoCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jean Th 2003-09-14 01:18:13 UTC
Comment 1 Jean Th 2003-09-14 01:21:04 UTC 
Created attachment 1368 [details]
Spam that can't be totally decoded
Comment 2 Jean Th 2003-09-14 01:24:33 UTC 
mozilla and outelook are decoding this without any problems
Comment 3 Theo Van Dinter 2003-09-14 01:58:31 UTC 
after poking around a bit, I determined a few things.

1) it's not the base64 decoders that have the issue.  both our "slow" version 
and the MIME::Base64 versions deal with the invalid space and ! chars just fine.

2) The problem lies in PerMsgStatus->get_decoded_body_text_array().  we try to 
be smart and figure out what's base64 encoded and what isn't, but that doesn't 
work well when the base64 stuff is malformed.
Comment 4 Theo Van Dinter 2003-09-14 02:11:33 UTC 
fyi, the source of the problem is that there is whitespace in the base64 
section, which makes our code think it's not encoded, and thereby kills the 
decoding.

having "--" at the start of the line would do the same thing, btw.
Comment 5 Theo Van Dinter 2003-09-14 02:21:18 UTC 
since we're going to want to rewrite that function for other reasons, here's my 
thought:

<felicity> my version of that code would break down whatever it was passed into 
attachment parts.
<felicity> then go recursive and decode as necessary.  when it all ends back up 
at the parent, it'll all be
           decoded properly.
Comment 6 Daniel Quinlan 2003-09-18 13:38:14 UTC 
changing severity to normal, priority to P3
Comment 7 Theo Van Dinter 2004-01-24 21:32:52 UTC 
fixed in 2.70
Comment 8 Theo Van Dinter 2004-01-25 20:55:28 UTC 
I'll actually close the ticket this time. <sigh>