Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?

Julien ÉLIE <> Mon, 18 January 2010 08:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08EB63A6A36 for <>; Mon, 18 Jan 2010 00:18:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, STOX_REPLY_TYPE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sbdKVn8zkvPK for <>; Mon, 18 Jan 2010 00:18:03 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id CEF783A680F for <>; Mon, 18 Jan 2010 00:18:02 -0800 (PST)
Received: (qmail 5524 invoked by uid 503); 18 Jan 2010 07:22:36 -0000
Received: from (HELO ( by with SMTP; 18 Jan 2010 07:22:36 -0000
Received: from (HELO queueout) ( by with SMTP; 18 Jan 2010 07:17:59 -0000
Received: from (HELO Iulius) ( by with SMTP; 18 Jan 2010 07:17:58 -0000
Message-ID: <75D72130D5F940E49B78BB10F879AC9A@Iulius>
From: Julien ÉLIE <>
References: <><><> <>
In-Reply-To: <>
Date: Mon, 18 Jan 2010 08:17:59 +0100
Organization: TrigoFACILE --
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6002.18005
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005
X-Ovh-Tracer-Id: 803329584475995462
X-Ovh-Remote: (
X-Ovh-Local: (
X-Spam-Check: DONE|U 0.5/N
Subject: Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jan 2010 08:18:04 -0000

Hi Ned,

> But we have documented this at this level of detail before now - in RFC 2595
> section 7.
> Now, I have no objection to adding a sentence to the security considerations
> section saying that use of imaps/pops are discouraged and pointing to the
> previous text on this issue. But I see little if any value in repeating the
> explanation here. And I'll again repeat that if your goal really is to change
> existing deployment practices, the only chance you have of doing that is with a
> separate document specifically on this point and this point alone.

For what it's worth, RFC 4642 for the STARTTLS command with NNTP
mentions in its introduction:

   In some existing implementations, TCP port 563 has been dedicated to
   NNTP over TLS.  These implementations begin the TLS negotiation
   immediately upon connection and then continue with the initial steps
   of an NNTP session.  This use of TLS on a separate port is
   discouraged for the reasons documented in Section 7 of "Using TLS
   with IMAP, POP3 and ACAP" [TLS-IMAPPOP].

   This specification formalizes the STARTTLS command already in
   occasional use by the installed base.  The STARTTLS command rectifies
   a number of the problems with using a separate port for a "secure"
   protocol variant; it is the preferred way of using TLS with NNTP.

   [TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
                 2595, June 1999.

Same problem.  That behaviour was never documented, but unfortunately
is what is currently usually implemented :-/

Julien ÉLIE

« The most effective way to remember your wife's birthday
  is to forget it once... » (Nash)