Re: STARTTLS & EHLO: Errata text?
Hector Santos <hsantos@santronics.com> Sun, 01 February 2009 21:52 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 n11LqLDt007555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2009 14:52:21 -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 n11LqLZK007554; Sun, 1 Feb 2009 14:52:21 -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 (secure.winserver.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n11LqKqp007547 for <ietf-smtp@imc.org>; Sun, 1 Feb 2009 14:52:20 -0700 (MST) (envelope-from hsantos@santronics.com)
Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-smtp@imc.org; Sun, 01 Feb 2009 16:52:57 -0500
Received: from hdev1 ([65.10.45.22]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 3010999406; Sun, 01 Feb 2009 16:52:56 -0500
Message-ID: <49861982.60809@santronics.com>
Date: Sun, 01 Feb 2009 16:52:02 -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 Finch <dot@dotat.at>
CC: John C Klensin <john+smtp@jck.com>, ietf-smtp@imc.org
Subject: Re: STARTTLS & EHLO: Errata text?
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> <alpine.LSU.2.00.0901281434440.4546@hermes-2.csi.cam.ac.uk> <498088B8.9040404@pscs.co.uk> <alpine.LSU.2.00.0901291310080.4546@hermes-2.csi.cam.ac.uk> <4981C0D5.1010401@pscs.co.uk> <4981C6BD.2040900@att.com> <37F39FF37390694B69567838@PST.JCK.COM> <4981E1AB.9000002@att.com> <alpine.LSU.2.00.0901301832470.4795@hermes-2.csi.cam.ac.uk> <49835DE2.3030403@santronics.com> <alpine.LSU.2.00.0901312021190.14750@hermes-2.csi.cam.ac.uk> <4984C49C.5030401@santronics.com> <alpine.LSU.2.00.0902011706190.10756@hermes-2.csi.cam.ac.uk> <AE5689449BAC89829F0DD5E7@PST.JCK.COM> <4985FCD8.8040305@santronics.com> <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.0902012028320.10756@hermes-2.csi.cam.ac.uk>
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>
Tony Finch wrote: > On Sun, 1 Feb 2009, Hector Santos wrote: >> I was thinking of 3207 with text similar to: >> >> The secured SMTP client MUST resend the EHLO command and the >> secured SMTP server MUST be prepared to issue an 503 >> for any out of sequence commands by legacy 3207 clients. > > What's wrong with the text I suggested? > > 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 requirement in [RFC5321] that "a client > MUST issue HELO or EHLO before starting a mail transaction" also > applies to this fresh state. IMO, it is lacking insights regarding legacy servers and clients potential behavior. See below. >> On the other hand, if 3207 is altered to enforce a MUST, then we need to >> change our server and in that vain, I reject this 3207 change to a MUST. > > This isn't a change to 3207, it's a clarification. This is a requirement > on the client so it isn't strictly necessary for servers to enforce it > (robustness principle and all that). I like to see "Protocol Consistency." What is expected of the client, helps define what is expected of the server, and vice versa. > Does your server enforce the > requirement for plaintext connections? Not sure how that applies. But specifically, its all local policy. Ok, lets back track and summarize some of this. Because of the 3207 conflictive semantics, we have come to learn there are three forms or potential outcomes for behavior: 1) A secured client who literally took the term 3207 SHOULD as an option and did not expect the secured server to barf when the secured client did not issue EHLO/EHLO and went straight to MAIL FROM. 2) A secured server who issued the wrong reply code (550), but did include correct human response text to an out of sequence command. This is probably why the OP was able to find the cause, the human text, but an automated client seeing 550 would think it was a normal server defined return path address rejection, e.g., maybe SPF? CBV? 3) Due to the 7 year old current wordings in the text, possible servers, including ours, who will not enforce EHLO/HELO after TLS is established. We might be the only one, but who knows without testing all the servers there. Because of these potentials, I don't think you can generally clarify and produce generic documents and "cross your fingers" that all documents will fit and work together to fix the above potentials. You will need more clarification that will provide specifics to address situations where they might be compatibility issues. You covered the general statement. A specific statement is required to remind legacy servers and clients that out of sequence issues are possible and appropriate (code) change actions are necessary. For example, adding to your text: 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 requirement in [RFC5321] that "a client MUST issue HELO or EHLO before starting a mail transaction" also applies to this fresh state. Note: Keep in mind that legacy clients may exist which do not re-issue EHLO/HELO. As required by SMTP, the server [SHOULD|]MUST issue an out of sequence negative response. i.e. 503 versus 55x. If you are not specific, then it is quite possible an "security argument" can be made such as: A secured server expects no "errors" in commands sequence and thus will abort (55x) all unexpected commands during a secured session. If you deem this is an appropriate possibility, then that should probably be stated as well. ' Simply looking for client/server protocol consistency. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com
- 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