ISPDB configs without STARTTLS and/or SSL
ben.bucksch at beonex.com
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
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
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.
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
> 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
> The list is greatly appreciated! Thank you!
More information about the tb-planning