On 12.01.2016 17:20, Mike Brudenell wrote:
> 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.
The way I reed it: "the client MUST issue HELO or EHLO, but it SHOULD
send EHLO instead of HELO."
There is no need for non-mail transactions instructions...
>
> 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 suppose that's something that caught some people (me included) by
surpise. Why does exim allow the transaction to continue if there has
been a deny? Excluding RCPT-TO of course. I'll have to check my acls.
However, since it has not surfaced before, I guess spammers are more
likely to conform to the RFCs than many would believe. ;-)
--
Karlsruher Institut für Technologie (KIT)
Steinbuch Centre for Computing (SCC)
Patrick von der Hagen
Zirkel 2, Gebäude 20.21, Raum 004.2
76131 Karlsruhe
Telefon: +49 721 608-46433
E-Mail: hagen@???
Web:
http://www.scc.kit.edu
KIT - Universität des Landes Baden-Württemberg und
nationales Forschungszentrum in der Helmholtz-Gemeinschaft
