[Dev] IMAP and SMTP accounts defined in external parcel

[RL 'Bob' Morgan]

> [1] In the case we're calling "SSL", the client connects to the SMTP/IMAP 
> server (usually on port 465 for SMTP, 993 for IMAP), and immediately starts 
> an SSL handshake.
>
> [2] For "TLS", the client starts a normal SMTP/IMAP connection on the 
> standard port, queries the server as to whether it supports SSL, and then 
> begins an SSL handshake if it does.

Right, via the STARTTLS command.  Several protocols use this same pattern, 
including SMTP, POP, IMAP, LDAP, BEEP, and others.  There is a reason for 
this, more below.

> FWIW, the thing people think of as "SSL" comes in four different 
> versions. In the fourth of these, it was decided that "Transport Layer 
> Security" was a more accurate term than "Secure Sockets Layer". So, in a 
> way, TLS version 1 == SSL version 4.

Actually it's literally SSL version 3.1, if you look at the numbers in the 
protocol message.  SSL was developed by Netscape on its own.  When an IETF 
working group was formed to make this technology an IETF standard, the 
name TLS was chosen as a neutral term since Microsoft at the time was 
promoting a SSL alternative, which was later abandoned.  In retrospect 
they should have just stuck with the SSL name since everyone knows what it 
means (more or less).

> Also, in general, the IETF is trying to get people to move away from 
> option [1] above, in favour of [2].

That is understating the point.  For all protocols for which STARTTLS is 
defined there is no standards status for the separate-port approach; that 
is, there is no RFC that mentions it.  So to be standards-compliant an 
implementation has to support the STARTTLS approach.  Implementations can 
support the separate-port approach if they want to (and of course most 
do), but it's outside of any standard (though of course for most protocols 
the foo-over-SSL port remains allocated).  For SMTP there was a particular 
push to deprecate the separate-port approach because there were legitimate 
concerns that it could destabilize Internet email if MTAs didn't know 
which ports service was being offered on and had to depend on resets and 
timeouts to figure it out.

> At the very least, it makes writing smarter, self-configuring clients 
> easier.

Let me stress this point, since it is often misunderstood (for example 
Thunderbird is still entirely screwed up in this regard).  The 
separate-port-for-SSL approach probably was necessary in the case of HTTP 
to get SSL adopted, but it is really a terrible approach to adding 
security to a protocol.  The key with making optional features work in 
general is to permit their use to be negotiated, which is what the 
combination of CAPABILITY and STARTTLS do for TLS.  Without the ability to 
negotiate, the use of SSL/TLS has to be explicitly selected by the user 
(theoretically clients could try probing ports by default but that just 
seems like a bad idea).  So with the separate-port approach, the default 
is no SSL, and if you want SSL the user has to go into a mysterious config 
screen and check a scary box.  Sites are reluctant to force users to do 
this, for fear of support costs, so they just run without SSL and suffer 
stolen passwords.  This sucks.

With STARTTLS, a site like ours that wants to protect people's passwords 
can set our IMAP servers to advertise TLS and require that it be 
negotiated by a client in order to log in (or they can use 
SASL/GSS/Kerberos, but that's another story).  A client that has been 
thoughtfully designed will be set to use TLS if it is offered by the 
server.  This way the client will work just fine, securely, with our site 
*without the user having to configure it*.  And it will still work fine 
with plain old sites that just use cleartext.  So everybody wins.  But 
note this means that the client has to ship with "use TLS if offered" as a 
default.  It is sometimes argued that client providers don't want to do 
this because it can mean users will see funny SSL error messages (can't 
validate cert etc) if a server supports STARTTLS but hasn't set it up 
right.  But it seems profundly wrong to me that such misconfigured sites 
should cause the default to be set wrong for all the rest of us.

This is kind of a pet issue of mine.

  - RL "Bob"