http://bugzilla.spamassassin.org/show_bug.cgi?id=3950
------- Additional Comments From [EMAIL PROTECTED] 2004-11-05 21:14 ------- 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". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
