Incorrect handling of subsequent calls to Hello()

[Hsn723]

trafficstars

RFC 5321 Section 4.1.4 states that

An EHLO command MAY be issued by a client later in the session. If it is issued after the session begins and the EHLO command is acceptable to the SMTP server, the SMTP server MUST clear all buffers and reset the state exactly as if a RSET command had been issued. In other words, the sequence of RSET followed immediately by EHLO is redundant, but not harmful other than in the performance cost of executing unnecessary commands.

Prior work in #270 and #265 partially address that, but according to section 4.1.4, EHLO/HELO may be (re)sent at any time during the session. For instance, later in 4.1.4 an example is given where a new EHLO is issued after MAIL to abort an ongoing mail transaction.

The MAIL command (or the obsolete SEND, SOML, or SAML commands) begins a mail transaction. Once started, a mail transaction consists of a transaction beginning command, one or more RCPT commands, and a DATA command, in that order. A mail transaction may be aborted by the RSET, a new EHLO, or the QUIT command.