On Thu, 2011-06-23 at 08:06 +0800, Bryan Sat wrote: > Hi Karsten, > > Please see the attached full email header for my problem. Can you > please verify again. Thanks.
Bryan, as has been pointed out to you in bug 6622 comment 3, please do reply in bugzilla by leaving an additional comment. Do NOT reply by mail to the commenter's address harvested from bugzilla mail. Even less so, do NOT reply to bugzilla-daemon. Despite my habit of keeping off-list replies quoted in full and unaltered when bouncing back to the list, in this case I'll prune unnecessary headers and full-quotes. > X-Spam-Subject: ***SPAM*** Quarantine report > X-Spam-Status: Yes, score=9.4 > X-Spam-Score: 94 > X-Spam-Bar: +++++++++ OK, this is different from whatever you dropped as an attachment to your bug report. See my comment 4. > X-Spam-Report: Spam detection software, running on the system > "klia.mschosting.com", has > identified this incoming email as possible spam. The original message > [...] Your Report header setting is broken. The above stuff is meant for report_safe wrapped body text, NOT a header. > pts rule name description > ---- ---------------------- > -------------------------------------------------- > 0.7 SPF_SOFTFAIL SPF: sender does not match SPF record > (softfail) > 2.4 URI_NO_WWW_BIZ_CGI URI: CGI in .biz TLD other than third-level > "www" > 1.3 TVD_FW_GRAPHIC_NAME_LONG BODY: TVD_FW_GRAPHIC_NAME_LONG > 0.0 HTML_MESSAGE BODY: HTML included in message > 3.0 BAYES_95 BODY: Bayes spam probability is 95 to 99% > [score: 0.9864] > 0.5 MISSING_MID Missing Message-Id: header > 1.4 MISSING_DATE Missing Date: header > 0.1 AWL AWL: From: address is in the auto white-list Given these scores, you appear to be running 3.3 with bayes and network tests enabled, score-set 3. Which again does not match your attached sample. However, I'd still close the bug report INVALID given the above rules. Hitting URI_NO_WWW_BIZ_CGI rather clearly shows what I mentioned in my bug comment. Internal reporting and server logs should NOT be scanned by anti-virus or anti-spam software, since they are highly prone to pick up exactly those links in the report, that led to the original message being classified spam or malware in the first place. The spammy Bayes score further shows, that such content is not to be scanned just like incoming mail. Moreover, the hits on MISSING_MID and MISSING_DATE clearly show local issues. The sending $entity is behaving badly by not adding those headers. And the SPF_SOFTFAIL hit strongly hints, you did not even intend that system to send mail... In conclusion, this is not a SA bug. There are a bunch of hits showing a bad internal sending environment. And even without these, the remaining rules clearly reflect this being an internal report -- which intention is to report the spammy signs to admins. By its very nature, those will NOT be considered a FP bug report. > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6622 > > Karsten Bräckelmann <[email protected]> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Resolution| |INVALID > Bryan, first of all -- scanning internal server logs and stuff with anti-virus > or anti-spam software is generally rather prone to trigger FPs. Simply because > the reports usually include the offending URIs and other snippets. Purely > internal server reports are best not scanned at all. -- 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; }}}
