Re: FW: [Exim] AOL - SPF - and EXIM

Pàgina inicial
Delete this message
Reply to this message
Autor: Edgar Lovecraft
Data:  
A: 'Exim User's Mailing List'
Assumpte: Re: FW: [Exim] AOL - SPF - and EXIM
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--