You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ben Wylie <sa...@benwylie.co.uk> on 2005/06/05 19:57:20 UTC
Received header not parsed
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 <em...@mydomain.tld>; 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
PS here is a rather amusing received header I got today ...
Received: from
#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHAR.#RND_WORD.#RND_WORD.com
by
#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHAR.#RND_WORD.#RND_
WORD.com (#RND_UC_CHARupfix) with SMTP id
#RND_DIGITB29E820#RND_DIGIT#RND_DIGIT#RND_DIGIT
for <yx...@fuse.net>; #RND_DATE_TIME
Message-ID:
<#RND_UC_CHAR#RND_UC_CHAR#RND_UC_CHARAEZ#RND_DIGIT#RND_DIGIT#RND_DIGIT.6ATL2
PUKI.#RND_UC_CHAR0000b2a1@#RND_WORD.#RND_WORD.com>
Date: #RND_DATE_TIME
Re: Received header not parsed
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 6/4/2006 9:54 PM, Ben Wylie wrote:
> 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.
Current versions of SpamAssassin won't fire ALL_TRUSTED if it can't
parse all of the received headers.
Since you provided no current debug info, or even said what version you
are using, I can only guess at what you're problem might be. Are you
sure it's not parsing the header and isn't instead a trust path issue?
Or maybe did you not upgrade (you haven't said that you did) or maybe
you upgraded to a version that hadn't yet modified the ALL_TRUSTED
behavior, or maybe...
Daryl
RE: Received header not parsed
Posted by Ben Wylie <sa...@benwylie.co.uk>.
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 <em...@mydomain.tld>; 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 <em...@mydomain.tld>;
> 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 <em...@domain.tld>; 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
==========================================
Re: Received header not parsed
Posted by Loren Wilton <lw...@earthlink.net>.
> 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
RE: Received header not parsed
Posted by Ben Wylie <sa...@benwylie.co.uk>.
>> 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 <em...@domain.tld>; 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
Re: Received header not parsed
Posted by Loren Wilton <lw...@earthlink.net>.
> Received: (from localhost [218.232.123.135])
> by server. (NAVGW 2.5.2.12) with SMTP id M2005060510393927686
> for <em...@mydomain.tld>; 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