A more formal process to add ISP information to the auto-configuration list

2 views
Skip to first unread message

Ludovic Hirlimann

unread,
May 28, 2009, 11:46:05 AM5/28/09
to
Hi,

I'm writing down the process to add/edit information regarding ISPs to
the list of ISP thunderbird will be able to access when creating a new
account using the auto configuration feature in TB3.

First draft as been posted at :
https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Process_to_edit_ISP_list

Please comment and discuss here I will update the wiki with your feedback.

I have a few question on which I would love to have your input :

* Shall we make a distinction between a ISP providing the data and
a user providing the data ?
* Domain Highjacking - how do we deal with that ?
* Who should initially get the rights to commit the information (1) ?
* How do we grant new users the power to do so ?(2)

(1) (2) Ideas are welcome here - I don't think we need to have many
people - but we should think about it now.


Ludovic
--
Ludovic Hirlimann MozillaMessaging QA lead
http://www.spreadthunderbird.com/aff/79/2

Ben Bucksch

unread,
May 28, 2009, 7:39:08 PM5/28/09
to
On 28.05.2009 17:46, Ludovic Hirlimann wrote:
> Please comment and discuss here I will update the wiki with your feedback.

I don't think we should have a bug for each addition/change. Esp. not in
the beginning. I'm expecting 100-1000 ISPs, and a bug causes at least 10
mails and even more steps, so that's up to 10000 steps.
Also, if only staff can change it, there's a clear bottleneck.

We were more thinking of a community approach, with a (very simple)
database.

1. Somebody submits a configuration. That could happen via a web form or
by a button the Account Manager in Thunderbird.
2. A script makes some basic checks: Does the domain of email address
and imap server match? In case of alternative domains (live.com,
live.de, live.fr), do the WHOIS records match, esp. DNS server? Does the
MX (incoming SMTP mail server) of the email address domain match the
imap server domain?
3. Those passing the script test could be put online directly, or after
minimal checks by a reviewer. Those failing the test could undergo more
scrutiny by a reviewer.
4. The record gets put live.


Ben Bucksch

unread,
May 28, 2009, 7:39:29 PM5/28/09
to
On 28.05.2009 17:46, Ludovic Hirlimann wrote:
> Please comment and discuss here I will update the wiki with your feedback.

I don't think we should have a bug for each addition/change. Esp. not in

Dennis Melentyev

unread,
May 29, 2009, 5:13:46 AM5/29/09
to

+1
I'd prefer to have a button in account setup dialog to "Report Settings".
Once settings done and checked to be working, one can report them to the
community by simple pressing the button. Without username/password and
other sensitive info, sure.

Even more, ISP support could do this themselves. Also, mozilla could
offer some kind of "Mozilla-friendly ISP" banner for such ISPs.

As a result, "Account settings" wizard could query community database
for the list of known ISP's in the region or worldwide.

/dennis

Mark Banner

unread,
May 29, 2009, 5:23:48 AM5/29/09
to
On 29/05/2009 00:39, Ben Bucksch wrote:
> On 28.05.2009 17:46, Ludovic Hirlimann wrote:
>> Please comment and discuss here I will update the wiki with your
>> feedback.
>
> I don't think we should have a bug for each addition/change. Esp. not in
> the beginning. I'm expecting 100-1000 ISPs, and a bug causes at least 10
> mails and even more steps, so that's up to 10000 steps.

Well the other option is not bugzilla, but some other processing system.
My guess is there's more lightweight systems about.

> Also, if only staff can change it, there's a clear bottleneck.

That could be true but I'd assert it would most likely only be for the
initial phase where this is opened up. Once we've got the initial set
through, I'd expect there to be a lowish level of changes from month to
month which would be easier for only a couple of people to handle.

I think its worth remembering Mozilla Messaging is providing the
service, if we allow an incorrect/fake set up, then someone could
disclose their details unintentionally and it'd be Mozilla Messaging
held accountable. That doesn't stop Mozilla Messaging having non-staff
aid the process or access to publish the results, but I'd there may be
agreements put in place or a final check by a Mozilla Messaging staff
member.

> 2. A script makes some basic checks: Does the domain of email address
> and imap server match? In case of alternative domains (live.com,
> live.de, live.fr), do the WHOIS records match, esp. DNS server? Does the
> MX (incoming SMTP mail server) of the email address domain match the
> imap server domain?
> 3. Those passing the script test could be put online directly, or after
> minimal checks by a reviewer. Those failing the test could undergo more
> scrutiny by a reviewer.

I'd be very concerned about this approach. With some basic knowledge, I
could quite easily set up something that would pass all the criteria of
the script, I probably wouldn't even have to set up much of a web page
if at all. Give it a name similar to someone else, and have it listed.
Then just wait for the account info to come in. This might not work that
well because of the fact we base it on email addresses, but it could
still happen if based on miss-typed addresses.

I think a script can aid a lot of the process, but I think there has to
be a human step somewhere in all cases.

Standard8

Nikolay Shopik

unread,
May 29, 2009, 5:28:17 AM5/29/09
to
On 29.05.2009 13:13, Dennis Melentyev wrote:
> I'd prefer to have a button in account setup dialog to "Report Settings".
Also we don't really need that in Thunderbird itself, instead write an
extension for that.

Ludovic Hirlimann

unread,
May 29, 2009, 8:16:35 AM5/29/09
to
On 5/29/09 1:39 AM, Ben Bucksch wrote:
> On 28.05.2009 17:46, Ludovic Hirlimann wrote:
>> Please comment and discuss here I will update the wiki with your
>> feedback.
>
> I don't think we should have a bug for each addition/change. Esp. not in
> the beginning. I'm expecting 100-1000 ISPs, and a bug causes at least 10
> mails and even more steps, so that's up to 10000 steps.

True - so the model I took on while writing this process is the one used
to add CA authorities to the mozilla security stack. And I'd rather have
good data then hurried data that needs chagning all the time. Using
Bugzilla gives us alos a good tracking and history tool.

> Also, if only staff can change it, there's a clear bottleneck.

So no the idea is not to only have staff do the change - just the final
change so it becomes usable for all production clients out there. We
want to use the nightly build to be able to check the configurations -
this does not need to be pushed by staff. As I said the fact that we
want staff to push to production is to ensure :
1) that mozillamessaging is responsible for the push to Thunderbird users
2) that in case of a dispute complains will go to mozillamessaging

> We were more thinking of a community approach, with a (very simple)
> database.
>
> 1. Somebody submits a configuration. That could happen via a web form or
> by a button the Account Manager in Thunderbird.

This would need to be written and debugged.

> 2. A script makes some basic checks: Does the domain of email address
> and imap server match? In case of alternative domains (live.com,
> live.de, live.fr), do the WHOIS records match, esp. DNS server? Does the
> MX (incoming SMTP mail server) of the email address domain match the
> imap server domain?

This would not work for hosted domains for instance.

> 3. Those passing the script test could be put online directly, or after
> minimal checks by a reviewer. Those failing the test could undergo more
> scrutiny by a reviewer.

How would you track that ?

> 4. The record gets put live.

see above.

Ben Bucksch

unread,
May 29, 2009, 6:37:36 PM5/29/09
to Mark Banner
On 29.05.2009 11:23, Mark Banner wrote:
>> 2. A script makes some basic checks: Does the domain of email address
>> and imap server match? In case of alternative domains (live.com,
>> live.de, live.fr), do the WHOIS records match, esp. DNS server? Does the
>> MX (incoming SMTP mail server) of the email address domain match the
>> imap server domain?
>> 3. Those passing the script test could be put online directly, or after
>> minimal checks by a reviewer. Those failing the test could undergo more
>> scrutiny by a reviewer.
>
> I'd be very concerned about this approach. With some basic knowledge,
> I could quite easily set up something that would pass all the criteria

How so?

You can't have imap.live.com (usually not even imap.fred.live.com).

If you manage to get you.com into the DB, and then try to make live.de
an alternative domain for you.com, live.de will have a different DNS
server than you.com, and the script will catch that. If you make the DNS
server the same as the one for live.de, then the DNS server won't have
records for your domain, and you can't do anything.

And these were just examples of checks we could make - if you come up
with a specific attack, we could find a check to counter it.

> might not work that well because of the fact we base it on email addresses

Yes. The system was intentionally crafted like that.

> I think a script can aid a lot of the process, but I think there has
> to be a human step somewhere in all cases.

What would a human reasonably add? If you get a config for racoon.co.es,
how can you verify that the config is correct? Wouldn't you essentially
go what I described above?

Only think I know would be a webpage (on the ISP's domain) that
describes the config - but that's not much more secure than above, esp.
given that the official descriptions are often in quite unofficial
locations, like forums, random FAQs, subdomains etc..

Ben Bucksch

unread,
May 29, 2009, 6:44:26 PM5/29/09
to Ludovic Hirlimann
On 29.05.2009 14:16, Ludovic Hirlimann wrote:
> This would need to be written and debugged.

Compared to the amount of work and spam 1000 bugzilla bugs cause, that's
small.

>> 2. A script makes some basic checks: Does the domain of email address
>> and imap server match? In case of alternative domains (live.com,
>> live.de, live.fr), do the WHOIS records match, esp. DNS server? Does the
>> MX (incoming SMTP mail server) of the email address domain match the
>> imap server domain?
>
> This would not work for hosted domains for instance.

Hosted domains (myname.com) are not covered by the ISP config DB. It's
specifically for ISPs, with - say - at minimum 10000 users, or 3000 TB
users.

The document said we need to find other tricks for hosted domains,
corporate servers etc.pp..

Hosted domains could also use the ISP config fetch (that is still
pending review, BTW).

>> 3. Those passing the script test could be put online directly, or after
>> minimal checks by a reviewer. Those failing the test could undergo more
>> scrutiny by a reviewer.
>
> How would you track that ?

Write a column in the DB.
I'd probably make a table for the config, and a column for "version",
and a column for "reviewed" (boolean) and "reviewedby". Delivered would
be the highest version with reviewed=true. Whatever works, but nothing
fancy.

Ben

Ben Bucksch

unread,
May 29, 2009, 6:45:29 PM5/29/09
to Nikolay Shopik
On 29.05.2009 11:28, Nikolay Shopik wrote:
> Also we don't really need that in Thunderbird itself, instead write an
> extension for that.

Yes. And it would be fairly easy to write, I think.

Mark Banner

unread,
May 30, 2009, 3:58:01 AM5/30/09
to
On 29/05/2009 23:37, Ben Bucksch wrote:
>> I'd be very concerned about this approach. With some basic knowledge,
>> I could quite easily set up something that would pass all the criteria
>
> How so?
>
> You can't have imap.live.com (usually not even imap.fred.live.com).
>
> If you manage to get you.com into the DB, and then try to make live.de
> an alternative domain for you.com, live.de will have a different DNS
> server than you.com, and the script will catch that. If you make the DNS
> server the same as the one for live.de, then the DNS server won't have
> records for your domain, and you can't do anything.

Ok, so then my speeling one would be an "easy" attack.


>
> And these were just examples of checks we could make - if you come up
> with a specific attack, we could find a check to counter it.

Spellings? I doubt you could script that easily.

>> I think a script can aid a lot of the process, but I think there has
>> to be a human step somewhere in all cases.
>
> What would a human reasonably add? If you get a config for racoon.co.es,
> how can you verify that the config is correct? Wouldn't you essentially
> go what I described above?

The human step can be to look at the website and check it looks valid -
check that this thing exists and its not just a set of dns records and
fake servers.

Standard8

Ben Bucksch

unread,
May 30, 2009, 3:31:21 PM5/30/09
to Mark Banner
On 30.05.2009 09:58, Mark Banner wrote:
> Ok, so then my speeling one would be an "easy" attack.

What do you mean? A user trying to configure fr...@yahooo.com ?

That attack would require you to own the domain yahooo.com, at which
point you're also "attacking" the webmail of yahoo, which yahoo
hopefully took care of. That's old-school domain grabbing, and we're not
more at risk than other places.

Spelling errors in the configure file would either not pass the script
or not work (you don't own the DNS server).

Ben

Ben Bucksch

unread,
May 30, 2009, 3:35:11 PM5/30/09
to Mark Banner
On 30.05.2009 09:58, Mark Banner wrote:
> Ok, so then my speeling one would be an "easy" attack.

What do you mean? A user trying to configure fr...@yahooo.com ?

That attack would require you to own the domain yahooo.com, at which
point you're also "attacking" the webmail of yahoo, which yahoo
hopefully took care of. That's old-school domain grabbing, and we're not
more at risk than other places.

Spelling errors in the configure file would either not pass the script
or not work (you don't own the DNS server).

> The human step can be to look at the website and check it looks valid

> - check that this thing exists and its not just a set of dns records
> and fake servers.

Problem is: "Looks valid" is vulnerable to old-style phishing. I can
mirror a whole ISP website on "customer.yahoo.com", if yahoo.com hands
our subdomains to customers, if you want to be picky.

Bottom line: I did the initial list of ISP configs, and did the
verifications, as diligently as I could. I noticed that most of this
could not only be done by a script, but probably more diligently and
thoroughly can a human would bother to.

Ben

Ben Bucksch

unread,
May 30, 2009, 3:35:56 PM5/30/09
to Mark Banner
On 30.05.2009 09:58, Mark Banner wrote:
> Ok, so then my speeling one would be an "easy" attack.

What do you mean? A user trying to configure fr...@yahooo.com ?

That attack would require you to own the domain yahooo.com, at which
point you're also "attacking" the webmail of yahoo, which yahoo
hopefully took care of. That's old-school domain grabbing, and we're not
more at risk than other places.

Or do you mean spelling errors in the configure file? They would either
not pass the script (considered attack) or not work (you don't own the
DNS server of the domain).

> The human step can be to look at the website and check it looks valid
> - check that this thing exists and its not just a set of dns records
> and fake servers.

Problem is: "Looks valid" is vulnerable to old-style phishing. I can

Ludovic Hirlimann

unread,
Jun 2, 2009, 5:47:19 AM6/2/09
to
On 5/30/09 9:35 PM, Ben Bucksch wrote:

> Bottom line: I did the initial list of ISP configs, and did the
> verifications, as diligently as I could. I noticed that most of this
> could not only be done by a script, but probably more diligently and
> thoroughly can a human would bother to.

If we go the script what do you propose when the script finds a false
positive ? would the config be added manually ? Would we modify the
script ? how would we track that this particular configuration did not
pass the script ?

ludo

Ludovic Hirlimann

unread,
Jun 3, 2009, 9:06:52 AM6/3/09
to
On 5/28/09 5:46 PM, Ludovic Hirlimann wrote:
> Hi,
>
> I'm writing down the process to add/edit information regarding ISPs to
> the list of ISP thunderbird will be able to access when creating a new
> account using the auto configuration feature in TB3.
>
> First draft as been posted at :
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Process_to_edit_ISP_list

Ok I've edited the wiki so we can start going on with adding data. As a
matter of getting things started in a timely manner we've choosen to
start with a known process and use bugzilla to do the initial work.

At a later stage we will add tools to automate the process.

I've added the use of bugzilla's status to track down what bugs should
or should not be taken care of. We've also thought that as
Mozillamessaging is responsible for the list the component to create
bugs in should be in Mozillamessaging product.

Once I get feedback on the process I'll start creating bugs for people
to use.

Ludo

Chris Hills

unread,
Jun 4, 2009, 5:34:27 AM6/4/09
to

Rather than maintaining a list, why not implement something along the
lines of jabber?

For example, using DNS SRV:-

_imaps-client._tcp.example.com. IN SRV 5 0 993 imaps.example.com.

My personal preference would be to use NAPTR in addition to SRV for the
service resolution, for example:-

example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" "" _imaps._tcp.example.com.

Chris Hills

unread,
Jun 4, 2009, 5:35:30 AM6/4/09
to
On 04/06/09 11:34, Chris Hills wrote:
> example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" "" _imaps._tcp.example.com.

Oops, should read:-

example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" "" _imaps-client._tcp.example.com.

Chris Hills

unread,
Jun 4, 2009, 5:38:41 AM6/4/09
to
On 04/06/09 11:35, Chris Hills wrote:
> Oops, should read:-
>
> example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" ""
> _imaps-client._tcp.example.com.

In hindsight, -client and -server are not appropriate here since imaps
connections are only between clients and servers, not servers and
servers, so in all the previous lines, "_imaps-client" can be replaced
by "_imaps".

Ludovic Hirlimann

unread,
Jun 4, 2009, 6:18:58 AM6/4/09
to
On 6/4/09 11:34 AM, Chris Hills wrote:
> On 28/05/09 17:46, Ludovic Hirlimann wrote:
[snip]

> Rather than maintaining a list, why not implement something along the
> lines of jabber?
>
> For example, using DNS SRV:-
>
> _imaps-client._tcp.example.com. IN SRV 5 0 993 imaps.example.com.
>
> My personal preference would be to use NAPTR in addition to SRV for the
> service resolution, for example:-
>
> example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" "" _imaps._tcp.example.com.

Because this is not doable with necko at the moment. So we would need to
extend/expand/rewrite the part of the mozilla code that deals with dns
... Maintaining a list seemed the best solution to bring easy
configuration to Thunderbird users.


Ludo

Eddy Nigg

unread,
Jun 4, 2009, 7:14:30 AM6/4/09
to
On 06/04/2009 01:18 PM, Ludovic Hirlimann:

>>
>> For example, using DNS SRV:-
>>
>> _imaps-client._tcp.example.com. IN SRV 5 0 993 imaps.example.com.
>>
>> My personal preference would be to use NAPTR in addition to SRV for the
>> service resolution, for example:-
>>
>> example.com. IN NAPTR 5 5 "s" "IMAPS+D2T" "" _imaps._tcp.example.com.
>
> Because this is not doable with necko at the moment. So we would need
> to extend/expand/rewrite the part of the mozilla code that deals with
> dns ... Maintaining a list seemed the best solution to bring easy
> configuration to Thunderbird users.
>

Which sucks big time and is discriminative, doesn't scale and doesn't
take the enterprise into account. Deployment for corporations is
apparently none of importance and unfortunately MM prefers to leave that
market to the competition. :S

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org

Eddy Nigg

unread,
Jun 4, 2009, 7:28:56 AM6/4/09
to
On 06/04/2009 01:18 PM, Ludovic Hirlimann:
> Because this is not doable with necko at the moment. So we would need
> to extend/expand/rewrite the part of the mozilla code that deals with
> dns ... Maintaining a list seemed the best solution to bring easy
> configuration to Thunderbird users.
>

BTW, what about the effort to write the code to parse the list and
everything else required for it? You don't know yet which effort you are
going to spend to maintain that list for the next years to come. And
they'll complain loudly and noisily when maintenance is lacking
attention. IMO certainly not a smart decision.

Mark Banner

unread,
Jun 4, 2009, 8:34:10 AM6/4/09
to
On 04/06/2009 12:14, Eddy Nigg wrote:
> On 06/04/2009 01:18 PM, Ludovic Hirlimann:
>> Because this is not doable with necko at the moment. So we would need
>> to extend/expand/rewrite the part of the mozilla code that deals with
>> dns ... Maintaining a list seemed the best solution to bring easy
>> configuration to Thunderbird users.
>>
>
> Which sucks big time and is discriminative, doesn't scale and doesn't
> take the enterprise into account. Deployment for corporations is
> apparently none of importance and unfortunately MM prefers to leave that
> market to the competition. :S

You're a little unclear, but I think you are saying that it sucks that
we're maintaining a list format on MoMo's server and corporations can't
use it?

Well corporations can quite easily run their own autoconfig server -
they can override the mailnews.auto_config_url location in their
deployed Thunderbird builds. I expect a lot of them would be doing
custom tweaks anyway, and the various methods of doing this aren't hard
to do at all.

Worst case they have to tell users what to type in, which is basically
what they have to do now unless they have written an extension or something.

Standard8

Ludovic Hirlimann

unread,
Jun 4, 2009, 12:00:58 PM6/4/09
to
On 6/4/09 2:34 PM, Mark Banner wrote:
> On 04/06/2009 12:14, Eddy Nigg wrote:
>> On 06/04/2009 01:18 PM, Ludovic Hirlimann:
>>> Because this is not doable with necko at the moment. So we would need
>>> to extend/expand/rewrite the part of the mozilla code that deals with
>>> dns ... Maintaining a list seemed the best solution to bring easy
>>> configuration to Thunderbird users.
>>>
>>
>> Which sucks big time and is discriminative, doesn't scale and doesn't
>> take the enterprise into account. Deployment for corporations is
>> apparently none of importance and unfortunately MM prefers to leave that
>> market to the competition. :S
>
> You're a little unclear, but I think you are saying that it sucks that
> we're maintaining a list format on MoMo's server and corporations can't
> use it?
>
> Well corporations can quite easily run their own autoconfig server -
> they can override the mailnews.auto_config_url location in their
> deployed Thunderbird builds. I expect a lot of them would be doing
> custom tweaks anyway, and the various methods of doing this aren't hard
> to do at all.

Might be worth documenting somwehere.

Eddy Nigg

unread,
Jun 4, 2009, 1:20:12 PM6/4/09
to
On 06/04/2009 03:34 PM, Mark Banner:

> You're a little unclear, but I think you are saying that it sucks that
> we're maintaining a list format on MoMo's server and corporations
> can't use it?

I don't like centralized lists if possible, certainly not with an
application like TB :-)

>
> Well corporations can quite easily run their own autoconfig server -
> they can override the mailnews.auto_config_url location in their
> deployed Thunderbird builds. I expect a lot of them would be doing
> custom tweaks anyway, and the various methods of doing this aren't
> hard to do at all.

OK, this seems to provide some relief indeed - even though overriding
the config isn't that easy yet on a large scale (as far as I know)

>
> Worst case they have to tell users what to type in, which is basically
> what they have to do now unless they have written an extension or
> something.

Yes, that's however not what we want, isn't it. Progress is :-)

Nikolay Shopik

unread,
Jun 5, 2009, 6:51:51 AM6/5/09
to Ludovic Hirlimann
https://developer.mozilla.org/en/MCD,_Mission_Control_Desktop_AKA_AutoConfig
Probably this what you are looking for, but its difficult to understand
it in first time. Probably its good idea to edit it to make some sub
articles so this doesn't look too scary as ONE long page.

Gervase Markham

unread,
Jun 8, 2009, 11:47:17 AM6/8/09
to
On 28/05/09 16:46, Ludovic Hirlimann wrote:
> I'm writing down the process to add/edit information regarding ISPs to
> the list of ISP thunderbird will be able to access when creating a new
> account using the auto configuration feature in TB3.
>
> First draft as been posted at :
> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Process_to_edit_ISP_list

Ludo,

How would this process fit with the current "community" process using
the Google spreadsheet? We've got a fairly large and detailed collection
of data there now...
http://spreadsheets.google.com/ccc?key=p49SW32nNYX0otkRc3UZUJA

Gerv

Ben Bucksch

unread,
Jun 8, 2009, 6:25:19 PM6/8/09
to Gervase Markham

I'd say that the spreadsheet data is to be processed (by whoever
processes the bugs) as if it were bug entries.
Any new ISPs (or corrections) submitted as bugs should also be put in
the spreadsheet.

The spreadsheet would be superceeded by the database that we should
later write.

Gervase Markham

unread,
Jun 9, 2009, 5:47:13 AM6/9/09
to
On 08/06/09 23:25, Ben Bucksch wrote:
> I'd say that the spreadsheet data is to be processed (by whoever
> processes the bugs) as if it were bug entries.
> Any new ISPs (or corrections) submitted as bugs should also be put in
> the spreadsheet.
>
> The spreadsheet would be superceeded by the database that we should
> later write.

So what value does the additional MoMo step add? I can see on the wiki
page that one of the possible problems is MoMo liability for bad data.
But if MoMo has no way of checking the correctness of the data, then it
doesn't help much to have an extra step.

These are the only possible methods I can see of MoMo doing extra checks:

1) By re-doing the research. But then why have submissions at all?
2) By logging in using a test account. But in many cases (everything
except public webmail), that would require contacting the ISP to set one
up - then you might as well ask them for the details directly.

So I guess I can't immediately see the added value of putting more
process on top of the spreadsheet.

Gerv

Ludovic Hirlimann

unread,
Jun 9, 2009, 6:18:32 AM6/9/09
to Ben Bucksch, Gervase Markham
On 6/9/09 12:25 AM, Ben Bucksch wrote:
> On 08.06.2009 17:47, Gervase Markham wrote:
>> On 28/05/09 16:46, Ludovic Hirlimann wrote:
>>> I'm writing down the process to add/edit information regarding ISPs to
>>> the list of ISP thunderbird will be able to access when creating a new
>>> account using the auto configuration feature in TB3.
>>>
>>> First draft as been posted at :
>>> https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Process_to_edit_ISP_list
>>>
>>
>> Ludo,
>>
>> How would this process fit with the current "community" process using
>> the Google spreadsheet? We've got a fairly large and detailed
>> collection of data there now...
>> http://spreadsheets.google.com/ccc?key=p49SW32nNYX0otkRc3UZUJA

Using bugzilla is by no mean meant to remove community involvement . One
of the goals is to enable easier tracing for US.

> I'd say that the spreadsheet data is to be processed (by whoever
> processes the bugs) as if it were bug entries.

I agree on that. At some point the spreadsheet needs to be changed to
read-only.
When this is done Spreasheet entries are converted to bugs (I might
volunteer to do that) and then we'll process them. If we keep both
process aside the spreadsheet and the bugs then it's going to become
unmaintainable. If you have a better idea on how to make the transition
I'm very interested.

> Any new ISPs (or corrections) submitted as bugs should also be put in
> the spreadsheet.
>
> The spreadsheet would be superceeded by the database that we should
> later write.

Agreed on that one. I have one issue with the spreadsheet at the moment
: I'm unable to know which of the entries have been processed so far ?

Ludovic

Gervase Markham

unread,
Jun 10, 2009, 4:37:37 AM6/10/09
to
On 09/06/09 11:18, Ludovic Hirlimann wrote:
> When this is done Spreasheet entries are converted to bugs (I might
> volunteer to do that) and then we'll process them. If we keep both
> process aside the spreadsheet and the bugs then it's going to become
> unmaintainable. If you have a better idea on how to make the transition
> I'm very interested.

See below.

>> Any new ISPs (or corrections) submitted as bugs should also be put in
>> the spreadsheet.
>>
>> The spreadsheet would be superceeded by the database that we should
>> later write.
>
> Agreed on that one. I have one issue with the spreadsheet at the moment
> : I'm unable to know which of the entries have been processed so far ?

Google spreadsheets have a change-tracking function. (Go to "Revision
History" on the File menu.) So all you need to do is remember/store the
date of the revision you've processed. Then at a later date you can step
through the revisions between that one and the current one see what's
new. Or, you could export to ODF and use ODF's document-diffing function.

This is why I don't think it's worth having a Bugzilla process. The
spreadsheet can do all that's required.

Gerv

Dennis Melentyev

unread,
Jun 10, 2009, 3:57:34 PM6/10/09
to Gervase Markham
On 06/09/2009 12:47 PM, Gervase Markham wrote:
> On 08/06/09 23:25, Ben Bucksch wrote:
>> I'd say that the spreadsheet data is to be processed (by whoever
>> processes the bugs) as if it were bug entries.
>> Any new ISPs (or corrections) submitted as bugs should also be put in
>> the spreadsheet.
>>
>> The spreadsheet would be superceeded by the database that we should
>> later write.
>
> So what value does the additional MoMo step add? I can see on the wiki
> page that one of the possible problems is MoMo liability for bad data.
> But if MoMo has no way of checking the correctness of the data, then it
> doesn't help much to have an extra step.
>
> These are the only possible methods I can see of MoMo doing extra checks:
>
> 1) By re-doing the research. But then why have submissions at all?
> 2) By logging in using a test account. But in many cases (everything
> except public webmail), that would require contacting the ISP to set one
> up - then you might as well ask them for the details directly.

Why don't propose ISP's to advertise themselves for free as
Mozilla-friendly in response to providing pre-set settings (including
Firefox Proxy settings, Thunderbird e-mail/news, planned
maintainance/downtime calendars, download mirrors for their users, you
name it).

So, Mozilla provides some icons/banners to put on ISP pages and put some
download numbers, ratings, whatever on official Mozilla site.

IMHO - win-win. Would it be really interesting business-wide? No idea.
I'm not e-salesman. Ask your PR/Marketing people. They are.

Ludovic Hirlimann

unread,
Jun 11, 2009, 8:52:25 AM6/11/09
to
On 6/10/09 10:37 AM, Gervase Markham wrote:
>
> Google spreadsheets have a change-tracking function. (Go to "Revision
> History" on the File menu.) So all you need to do is remember/store the
> date of the revision you've processed. Then at a later date you can step
> through the revisions between that one and the current one see what's
> new. Or, you could export to ODF and use ODF's document-diffing function.
>
> This is why I don't think it's worth having a Bugzilla process. The
> spreadsheet can do all that's required.

I had failed to notice that :

* You own the spreadsheet
* You can receive notifications of changes (like bugzilla would do).
* We can probably track state with colors or by adding a column.

I have an issue with the following setting "People can edit this item
without signing in." , but we could change it to something else.

The other issue I have is what happens to the document the day Gerv
disappears from the Mozilla ecosystem ?

Andreas Nilsson

unread,
Jun 11, 2009, 9:24:07 AM6/11/09
to dev-apps-t...@lists.mozilla.org
On 06/11/2009 02:52 PM, Ludovic Hirlimann wrote:
> On 6/10/09 10:37 AM, Gervase Markham wrote:
>>
>> Google spreadsheets have a change-tracking function. (Go to "Revision
>> History" on the File menu.) So all you need to do is remember/store the
>> date of the revision you've processed. Then at a later date you can step
>> through the revisions between that one and the current one see what's
>> new. Or, you could export to ODF and use ODF's document-diffing
>> function.
>>
>> This is why I don't think it's worth having a Bugzilla process. The
>> spreadsheet can do all that's required.
>
> I had failed to notice that :
>
> * You own the spreadsheet
> * You can receive notifications of changes (like bugzilla would do).
> * We can probably track state with colors or by adding a column.
>
> I have an issue with the following setting "People can edit this item
> without signing in." , but we could change it to something else.
Something I would like to see, regardless of process, is a easy way to
track something like "All ISP's in Sweden".
I would like to involve the Swedish Mozilla Community in this and the
sooner we can reach a decision, the better.
- Andreas

Magnus Melin

unread,
Jun 11, 2009, 1:07:21 PM6/11/09
to

It doesn't sound very feasible to me for MoMO to really check all submissions,
language barriers being just one part of it.

Also, re legal responsibilities, if MoMO really does pre-approve submitted
configs that liability might go up... (IANAL)

-Magnus

Reply all
Reply to author
Forward
0 new messages