Auto configuration validation
Dan Schwartz
I've been reading a variety of wiki, bugzilla, group postings (both
here and in mozilla.dev.apps.thunderbird) regarding thunderbird
configuration and to say the least I'm confused. Here are some of the
wiki pages -
https://wiki.mozilla.org/Thunderbird:Autoconfiguration#Implementation
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:DNSBasedLookup
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:NextSteps
The first of these has a 5 step process to "autoconfig" which seems to
follow this structure -
1. Look for a local config file (packaged or bundled with TB,
customized by the ISP)
2. Look on the web for the config file (perhaps in a static location
(based on domain) or dynamic one pointed to via DNS records) which
could be a cgi that generates the config file using e-mail address as
input.
3. Look to a centralized mozilla.org hosted DB using e-mail address
as input.
4. Try to guess the config based on some pre-defined (and hopefully
well documented) rules.
5. Ask the user to manually config/confirm.
DNSBasedLookup defines some ideas about the structure of step 2 above.
NextSteps talks about a separate "Master Configuration Process" that
would be separate from TB? Perhaps web based? perhaps local? It
isn't clear to me how this would work. Is this similar to step 2
above?
Security concerns seem to revolve around getting back the correct
config (so people don't end up connecting to the wrong (evil) host/
server and sending them their credentials). Perhaps adding in a
verify screen after the autoconfig so that people can see the results
and correct/test the settings would be useful? Having a test that
sends and reads an email might be useful, since both need to be
checked and ports might need to be adjusted (particularly in the case
of step 4 with lots of TLS/SSL/STARTTLS options).
Would it be useful to present a URL to local help/documentation on the
verify screen? Perhaps if they aren't sure they could be directed to
read locally written instructions/contact info (which they hopefully
won't need or read).
Or are these ideas simply making it more complicated for the user?
When should it just fail and let them figure it out themselves?
Dan Schwartz
Jesse Thompson
I believe that the intent is to have the central server use the step 2
process to proxy information back to the client until the client is able
to perform step 2 independently. This also has the advantage that
Mozilla's servers would be less susceptible to DNS poisoning. But, it
has disadvantages as well, such as trust, local control, and privacy.
> Security concerns seem to revolve around getting back the correct
> config (so people don't end up connecting to the wrong (evil) host/
> server and sending them their credentials). Perhaps adding in a
> verify screen after the autoconfig so that people can see the results
> and correct/test the settings would be useful? Having a test that
> sends and reads an email might be useful, since both need to be
> checked and ports might need to be adjusted (particularly in the case
> of step 4 with lots of TLS/SSL/STARTTLS options).
Users won't know what the correct settings are unless they are reading
the ISP's documentation, which is exactly what this autoconfig process
is trying to avoid. This process can't succeed unless the settings are
guaranteed to be correct, which is why step 4 is futile and step 3 will
get out of hand quickly.
> Would it be useful to present a URL to local help/documentation on the
> verify screen? Perhaps if they aren't sure they could be directed to
> read locally written instructions/contact info (which they hopefully
> won't need or read).
As part of step 2? Yes, that's a good idea. There might be some manual
configuration steps that aren't covered by the autoconfiguration, such
as LDAP server and S/MIME configuration in our case.
> Or are these ideas simply making it more complicated for the user?
> When should it just fail and let them figure it out themselves?
Manual configuration is the status quo, so we should avoid making it
worse. Step 4 has lead to confusion with our users already. Step 3 has
good intentions, but most TB users won't be using a "large enough" email
provider to make use of this, and the admins of these email providers
are constantly wondering if unauthorized users are submitting
configurations to the database.
Jesse
>
> Dan Schwartz