On 22 Mar 2005 at 16:50, Matt Fretwell wrote about
"Re: [exim] Exim server behind NAT r":
|...
| If, according to the RFC's, a client MUST helo with a valid hostname, and
| doesn't, why should the reference to 'must not refuse to accept', (or
| something similiar), be adhered to?
Assuming what you mean to ask is why both MUSTS are in the RFC in the
first place, since they seem contradictory, good question. RFC2821
answers it by adding the "if possible" language to the client side.
| If someone who is trying to connect to our system(s) can't be arsed
| adhering to the RFC's, why should we pay any gorm to the RFC's?
That's up to you. As a *practical* matter, you can reject
connections and messages for any policy reason that makes sense for
you, regardless of what the RFCs say. For my site (and, I believe,
most business/commercial sites), rejecting based on an unverifiable
HELO/EHLO parameter is just not practical. The "false positive" rate
is *way* too high.
OTOH, there have been techniques posted here for rejecting certain
common HELO/EHLO forgeries that are quite useful with virtually no
false positives.
- Fred
