ietf-smtp
[Top] [All Lists]

Re: STARTTLS & EHLO

2009-01-28 20:36:15

HI Tony,

Yes, right, I acknowledge this question. My point is that the simplistic statement in 4.2

   The client SHOULD send an EHLO command as the
   first command after a successful TLS negotiation.

was not "considerate" of the other key points the documents makes about private vs public vs authentication levels it clearly made.

IOW, programmatically, the client should of interpret these points in the document and see this a MUST is the only logical option simply because of the other key points made about how the server status can change, especially when accessing a private smtp host (ie. SUBMIT server),

If the private submit server presented only STARTTLS then the client has no choice but to start with STARTTLS and when completely, only then the SERVER will present the AUTH schemes, then the client has no choice but to reissue the EHLO to find what methods are available.

The point is that there are some states the force the issue, programmatically.

--
Sincerely

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

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?

        Tony Hansen
        tony(_at_)att(_dot_)com

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.






<Prev in Thread] Current Thread [Next in Thread>