Thunderbird/ISPDB/Requirements
David Ascher
ISPDB will evolve a lot, I'm sure. For example, the idea of ISPs like Rick's being able to feed data into it is a fascinating one, but I think we should start with baby steps.
Here are the first few steps as I see them:
Stage 0: what we have now -- we serve a set of static XML files at a well known URL, that Thunderbird's autoconfig dialog can poke at, indexed by domain. That's all we need to ship Thunderbird 3.
Stage 1: we push out the django app which we've been talking about mostly, so that we have a minimal, biased-towards-secure, simple-but-safe process for soliciting new configurations and validating them.
The Django app that is currently in draft form has the following design criteria:
- it's easy for people to submit data (requiring some sort of login
-- currently openid, cause it's simple and means we don't need to store emails or passwords)
- only trusted people can label user-submitted data as "verified"
- verified data can be exported into the XML format that Thunderbird
expects.
- publishing of those XML files will be done by a (at first) manual
process of exporting to disk, and svn checkin into the repo that's serving the static files, so that we have another review of data changes before they go live.
End of Stage 1 is defined by: ispdb is live, and we actively solicit input from the greater Mozilla community about settings for their ISPs.
Stages 2
- we get feedback based on stage 1 being live - we analyze the logs from the autoconfig HTTP GET calls to find out
what domains people are asking for, so we can proactively look for configuration information for those domains
- we automate the export from the django app to svn - we put in some process for revocation
later:
- we build in some karma notions, so we can reward good
contributors/reviewers.
- we increase the scope of ISPs we target (e.g. Exchange servers?) - we increase the scope of kinds of data we publish (more than email?)
even later:
- we internationalize the site - we actually serve from django directly (with a suitable caching
proxy in front)
I'd strongly encourage that we focus on what's needed to get to Stage 1, so that we have something to do Stage 2 with =). To that end, here are some of the things I suspect we need to have in place, and some ideas as to who could do what.
- a test suite, so we feel more confidence in changing code. In
particular, I think it's critical that we test the code that does "import from XML -> export to XML", and makes sure that that is not lossy =). [students]
- more testing from people acting as users, and acting as reviewers,
to expose issues in the user experience of both of those scenarios. [students, everyone]
- a feature that given an ISP configuration, does some sanity
checking, to try and avoid security issues -- check that hostnames are subdomains of the email domain in question, sanity check against known bad actors somehow.
- publish documentation on the rules that we're following to approve a
configuration. My current draft is something like:
- configuration information is available on a public web page that
is clearly affiliated with the main owner of the domain (not on some bboard or newsgroup).
- said configuration information is in a language that one of the
trusted people speaks
- passes sanity-check enforced by the backend.
- some scripts for gozer to test the exporting / checkin / publishing
phase. [gozer?]
- until we have some more confidence in the data, I'd suggest that we
do daily backups of the sqlite DB, to go along w/ our changes to the code [gozer].
- we probably want some better looking graphics, but that can be late
in the process. [rebron]
- we probably want some editorial review of the words on the page. [??]
- we want a clear deployment plan, with the /admin URL probably
behind a MoMo certificate, which we can issue to any trusted person. [gozer]
I think stage 1 is doable in a small number of weeks, because I think what we have isn't a very complicated system. If there are things that strike people as complicated, _please_ point them out, I'm completely happy to revise the requirements to make it less complicated.
Feedback, questions?
--david
PS: ISPDB is woefully underdocumented. If someone wanted to start authoring some wiki pages that collects some of the various bits of writing (such as this one) on it, feel free.