Bug 5966 - BASE64_LENGTH_78_79 'catches' properly formatted line with trailing CR/LF
Summary: BASE64_LENGTH_78_79 'catches' properly formatted line with trailing CR/LF
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.2.4
Hardware: Other All
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-27 14:29 UTC by Dennis Pearson
Modified: 2008-08-27 15:29 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
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 Dennis Pearson 2008-08-27 14:29:08 UTC 
The RFC for base64 encoding (RFC 2045) says "The 76 character limit does not count the trailing CRLF, but counts all other characters, including any equal signs."

So those sending a perfectly acceptable line of 76 char of data with a trailing CR/LF as allowed by the RFC get flagged by BASE64_LENGTH_78_79 eval.
Comment 1 Theo Van Dinter 2008-08-27 15:29:28 UTC 
No, this doesn't happen.  SA converts CRLF to LF during processing, and turns it back into CRLF when outputting the message if necessary.  So it'd be 76+1 = 77, not in the 78-79 range.

This is easily shown by the results of last night's corpus run:

  0.125   0.1316   0.0000    1.000   0.71    3.90  BASE64_LENGTH_79_INF
  0.033   0.0348   0.0000    1.000   0.59    3.70  BASE64_LENGTH_78_79

which at this point says that the rule doesn't hit much spam anymore (though 79+ still does well), and the ham hit rate is 0.