On Thu, 11 Mar 2004, Greg A. Woods wrote:
> [ On Thursday, March 11, 2004 at 14:27:56 (+0100), Toralf Lund wrote: ]
> > Subject: [Exim] helo_verify and EHLO containing *domain* name?
> >
> > (from the reject log.) The problem appears to be that the EHLO contains
> > a domain name rather than a host. Shouldn't this be accepted?
>
> No, absolutely not.
Would you care to interpret the meaning of this part of RFC2821
section 4.1.4:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
^^^^^^^^^^^^^^^^^^^^^^^^^^
reason if the verification fails: [...]
> The greeting command (HELO or EHLO) _MUST_ use the
> fully qualified _canonical_ host domain name of the client and that
> hostname must resolve in the DNS to an A record specifying the source
> address of the client connection.
That is the correct mandate to apply to the MTA which is initiating
the transaction, indeed. However, the questioner isn't the initiating
partner in this case.
The questioner was asking about the action of a recipient on
receiving a HELO/EHLO which does not conform to the mandate.
It seems to me that the RFC is equally clear on that point.
> If you're going to do any kind of HELO verification then _please_ do it
> the one and only "right way" -- i.e. stick to the real rules and DO NOT
> try to invent bogus and misleading rules of your own.
No, I'm perfectly willing to refuse a request on the basis of certain
improprieties in its HELO/EHLO: for example if it presents our own IP
address or our own domain name then we *will* reject the request in
due course (in fact, we do it at RCPT time, but that's a technical
detail). The RFC (which, according to you, must be obeyed without
exception) forbids such refusal, as I read it. What say you?
> You are not helping yourself or your users and you are certainly not
> helping the poor clueless soul who tried to get away with a bogus
> partial name.
You seem on the face of it to be wanting the questioner to police the
protocol in a way that is outright *prohibited* by the RFC. There may
be justifiable reasons for doing that, but at least you might be
prepared to put your cards on the table when you encourage them to do
so.
regards
