> On 12 January 2016 at 16:11, Michael Toth <exim@???> wrote:
> > And right after that the RFC says "In any event, a client MUST issue
> > HELO or EHLO before starting a mail transaction"
>
> Hmmm ... A very good point. Presumably there are some non-mail
> transaction instructions you can give that are valid without the
> HELO/EHLO first being issued.
This means it's valid to do eg 'HELP', 'VRFY', 'EXPN', or even 'RSET'
before (or without) a HELO/EHLO. This is probably at least historical
behavior and may be convenient in some situations, although these days
there's probably very little useful usage of any of these commands.
> 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 suspect that there are MUA clients that start sending MAIL FROM
without HELO/EHLO'ing first and that Exim defaults to accomodating
them. It's possible to construct ACLs that mostly stop this if you want
to (set a connection ACL variable in the HELO/EHLO ACL, then check for
it being set in MAIL FROM)[*].
- cks
[*: The case I don't think this stops is if the client EHLOs, does
STARTTLS, and then does not re-EHLO before MAIL FROM.
]
