At 13:33 28-01-2009, Tony Hansen wrote:
Hector, what started this was a client that doesn't use any other
extended smtp features beyond STARTTLS. So once it had started up TLS,
it had no use for the output of EHLO, and consequently it didn't bother
sending either HELO or EHLO after the STARTTLS. This was fine until it
ran into a server that demanded that EHLO be sent again. Leading to the
questions on the table: 1) which interpretation of the spec is correct,
and 2) what should be done once this is decided?
From RFC 3207:
"Upon completion of the TLS handshake, the SMTP protocol is reset to
the initial state (the state in SMTP after a server issues a 220
service ready greeting)."
The SMTP Client can either send a HELO or EHLO after that. As the
SMTP Client supports the service extension (it would not have been
able to do a STARTTLS without that), the likely command would be EHLO
to determine which extensions the SMTP server supports. If we go to
RFC 2821, we find that "a client MUST issue HELO or EHLO before
starting a mail transaction."
Paul Hoffman agreed to make some clarifications a few months ago.
Regards,
-sm