Dirk the Daring wrote:
I've theorized that if the connecting host issues a RSET followed by another (valid) HELO, the connection can proceed and be successful. This might be why the connection is not immediately dropped. Also, I use FEATURE(`delay_checks'), which may have something to do with it.
Ah, yes. Of course. I knew there was something like that about HELO. Time to refresh memory from RFCs... Checking... Reading... Ok.
From rfc821, 4.1.1: The first command in a session must be the HELO command. The HELO command may be used later in a session as well. If the HELO command argument is not acceptable a 501 failure reply must be returned and the receiver-SMTP must stay in the same state.
From rfc2821, 4.1.1: 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.
The SMTP server cannot close the connection after a rejected HELO/EHLO since that is simply not allowed by the SMTP RFCs, but if the client sends any command except HELO/EHLO without first having sent an *accepted* HELO/EHLO it can be rejected because it's sending commands out of order. So, of course sendmail waits for *something* after a rejected HELO/EHLO. And as many spam apps seem to have no idea what a rejected HELO/EHLO means they go on to send a MAIL command and gets rejected because the only command the server will accept is another HELO/EHLO. Regards /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/ _______________________________________________ NOTE: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it. Visit http://www.mimedefang.org and http://www.roaringpenguin.com MIMEDefang mailing list [email protected] http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
