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

Ned Freed <> Sun, 17 January 2010 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 178CA3A6893 for <>; Sun, 17 Jan 2010 09:51:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1PmrBCAGOnuI for <>; Sun, 17 Jan 2010 09:51:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 58C1E3A63EC for <>; Sun, 17 Jan 2010 09:51:32 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 17 Jan 2010 09:51:23 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Sun, 17 Jan 2010 09:51:16 -0800 (PST)
Message-id: <>
Date: Sun, 17 Jan 2010 09:35:47 -0800
From: Ned Freed <>
In-reply-to: "Your message dated Sun, 17 Jan 2010 04:10:51 +0000" <>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <>
To: Sabahattin Gucukoglu <>
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: Sun, 17 Jan 2010 17:51:33 -0000

> Hi all,

> Just had a look at draft-daboo-srv-email, all very pleasant.  I think service
> weights have been discussed already but:

> Why does the spec provision for IMAPS and POP3S?

Because a provisioning mechanism that fails to deal with the needs ot
real-world deployments - and there's plenty of this secure port stuff deployed
out there - makes itself far less likely to deploy.

> Shouldn't we be seriously discouraging that usage?

Perhaps. But a provisioning mechanism specification isn't the place to do it.

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.

We have buckets full of past experience informing us that trying to shift
existing deployments away from approaches we don't like through registration
policy resrictions not only doesn't work, it often backfires and causes far
more harm than good.

> Is there some reason to keep them, even if "deprecated"/discouraged?

Yes. See above.

> Right now the only reason I know of is IMAP clients which send out LOGIN
> complete with password before they can be stopped; for that we have the
> LOGINDISABLED capability.

The abscence of a technical justification doesn't mean no other sort of
justification exists.