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

Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com> Mon, 18 January 2010 02:42 UTC

Return-Path: <mail@sabahattin-gucukoglu.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213013A692B for <yam@core3.amsl.com>; Sun, 17 Jan 2010 18:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0N+4ehqLQ4W for <yam@core3.amsl.com>; Sun, 17 Jan 2010 18:42:19 -0800 (PST)
Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 21AB53A683F for <yam@ietf.org>; Sun, 17 Jan 2010 18:42:18 -0800 (PST)
Received: by fxm5 with SMTP id 5so1859486fxm.29 for <yam@ietf.org>; Sun, 17 Jan 2010 18:42:11 -0800 (PST)
Received: by 10.223.144.208 with SMTP id a16mr3288659fav.62.1263782531882; Sun, 17 Jan 2010 18:42:11 -0800 (PST)
Received: from ?192.168.1.3? (62-31-227-19.cable.ubr07.dals.blueyonder.co.uk [62.31.227.19]) by mx.google.com with ESMTPS id 16sm1491552fxm.12.2010.01.17.18.42.10 (version=SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 18:42:11 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1077)
From: Sabahattin Gucukoglu <mail@sabahattin-gucukoglu.com>
In-Reply-To: <01NIK8RBBRJK004042@mauve.mrochek.com>
Date: Mon, 18 Jan 2010 02:42:09 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3A31776-016E-4DD9-9F5B-B51821EFB0CF@sabahattin-gucukoglu.com>
References: <9A584868-5961-4871-B32E-915394043727@sabahattin-gucukoglu.com> <01NIK8RBBRJK004042@mauve.mrochek.com>
To: yam@ietf.org, imap-protocol@u.washington.edu
X-Mailer: Apple Mail (2.1077)
Subject: Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2010 02:42:20 -0000

On 17 Jan 2010, at 17:35, Ned Freed wrote:
>> Shouldn't we be seriously discouraging that usage?
> 
> Perhaps. But a provisioning mechanism specification isn't the place to do it.
> 
The specification, if it describes the method of "Wrapped SSL", must explain what's wrong with it, and we know too well what's wrong with it (implementation specific behaviours, IANA problems, negotiation problems, although the latter is addressed in part by this very specification).  If it doesn't describe a specification that the IETF wrote or vouches for, then that specification needs to be written.  Otherwise, it shouldn't specify its usage at all.

Happily, this specification *does* explain the procedure for wrapping POP/IMAP/SMTP inside a directly-negotiated SSL stream, so all that's required now is to explain why, in all this time, we haven't documented it before now.  Perhaps we can even kill two birds with one stone. :-)

> If you want to promote or discourage a particular approach to deploying network
> services, you need to do it directly. Write a "IMAPS/POPS considered harmful"
> draft and get it published.
> 
See above; I have no problem with propitiating those who choose to do it wrong, but only so long as they don't do it very wrong, and hurt lots of innocent bystanders who obey well-written rules as a consequence of their own desires.  The deployment or not of broken vs correct behaviour will speak for itself, and I have no problem with that.  But neither should we simply allow for the specification of broken behaviour without a cautionary note.

Cheers,
Sabahattin