https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6708
--- Comment #2 from Karsten Bräckelmann <[email protected]> 2011-11-26 22:20:04 UTC --- (In reply to comment #1) > It needs more testing IMO. Plus that loop hurts my brain to unroll ;-) Referring to split_into_array_of_short_paragraphs() I assume? Agreed. However, that's just breaking large-ish MIME-parts up into chunks, and can be ignored. It used to be one string pushed onto the array per MIME-part, now it's one or more. The loop in question for this bug, in get_decoded_body_text_array(): # Go through each part for(my $pt = 0 ; $pt <= $#parts ; $pt++ ) { push(@{$self->{text_decoded}}, "\n") if ( @{$self->{text_decoded}} ); push(@{$self->{text_decoded}}, split_into_array_of_short_paragraphs($parts[$pt]->decode())); } That's simply going through all relevant MIME-parts, and pushing them onto the text_decoded array -- with an additional "\n" string pushed onto the array, if it evaluates true in scalar context, or simply, if there already has been content pushed onto the array before. Aka inject an empty line between MIME-parts. Anyone know why this has been done? Probably left-over from the old days, where the content for the rawbody rules actually has been lines -- rather than MIME-parts, or chunks thereof since 3.3. Grepping for this function name shows it really is used only for rawbody rules. Well, and the BodyEval check_blank_line_ratio(), which likely should not count artificially injected blank lines between MIME-parts anyway. That's not content... -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
