Subject: Re:  New: Exim $sender_fullhost not recognised by Received
 header parser

On Thu, 4 Nov 2004 bugzilla-daemon@bugzilla.spamassassin.org wrote:
>
> > Received: from helene8.i.pinwand.net (helene.cats.ms) [10.0.8.6.13219] (mail)
> > 	by lisbeth.i.pinwand.net with esmtp (Exim 3.35 #1 (Debian))
> > 	id 1CO5y7-0001vC-00; Sun, 31 Oct 2004 04:01:23 +0100

This is not permitted by the syntax in RFC 821, so is a misconfiguration
of Exim and not a bug in SpamAssassin. You should use $sender_rcvhost
which includes the same information as $sender_fullhost but in a form that
is compatible with the RFC.

Tony.

It may be against 821 and possibly also 2821, but if Exim does do it, we will
probably have to support it anyway.  it wouldn't be the first anti-standard
thing we've supported :(

Subject: Re:  Exim $sender_fullhost not recognised by Received
 header parser

Exim doesn't do it by deafult. As I said, it's a misconfiguration,
breakage caused by the admin changing something incorrectly.

Tony.

Created attachment 2507 [details]
fix

ok, here's a patch.   this fixes the failure, by just falling back to some
simple inferences if the existing REs don't match.

however, there's one issue that could cause trouble; it assumes that in the
case of 

  Received: from hostname (hostname) [x.y.z.a....etc

given that there's two hostnames there, it assumes that the first one is the
rDNS (as it is in the pasted example header).	this isn't usual for most MTAs,
at least going by sendmail and Postfix; is it a reasonable assumption to make
as an Exim-specific fallback, though?

Subject: Re:  Exim $sender_fullhost not recognised by Received
 header parser

On Fri, 5 Nov 2004 bugzilla-daemon@bugzilla.spamassassin.org wrote:
>
> however, there's one issue that could cause trouble; it assumes that in the
> case of
>
>   Received: from hostname (hostname) [x.y.z.a....etc
>
> given that there's two hostnames there, it assumes that the first one is the
> rDNS (as it is in the pasted example header).	this isn't usual for most MTAs,
> at least going by sendmail and Postfix; is it a reasonable assumption to make
> as an Exim-specific fallback, though?

Yes. From the manual: A plain host name at the start of the string is a
verified host name w.r.t. both forward and reverse DNS; if this is not
present, verification either failed or was not requested. A host name in
parentheses is the argument of a HELO or EHLO command. This is omitted if
it is identical to the verified host name or to the host's IP address in
square brackets.

I note that the resolution of this bug is inconsistent with bug 3960. That
bug is also a misconfiguration of Exim that causes errors in the Received:
header according to the syntax in RFCs 821 and 2821. However 3960 is
WONTFIX but you are patching SpamAssassin for 3950 rather than telling the
user to get a clue.

Tony.

Subject: Re:  [review] Exim $sender_fullhost not recognised by
 Received header parser

There's also a Received: parsing simplification patch in bug 3582.

3960 was totally illegal and 100% user misconfiguration; this one is really just
using something Exim supplies as a legal setting, so even if it shouldn't do so,
I can certainly see other sites using it (sadly).

I've applied the bug 3582 bonus patch to 3.1.0 dev; thanks for the reminder!

Subject: Re:  [review] Exim $sender_fullhost not recognised by
 Received header parser

> 3960 was totally illegal and 100% user misconfiguration; this one is really just
> using something Exim supplies as a legal setting, so even if it shouldn't do so,
> I can certainly see other sites using it (sadly).

It isn't a legal setting because it isn't compatible with RFC 821. Exim
provides more than enough rope to shoot yourself in the foot when
configuring the received_header_text: it uses a general purpose string
expansion langusge without checking the syntax of the result. You chould
put the lyrics for Old Macdonald in if you wanted. The default setting is
correct and fiendishly complicated. If the admin changes it and gets it
wrong they deserve problems like SpamAssassin not working properly.

Bah, people are stupid.

Tony.

Subject: Re:  [review] Exim $sender_fullhost not recognised by
 Received header parser

I think I'm going to come down on the other side of this from Tony, and from the wontfix closure on 3650 or whatever it was.

General philosophy: if it is easy to f*** it up in Exim, and easy to correctly parse the f**'ed results, go ahead and do it.  (Alternately, have a debug or even a message header that bitches to the skies about the bad configuration, DON"T quietly ignore the misconfigured header.)  

OTOH, if it is hard to impossible to parse the screwed up results, don't.  However, if you can recognize it as an Exim misconfig, you should again output some sort of REAL OBVIOUS message about this, so that there is a chance of it getting fixed.

Things like switching the by and the from are pretty trivial to deal with, so probably should be dealt with.  The "hostname (hostname)" case also sounds pretty trivial to deal with, so again I'd personally be inclined to do it.   In both cases it is also pretty easy to recognize that the header format is odd, and if "(Exim" appears in the header, pretty easy to guess it is an Exim misconfig, and complain specifically about it in some obvious way.

Comment from rfc 2821: "As another consequence of trace
   fields arising in non-SMTP environments, receiving systems MUST NOT
   reject mail based on the format of a trace field and SHOULD be
   extremely robust in the light of unexpected information or formats in
   those fields."

Note the "should".

yeah, I'm with Loren on this one.  it's easy to catch this, and it will be a
relatively common screwup.

anyway, devs: votes pls

+1

+1 "C" is for "Cookie" and that's good enough for me.

r71481 -- applied.