> Is it a new spammer trick (base64 body with URL base64 > representation splitted across several lines) ?
It could be, but I suspect it's simply a coincidence. base64 encoding is normally done with a forced line length for the encoded data, and it has allways been this way. When decoding base64 encoded data, you're supposed to treat the whole data block as one data stream, the linebreaks does not signify line breaks in the decoded data. It's perfectly normal, even expected and usually required, for lines of original data to be split when the data is encoded, and that split occurs whenever the encoded data reaches the forced line length with no regards to where in the original data it is. Line breaks in the original data is just treated as another byte (or bytes) of data, so they will not create line breaks in the encoded data. This is all a result of the fact that base64 was intended for encoding *binary* data so that it can be transported via text based protocols and media. If spamassassin decodes and matches base64 encoded data one line at a time or treats the linebreaks as if they actually break lines in the decoded data, spamassassin isn't decoding the data correctly. This could be an on purpose design decision (because it saves memory when dealing with attached files) or it could be a bug. If it is a design decision, it might be a good idea to reevaluate it as the amount of base64 encoded spams might have rised since the decision was first made. /Jonas -- Jonas Eckerman, [EMAIL PROTECTED] http://www.fsdb.org/ ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
