On Tue, Jan 12, 2016 at 04:27:25PM +0000, Drav Sloan wrote:
> > OK, so this begs the question that if the RFC says a client MUST issue a
> > HELO/EHLO before a mail transaction, then shouldn't Exim refuse to accept
> > MAIL FROM until a HELO/EHLO has been received *and* accepted? (ie, doing a
> > "deny" and issuing a 5xx response should leave Exim in its initial 'still
> > looking for a HELO/EHLO or non-mail transaction command')
>
> I've always dealt with that situation in the rcpt acl:
>
> # some spammers can't be bothered saying HELO
> deny condition = ${if eq{$sender_helo_name}{}{yes}{no}}
> !hosts = +relay_from_hosts
> message = RFCs mandate HELO/EHLO before mail can be sent
If Exim returns a 5XX banner or a 5XX response to HELO/EHLO, then
it should continue to return unconditional 5XX responses to all
other commands (up to a configurable limit, at which point it can
hang up). The remote SMTP client should have disconnected immediately
after the 5XX banner or 5XX HELO/EHLO response, if it fails to do
so, it should not IMHO be up to each administrator to have to
implement logic to refuse service to the misbehaved client.
--
Viktor.
