Last modified: 2014-01-03 16:10:51 UTC
See also bug 43665. On the ticket linked in the bug URL, you'll see that SpamAssassin marked the message with X-Spam-Flag = "YES", yet the message was still delivered to the regular info queue, rather than the Junk queue, as of course it should have.
Does this always happen for messages with X-Spam-Flag = "YES", or only sometimes?
Apr 18 20:45:21 williams spamd[17562]: spamd: checking message <8D00A8CC56066EA-CA0-AA39@webmail-d153.sysops.aol.com> for otrs:1000 Apr 18 20:45:25 williams spamd[17562]: spamd: result: . -3 - BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID scantime=4.0,size=3813,user=otrs,uid=1000,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=46656,mid=<8D00A8CC56066EA-CA0-AA39@webmail-d153.sysops.aol.com>,bayes=0.000000,autolearn=ham Our filter scored it a 3 which is below the threshold for tagging. The header must have been on the message already and it was probably ignored.
Ryan: Is this still an issue?
I'll look for a specific example that has an assigned spam score, but yes - the queues are generally still getting a lot of spam.
I found and fixed a couple of issues in the local exim/spamassassin configuration that should help. As of yesterday all incoming messages are scanned, and tagged if the score is significant (>=1.0) with X-Spam headers: X-Spam-Score: 11.9 (+++++++++++) X-Spam-Flag: YES X-Spam-Report: Yes, score=11.9 | host: iodine.wikimedia.org | scores: BAYES_99=3.5,FORGED_MUA_OUTLOOK=1.927,FREEMAIL_FROM=0.001,MISSING_MID=0.497,RCVD_IN_BRBL_LASTEXT=1.449,RCVD_IN_PBL=3.335,RCVD_IN_XBL=0.375,RDNS_NONE=0.793 | autolearn=no Messages scoring >= 5.0 get "X-Spam-Flag: YES". Messages scoring >= 12 are simply dropped. There's an postmaster filter in OTRS which checks for X-Spam-Flag: YES, but it directs messages to the probably-spam queue. That should probably be changed to the Junk queue.
That PostMaster Filter was just temporary, until this bug was resolved. We won't need it if the scoring is directing the messages to the appropriate queue.
I believe this is fixed. Important: I changed the way things work a little. We no longer have both Exim and OTRS postmaster filters doing the queuing. Exim adds X headers, and OTRS postmaster filters look for those headers and queue accordingly.
