Proposal: Auto-configuration

136 views
Skip to first unread message

Ben Bucksch

unread,
Mar 4, 2008, 1:07:03 AM3/4/08
to
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.ac...@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.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 5:29:11 AM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org
Hi Ben,

Ben Bucksch:


> 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.ac...@example.net) which contains an URL like
> https://mailconfig.example.net/mozilla.xml .
>

Something like this:

mta1.mozilla.org. IN TXT
"misp=http://www.mozilla.com/isp/config.rdf"

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.

--
Regards

Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390

Joey Minta

unread,
Mar 4, 2008, 7:47:46 AM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org
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.buck...@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.ac...@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.
>

> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>

Peter Lairo

unread,
Mar 4, 2008, 11:03:08 AM3/4/08
to
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:

+-------------------------------------------------+
| Account Wizard |
~ ~
| (o) E-Mail account |
| (o) Pre-configured e-mail providers (ISPs) | <--- NEW
| +-------------------------------------+ |
| | fastmail.fm /\| |
| | freenet.de ||| |
| | Google Mail (gmail) ||| |
| | gmx.de \/| |
| +-------------------------------------+ |
| ( ) Import settings from a file | <--- NEW
| ( ) Manual Configuration |
| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next ] [ Cancel ] |
+-------------------------------------------------+

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).

Combining your and my methods could yield:

+--------------------------------------------------+
| *Account Wizard* |
~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |
| (o) Auto-detect:[ ] [Refresh] | <-- yours
| ( ) Pre-configured e-mail providers (ISPs) | <-- and mine
| +-----------------------------------+ |
| | fastmail.fm /\| |
| | freenet.de ||| |
| | Google Mail (gmail) ||| |
| | gmx.de \/| |
| +-----------------------------------+ |
| ( ) Import settings from a file |
File: [ ] [Browse] |
| ( ) Manual configuration |
| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+

Since the three fields apply to all e-mail setup options, I have placed
them above the three radio buttons.

If the ISP offers both POP and IMAP, I hope Thunderbird will choose IMAP.

If the user selects "Newsgroup account", the name and email fields would
appear there:

| (o) Newsgroup account |
| Full name: [ ] |
| E-Mail address: [ ] |

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,

Peter Lairo

The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com

Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Dangers of Islam (German): http://www.pi-news.net/
Church of the Flying Spaghetti Monster: http://www.venganza.org/

Peter Lairo

unread,
Mar 4, 2008, 11:08:42 AM3/4/08
to
Peter Lairo on 04.03.2008 17:03 wrote:
> | (o) E-Mail account |
> | |
> | Full name: [ ] |
> | E-Mail address: [ ] |
> | Password: [ ] |
> | |
> | (o) Auto-detect:[ ] [Refresh] | <-- yours

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.

IANAP (i am not a programmer)

Peter Lairo

unread,
Mar 4, 2008, 11:09:56 AM3/4/08
to
Peter Lairo on 04.03.2008 17:08 wrote:
> Perhaps the auto-detect filled ...

s/filled/field :-[

Tuukka Tolvanen

unread,
Mar 4, 2008, 11:41:03 AM3/4/08
to
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.)

't.

Ben Bucksch

unread,
Mar 4, 2008, 12:10:17 PM3/4/08
to Joey Minta
Joey Minta schrieb:

> 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

Ben Bucksch

unread,
Mar 4, 2008, 12:18:06 PM3/4/08
to
Peter Lairo schrieb:

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.

So, my proposal would be:

+--------------------------------------------------+
| *Account Setup* |


~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |

| ( ) E-Mail account, manual configuration |


| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+

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 his...@gmail.com or googlemail.com/de in automatic
setup option.

Ben

Peter Lairo

unread,
Mar 4, 2008, 12:49:57 PM3/4/08
to
Ben Bucksch on 04.03.2008 18:18 wrote:
> The idea is to make things very simple... The more options there are,
> the more scared people are.

Good point.

> +--------------------------------------------------+
> | *Account Setup* |
> ~ ~
> | (o) E-Mail account |
> | |
> | Full name: [ ] |
> | E-Mail address: [ ] |
> | Password: [ ] |
> | |
> | ( ) E-Mail account, manual configuration |
> | ( ) RSS News Feeds and Blogs |
> | ( ) Newsgroup account |
> | |
> | [ Back ] [ Next/Done ] [ Cancel ] |
> +--------------------------------------------------+

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:

+--------------------------------------------------+
| *Account Wizard* |
~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |
| (o) Auto-detect:[ ] [Refresh] |
| |

| ( ) Manual configuration |
| |
| ( ) RSS News Feeds and Blogs |
| |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+

I think this arrangement is more logical (e-mail settings sub-types are
grouped in sub-radio-buttons under e-mail account).

I've eliminated the "Pre-configured" and the "Import settings from a file".

The "Import settings from a file" could (should?) be possible from the
"Manual configuration".

BTW: Should selecting "Newsgroup account" yield:

+--------------------------------------------------+
| *Account Wizard* |
~ ~

| ( ) E-Mail account |


| |
| ( ) RSS News Feeds and Blogs |
| |

| (o) Newsgroup account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Newsgroup server:[ ] |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+

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?

Kent James

unread,
Mar 4, 2008, 1:32:46 PM3/4/08
to
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.

- rkent

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 1:41:49 PM3/4/08
to Kent James, dev-apps-t...@lists.mozilla.org
Kent James:
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....?

Henrik Gemal

unread,
Mar 4, 2008, 2:03:44 PM3/4/08
to
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.

Tuukka Tolvanen

unread,
Mar 4, 2008, 2:07:08 PM3/4/08
to
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,

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.

't.

Ben Bucksch

unread,
Mar 4, 2008, 2:24:32 PM3/4/08
to Henrik Gemal
Henrik Gemal schrieb:

> 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.

Simon Wilkinson

unread,
Mar 4, 2008, 2:34:37 PM3/4/08
to dev-apps-t...@lists.mozilla.org

On 4 Mar 2008, at 19:03, Henrik Gemal wrote:

> 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.

Simon.


Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 2:39:17 PM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org
Ben Bucksch:

> I don't think many ISPs are using that, though. I have never seen it in
> my real-world usage.
-1 Me either

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 2:54:11 PM3/4/08
to Simon Wilkinson, dev-apps-t...@lists.mozilla.org
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. 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

Whereas with a TXT record we could use:

mail IN TXT "misp=http://mail.mozilla.org/somewhere/myisp.rdf"

Obviously both records would be discovered using the MX record of the
email address first. The parent of both records is mozilla.org.

Simon Wilkinson

unread,
Mar 4, 2008, 3:03:49 PM3/4/08
to Eddy Nigg (StartCom Ltd.), dev-apps-t...@lists.mozilla.org

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.

S.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 3:19:41 PM3/4/08
to Simon Wilkinson, dev-apps-t...@lists.mozilla.org
Simon Wilkinson:

>
> 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!!! :-)

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 3:23:05 PM3/4/08
to Simon Wilkinson, dev-apps-t...@lists.mozilla.org
Eddy Nigg (StartCom Ltd.):

> 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!!! :-)
>
Actually there is, albeit not complete:
http://www.dns-sd.org/ServiceTypes.html

Ben Bucksch

unread,
Mar 4, 2008, 3:53:24 PM3/4/08
to
Proposal placed on wiki, incorporating some of the feedback, and adding
a bit of the XML file format:

http://wiki.mozilla.org/Tb:Autoconfiguration

Simon Wilkinson

unread,
Mar 4, 2008, 3:59:11 PM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org

On 4 Mar 2008, at 20:53, Ben Bucksch wrote:

> Proposal placed on wiki, incorporating some of the feedback, and
> adding
> a bit of the XML file format:
>
> http://wiki.mozilla.org/Tb:Autoconfiguration

You say...

"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.

S.

Ben Bucksch

unread,
Mar 4, 2008, 4:03:56 PM3/4/08
to Simon Wilkinson
Simon Wilkinson schrieb:

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.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 4:03:08 PM3/4/08
to Simon Wilkinson, Ben Bucksch, dev-apps-t...@lists.mozilla.org
Simon Wilkinson:
> You say...

>
> "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.

Ben Bucksch

unread,
Mar 4, 2008, 4:10:11 PM3/4/08
to Simon Wilkinson
Simon Wilkinson schrieb:

>
> 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.

Ah. No, that's not sufficient. There are many fine options that the
config files set, some of them critical, like SSL/TLS, the
authentication method, the mailbox folder root and inbox path for IMAP,
how to compose the login name etc.. Server name/port is not sufficient.

> 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.

I would not like to rely on the IMAP or POP or SMTP server
implementation supporting that, because that requires a whole bunch of
other software support.

Simon Wilkinson

unread,
Mar 4, 2008, 4:13:17 PM3/4/08
to Eddy Nigg (StartCom Ltd.), Ben Bucksch, dev-apps-t...@lists.mozilla.org

On 4 Mar 2008, at 21:03, Eddy Nigg (StartCom Ltd.) wrote:

> LOL! That's why it should be secured over https in order to avoid
> spoofing.

This doesn't help. Which was my point, if you'd read carefully. https
is not a universal panacea.

The proposal involves getting the URL from a TXT record. In the
absence of DNS-SEC, TXT records are insecure.

So, an attacker can subvert the DNS, and have the TXT record for
mozilla.org point to, say, https://nasty.evil.git/autoconfig.rdf

Providing they have a valid certificate for nasty.evil.git (and why
shouldn't they, if they own that domain), then the client will see no
SSL verification errors, and happily download the autoconfiguration
file. You might as well just use http, and save the processor overhead.

S.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 4:21:22 PM3/4/08
to Simon Wilkinson, ben.bucksch@beonex.com >> Ben Bucksch, dev-apps-t...@lists.mozilla.org
Simon Wilkinson:

> On 4 Mar 2008, at 21:03, Eddy Nigg (StartCom Ltd.) wrote:
>
>
>> LOL! That's why it should be secured over https in order to avoid
>> spoofing.
>>
>
> This doesn't help. Which was my point, if you'd read carefully. https
> is not a universal panacea.
>
> The proposal involves getting the URL from a TXT record.
The same way you get A records and any other one...

> In the
> absence of DNS-SEC, TXT records are insecure.
>
All of DNS is insecure... (which means we agree on that one ;-) )

> So, an attacker can subvert the DNS, and have the TXT record for
> mozilla.org point to, say, https://nasty.evil.git/autoconfig.rdf
>
> Providing they have a valid certificate for nasty.evil.git (and why
> shouldn't they, if they own that domain), then the client will see no
> SSL verification errors, and happily download the autoconfiguration
> file.
Right! Because of that we should do two things here:

1.) The file MUST be over SSL/TLS
2.) The wizard must prompt first before continuing, similar to package
installation, e.g. "Do you want to download and configure....blah,
blah...(with the usual 2 seconds delay)

> You might as well just use http, and save the processor overhead.

No, lets do it right from the beginning...

Simon Wilkinson

unread,
Mar 4, 2008, 4:29:47 PM3/4/08
to Eddy Nigg (StartCom Ltd.), ben.bucksch@beonex.com >> Ben Bucksch, dev-apps-t...@lists.mozilla.org

On 4 Mar 2008, at 21:21, Eddy Nigg (StartCom Ltd.) wrote:

> Simon Wilkinson:
>>
>> On 4 Mar 2008, at 21:03, Eddy Nigg (StartCom Ltd.) wrote:
>>>
>>> LOL! That's why it should be secured over https in order to avoid
>>> spoofing.
>> This doesn't help. Which was my point, if you'd read carefully.
>> https is not a universal panacea. The proposal involves getting
>> the URL from a TXT record.
> The same way you get A records and any other one...

But when you get an A record, and then use that for https, there is a
process that binds the IP layer (the address) with the security layer
(the TLS certificate). Nothing in the current proposal achieves this
binding, and so everything else is just snake oil.

> 1.) The file MUST be over SSL/TLS
> 2.) The wizard must prompt first before continuing, similar to
> package installation, e.g. "Do you want to download and
> configure....blah, blah...(with the usual 2 seconds delay)

This falls foul of all of the 'goal motivated user' problems. If you
want to do this properly, then you have to tie the domain of the
server being configured with the domain from which the configuration
is fetched. This will inevitably cause problems for ISPs which
support a large number of 'vanity' domains.

S.

Ben Bucksch

unread,
Mar 4, 2008, 4:32:59 PM3/4/08
to Simon Wilkinson
Simon Wilkinson schrieb:

> "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.

Yes, unfortunately.

The favicon approach would not have that problem.

Any kind of security check that can use only the email address domain as
trust root has the problem that there are email providers with countless
domains (coolpeople.com etc.).

Ben Bucksch

unread,
Mar 4, 2008, 4:37:48 PM3/4/08
to Simon Wilkinson
Simon,

you cced ben.b...@beonex.com, in a posting that's on
news.mozilla.org, which is gated to the Usenet. Now that address is on
Usenet and will get spammed more :-( .

Ben

Ben Bucksch

unread,
Mar 4, 2008, 4:38:52 PM3/4/08
to Simon Wilkinson
Ben Bucksch schrieb:
> you cced <removed>, in a posting that's on news.mozilla.org, which is
> gated to the Usenet. Now that address is on Usenet and will get
> spammed more :-( .

An idiotic as I am, I post this private mail to Usenet.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 4:38:28 PM3/4/08
to Simon Wilkinson, dev-apps-t...@lists.mozilla.org
Simon Wilkinson:

> But when you get an A record, and then use that for https, there is a
> process that binds the IP layer (the address) with the security layer
> (the TLS certificate).
Yes, this is how it works...

> Nothing in the current proposal achieves this
> binding, and so everything else is just snake oil.
>
Huuu? And why not exactly? Maybe I'm missing something here, but I
understand that this is just about how the config file is fetched (over
https), nothing more....why should TB "bind" any different? TB has NSS
and can connect to a https socket...I'm not seeing what's wrong with that..

>
> This falls foul of all of the 'goal motivated user' problems. If you
> want to do this properly, then you have to tie the domain of the
> server being configured with the domain from which the configuration
> is fetched.
That would be perhaps preferred. On the other hand you'd know when you
host your mail at google and it asks to download the config from an
unknown location? No, it's not perfect, but perhaps as good as it gets...

Ben Bucksch

unread,
Mar 4, 2008, 5:19:03 PM3/4/08
to
Eddy Nigg (StartCom Ltd.) schrieb:

> Huuu? And why not exactly? Maybe I'm missing something here, but I
> understand that this is just about how the config file is fetched
> (over https), nothing more....why should TB "bind" any different? TB
> has NSS and can connect to a https socket...I'm not seeing what's
> wrong with that..

https on the web would be just snake oil, if the browser did not enforce
that the domain "subject" in the cert matches the domain of the URL that
the user entered or clicked on originally. I think that's what he means
with "binding".

Here, the trust root that the user entered is the email address domain.
It's possible to match the cert with that, but that poses a problem for
vanity email providers with a few thousand dozen, hundred or thousand
domains. Not to even start with those offers where people get their own
domain name (which everyone should!). Of course you're from an CA, so
that's not a problem from your perspective, but it's a serious
deployment problem for ISPs, if not financial. https also needs one IP
address per cert.

I added a security section at the wiki page documenting the mentioned
problems.

Ben

Stefanie Blackburn

unread,
Mar 4, 2008, 6:08:21 PM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org
Please forgive me if I missed this in the thread - but - will this new
framework support/replace the existence of the autoconfig.jsc file if
this is being used by companies running this internally?

Thanks

> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>

--
********************************************************************
Stefanie Blackburn
Product Manager, Netscape Messenger
Productivity Tools & Services
Corporate Resources IT Tel: (303) 223-7619
Sun Microsystems Inc. Fax: (303) 272 6703
500 Eldorado Blvd BRM02
Broomfield, CO 80021 mailto:Stefanie....@Sun.Com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The information contained in this electronic transmission is
intended only for the use of the recipient and may be Sun
Microsystems, Inc. or its Subsidiaries, confidential,
attorney-client privileged, and/or constitute inside
information. Unauthorized use, disclosure, or reproduction is
strictly prohibited, and may be unlawful. If you have received
this electronic transmission in error, please notify the sender
immediately and delete all copies from your system."


********************************************************************

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 6:09:53 PM3/4/08
to dev-apps-t...@lists.mozilla.org
Ben Bucksch:

> Eddy Nigg (StartCom Ltd.) schrieb:
>
>> Huuu? And why not exactly? Maybe I'm missing something here, but I
>> understand that this is just about how the config file is fetched
>> (over https), nothing more....why should TB "bind" any different? TB
>> has NSS and can connect to a https socket...I'm not seeing what's
>> wrong with that..
>>
>
> https on the web would be just snake oil, if the browser did not enforce
> that the domain "subject" in the cert matches the domain of the URL that
> the user entered or clicked on originally. I think that's what he means
> with "binding".
>
Well, the first condition is that obviously the certificate must match
the URL we are going to use to download the config file. So far so good
I guess. Now, by visually having the user confirm this like:

"You are about to download a configuration file from
*https://www.mozilla.org/config.rdf* which Thunderbird found for your
email address. The address above provided a valid certificate for this
purpose. Do you want to continue or configure your account manually?"

[ Yes ] [ Configure Manually ] [ Cancel ]


> Here, the trust root that the user entered is the email address domain.
> It's possible to match the cert with that, but that poses a problem for
> vanity email providers with a few thousand dozen, hundred or thousand
> domains. Not to even start with those offers where people get their own
> domain name (which everyone should!). Of course you're from an CA, so
> that's not a problem from your perspective, but it's a serious
> deployment problem for ISPs, if not financial. https also needs one IP
> address per cert.
>

No only that, but also from an ISP for mail and web. Now lets look at
this more carefully...not saying there is a perfect solution, but I
guess we should do the obvious or drop the idea altogether....

As an ISP I provide the user with his account details which he in turn
uses to configure is mail client. Supposed the DNS server of the ISP or
the ones the user is using gets poised, he might end up either way at
the wrong server, offering generously his password for his mail account.
This is nothing new, it can happen every time, everyday! Every time a
mail client authenticates against the server, sometimes every ten
minutes or so (with SMTP auth and POP3) does this happen. However it is
less likely if the mail server uses SSL for IMAP,POP and SMTP.

Lets continue to the next step. We should only offer account setup via
config files when the following conditions are met:

1.) An MX record for the email address exists.
2.) There is a TXT entry as proposed by you for the config file. (At
this stage please note that one mail server handles multiple domain
names, hence the requirement for an MX record (even so an A record is
allowed as well according to RFC)).
3.) The URL found in the TXT record is an SSL secured site and uses the
https:// prefix (it is allowed to use a different port then 443).
4.) The site is correctly secured and the certificate can be chained to
a trusted root.
5.) The user confirms the download (See above).

If we follow this rule, the likelihood for misuse is limited to a
reasonable extend. Certainly better than just dropping SSL and download
via plain any file, no questions asked (As Simon proposes it). Also ways
better than any authentication via the regular POP3, IMAP and SMTP
services in plain text.

ISPs which operate one or more mail servers will still need only ONE
configuration file (see for example google mail configuration when
hosting mail with them). Therefore the TXT record for domain1.com,
domain2.com and domain3.com will all use the same config file, i.e. the
only one for the responsible mail server (mail.domain.com as per MX
record of the domain in question). There is no need for more than one
secured host. It can be any URL, perhaps an existing SSL site.

(** Somewhat off-topic: The requirement for unique IP addresses per
(sub)domain for SSL is coming to an end pretty soon. IIS supports DNS
entries via Alt Names extension for a long time already and the newest
Apache-to-come will supports it as well. All modern browsers support it
too. All you need is a certificate will all domain names and/or wild
cards or any combination thereof.)

Dan Mosedale

unread,
Mar 4, 2008, 6:48:01 PM3/4/08
to

This is an interesting use case. Seems like it wouldn't be hard to do
by using a MIME-type for autoconfig files.

Dan

Dan Mosedale

unread,
Mar 4, 2008, 7:00:53 PM3/4/08
to
Ben Bucksch wrote:
> Joey Minta schrieb:
>> 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.

I'm not sure what you mean by "clear", here. I find XML notably harder
for my eyes to read than JSON.

> 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.

You are correct that parsing it manually is required. Fortunately, such
parsers have been written for every language imaginable. See
<http://json.org/> for one list.

> 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.

This is a little hard to guess. XML is certainly used in non-web
contexts more than JSON, but JSON is pretty huge these days. I
personally lean towards JSON a bit, but it's not clear to me that which
format is chosen matters all that much.

> 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.

This sounds about right to me.

Dan

Dan Mosedale

unread,
Mar 4, 2008, 7:37:28 PM3/4/08
to
Eddy Nigg (StartCom Ltd.) wrote:
> Eddy Nigg (StartCom Ltd.):
>> 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!!! :-)
> Actually there is, albeit not complete:
> http://www.dns-sd.org/ServiceTypes.html

While I agree that using SRV or TXT records feels like the part of the
"right" solution, it does require that someone sign up to extend the DNS
service. Right now, nsIDNSService only exposes an API analogous to
getaddrinfo(), it's not currently possible to get SRV or TXT records at
all. It's not clear to me how big a piece of work this is likely to be.

Dan

Simon Wilkinson

unread,
Mar 4, 2008, 7:51:37 PM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org

On 4 Mar 2008, at 22:19, Ben Bucksch wrote:
>
> I think that's what he means with "binding".

Bindings are the accepted term in the security community for
describing the security linkages between different layers. See, for
example, RFC5056

> Here, the trust root that the user entered is the email address
> domain.
> It's possible to match the cert with that, but that poses a problem
> for
> vanity email providers with a few thousand dozen, hundred or thousand
> domains. Not to even start with those offers where people get their
> own
> domain name (which everyone should!). Of course you're from an CA, so
> that's not a problem from your perspective, but it's a serious
> deployment problem for ISPs, if not financial. https also needs one IP
> address per cert.

Yup. It's not at all clear that requiring that domain of the server
pointed to by the TXT record match the domain of the user is a
scalable solution, for exactly the reasons you outline above.

S.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 7:52:27 PM3/4/08
to Dan Mosedale, dev-apps-t...@lists.mozilla.org
Dan Mosedale:

> While I agree that using SRV or TXT records feels like the part of the
> "right" solution, it does require that someone sign up to extend the DNS
> service. Right now, nsIDNSService only exposes an API analogous to
> getaddrinfo(), it's not currently possible to get SRV or TXT records at
> all. It's not clear to me how big a piece of work this is likely to be.
>
>
Outshhh....what a minor detail ;-)

Guess this should be added to the wiki page...

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 8:03:19 PM3/4/08
to Simon Wilkinson, Ben Bucksch, dev-apps-t...@lists.mozilla.org
Simon Wilkinson:

>
> Yup. It's not at all clear that requiring that domain of the server
> pointed to by the TXT record match the domain of the user is a
> scalable solution, for exactly the reasons you outline above.
>
>
>
But you are perhaps forgetting that mail is handled via MX records in
the DNS. This isn't web per se, the TXT must be obtained from the
matching MX record:

Email address: eddy...@startcom.org
Mail server (MX record): mta1.startcom.org
ISP config discovery must be a TXT record of mta1.startcom.org and not
that of startcom.org! Hence the entry would be

mta1 IN A 192.116.202.202
IN MX 10 mta1.startcom.org.
IN TXT "mailconf=https://someurl/somepath/somefile"


And obviously not what you mentioned above. Mail servers and domain
names of mail accounts are scalable. There can be even multiple mail
servers for multiple domain names with failover and priority backups all
using the same config.

Dan Mosedale

unread,
Mar 4, 2008, 8:08:22 PM3/4/08
to
Stefanie Blackburn wrote:
> Please forgive me if I missed this in the thread - but - will this new
> framework support/replace the existence of the autoconfig.jsc file if
> this is being used by companies running this internally?

This is unrelated to autoconfig.jsc.

Dan

Ben Bucksch

unread,
Mar 4, 2008, 8:44:28 PM3/4/08
to Eddy Nigg (StartCom Ltd.)
Eddy Nigg (StartCom Ltd.) schrieb:
> Simon Wilkinson:
>> Yup. It's not at all clear that requiring that domain of the server
>> pointed to by the TXT record match the domain of the user is a
>> scalable solution, for exactly the reasons you outline above.
>>
>>
>>
> But you are perhaps forgetting that mail is handled via MX records in
> the DNS. This isn't web per se, the TXT must be obtained from the
> matching MX record:
>
> Email address: eddy...@startcom.org <mailto:eddy...@startcom.org>

> Mail server (MX record): mta1.startcom.org
> ISP config discovery must be a TXT record of mta1.startcom.org and not
> that of startcom.org! Hence the entry would be
>
> mta1 IN A 192.116.202.202
> IN MX 10 mta1.startcom.org.
> IN TXT "mailconf=https://someurl/somepath/somefile"

First, I would look up TXT startcom.org, not MX startcom.org ->
mta1.startcom.org -> TXT mta1.startcom.org, because a domain can and
should have several, if not many MX, and you don't want to configure
them for each MX, just for the domain. Also, MX is about incoming mail
(SMTP->SMTP), not about fetching or sending mail.

Second, in any case, this doesn't help. As Simon pointed out, you cannot
rely on DNS. As I said, you need to check the domain that the *user
entered* against the SSL cert of the config file server.

Eddy, do certificates exist (and are supported by Mozilla) that list
several unrelated domains, i.e. one server, one IP, one cert, but valid
for coolpeople.com, cansas.us, green.org and 300 other domains?

Ben

Eddy Nigg (StartCom Ltd.)

unread,
Mar 4, 2008, 9:47:28 PM3/4/08
to Ben Bucksch, dev-apps-t...@lists.mozilla.org
Ben Bucksch:

>> But you are perhaps forgetting that mail is handled via MX records in
>> the DNS. This isn't web per se, the TXT must be obtained from the
>> matching MX record:
>>
>> Email address: eddy...@startcom.org <mailto:eddy...@startcom.org>
>> Mail server (MX record): mta1.startcom.org
>> ISP config discovery must be a TXT record of mta1.startcom.org and not
>> that of startcom.org! Hence the entry would be
>>
>> mta1 IN A 192.116.202.202
>> IN MX 10 mta1.startcom.org.
>> IN TXT "mailconf=https://someurl/somepath/somefile"
>>
>
> First, I would look up TXT startcom.org, not MX startcom.org ->
> mta1.startcom.org -> TXT mta1.startcom.org, because a domain can and
> should have several, if not many MX, and you don't want to configure
> them for each MX, just for the domain. Also, MX is about incoming mail
> (SMTP->SMTP), not about fetching or sending mail.
>
Right, and this is exactly how I would advertise the service (and its
discovery). You don't have a better hint than the MX record. Even so A
records are valid, MX has priority over the A record. And then it
doesn't scale. So you should search for it the same way mail would
search for it, i.e. 1.) MX record, 2.) A record and not the other way
around.

And then, SMTP is part of the configuration, so the MX record makes
discovery easier...why do you want to go the hard/non-natural way? And
then, wasn't it you that proposed to scan each and every TXT record of
the DNS zone? Now you are complaining about having to check maybe two MX
records?


> Second, in any case, this doesn't help. As Simon pointed out, you cannot
> rely on DNS. As I said, you need to check the domain that the *user
> entered* against the SSL cert of the config file server.
>

Of course, this is what NSS does...it does it for web, it does it also
for STMP, IMAPS and POP3S. I proposed to visually show the download
location to the user (not that it means to everybody would realize a
spoof, but it might help. The same users would click also on every XPI
file etc. instead...)


> Eddy, do certificates exist (and are supported by Mozilla) that list
> several unrelated domains, i.e. one server, one IP, one cert, but valid
> for coolpeople.com, cansas.us, green.org and 300 other domains?
>

Yes! I think many CAs can support that. https://www.startssl.com/
supports it to a certain extend after performing Class 2 identity
validation. The fee is US$ 25 for identity validation, another 25 for
organization validation. (Sorry for the advertisement, but you asked for
it ;-) )

However as I explained above, this isn't the way mail is handled and
there is no need for it! Lets say I've got a mail server which handles a
few hundred different domain names and a few thousand users, all of them
are handled from the same mail server. All users configure their client
THE SAME WAY. They would download the very same config file for the
setup. There is no need to have for each domain name a different config
file.

More than that, just forget a second about SSL. Do you really think if I
have a few hundred domain names to handle I'm going to create a config
file for each domain name in my hosting department? It's easier to send
the standard notices and point to the FAQ pages how to configure the
mail. Nonono...If I can add a TXT record into the DNS zone of the mail
server, pointing to one or two different config files, then I'd do it,
because it saves me time and headache. With and without SSL it should be
handled that way.

Chris Ilias

unread,
Mar 5, 2008, 12:30:54 AM3/5/08
to
On 3/4/08 4:37 PM, _Ben Bucksch_ spoke thusly:

> you cced <removed>, in a posting that's on

> news.mozilla.org, which is gated to the Usenet. Now that address is on
> Usenet and will get spammed more :-( .

<nitpick>
Mozilla newsgroups are not actually fed to Usenet. It's a local
hierarchy, only available through news.mozilla.org and Google Groups.
You'll still get spam though. :-(
</nitpick>

--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia

Henrik Gemal

unread,
Mar 5, 2008, 11:44:38 AM3/5/08
to
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.
>

Two things that I think is missing:

1) Some kind of icon or graphics that the provider can have
2) a way to specify a URL for help/support etc

Otherwise super!

Eddy Nigg (StartCom Ltd.)

unread,
Mar 5, 2008, 5:07:41 AM3/5/08
to Chris Ilias, dev-apps-t...@lists.mozilla.org
Chris Ilias:

> On 3/4/08 4:37 PM, _Ben Bucksch_ spoke thusly:
>
>
>> you cced <removed>, in a posting that's on
>> news.mozilla.org, which is gated to the Usenet. Now that address is on
>> Usenet and will get spammed more :-( .
>>
>
> <nitpick>
> Mozilla newsgroups are not actually fed to Usenet. It's a local
> hierarchy, only available through news.mozilla.org and Google Groups.
> You'll still get spam though. :-(
> </nitpick>
>
At Google Groups the email address is removed unless you are logged in
as a user. So robots aren't picking it up.

Robert Kaiser

unread,
Mar 5, 2008, 4:21:37 PM3/5/08
to
Simon Wilkinson wrote:
>
> On 4 Mar 2008, at 20:53, Ben Bucksch wrote:
>
>> Proposal placed on wiki, incorporating some of the feedback, and adding
>> a bit of the XML file format:
>>
>> http://wiki.mozilla.org/Tb:Autoconfiguration
>
> You say...

>
> "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.

Actually, is _anything_ transferred there that requires strong security?
That is, as in "any stronger security than the usually non-encrypted
SMTP traffic"?

Robert Kaiser

Simon Wilkinson

unread,
Mar 5, 2008, 4:29:29 PM3/5/08
to Robert Kaiser, dev-apps-t...@lists.mozilla.org

On 5 Mar 2008, at 21:21, Robert Kaiser wrote:
>
> Actually, is _anything_ transferred there that requires strong
> security?
> That is, as in "any stronger security than the usually non-encrypted
> SMTP traffic"?


The danger is with transferring server location information. In the
current model, the user enters the identity of all of the servers
they'll use. SSL is then used to ensure that the identity of the
server they're connected to matches what they entered.

In the new model, the user enters their email address, and this is
then used to obtain configuration information. However, there isn't a
verifiable trust relationship between the server they're connecting
to, and the email address. This means that an attacker can simply
replace the server name in the configuration data (or replace the
entire configuration data). TLS will still think this is a valid
connection, because the server name in the users configuration
matches the certificate the server presents.

So, you make it very easy for man in the middle attacks which capture
the user's password.

S.

Eddy Nigg (StartCom Ltd.)

unread,
Mar 5, 2008, 4:34:19 PM3/5/08
to Robert Kaiser, dev-apps-t...@lists.mozilla.org
Robert Kaiser:

>> "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.
>>
>
> Actually, is _anything_ transferred there that requires strong security?
> That is, as in "any stronger security than the usually non-encrypted
> SMTP traffic"?
Agreed... so we should encourage usage of secured protocols also by
giving good examples and lead the way. In relation to that TB does a
good job thanks to the NSS module etc....and supports STARTTLS, SSL,
IMAPs and POP3s. I think we should provide a secure mechanism if
possible in order to facilitate providers which take security seriously.
The "auto-setup-feature" should not be the weak link for such providers.

Joshua Cranmer

unread,
Mar 5, 2008, 5:59:41 PM3/5/08
to
Ben Bucksch wrote:
> Now that address is on
> Usenet and will get spammed more :-( .
>
> Ben

I think you overestimate the amount of spam generated by Usenet. I used
my ISP email address for well over a year on c.l.j.*--and publicly
posted nowhere else by myself--and the total amount of spam I get is at
best 1 every few weeks. Oh wait, I'm still posting on my actual email
address here.

Peter Lairo

unread,
Mar 6, 2008, 3:46:38 AM3/6/08
to
Robert Kaiser on 05.03.2008 22:21 wrote:
> Actually, is _anything_ transferred there that requires strong security?
> That is, as in "any stronger security than the usually non-encrypted
> SMTP traffic"?

If the user enters Joh...@myISP.com as his e-mail address, and the
server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
traffic is then between the user and the server at myISP.com, then how
can a MITM attack even occur.

If the (MITM) server responds with anything BUT myISP.com (e.g.,
evilISP.com) then Thunderbird would NOT auto-complete the setup but
could bring up a dialog telling the user that there is a mismatch and a
POTENTIAL MITM issue and ask him to confirm.

Wouldn't this solve the problem? (and let us proceed to implementing
this feature - http://wiki.mozilla.org/Tb:Autoconfiguration)
--
Regards,

Peter Lairo

The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com

Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Dangers of Islam (German): http://www.pi-news.net/
Church of the Flying Spaghetti Monster: http://www.venganza.org/

Peter Lairo

unread,
Mar 6, 2008, 6:28:01 AM3/6/08
to
Ben Bucksch on 04.03.2008 21:53 wrote:
> Proposal placed on wiki, incorporating some of the feedback, and adding
> a bit of the XML file format:
>
> http://wiki.mozilla.org/Tb:Autoconfiguration

There's related information on "Thunderbird ISP hooks" at
http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks.
(Which probably should be moved to http://wiki.mozilla.org)

Robert Kaiser

unread,
Mar 6, 2008, 6:42:11 AM3/6/08
to
Peter Lairo wrote:
> Ben Bucksch on 04.03.2008 21:53 wrote:
>> Proposal placed on wiki, incorporating some of the feedback, and
>> adding a bit of the XML file format:
>>
>> http://wiki.mozilla.org/Tb:Autoconfiguration
>
> There's related information on "Thunderbird ISP hooks" at
> http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks.
> (Which probably should be moved to http://wiki.mozilla.org)

First of all, NEVER put questions about a wiki article on the top of the
article itself, there is a discussion page for every wiki page that is
intended for just that.

Then, this MDC page describes the current integration of ISP hooks that
_is already_ in stable Thunderbird versions. This is documentation about
available functionality in Thunderbird, and therefore belongs on MDC.

wiki.mozilla.org is for development planning, and the new stuff about
"autoconfiguration" goes much further than the already existing "ISP
hooks" feature and is in a planning phase, and therefore belong on the
"scratchpad" that wikimo is.

Robert Kaiser

Eddy Nigg (StartCom Ltd.)

unread,
Mar 6, 2008, 6:58:39 AM3/6/08
to dev-apps-t...@lists.mozilla.org
Hi Peter,

Peter Lairo:


> Robert Kaiser on 05.03.2008 22:21 wrote:
>
>> Actually, is _anything_ transferred there that requires strong security?
>> That is, as in "any stronger security than the usually non-encrypted
>> SMTP traffic"?
>>
>
> If the user enters Joh...@myISP.com as his e-mail address, and the
> server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
> traffic is then between the user and the server at myISP.com, then how
> can a MITM attack even occur.
>
> If the (MITM) server responds with anything BUT myISP.com (e.g.,
> evilISP.com) then Thunderbird would NOT auto-complete the setup but
> could bring up a dialog telling the user that there is a mismatch and a
> POTENTIAL MITM issue and ask him to confirm.
>
> Wouldn't this solve the problem? (and let us proceed to implementing
> this feature - http://wiki.mozilla.org/Tb:Autoconfiguration)
>

This isn't really feasible since mail servers handle mail for many
different domain names usually. This would mean that the config file
must be hosted at the host of that domain name. Sometimes domain names
don't even have a web site....

However discovery for mail servers in order to reach a particular user
[at] domain, MX records are used in the DNS zone. Many different domains
can point to one and the same mail server. I suggested to use the MX
record to retrieve the config file if the MX domain also has a TXT
record with a URL and location of the config file. This makes sense,
since all users of all domains handled by that mail server will use the
very same configuration anyway.

Peter Lairo

unread,
Mar 6, 2008, 7:54:28 AM3/6/08