Thunderbird/ISPDB/Requirements: Difference between revisions

Jump to navigation Jump to search

Thunderbird/ISPDB/Requirements (view source)

Revision as of 20:26, 11 November 2015

4,448 bytes removed ,  11 November 2015
redirect this page that was an extracted email infodump to the ISPDB for bouncing to MDN with rationale
(Created page with ' 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 st…')
 
(redirect this page that was an extracted email infodump to the ISPDB for bouncing to MDN with rationale)
 
Line 1: Line 1:
 
#REDIRECT [[Thunderbird/ISPDB]]
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.
Andrew Sutherland
Confirmed users
360

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1105247"

Navigation menu