Valentin Nechayev wrote:
>
> Tue, Jun 15, 2004 at 15:06:15, DavidB wrote about "FW: [Exim] AOL - SPF
> - and EXIM":
> > Only if you accept the HELO command in the first place, It says
> > nothing about rejecting the HELO command because of verification
> > failures.
> >
> > Please note that both the 2821 "Standards Track", and the official
> > 1123 specificatons only say that the server must not refuse to accept
> > a message if verificaition fails, neither say that the connection
> > can not be terminated, nor do either say that the HELO/EHLO
> > command must be considered acceptable when verification fails.
>
> More detailed, it prohibits only one kind of rejection policy:
> correspondence of $sender_helo_name and $sender_host_address.
No it does not. I may be being really picky here, but it specifically
says 'accept a message', not 'accept the command as acceptable'. If
the HELO/EHLO command is found to be unacceptable for any reason then
you can send a 5xx in response.
> But this says nothing for another kind of checks.
>
> We don't accept bare IP addresses (in standard four-octet text form) and
> this gives noticeable percent of rejections of spamming hosts. Another
> group of checks gives formal and quick check for undoubtedly invalid
> helo name (one that is invalid regardless of sender host multihoming,
> multiple mail domains, etc.)
>
> > <RFC 2821 "Standards Track">
> > 4.1.4 Order of Commands
>
> > If the EHLO command is not acceptable to the SMTP server, 501, 500,
> > or 502 failure replies MUST be returned as appropriate. The SMTP
> > server MUST stay in the same state after transmitting these replies
> > that it was in before the EHLO was received.
>
> Whether does this prohibit connection termination on inacceptable
> HELO/EHLO?
That is correct, it does not specify what MUST be acceptable. Therfore,
"correspondence of $sender_helo_name and $sender_host_address" is just
as valid a reason to reject as rejecting on a malformed IP literal
(i.e one without the []). But lets look at WHEN we are rejecting.
The way the protocol works is you either accept '2xx', defer '4xx', or
deny '5xx' a command as it is given, not after some other command.
In other words this is 'bad':
HELO test.domain.com
250 OK
MAIL FROM:<>
250 OK
RCPT TO:<joe@localhost>
550 NOT OK: We don't like 'test.domain.com'
And this is 'good':
HELO test.domain.com
550 NOT OK: We don't like 'test.domain.com'
--
--EAL--
