Re: STARTTLS & EHLO

[Tony Hansen <[e-mail]>]

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?

	Tony Hansen
	[e-mail]

Hector Santos wrote:
> 
> My take on this:
> 
> I think the client should be aware that most, if not all, servers expect
> a 2nd pass of EHLO, but I also believe the client should not presume
> server features would be the same under TLS and NON-TLS sessions.
> 
> For example, the use case where the private or even public server allows
> a stronger AUTH for non TLS sessions and allows weaker AUTH under TLS:
> 
>    S: 220 blah blah blah
>    C: EHLO client-domain.com
>    S: 250-server-domain.com
>    S: 250 AUTH CRAM-MD5 OTHER
>    S: 250 STARTTLS
>    C: MAIL FROM: <xxxxxxx>
>    S: 530 Must issue a STARTTLS or AUTH command first
>    ...
> 
> Note: both RFC 2487 (TLS) and RFC 2554 (AUTH) use 530 for an enforcement
> requirement. So here, if it client support CRAM or DIGEST it can
> continue with AUTH CRAM-MD5 or AUTH OTHER. But if it does not support
> these stronger AUTH, and does support TLS, it can continue with a STARTLS:
> 
>    ...
>    C: STARTTLS
>    S: 220 Go ahead
>    C & S: <TLS negotiation>
>    C: MAIL FROM: <xxxxxxx>
>    S: 530 AUTH command first
>    C: EHLO client-domain.com
>    S: 250-server-domain.com
>    S: 250 AUTH LOGIN
>    S: 250 AUTH-LOGIN
>    S: AUTH LOGIN
>    S: 235 Authentication successful.
> 
> The point is, the client MUST be aware of this possibility and should
> always (MUST) issue an EHLO after TLS is established.
> 
> The idea of public vs private and level of authentication is discussed
> in 2487 and this is where the 4.2 statement:
> 
>    The client SHOULD send an EHLO command as the
>    first command after a successful TLS negotiation.
> 
> is "forgetful" of its other key points.  So it should of been something
> like:
> 
>    For a SMTP server that is privately referenced, the client
>    MUST issue the EHLO command after a successful TLS negotiation
>    to determine if there are any changes in AUTH methods, such
>    as the strength of the authentication.
> 
>    If the server is the publicly reference, the client SHOULD
>    send an EHLO command as the first command after a successful
>    TLS negotiation, however, it is highly recommended it reissues
>    the EHLO in all cases.
> 
>    The client SHOULD not degrade from EHLO to HELO.
> 
> My take.
>