Potential expansion of ISPDB scope for Gaia Email app invalid/self-signed certificate issues

Andrew Sutherland asutherland at asutherland.org
Tue Jun 3 17:00:20 UTC 2014


On 06/03/2014 04:04 AM, Ludovic Hirlimann wrote:
> How do you deal with "hosted" configs as per
> https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration#Small_company
> ? we probably don't want to scan all available domains to figure this
> ou, or is this the goal ?

The following quote from near the end of my message is meant to cover 
this: "While we would still allow ISPs to override the ISPDB by hosting 
an autoconfig file at one of two locations, these requests would only be 
made against https:// servers and would be made in parallel with the 
ISPDB request as well as our ActiveSync AutoDiscover probes.  A valid 
ISPDB result for a server may hasten any timeouts against the parallel 
requests to avoid problems we've seen with blackholed 
autoconfig/autodiscover attempts.  A hint in ISPDB that we should wait 
around for the autoconfig server might be something we eventually do if 
slow servers turn out to be a problem."

To restate, the client would still check:
* 
https://autoconfig.xampl.tld/mail/config-v1.1.xml?emailaddress=user%40xampl.tld
* 
https://xampl.tld/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=user%40xampl.tld

With the notable change that these are currently http, not https. These 
would also be checked in parallel with the ISPDB; currently we wouldn't 
check the ISPDB if we found a valid autoconfig at the given locations.  
The rationale for this change is that there has been no large-scale 
uptake/adoption of our autoconfig mechanism and we expect it to take 
longer / be more likely to blackhole/timeout when we perform the https 
access, so the expected outcome is hitting the ISP database anyways.  
The change from a user perspective from this change beside reduced 
latency is that in hosted config situations the mail domain the user is 
using will still be conveyed to the Mozilla server where we may use the 
information in aggregate to know what servers are in use for autoconfig 
coverage or other feature support/bug triage decisions.

Andrew



More information about the tb-planning mailing list