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 2008/08/27 23:29:08 UTC
[Bug 5966] New: BASE64_LENGTH_78_79 'catches' properly formatted
line with trailing CR/LF
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5966
Summary: BASE64_LENGTH_78_79 'catches' properly formatted line
with trailing CR/LF
Product: Spamassassin
Version: 3.2.4
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: Rules (Eval Tests)
AssignedTo: dev@spamassassin.apache.org
ReportedBy: medlin@medlin.com
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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
[Bug 5966] BASE64_LENGTH_78_79 'catches' properly formatted line
with trailing CR/LF
Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5966
--- Comment #1 from Theo Van Dinter <fe...@apache.org> 2008-08-27 15:29:28 PST ---
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.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.