Objective: Make my non-tech friends use Thunderbird, by making it dead-simple to set up.
Most people are using webmail these days, mainly because it's so easy. You only need to know the URL (usually linked from the provider's homepage) and email address and password, and there's your inbox already. ISPs, although all of them provide POP/IMAP, are leading users to webmail because of that ease of use (and free mail providers do so for the advertizing revenue).
Goal: Setting up Thunderbird should be as easy as download/install and entering real name, email address and password. The Account Setup Wizard consists of only one screen.
Proposal: In the Account Setup wizard, if the "Email account" radio button is selected (which is the default), 3 text fields are visible and enabled: real name, email address and password.
Email address is properly syntax-checked, and the existance of the domain in DNS is checked.
The domain if the email address is used to determine the configuration (POP/IMAP and SMTP server names, SSL yes/no, authentication methods etc.), via several mechanisms:
1. The legacy rdf files in <installdir>/isp/, like we have for Google Mail right now. (This may be dropped.) 2. Try to contact a mail configuration server of the provider, e.g. define an DNS TXT record or similar on domain example.net (for my.acco...@example.net) which contains an URL like https://mailconfig.example.net/mozilla.xml . That file contains the mail configuration, essentially the same as in RDF files, just the format a bit cleaned up. The email address (before @ or with domain) that the user can be used as placeholder in the config file, so the file is the same for all users (i.e. static). The protocol should be https (otherwise a MITM can direct my traffic and login request to him by just telling me his server as config). 3. If the email provider does not provide the configuration, we try to find it at mozillamessaging.com, e.g. https://autoconfig.mozillamessaging.com/example.net/config.xml . This service will have the configuration for all the major ISPs and email providers, so there's a 90+% hit rate. It will not work for company email addresses. If a provider disagrees with a setting there, it can override the configuration by simply providing the config server in step 2. 4. Other ways, esp. for company email accounts? Avoid heuristics! 5. If all fails, we ask the user to enter the configuration, using the existing wizard. We should also provide an option to ignore the autoconfig and go into manual config, e.g. using a new radio button "Email account, manual configuration".
Unless we go into manual config, the "Next" button turns into "Done", on the first page already. In that case, there is no second page, not even the summary screen. The user ends up directly in his inbox. (The password dialog does not need to come up either, as the password has already been entered by the user and the wizard filled it in using the password manager.)
-- When responding via mail, please remove the ".news" from the email address.
> Objective: Make my non-tech friends use Thunderbird, by making it > dead-simple to set up.
+1
> 1. The legacy rdf files in <installdir>/isp/, like we have for Google > Mail right now. (This may be dropped.)
Should be dropped in this scenario, IMO.
> 2. Try to contact a mail configuration server of the provider, e.g. > define an DNS TXT record or similar on domain example.net (for > my.acco...@example.net) which contains an URL like > https://mailconfig.example.net/mozilla.xml .
If we'd use a unique extension for the RDF file (something like .mrdf, we could also try to trigger the account setup if clicked on)?
> The protocol should be https (otherwise a MITM can direct my > traffic and login request to him by just telling me his server as > config).
This is a MUST not SHOULD...IMO.
> Unless we go into manual config, the "Next" button turns into "Done", on > the first page already. In that case, there is no second page, not even > the summary screen. The user ends up directly in his inbox. (The > password dialog does not need to come up either, as the password has > already been entered by the user and the wizard filled it in using the > password manager.)
There might be a need to let the user select different server types if the ISP offers them, like POP3, IMAP and it's secured equivalents.
I just wanted to note that I'm in the process of changing the ISP rdf files from rdf to json. That doesn't alter much of the logistics of this proposal, more just a technical correction though. See bug 418693.
-Joey
On Tue, Mar 4, 2008 at 1:07 AM, Ben Bucksch <ben.bucksch.n...@beonex.com> wrote:
> Objective: Make my non-tech friends use Thunderbird, by making it > dead-simple to set up.
> Most people are using webmail these days, mainly because it's so easy. > You only need to know the URL (usually linked from the provider's > homepage) and email address and password, and there's your inbox > already. ISPs, although all of them provide POP/IMAP, are leading users > to webmail because of that ease of use (and free mail providers do so > for the advertizing revenue).
> Goal: Setting up Thunderbird should be as easy as download/install and > entering real name, email address and password. The Account Setup Wizard > consists of only one screen.
> Proposal: > In the Account Setup wizard, if the "Email account" radio button is > selected (which is the default), 3 text fields are visible and enabled: > real name, email address and password.
> Email address is properly syntax-checked, and the existance of the > domain in DNS is checked.
> The domain if the email address is used to determine the configuration > (POP/IMAP and SMTP server names, SSL yes/no, authentication methods > etc.), via several mechanisms:
> 1. The legacy rdf files in <installdir>/isp/, like we have for Google > Mail right now. (This may be dropped.) > 2. Try to contact a mail configuration server of the provider, e.g. > define an DNS TXT record or similar on domain example.net (for > my.acco...@example.net) which contains an URL like > https://mailconfig.example.net/mozilla.xml . > That file contains the mail configuration, essentially the same as > in RDF files, just the format a bit cleaned up. The email address > (before @ or with domain) that the user can be used as placeholder > in the config file, so the file is the same for all users (i.e. > static). > The protocol should be https (otherwise a MITM can direct my > traffic and login request to him by just telling me his server as > config). > 3. If the email provider does not provide the configuration, we try > to find it at mozillamessaging.com, e.g. > https://autoconfig.mozillamessaging.com/example.net/config.xml . > This service will have the configuration for all the major ISPs > and email providers, so there's a 90+% hit rate. > It will not work for company email addresses. > If a provider disagrees with a setting there, it can override the > configuration by simply providing the config server in step 2. > 4. Other ways, esp. for company email accounts? Avoid heuristics! > 5. If all fails, we ask the user to enter the configuration, using > the existing wizard. We should also provide an option to ignore > the autoconfig and go into manual config, e.g. using a new radio > button "Email account, manual configuration".
> Unless we go into manual config, the "Next" button turns into "Done", on > the first page already. In that case, there is no second page, not even > the summary screen. The user ends up directly in his inbox. (The > password dialog does not need to come up either, as the password has > already been entered by the user and the wizard filled it in using the > password manager.)
> -- > When responding via mail, please remove the ".news" from the email > address.
> Objective: Make my non-tech friends use Thunderbird, by making it > dead-simple to set up.
> Goal: Setting up Thunderbird should be as easy as download/install and > entering real name, email address and password. The Account Setup Wizard > consists of only one screen.
> Proposal: > In the Account Setup wizard, if the "Email account" radio button is > selected (which is the default), 3 text fields are visible and enabled: > real name, email address and password.
> Email address is properly syntax-checked, and the existance of the > domain in DNS is checked.
> The domain if the email address is used to determine the configuration > (POP/IMAP and SMTP server names, SSL yes/no, authentication methods > etc.),
Good idea. I proposed another possibility iyesterday in another thread:
The pre-configured list could either be hard-coded into the current Thunderbird release (requires no internet connection but is not up-to-date), or it could be downloaded from a server (requires internet connection but is up-to-date). Perhaps the list could also auto-filter on whatever locale the OS reports (e.g., German users get only German ISPs plus the major international ISPs).
PS. I'm not sure if the suddenly appearing fields and thereby vertically shifting radio buttons would be a source of confusion/distraction to the inexperienced user. -- Regards,
Perhaps the auto-detect filled could start auto-detecting when it detects that the e-mail address field has data in it. Either by pinging the e-mail field every second (or so) or if the user "exits" the e-mail field.
Ben Bucksch wrote: > Objective: Make my non-tech friends use Thunderbird, by making it > dead-simple to set up.
Ooh.
> Proposal: > In the Account Setup wizard, if the "Email account" radio button is > selected (which is the default), 3 text fields are visible and enabled: > real name, email address and password.
I feel a bit wary about asking for and using a password without running the server details past the user first.
> Unless we go into manual config, the "Next" button turns into "Done", on > the first page already. In that case, there is no second page, not even > the summary screen. The user ends up directly in his inbox. (The > password dialog does not need to come up either, as the password has > already been entered by the user and the wizard filled it in using the > password manager.)
I think skipping to the summary screen would be more appropriate, and allowing the user to go back and customize stuff from there if they want to, so "advanced" users can do their personal weird thing while getting the benefits of the autoconfig. I suppose skipping wizard pages that might be of interest would require showing what pages exist... there's probably a better way to do that flow but that's details :)
(Just pre-filling would be helpful, but wouldn't go that far in dispelling the "this is complicated" and avoiding preventable user errors even if it's just next next next finish.)
> I just wanted to note that I'm in the process of changing the ISP rdf files > from rdf to json. That doesn't alter much of the logistics of this > proposal, more just a technical correction though. See bug 418693.
Thanks for the hint.
I see the desire to get rid of RDF, but I chose XML intentionally, because it's a clear description format, and easy and safe to process. With JSON, you need to start to either parse it manually or it gets dangerous with security (even when you try to run it unprivileged) when it's loaded from the network. Also, last but not least, the configuration files in my proposal should be usable by other email clients as well and not be specific to Thunderbird. Although it's possible to parse JSON with other languages, I think XML is a more accepted general data format than JSON, and would have a higher chance of being adopted by other clients.
My ideal is to get rid of the current rdf files entirely. The shipping google.rdf would be replaced by the website service. We could include a step to try to get the XML config file (same format as from the net) from the harddisk. Then, companies deploying Thunderbird would have the option of either putting the config on a server and modify their DNS, or to include the config file in their own Thunderbird distribution.
The concrete format for the XML file would probably be very close to the current RDF files, just the namespace and element names some nesting cleaned up to remove the Mozilla-specific parts. Most of the current nesting/structure seems reasonable to me, though.
> Ben Bucksch on 04.03.2008 07:07 wrote: >> Objective: Make my non-tech friends use Thunderbird, by making it >> dead-simple to set up.
>> Goal: Setting up Thunderbird should be as easy as download/install >> and entering real name, email address and password. The Account Setup >> Wizard consists of only one screen.
>> Proposal: >> In the Account Setup wizard, if the "Email account" radio button is >> selected (which is the default), 3 text fields are visible and >> enabled: real name, email address and password.
>> Email address is properly syntax-checked, and the existance of the >> domain in DNS is checked.
>> The domain if the email address is used to determine the >> configuration (POP/IMAP and SMTP server names, SSL yes/no, >> authentication methods etc.),
> Good idea. I proposed another possibility iyesterday in another thread:
> The pre-configured list could either be hard-coded into the current > Thunderbird release (requires no internet connection but is not > up-to-date), or it could be downloaded from a server (requires > internet connection but is up-to-date). Perhaps the list could also > auto-filter on whatever locale the OS reports (e.g., German users get > only German ISPs plus the major international ISPs).
The idea is to make things very simple... The more options there are, the more scared people are. The "preconfigured" option is not needed, this is already automatically used in my proposal. The provider is selected based on the domain of the email address.
where "Email account, manual configuration" does exactly what "Email account" does today, while the new "Email account" is the automatic setup, using the logic I posted, using the preconfigured providers, the provider's config file on the net, or the mozilla config web service. The current "Google mail" option goes away and is used automatically when the user enters hisn...@gmail.com or googlemail.com/de in automatic setup option.
I don't like that there are two top-level radio buttons for e-mail. Also, there is no visual indication if the auto-detect was successful (or if it is even doing anything). That is why I suggest a morph between your current dialog and mine:
That would show all info in *one dialog* (user feels less "lost") (which I think is a big improvement), but would cause the radio buttons to "jump" vertically, depending on the selection. In any case, the height of the dialog should *never* change. What ya think?
PS. Should required entries be somehow marked? -- Regards,
Joey Minta wrote: > I just wanted to note that I'm in the process of changing the ISP rdf files > from rdf to json. That doesn't alter much of the logistics of this > proposal, more just a technical correction though. See bug 418693.
It's sort of ironic that while Mozilla seems to have adopted the "we hate RDF" philosophy, down the street at SRI a major, well-funded RDF-based initiative has adapted the mozilla mailnews and browser into OpenIris for an integrated desktop.
>> I just wanted to note that I'm in the process of changing the ISP rdf files >> from rdf to json. That doesn't alter much of the logistics of this >> proposal, more just a technical correction though. See bug 418693.
> It's sort of ironic that while Mozilla seems to have adopted the "we > hate RDF" philosophy, down the street at SRI a major, well-funded > RDF-based initiative has adapted the mozilla mailnews and browser into > OpenIris for an integrated desktop.
I'd say, whatever works best and solves the problem at hand most efficiently should be used. We should take into account that it's the ISPs which have to understand and prepare the discovery file, so lets make it most friendly for them in every respect. It looks to me as if both options mentioned are simple XML, so....?
On Mar 4, 7:07 am, Ben Bucksch <ben.bucksch.n...@beonex.com> wrote:
> Objective: Make my non-tech friends use Thunderbird, by making it > dead-simple to set up.
Would also be nice if Thunderbird supported being called from a webpage to setup accounts. This way ISP could setup account when users register with the service.
Ben Bucksch wrote: > Peter Lairo schrieb: >> Ben Bucksch on 04.03.2008 07:07 wrote: >>> Objective: Make my non-tech friends use Thunderbird, by making it >>> dead-simple to set up. > The idea is to make things very simple... The more options there are, > the more scared people are. > The "preconfigured" option is not needed, this is already automatically > used in my proposal. The provider is selected based on the domain of the > email address.
> where "Email account, manual configuration" does exactly what "Email > account" does today, while the new "Email account" is the automatic > setup, using the logic I posted, using the preconfigured providers, the > provider's config file on the net, or the mozilla config web service. > The current "Google mail" option goes away and is used automatically > when the user enters hisn...@gmail.com or googlemail.com/de in automatic > setup option.
Current wizard pages, assuming email selected on first page: 1. new acct setup: email / feeds / newsgroups [cancel] [next] 2. identity: name, address [cancel] [back] [next] 3. server: pop / imap, server, global inbox [cancel] [back] [next] 4. user names: incoming, outgoing [cancel] [back] [next] 5. account name [cancel] [back] [next] 6. verify, download now? [cancel] [back] [finish]
Here's my suggestion: 1. new acct setup: email / feeds / newsgroups [cancel] [next] 2. identity: name, address [cancel] [back] [next] 6a. (progress meter isn't optional since we're networking...)
A: service autoconf found 6b. verify, download now? [cancel] [back] [customize] [finish]
B: service autoconf not found, or customize pressed 6c. (sorry, autoconf not found, or this could just skip forward) 3. server: pop / imap, server, global inbox [cancel] [back] [next] 4. user names: incoming, outgoing [cancel] [back] [next] 5. account name [cancel] [back] [next] 6. verify, download now? [cancel] [back] [finish]
I.e. use current pages, insert a page similar to 6 that indicates progress and then confirms account data. If autoconf is successful and customize is selected, values are prefilled on the subsequent wizard pages. That's two wizard page more than your suggestion, but you * know which server you send the password to * don't have to choose between getting easy configured values and being able to customize whatever * the first page stays neat, putting in an address is applicable to the other choices as well so it only appearing under email for its fast case would be weird
The suggested fast case flow would be identical to what the first page gmail selection does now.
> Would also be nice if Thunderbird supported being called from a > webpage to setup accounts. This way ISP could setup account when users > register with the service.
Outlook Express can do that. They have such provider files, IIRC in INI file form, and a special file extension for that. We could register that file extension in the OS and try to parse that file.
I don't think many ISPs are using that, though. I have never seen it in my real-world usage. The advantage of this proposal is that ISPs can use it, but it works without their support. We could support both.
-- When responding via mail, please remove the ".news" from the email address.
> Would also be nice if Thunderbird supported being called from a > webpage to setup accounts. This way ISP could setup account when users > register with the service.
Can SRV records offer us anything here? They require effort on behalf of the ISPs to set up, but provide a relatively standard mechanism for service location.
> Can SRV records offer us anything here? They require effort on behalf > of the ISPs to set up, but provide a relatively standard mechanism > for service location.
So SRV records are made for service discovery, I think it will not serve our purpose well. It would have to look something like this:
_mail_isp._tcp IN SRV 0 100 80 mail.mozilla.org.
But in this case the discovery file would have to be always at the same known location, like http://mail.mozilla.org/isp.rdf
On 4 Mar 2008, at 19:54, Eddy Nigg (StartCom Ltd.) wrote:
> Simon Wilkinson: >> Can SRV records offer us anything here? They require effort on behalf >> of the ISPs to set up, but provide a relatively standard mechanism >> for service location.
> So SRV records are made for service discovery, I think it will not > serve > our purpose well.
I don't think that SRV records could be used as a replacement for your RDF discovery files, but they could prove a useful alternative to them. In cases where all you want to be able to do is say "where is the IMAP server for the domain 'example.com'", they can provide a lightweight alternative.
Once you've found whether you're supposed to be using IMAP or POP, you can auto-discover pretty much everything else by talking to the server. In particular, the SASL refactoring I'm working on should provide a mechanism to pick the 'best' SASL mechanism supported by the server, and record that for future use. This is particularly important for mechanisms like GSSAPI.
> I don't think that SRV records could be used as a replacement for your > RDF discovery files, but they could prove a useful alternative to > them. In cases where all you want to be able to do is say "where is > the IMAP server for the domain 'example.com'", they can provide a > lightweight alternative.
> Once you've found whether you're supposed to be using IMAP or POP, you > can auto-discover pretty much everything else by talking to the > server. In particular, the SASL refactoring I'm working on should > provide a mechanism to pick the 'best' SASL mechanism supported by the > server, and record that for future use. This is particularly important > for mechanisms like GSSAPI.
Well, maybe you are right, but I'm not aware that there is convention or known standard for lets say pop3, imap, smtp like:
_pop3._tcp IN SRV 0 100 110 mail.mozilla.org. _pop3s._tcp IN SRV 0 100 995 mail.mozilla.org. _imap._tcp IN SRV 0 100 143 mail.mozilla.org. _imaps._tcp IN SRV 0 100 993 mail.mozilla.org. _smtp._tcp IN SRV 0 100 25 mail.mozilla.org.
Or is there? And what about STARTTLS for SMTP? Perhaps _starttls._tcp ? But SRV discovery would be COOL!!! :-)
"The protocol should be https (otherwise a MITM can direct my traffic and login request to him by just telling me his server as config)"
This actually makes no difference from a security perspective, because the URL was originally obtained via a TXT record. It's as easy to spoof DNS records, as it is to redirect http connections. This is the main issue with obtaining any form of service location information through DNS, be it A, SRV, or TXT, records.
>> Would also be nice if Thunderbird supported being called from a >> webpage to setup accounts. This way ISP could setup account when users >> register with the service.
> Can SRV records offer us anything here? They require effort on behalf > of the ISPs to set up, but provide a relatively standard mechanism for > service location.
I am not very clear on service discovery, somebody with knowledge of the pros/cons please fill in.
So far, I have as options: * favicon approach: Look up a certain defined hostname in the DNS like mailconfig.<emaildomain>, e.g. mailconfig.example.net , assume that it's an https server and contact a hardcoded URL like https://mailconfig.example.net/config/mozilla.xml I hate favicons. I think it's arrogant to assume and dictate that a certain URL is valid. This here will spam the DNS system, not http servers. Put off by the fact that setting up an account is a rare action. * DNS TXT record Look up all TXT records for example.net and pick the one starting with "mailconfig=". * DNS SRV record Your proposal.
I have no idea how hard it is for admins to set up such custom DNS records, in the various DNS server implementations. If the admin doesn't know how to do it (and many are clueless Windows click click admins, even in big companies), or simply refuses because he doesn't like it ("company policy"), then whoever at the ISP is in support for this will be blocked.
More info and proposals welcome.
-- When responding via mail, please remove the ".news" from the email address.
> "The protocol should be https (otherwise a MITM can direct my traffic > and login request to him by just telling me his server as config)"
> This actually makes no difference from a security perspective, > because the URL was originally obtained via a TXT record. It's as > easy to spoof DNS records, as it is to redirect http connections. > This is the main issue with obtaining any form of service location > information through DNS, be it A, SRV, or TXT, records.
LOL! That's why it should be secured over https in order to avoid spoofing.
