Daryl C. W. O'Shea wrote:
Loren Wilton wrote:
I am not NAT'ed so I can see no reason why it is ALL_TRUSTED
I think I can:
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 19588 invoked from network); 20 May 2005 22:45:07 +0100
Received: from 82-35-6-77.cable.ubr01.hari.blueyonder.co.uk
(@82.35.6.77)
by secure.roshan.name with SMTP; 20 May 2005 22:45:07 +0100
Language: English
I suspect the qmail header either isn't parsable by SA or doesn't contain
enough information to be interesting, or is considered local
delivery. This
means that the next and only header would be from your gateway and
would be
trusted, I assume. Since it is directly from the spammer with no
indication
of a local gateway, SA makes the wrong guess.
I *think* that normally SA expects to see a received header from your
local
MTA in the mail, and in this case there isn't one. You might be able
to get
around this by setting trusted_networks to local only, but I suspect the
right fix is to get a received header for your MTA in there.
Actually, SpamAssassin 3.0.3 can't parse the first received header
either, due to the @ in front of the IP. Even if you were to set
trusted_networks all trusted would fire and there'd be no RBL lookups etc.
Daryl
I think that is exactly right. If you remove the '@' everything is fixed
and the spam gets a very high score!
This parsing problem looks like something that would be fixable in
spamassassin or does it classify as a mail server problem that shouldn't
be worked around?
Raphael
