Where I think we are...

Skip to first unread message

David Ascher

Nov 26, 2009, 1:23:38 PM11/26/09
to ISP Configuration Database
An update on where we stand, and what I think are some of the big next

0) We have a bunch of good work going on closing release blockers.
Thanks everyone!

1) we have some work that Rob Mueller is taking a first stab at to
implement a web service that given a domain, does a DNS MX record
lookup, and returns a configuration, if the ISP for that domain has done
the right setup. The tracking bug is 527802. Rob, can you put up your
first cut at the code on that bug, along w/ a description of what it does?

2) We should do a similar domain query service for google apps for your
domain. The test there is a little gross, but at least it's simple.
Given a domain foo.com, look at google.com/a/foo.com. If the page
you're redirected to has a Username/Password form, return a suitably
tweaked config for the google apps configuration. Otherwise, the domain
isn't hosted by GoogleAppsForYourDomain. It'd be good if there was a
more real API for that, but I don't think there is. I don't have a bug
filed for that yet, I figured I'd wait until we got agreement on this
whole scheme first.

3) ISPDB has so far known only about the domains authored through it (or
imported through it). We should teach ISPDB to query the above two
services, so that when people submit a domain, we can tell them if it's
already covered by these 'automated' configuration lookup systems'.

4) the autoconfig endpoint that thunderbird talks to should use this

- call the service in 1), and if we get a configuration back, return
it, be done.
- if not, call the service in 2), and if we get a configuration back,
return it, be done.
- if not, look on disk, and if we get a configuration back, return it,
be done.

4.5) Only the endpoint in 4) needs to be net-available. Except for
testing purposes, it seems to me that we want the endpoints 1), 2) and
3) to be "implementation details" that we don't want Thunderbird or
anyone else to look at, so we can change their semantics easily.

5) At some point we can consider making ISPDB be a service #3 that
returns configurations for approved domains.

6) We still have a few blockers on ISPDB, including a nasty security bug =).

7) We have some submissions of autoconfig files from Kohei (MoCo Japan),
which would be good to include in the live DB soon if we can. That
would likely cover most ISPs in Japan!

8) Blake is working on a 'sanity check' endpoint to the Django webapp
which can be used to sanity check a configuration (both inside ispdb and
by other scripts as necessary

9) Blake has a patch to ispdb which would make it be usable by ISPDB
reviewers with a pref-tweaked version of Thunderbird so that they can
check that a config as entered works (although I suspect to really test
we'd need username/password pairs, no?)

10) At some point we should add a version number scheme to:

- autoconfig files as served by the public endpoint (4), so that
future Thunderbirds can know which schema to use. The endpoint probably
wants to be versioned itself, so that TB3 can always use the current
schema, and 3.1 can use a different schema.

- we should probably version the data that's sent back by ISPs
through DNS records. At this point we have one ESP committing to
publish that data. We should be able to rev that spec w/o everyone
having to jump at once.

Does the above sound about right?

Gozer, you said you wanted an 'aggregator' endpoint for these services.
In the case of 1) and 2) we can't do something that spans all existing
domains, only all domains that we happen to know already. Why do we
want this?


caméléon Vincent

Dec 29, 2011, 9:15:20 AM12/29/11
to is...@googlegroups.com
Hi David,

I would be very curious to know where we are now, 2 years after your post.
Autoconfiguration is great but the update of the configuration file seems to be quite difficult, from my own experience after I had recently submit updates at:
Reply all
Reply to author
0 new messages