owner:alexey.melnikov@isode.comtype_defect | by alexey.melnikov@isode.com
Section 4 of RFC 4954 says:
The client SHOULD send an EHLO command as the first command after a
successful SASL negotiation that results in the enabling of a
security layer.
It is not clear why this is only a SHOULD (instead of a MUST), considering that successful AUTH itself resets all SMTP session state, including the EHLO parameter.
Also, need to clarify, that EHLO after AUTH is always Ok (even without a SASL security layer) and that it doesn't reset the AUTH state. I.e. that the successful AUTH state is "sticky" on the TCP connection.
Issue migrated from trac:32 at 2022-01-31 12:36:15 +0000
owner:alexey.melnikov@isode.comtype_defect| by alexey.melnikov@isode.comSection 4 of RFC 4954 says:
The client SHOULD send an EHLO command as the first command after a successful SASL negotiation that results in the enabling of a security layer.
It is not clear why this is only a SHOULD (instead of a MUST), considering that successful AUTH itself resets all SMTP session state, including the EHLO parameter.
Also, need to clarify, that EHLO after AUTH is always Ok (even without a SASL security layer) and that it doesn't reset the AUTH state. I.e. that the successful AUTH state is "sticky" on the TCP connection.
Issue migrated from trac:32 at 2022-01-31 12:36:15 +0000