Re: STARTTLS & EHLO

[Hector Santos <[e-mail]>]

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.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Tony Hansen wrote:
> Ahhh, there's where the difference in interpretation lays. One
> interpretation is that the remote side is required to forget the value
> that was passed with the original EHLO command. Another interpretation
> is that it further must forget that an EHLO command was issued at all.
> 
> I guess I can see either interpretation of the STARTTLS spec.
> 
> 	Tony Hansen
> 	[e-mail]
> 
> Tony Finch wrote:
>> On Tue, 27 Jan 2009, Paul Smith wrote:
>>> S: 220-main.remotedns.co.uk ESMTP Exim 4.63 #1 Mon, 26 Jan 2009 18:25:48 +0000
>>> S: 220-We do not authorize the use of this system to transport unsolicited,
>>> S: 220 and/or bulk e-mail.
>>> C: EHLO vpop3.company.co.uk
>>> S: 250-main.remotedns.co.uk Hello vpop3.company.co.uk [IP address]
>>> S: 250-SIZE 52428800
>>> S: 250-PIPELINING
>>> S: 250-AUTH PLAIN LOGIN
>>> S: 250-STARTTLS
>>> S: 250 HELP
>>> C: STARTTLS
>>> S: 220 TLS go ahead
>>> <TLS negotiation>
>>> C: MAIL FROM:<[e-mail]>
>>> S: 550 HELO required before MAIL
>>>
>>> (It happens with a few domains, all of which seem to be using Exim (4.63
>>> or 4.69))
>> This is a common but (obviously) non-standard anti-spam check. Practically
>> the only software that doesn't issue HELO or EHLO is malware so the check
>> has a negligible false positive rate. (Malware doesn't use TLS either, so
>> your bug is triggering a slightly over-broad check.)
>>
>>> It certainly looks as if it has forgotten the fact of the EHLO command
>>> once the STARTTLS has happened.
>> As it is required to do.
>>
>> Tony.
> 
> 
>