Paul Smith <> Mon, 26 January 2009 16:30 UTC

Received: from (localhost []) by (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
Received: (from majordom@localhost) by (8.14.2/8.13.5/Submit) id n0QGULGM021706; Mon, 26 Jan 2009 09:30:21 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.14.2/8.14.2) with ESMTP id n0QGU8Mg021697 for <>; Mon, 26 Jan 2009 09:30:20 -0700 (MST) (envelope-from
Received: from ([]) by ([] running VPOP3) with ESMTP for <>; Mon, 26 Jan 2009 16:30:09 -0000
Received: from [] ([]) by ([] running VPOP3) with ESMTP for <>; Mon, 26 Jan 2009 16:28:02 -0000
Message-ID: <>
Date: Mon, 26 Jan 2009 16:28:02 +0000
From: Paul Smith <>
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
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
Precedence: bulk
List-Archive: <>
List-ID: <>
List-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

Paul Smith

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