STARTTLS & EHLO

Paul Smith <paul@pscs.co.uk> Mon, 26 January 2009 16:30 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 n0QGULGr021707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 09:30: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 n0QGULGM021706; Mon, 26 Jan 2009 09:30: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 mail.pscs.co.uk (mail.pscs.co.uk [77.240.14.73]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0QGU8Mg021697 for <ietf-smtp@imc.org>; Mon, 26 Jan 2009 09:30:20 -0700 (MST) (envelope-from paul@pscs.co.uk)
Received: from lmail.pscs.co.uk ([62.3.195.6]) by mail.pscs.co.uk ([77.240.14.73] running VPOP3) with ESMTP for <ietf-smtp@imc.org>; Mon, 26 Jan 2009 16:30:09 -0000
Received: from [192.168.66.101] ([192.168.66.101]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for <ietf-smtp@imc.org>; Mon, 26 Jan 2009 16:28:02 -0000
Message-ID: <497DE492.4080506@pscs.co.uk>
Date: Mon, 26 Jan 2009 16:28:02 +0000
From: Paul Smith <paul@pscs.co.uk>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: ietf-smtp@imc.org
Subject: STARTTLS & EHLO
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Authenticated-Sender: paul
X-Server: VPOP3 Enterprise V2.6.0e - Registered
X-Organisation: Paul Smith Computer Services
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>

We've just had a small issue come up wrt STARTTLS and I was wondering if
it was a mistake in RFC 3207, or just me :)

We did a quick patch for someone and added STARTTLS into a new part of
our software in a special build. For speed of releasing the patch, we
didn't make it issue a new EHLO afterwards, based on section 4.2 of RFC 3207

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


(SHOULD, not MUST). We were planning to add the extra EHLO in before
this went to a general release (we don't need to know about any
extensions other than that STARTTLS, so it's not necessary from our PoV)
. Anyway, 99.9% of the time, it's OK, but they have encountered one
recipient which refuses to accept the message in this case. So, they
seem to be treating the 'SHOULD' as 'MUST'.

Now, earlier in section 4.2, it says "

"  The server MUST discard any knowledge
   obtained from the client, such as the argument to the EHLO command,
   which was not obtained from the TLS negotiation itself"


which I guess is why they are rejecting the message, because (since they
have discarded the fact that we have previously sent EHLO) they are
complaining that we haven't sent EHLO yet.

So, should the 'SHOULD' be a 'MUST' in this RFC, or is the other server
incorrect?

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows