ISPDB configs without STARTTLS and/or SSL

Ben Bucksch ben.bucksch at
Sat Jan 19 16:47:25 UTC 2013

(I re-ordered the quotes to make my post more logical.)

On 19.01.2013 16:49, Andrew Sutherland wrote:
> On 01/19/2013 10:10 AM, Ben Bucksch wrote:
>> However, without supporting plain (non-SSL) connections, you are 
>> going to miss a huge amount of configs. Ditto with POP3.
> I think there remains a strong case for user privacy that we should 
> not facilitate the use of unencrypted e-mail connections at all.  A 
> similar, if less strong, case can be made for requiring valid SSL 
> certificates.

Agreed. But I think the approach Thunderbird takes is correct: Strongly 
warn the user, even scare him, but allow him to use it.

> I expect to also use it as a basis if we need to revisit whether or 
> not to allocate resources to supporting POP3.

Ah, good, I thought it was technically impossible (local storage). It 
would make a difference, POP3 is still significant, as you can see from 
the list. Some of the POP3-only ISPs are huge.

> And there are free SSL certificates available from StartCom and maybe 
> others.

Yeah, there's no excuse for bad certs (at big ISPs).

> I am entirely on-board that if we can know with near-certainty that we 
> don't support something and believe that the information is still 
> correct, that we should say it.

Known unsupported:
Good. Please note that "we know the provider, and it only has non-SSL 
configs" is different from "we don't know this domain at all".
We know configs for about 40-50% of the accounts - that is with the MX 
lookup that Thunderbird implements. The remaining 50% are the long tail: 
ISPs and small servers with < 1% market share. These you do need to send 
to guess config (which I think catches a lot) or, failing that, manual 

If you find the domain, and you don't find a usable config, then there's 
a 90+% chance that this domain won't work even with manual efforts. So 
you can just as well tell the user that (and still allow user override, 
in case we're really getting it wrong). The wording for "config found, 
but not supported" should be very different from "no config at all 
found", though, and make it clear that it's fairly useless for the user 
to make manual attempts.


Choice of mail providers:

> There are free alternatives like gmail that are known to be, at the 
> very least, competent.

There are other serious disadvantages with GMail. They do read your 
mail, after all, and use that information in other Google services. And 
when 20% of the world's human-human communication happens via a single 
provider, that gives them a lot of power, and I think we should do 
everything to limit further expansion of such a centralization, not add 
to it.

> I personally am of the mind that people should switch e-mail providers 
> in that case as well, but that's not the decision-making process :)

This will cause users lots of work. They need to tell all their 
contacts, they will miss out on email in the migration process, etc.pp. 
Don't drive users into this, please. That's everything but smooth.

If you drive them to another mail provider, implicitly or explicitly, 
then it should:
* be a specific one that we know is good - in terms of tech, reliability 
and privacy and other values.
* give them their own domain, so that they are never again locked to a 
certain provider

> The list is greatly appreciated!  Thank you!



More information about the tb-planning mailing list