OK, I think I'm onto something here. The warnings would appear for the
first message processed by that process. I was able to reproduce by
restarting the daemon and sending in a new message.
>From my experimenting with the shortcircuit plugin I know that it
has the ability to change the order rules are evaluated (based on the
"priority"). So I suspected that the order that rules are
evaluated introduced this problem. I added a short-circuit rule for
NO_RELAYS, i.e.
shortcircuit NO_RELAYS ham
If I remove this rule, I no longer see the warnings. Hmmmm.
So now I need a SA/shortcircuit guru to help me understand what I did
wrong. Is there a way for me to short-circuit when there are no
relays without introducing these problems?
Well, let's back up a bit.
NO_RELAYS is an *error*. This should never happen. If it is happening,
you very likely have a problem that needs fixing for SA to work
accurately.
Usually if this is firing off, you've integrated SA in a way that it
never sees Recieved: headers generated by your local MTA, which is
bad. (all mail should have at least one Received: header before it
gets to SA, even if it's just saying "received from localhost by
localhost".) Usually this is from a borked MTA layer integration.
So, my personal recomendation would be to stop trying to shortcircuit
this rule, and figure out why there are no Received: headers in the
message.
I was just investigating this myself (actually looking at the code
Received.pm but not getting very far). Maybe you have an idea? I
found an email with NO_RELAYS, but it had the following Received headers:
Received: from localhost
([127.0.0.1] helo=smaug.papercutsoftware.com ident=matt)
by smaug.papercutsoftware.com with esmtp (Exim 4.69)
(envelope-from <online-ord...@papercut.com>)
id 1NT3bj-0006Zd-Se
for m...@localhost; Fri, 08 Jan 2010 12:25:44 +1100
Received: from papercut.com [216.92.193.84]
by smaug.papercutsoftware.com with IMAP (fetchmail-6.3.9-rc2)
for <m...@localhost> (single-drop); Fri, 08 Jan 2010 12:25:43 +1100
(EST)
Received: (qmail 67842 invoked by uid 3020); 8 Jan 2010 01:25:38 -0000
Received: (qmail 67839 invoked by uid 65534); 8 Jan 2010 01:25:38 -0000
but when I run this through: spamassassin -D I only see the following
entries about received headers.
[28013] dbg: received-header: parsed as [ ip=127.0.0.1
rdns=localhost helo=smaug.papercutsoftware.com
by=smaug.papercutsoftware.com ident=matt
envfrom=online-ord...@papercut.com intl=0 id=1NT3bj-0006Zd-Se auth=
msa=0 ]
[28013] dbg: received-header: relay 127.0.0.1 trusted? yes internal?
yes msa? no
[28013] dbg: received-header: found fetchmail marker, restarting parse
[28013] dbg: metadata: X-Spam-Relays-Trusted:
[28013] dbg: metadata: X-Spam-Relays-Untrusted:
[28013] dbg: metadata: X-Spam-Relays-Internal:
[28013] dbg: metadata: X-Spam-Relays-External:
Why wouldn't it be parsing/recognizing the 2nd "Received" header?
Is there anything rule/config that makes SA ignore a received header/relay?
Thanks,
Matt
