MBOX-Line: From dave at cridland.net  Mon Mar 26 10:32:36 2007
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] IMAP features: which clients use them? 
In-Reply-To: <07Mar26.080619pst."57996"@synergy1.parc.xerox.com>
References: <07Mar20.114847pst."57996"@synergy1.parc.xerox.com>
	<07Mar24.114611pst."57996"@synergy1.parc.xerox.com>
	<7000.1174904408.192915@peirce.dave.cridland.net>
	<07Mar26.080619pst."57996"@synergy1.parc.xerox.com>
Message-ID: <6000.1174926756.434557@peirce.dave.cridland.net>

On Mon Mar 26 10:06:09 2007, Bill Janssen wrote:
> > 2: SSL support is pretty shaky. It's there, but quite possibly 
> not > fully working. The real problem is that Polymer cannot easily 
> figure > out a URL for message parts, and BURL servers cannot 
> handle them > anyway.
> 
> Dave, I don't think I understand this note.  What do URLs have to do
> with IMAP SSL support?

Yes, it's not an obvious issue, really.

<imap://dwd@turner.dave.cridland.net/INBOX;UIDVALIDITY=1173455933/;uid=48931> 
is a URI pointing to a message (yours, as it happens). BURL (possibly 
in concert with GENURLAUTH to provide pawn-ticket authorization) can 
take this URL and use it as part of the source for a message. Polymer 
can bookmark messages in ACAP by using the URI, too, and actuating 
that bookmark (possibly on another machine) would then connect to 
port 143 on turner, do the STARTTLS/AUTHENTICATE shuffle, and present 
the message. So far, so brilliant.

<imaps://dwd@turner.dave.cridland.net/INBOX;UIDVALIDITY=1173455933/;uid=48931> 
is what Polymer would generate if it was using old-style SSL on a 
different port. This is because for bookmarks, configuration, and 
other internal message relocations, this is what's needed. 
Unfortunately, this scheme is non-standard, and might not work for 
GENURLAUTH or BURL - although Polymer can normalize URIs to a degree, 
it can't know that port 143 is equivalent to port 993 except for SSL 
negotiation, and there's no chance at all of ascertaining the correct 
non-SSL port for an "imaps" service running on an arbitrary port, 
hence things break.

The general rules of thumb are:

1) If you are a mail provider offering SSL, offer STARTTLS too, and 
try to migrate your customers toward it. You are risking medium-term 
breakage which is not apparent yet, but almost certainly will be, 
especially for mobile email markets which are likely to be key to 
your survival in the longer term.

2) If you are a client developer, use STARTTLS wherever possible, and 
attempt to migrate users away from old-style SSL. STARTTLS support 
should be on by default and require no user-level configuration.

3) If you are a user, use SSL as a last resort for gaining 
encryption, and configure your client to use STARTTLS instead.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

