Re: [exim] Exim server behind NAT router (and HELO)

Greg A. Woods wrote:

> The client host _MUST_ ensure that the <domain> parameter in a HELO (or
> EHLO) command is a valid principal host domain name for the client host.
> Period. No exceptions. No allowances. No leeway. It's a very Very

Sure, but what is a server about to do when the clients lies in
HELO/EHLO (wether by intention or not)? That's all what the client cares
about. Setting up a server in a way to block mail from such a client
"because they do not behave rfc-compliant" is simply hypocritical. You
cannot enforce a rule by breaking it yourself. If you that as your local
policy, then be it so, it's your own business. But don't accuse anybody
of "rfc-violation" then.

> VERY simple little requirement and one that is almost impossible for any
> valid SMTP client host on the modern Internet to not be able to comply
> with.

That's simply not true. Many clients sit behind NATed gateways today,
without having any clue about that, and also no reason to care about it.
(could be a reason they added "if possible" to rfc 2821)
You don't want the gateway to translate that... given the quality of
current software on these devices there is a 100% chance that something
important will be broken. And using smtp with tls/ssl pushes this even
further.

> Why do you continue try to make invalid excuses for the kind of lameness
> that would be necessary for anyone to fail to comply with this simple
> little requirement? We have enough lame idiots on the net already and
> we do not need to make excuses for any more of them!

Greg, what is your point? HELO/EHLO information is really the least
useful information in the whole SMTP transaction. I see the benefit for
debugging, but with dynamic IP clients it's for sure better to see a
"EHLO some-client.example.net" than "EHLO
some-dynamic-dsl-host.of.example.com".

I'm also not glad (gently speaking) about the load of crap I receive
every day. But that's not a reason to become aggressive about stuff that
is in no way connected to this (and furthermore mostly irrelevant).