I have had a problem with a particular form of received header not being
parsed correctly because it is malformed. I had a brief conversation on this
list about a year ago with a glimmer of hope that in future versions this
would be overcome. However a year later these emails are still being marked
as ALL_TRUSTED because the untrusted relay received header is not parsed.
The received header is in the following form:
Received: (from
And I am informed it shouldn't have the bracket before the from.
Is there any way I can make sure that spamassassin will parse these received
headers and recognise them, or at least not allow ALL_TRUSTED to be given if
there is one or more badly formed received header?
As it was a year ago, I have copied the 4 emails in the exchange, below.
Thanks for your help,
Ben
==========================================
This email arrived today:
Received: from [127.0.0.1] by arkbb.co.uk with SMTP (HELO server.)
(ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.7.9)); Sun,
5 Jun 2005 10:40:10 +0100
Received: (from localhost [218.232.123.135]) by server. (NAVGW 2.5.2.12)
with SMTP id M2005060510393927686 for <[EMAIL PROTECTED]>; Sun, 05 Jun
2005 10:39:39 +0100
debug: IP is reserved, not looking up PTR: 127.0.0.1
debug: received-header: parsed as [ ip=127.0.0.1 rdns= helo= by=arkbb.co.uk
ident= envfrom= intl=0 id= auth= ]
debug: received-header: relay 127.0.0.1 trusted? yes internal? yes
debug: metadata: X-Spam-Relays-Trusted: [ ip=127.0.0.1 rdns= helo=
by=arkbb.co.uk ident= envfrom= intl=1 id= auth= ]
debug: metadata: X-Spam-Relays-Untrusted:
Why was the second header not parsed?
It was given an all trusted score because it failed to get that header.
Thanks
Ben
==========================================
> Received: (from localhost [218.232.123.135]) by server. (NAVGW
> 2.5.2.12) with SMTP id M2005060510393927686 for <[EMAIL PROTECTED]>;
> Sun, 05 Jun 2005 10:39:39 +0100
>
> Why was the second header not parsed?
Invalid format. Need "from" as the first word, not "(from".
> It was given an all trusted score because it failed to get that header.
Which version are you running? I thought this was fixed in 3.0.3, but maybe
it is in the panding 3.0.4/3.1 streams.
Loren
==========================================
>> Why was the second header not parsed?
>
> Invalid format. Need "from" as the first word, not "(from".
Ok thanks.
I don't know why it has it in that format. It was put in by my AV proxy,
which usually has valid headers:
Received: from a.mx.bluesine.com ([66.18.211.109]) by server. (NAVGW
2.5.2.12) with SMTP id M2005060520012009891 for <[EMAIL PROTECTED]>; Sun, 05
Jun 2005 20:01:20 +0100
I wonder what could have possessed it to change the way it did the headers.
>> It was given an all trusted score because it failed to get that header.
>
> Which version are you running? I thought this was fixed in 3.0.3, but
> maybe it is in the panding 3.0.4/3.1 streams.
I am using 3.0.3 on Windows 2003.
What is the fix? Will it recognise it as a received header even though it is
invalid?
Cheers,
Ben
==========================================
> I am using 3.0.3 on Windows 2003.
> What is the fix? Will it recognise it as a received header even though
> it
is
> invalid?
No. Well, I believe there have been some changes in received header
parsing, so some valid headers not recognized on .3 will be correctly
recognized. But this isn't that case.
What I believe it will do is decide that if there are any unparsable headers
(or maybe just any that could fall in the trust path, I'm not sure) that
all_trusted can't fire, because you can't know that all of them are trusted.
Loren
==========================================
