X-Spam-Report: not wrapped sometimes

[Matus UHLAR - fantomas <uh...@fantomas.sk>]

Hello,

I often receive see mail where X-Spam-Report header is longer than 80
characters. This causes mutt to re-wrap the header, which causes the header
be hardly readable. Since SA already wraps other headers, can we consider
that as a bug or does that have an reason/option to tune?

Examples (from 2 different systems, both 3.2.5)

X-Spam-Report:
        *  0.0 MISSING_MID Missing Message-Id: header
        *  0.0 MIME_HTML_MOSTLY BODY: Multipart message mostly text/html MIME
        *  0.0 HTML_MESSAGE BODY: HTML included in message
        *  1.1 MPART_ALT_DIFF BODY: HTML and text parts are different
        *  1.8 HTML_NONELEMENT_30_40 BODY: 30% to 40% of HTML elements are
        *      non-standard
        *  0.6 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area
        *  2.8 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/)
        *  0.2 URIBL_GREY Contains an URL listed in the URIBL greylist
        *      [URIs: streamsend.com]


X-Spam-Report:
        * -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
        * -0.0 SPF_PASS SPF: sender matches SPF record
        *  1.4 DATE_IN_FUTURE_96_XX Date: is 96 hours or more after Received: date
        *  0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60%
        *      [score: 0.4989]

descriptions of DATE_IN_FUTURE_96_XX and HTML_IMAGE_RATIO_02 are too long,
while HTML_NONELEMENT_30_40, URIBL_GREY and BAYES_50 are wrapped correctly.

-- 
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines. 

Re: X-Spam-Report: not wrapped sometimes

[Karsten Bräckelmann <gu...@rudersport.de>]

On Tue, 2009-04-28 at 12:21 +0200, Matus UHLAR wrote:
> I often receive see mail where X-Spam-Report header is longer than 80
> characters. This causes mutt to re-wrap the header, which causes the header
> be hardly readable. Since SA already wraps other headers, can we consider
> that as a bug or does that have an reason/option to tune?

No option to tune. Come on. ;)

After a quick look at the code, I guess I see what's going on. Actually
confirmed my suspicion looking at your headers. Probably worth filing a
low priority, enhancement / minor bug.


>   *  1.8 HTML_NONELEMENT_30_40 BODY: 30% to 40% of HTML elements are
>   *      non-standard
>   *  0.6 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area

This shows it quite nicely. The first one is exactly 80 chars long (yes,
indeed), while the second one is shorter, only 76 chars. So why should
we wrap the latter?

I guess the problem is with the leading tab. The \t is a *single* char,
thus leading to the wrapping problem -- when displaying a tab 8 spaces
wide.

M::SA::PerMsgStatus::_process_header() calls M::SA::Util::wrap() with a
line width of 79. Simply using 72 instead is quite nasty with respect to
the first line, though. So we'd need to make wrap() smarter, at least
understanding about a leading tab's width...

  guenther


-- 
char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}