On 12.01.2016 17:20, Mike Brudenell wrote: > On 12 January 2016 at 16:11, Michael Toth <[email protected]> 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: [email protected] Web: http://www.scc.kit.edu KIT - Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft
smime.p7s
Description: S/MIME Cryptographic Signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
