Created attachment 3793 [details]
correct this bug

Can you provide more information about what the issue is, a sample message
showing the problem, etc?

Thanks.

Created attachment 3804 [details]
sample message, with incorrect behaviour

sample message, with incorrect behaviour
for examine it - run spamassassin on win32 platform with active perl

how long time need for include this fix?

*** Bug 4363 has been marked as a duplicate of this bug. ***

-1 on that patch...

+		my $msghead = $`;
+		my $msgbody = $';

we cannot use $` and $' in SA -- use of them imposes a speed penalty on the
entire perl interpreter.

however, you're right -- we need to fix a bug here.

The test message contains 8-bit data using Content-Transfer-Encoding: 8bit .
This is a valid MIME message (arbitrary 8-bit data is fine according to rfcs
2045 and 3030).  This is damaged by SpamAssassin due to the s/\r?\n/\r\n/
substitution.

I think your patch is on the right track (replacing \r?\n in the headers only,
rather than in both hdrs+body) -- but it needs to be redone without $` and $'.

ok, fixed... I used bits of your patch ;) just without the $' and $` usage.
Also, report_safe rewriting needed to use the right line endings -- so
implemented that, too.

Committed revision 498825.

I'm not so thrilled with the submitted patch...

There is no guaranteed blank line between the header and the body, so the regexp
isn't necessarily going to do the right thing.

Since the lower down rewrite functions are supposed to be private
(rewrite_mail() is the standard API), we could just change them to return the
header/body separately and then do the appropriate thing.

There's also the question of what to do with report_safe body content since we
do want, imo, the line endings changed there.  Perhaps we'd want it to return
the components, set the appropriate areas to be line ending friendly, then
reassemble...

(In reply to comment #8)
> I'm not so thrilled with the submitted patch...
> 
> There is no guaranteed blank line between the header and the body, so the regexp
> isn't necessarily going to do the right thing.

ok, good point.  I'll look into that.

> Since the lower down rewrite functions are supposed to be private
> (rewrite_mail() is the standard API), we could just change them to return the
> header/body separately and then do the appropriate thing.

true.  I wanted to avoid peppering that code with s// statements, and just have
"one big fixup" before return -- but maybe it would be better to do some
peppering instead.

> There's also the question of what to do with report_safe body content since we
> do want, imo, the line endings changed there.  Perhaps we'd want it to return
> the components, set the appropriate areas to be line ending friendly, then
> reassemble...

that should be fixed already in the checked-in code; it fixes line endings
before inserting the (untouched) original-message message/rfc822 part.

ok, how's the latest checkin look?  I think it addresses your concerns...

: jm 146...; svn commit -m "bug 5250: previous fix didn't deal with messages
with no header/body separator; also, this way is more efficient, by pushing the
header-line-ending encoding nearer to point of insertion in the
rewrite_report_safe() and rewrite_no_report_safe() methods"
lib/Mail/SpamAssassin/PerMsgStatus.pm
Sending        lib/Mail/SpamAssassin/PerMsgStatus.pm
Transmitting file data .
Committed revision 499009.