Re: STARTTLS & EHLO
Hector Santos <hsantos@santronics.com> Thu, 29 January 2009 01:14 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T1EaW4079211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 18:14:36 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n0T1EaR2079210; Wed, 28 Jan 2009 18:14:36 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from winserver.com (mail.santronics.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0T1EPlO079192 for <ietf-smtp@imc.org>; Wed, 28 Jan 2009 18:14:35 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Wed, 28 Jan 2009 20:15:03 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 2677525375; Wed, 28 Jan 2009 20:15:02 -0500
Message-ID: <498102EA.7050809@santronics.com>
Date: Wed, 28 Jan 2009 20:14:18 -0500
From: Hector Santos <hsantos@santronics.com>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.0 (Windows/20070326)
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>
CC: ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO
References: <497DE492.4080506@pscs.co.uk> <497DED29.70402@att.com> <497ED420.30708@pscs.co.uk> <alpine.LSU.2.00.0901271403220.4546@hermes-2.csi.cam.ac.uk> <497F86CB.60904@att.com> <4980C684.2070300@santronics.com> <4980CF1D.4000303@att.com>
In-Reply-To: <4980CF1D.4000303@att.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
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@att.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. >> > > >
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? ned+ietf-smtp
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- Re: STARTTLS & EHLO: Errata text? Russ Allbery
- Re: STARTTLS & EHLO: Errata text? ned+ietf-smtp
- Re: STARTTLS & EHLO: Errata text? SM
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? Paul Smith
- Re: STARTTLS & EHLO: Errata text? Paul Smith
- Re: STARTTLS & EHLO Tony Hansen
- Re: STARTTLS & EHLO: Errata text? Russ Allbery
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? ned+ietf-smtp
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? ned+ietf-smtp
- Re: STARTTLS & EHLO: Errata text? Alexey Melnikov
- Re: STARTTLS & EHLO: Errata text? Alexey Melnikov
- Re: STARTTLS & EHLO: Errata text? SM
- Re: STARTTLS & EHLO: Errata text? ned+ietf-smtp
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? Bill McQuillan
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? SM
- Re: STARTTLS & EHLO: Errata text? Alexey Melnikov
- Re: STARTTLS & EHLO: Errata text? Tony Hansen
- Re: STARTTLS & EHLO John C Klensin
- Re: STARTTLS & EHLO Tony Hansen
- Re: STARTTLS & EHLO Paul Smith
- Re: STARTTLS & EHLO Tony Finch
- Re: STARTTLS & EHLO Hector Santos
- Re: STARTTLS & EHLO SM
- Re: STARTTLS & EHLO John C Klensin
- Re: STARTTLS & EHLO Tony Hansen
- Re: STARTTLS & EHLO Peter Bowyer
- Re: STARTTLS & EHLO Hector Santos
- Re: STARTTLS & EHLO Paul Smith
- Re: STARTTLS & EHLO Tony Finch
- Re: STARTTLS & EHLO Paul Smith
- Re: STARTTLS & EHLO John C Klensin
- Re: STARTTLS & EHLO Tony Hansen
- Re: STARTTLS & EHLO Tony Finch
- Re: STARTTLS & EHLO Alessandro Vesely
- Re: STARTTLS & EHLO Paul Smith
- Re: STARTTLS & EHLO Alexey Melnikov
- Re: STARTTLS & EHLO Tony Finch
- Re: STARTTLS & EHLO John C Klensin
- Re: STARTTLS & EHLO Tony Hansen
- STARTTLS & EHLO Paul Smith
- Re: STARTTLS & EHLO: Errata text? SM
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? SM
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- RFC 1123bis? Hector Santos
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? Hector Santos
- Re: STARTTLS & EHLO: Errata text? John C Klensin
- Re: STARTTLS & EHLO: Errata text? Tony Finch
- Re: STARTTLS & EHLO: Errata text? SM