Jo Rhett wrote:
Daryl C. W. O'Shea wrote:
Is there any part of this rule that might be affected by using
Amavisd or testing via Milter? (I do both)
If whatever handled the message for scanning didn't fudge the
"Received: from bigfootinteractive.com" header like it should be
then this would happen.
Hm. Okay, the NO_RECEIVED and NO_RELAYS rules fired on this as well.
Theory: perhaps Milter hands the message to Amavisd prior to adding the
local Received line? That it only adds that header once Milter agrees?
Sendmail milters won't see the received header added by that relay (I
don't know about other MTA milter-like interfaces but I suspect that
they're the same). Amavisd should be fudging a header for you. The
NO_RECEIVED and NO_RELAYS hits confirm that it is not.
I assume that we can check the current remote address in some form, yes?
If I can figure this out, I'll provide an updated rule. If you know
how to do this, clue me in.
Assuming you mean remote address of the machine sending the message,
sure if it's in the received header that *must* be provided to SA by
whatever passes it the message to scan.
The X-Spam-Relays-Untrusted pseudo header has all the info you need.
I just provide the SARE rules as found on the SARE website (checked
every few minutes) via sa-update channels. Beyond that, I have
nothing to do with them.
Whoops. Sorry, I confused you and Ted because you responded. Apparently
these are Ted's rules...
Yeah, I was just concerned with confirming that this is in fact not an
issue with SpamAssassin since it was suggested that SA was at fault. In
this case, it's just a coincidence that I happen to provide the SARE
sa-update channel infrastructure too.
Daryl
