Re: [Exim] Mail Reject Because Of Helo .xxxx

Alan J. Flavell wrote:
>
..[snip]...
>
> Any MTA is entitled to apply some kind of acceptance policy, and tests
> on the HELO/EHLO string could very well feature in that policy, no
> matter what the RFC may say. We're just dealing with thousands of cases
> where phishers send "HELO barclays.co.uk", and the body of the mail asks
> the recipient to reveal their bank account details. I have no
> hesitation in blocking these attempts, no matter what the RFC thinks
> about it. In fact, now that I'm aware of the fraud, I would probably be
> criminally negligent if I didn't try to block it, no matter what the RFC
> might say.

The RFC's (821/2821/1123) all state that the 'MUST NOT reject HELO/EHLO'
only applies to those HELO/EHLO strings when the given FQDN or HOSTNAME
does not match a DNS PTR record for the sending IP address, there is
absolutley nothing in any of the RFC's that state that you cannot, or
should not reject an invalid HELO/EHLO (i.e. 1.2.3.4 rather than [1.2.3.4])
nor do they say that a server cannot reject on what is an obvious
forgery (i.e. saying they are your server, or some other server that you
know for certain is at a different address). So as I read all the relevant
materials, you are not violating any RFC in doing so, IMHO.

But again, all of the RFC's were assuming that any connecting client would
at least try and give you valid information, not some forged information.

--

--EAL--