Proposal: Auto-configuration

This is a multi-part message in MIME format.
--------------060506010900020907010604
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------060506010900020907010604
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="sans-serif">Objective: Make my non-tech friends use
Thunderbird, by making it dead-simple to set up.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Proposal:<br>
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.<br>
<br>
Email address is properly syntax-checked, and the existance of the
domain in DNS is checked.<br>
<br>
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:<br>
</font>
<ol>
  <li><font face="sans-serif">The legacy rdf files in
&lt;installdir&gt;/isp/, like we have for Google Mail right now. (This
may be dropped.)</font></li>
  <li><font face="sans-serif">Try to contact a mail configuration
server of the provider, e.g. </font><font face="sans-serif">define an
DNS TXT record or similar on domain example.net (for
<a class="moz-txt-link-abbreviated" href="mailto:my.account@example.net">my.account@example.net</a>) which contains an URL like </font><font
 face="sans-serif"><a class="moz-txt-link-freetext" href="https://mailconfig.example.net/mozilla.xml">https://mailconfig.example.net/mozilla.xml</a></font><font
 face="sans-serif"> .<br>
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).<br>
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).</font></li>
  <li><font face="sans-serif">If the email provider does not provide
the
configuration, we try to find it at mozillamessaging.com, e.g.
<a class="moz-txt-link-freetext" href="https://autoconfig.mozillamessaging.com/example.net/config.xml">https://autoconfig.mozillamessaging.com/example.net/config.xml</a> . This
service will have the configuration for all the major ISPs and email
providers, so there's a 90+% hit rate.<br>
It will not work for company
email addresses.<br>
If a provider disagrees with a setting there, it can
override the configuration by simply providing the config server in
step 2.</font></li>
  <li>Other ways, esp. for company email accounts? Avoid heuristics!<br>
  </li>
  <li><font face="sans-serif">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".<br>
    </font></li>
</ol>
<font face="sans-serif">
<br>
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.)<br>
<br>
</font>
<pre class="moz-signature" cols="72">-- 
When responding via mail, please remove the ".news" from the email address.
</pre>
</body>
</html>

--------------060506010900020907010604--
0
Ben
3/4/2008 6:07:03 AM
mozilla.dev.apps.thunderbird 3464 articles. 0 followers. Post Follow

127 Replies
1577 Views

Similar Articles

[PageSpeed] 44

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.account@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:  	startcom@startcom.org <xmpp:startcom@startcom.org>
Blog:  	Join the Revolution! <http://blog.startcom.org>
Phone:  	+1.213.341.0390
 

0
Eddy
3/4/2008 10:29:11 AM
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.news@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.account@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-thunderbird@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
0
Joey
3/4/2008 12:47:46 PM
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/
0
Peter
3/4/2008 4:03:08 PM
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)
-- 
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/
0
Peter
3/4/2008 4:08:42 PM
Peter Lairo on 04.03.2008 17:08 wrote:
> Perhaps the auto-detect filled ...

s/filled/field :-[
-- 
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/
0
Peter
3/4/2008 4:09:56 PM
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.
0
Tuukka
3/4/2008 4:41:03 PM
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
0
Ben
3/4/2008 5:10:17 PM
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.
>>
>> 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 ]  |
> +--------------------------------------------------+

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

Ben
0
Ben
3/4/2008 5:18:06 PM
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?
-- 
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/
0
Peter
3/4/2008 5:49:57 PM
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
0
Kent
3/4/2008 6:32:46 PM
Kent James:
> 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'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....?

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

0
Eddy
3/4/2008 6:41:49 PM
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.
0
Henrik
3/4/2008 7:03:44 PM
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.
>
> 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 hisname@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.

't.
0
Tuukka
3/4/2008 7:07:08 PM
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.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
3/4/2008 7:24:32 PM
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.


0
Simon
3/4/2008 7:34:37 PM
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


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

0
Eddy
3/4/2008 7:39:17 PM
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.

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

0
Eddy
3/4/2008 7:54:11 PM
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.

0
Simon
3/4/2008 8:03:49 PM
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!!! :-)

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

0
Eddy
3/4/2008 8:19:41 PM
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

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

0
Eddy
3/4/2008 8:23:05 PM
Proposal placed on wiki, incorporating some of the feedback, and adding 
a bit of the XML file format:

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

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
3/4/2008 8:53:24 PM
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.

0
Simon
3/4/2008 8:59:11 PM
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.

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

0
Eddy
3/4/2008 9:03:08 PM
Simon Wilkinson schrieb:
>
> 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. 

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.
0
Ben
3/4/2008 9:03:56 PM
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.

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
3/4/2008 9:10:11 PM
Ben Bucksch:
>
> * DNS TXT record
> Look up all TXT records for example.net and pick the one starting with 
> "mailconfig=".
>   
I think it shouldn't check all TXT records, but rather follow the MX 
record and pick the right TXT record (if there is one). There is 
unneeded overhead and traffic if parsing all TXT records IMO.

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

0
Eddy
3/4/2008 9:12:43 PM
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.

0
Simon
3/4/2008 9:13:17 PM
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...

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

0
Eddy
3/4/2008 9:21:22 PM
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.

0
Simon
3/4/2008 9:29:47 PM
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.).

-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
3/4/2008 9:32:59 PM
Simon,

you cced ben.bucksch@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
0
Ben
3/4/2008 9:37:48 PM
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...


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

0
Eddy
3/4/2008 9:38:28 PM
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.


-- 
When responding via mail, please remove the ".news" from the email address.
0
Ben
3/4/2008 9:38:52 PM
This is a cryptographically signed message in MIME format.

--------------ms050505090104080403060409
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Ben Bucksch:
> 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.
>
>   
Don't worry, TB has a good spam filter ;-)

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


--------------ms050505090104080403060409
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCDCC
B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI
EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD
VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0
MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy
YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh
dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy
ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz
eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA
IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O
U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj
eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u
xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud
DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx
tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE
BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0
eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0
YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp
oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6
Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5
BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y
Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50
ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX
TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z
KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls
YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC
AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl
cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0
cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw
Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H
yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa
v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0
4STurMCFwLoyx5k1rDHQYTCCCEYwggcuoAMCAQICAwFCwTANBgkqhkiG9w0BAQUFADCBrzEL
MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj
MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t
IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz
dGFydGNvbS5vcmcwHhcNMDcwMzE3MjMxNTU0WhcNMDgwMzE2MjMxNTU0WjCBnjELMAkGA1UE
BhMCSUwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSwwKgYDVQQL
EyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRlIE1lbWJlcjESMBAGA1UEAxMJRWRkeSBO
aWdnMSUwIwYJKoZIhvcNAQkBFhZlZGR5X25pZ2dAc3RhcnRjb20ub3JnMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqsN7vhA4tfdpEuEcHG5Y+9Eb8NKB7uPMw5I1FtP61awH
rIGcX4llWxe7edM54HwhVdo4fTdj/Q4yUr0FMEKw7FMcjUp5EEshJ13kRkIoxu0bAc/ttx4g
7UeJtNx7gl5rS8mq667CHIrk9A6Np5oCrN7e9IuDHUy8Ng8LEYCMtCgmDcg5yWFdZWi0KQyB
RR+2O8//GFCr36iuQXO6YO5MCtUZ5mSEHn+j1EiCb8mpyqvhgiR06/AeNzC0iEHWy3sc2fR6
kf2ZZgm02MO1yQa4N2Xi4sYGGcFPdJwrGYHqPDrGX/NHMOD+EHqNk/BVTe9Nzv7p0mNlYoD3
1DNwWwqdVwIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADALBgNVHQ8EBAMCBLAwHQYDVR0l
BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT0z3nrjzJgL1eGYOaY2/HWJGfl
yjCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZCKGBtqSBszCBsDELMAkGA1UE
BhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNT
TCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRj
b20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEEAYG1NwEBAzCCAR4wNQYIKwYB
BQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMC8GCCsG
AQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjCBswYIKwYBBQUH
AgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRlZCBMaWFiaWxpdHksIHJlYWQg
dGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlm
aWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w
b2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9j
cnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwu
Y3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0dHA6Ly9vY3NwLnN0YXJ0Y29t
Lm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jZXJ0LnN0YXJ0
Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCGSAGG+EIBAQQEAwIFoDAxBglg
hkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBDZXJ0aWZpY2F0ZTAyBglghkgB
hvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwNQYJYIZIAYb4
QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMDIGCWCGSAGG
+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjAjBgNVHRIEHDAa
hhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcNAQEFBQADggEBAIvystykKhj0
Z5kss+428amoenAL8rJ+oHf6L+H84aQxxKBhF5ygrfpBMRumuaIoMHuC9KIfB+UK2wK5svBX
/5bbhJ4dswjbBIJSUk8+Jr1ypxUgSevsg48e8eIq91hmf1VeXh/ILKVtHhkMCiSM1JoFLWbr
ZQxSDVeyH28b9wCkGNTQsokWRK6MwRrJB89ILUPr/aJmtS6CZMlUIlP01vXLozcnZowR/vQd
n0ueIS2DDTyYo+jiaqXfSdDQLxIg5arCf4OaenEk3PqwZmil9iW+OdfMe8r6G7Wix+8U8Mde
mRHv9kIjd0ZwVnrCKaw0ZI2faLwwAIVYHtPKzbV+6V8wgghGMIIHLqADAgECAgMBQsEwDQYJ
KoZIhvcNAQEFBQAwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8w
LQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqG
SIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnMB4XDTA3MDMxNzIzMTU1NFoXDTA4MDMxNjIz
MTU1NFowgZ4xCzAJBgNVBAYTAklMMQ4wDAYDVQQHEwVFaWxhdDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIx
EjAQBgNVBAMTCUVkZHkgTmlnZzElMCMGCSqGSIb3DQEJARYWZWRkeV9uaWdnQHN0YXJ0Y29t
Lm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKrDe74QOLX3aRLhHBxuWPvR
G/DSge7jzMOSNRbT+tWsB6yBnF+JZVsXu3nTOeB8IVXaOH03Y/0OMlK9BTBCsOxTHI1KeRBL
ISdd5EZCKMbtGwHP7bceIO1HibTce4Jea0vJquuuwhyK5PQOjaeaAqze3vSLgx1MvDYPCxGA
jLQoJg3IOclhXWVotCkMgUUftjvP/xhQq9+orkFzumDuTArVGeZkhB5/o9RIgm/Jqcqr4YIk
dOvwHjcwtIhB1st7HNn0epH9mWYJtNjDtckGuDdl4uLGBhnBT3ScKxmB6jw6xl/zRzDg/hB6
jZPwVU3vTc7+6dJjZWKA99QzcFsKnVcCAwEAAaOCBHgwggR0MAwGA1UdEwQFMAMCAQAwCwYD
VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9M95
648yYC9XhmDmmNvx1iRn5cowgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaWXxcBXH1CR71IGQih
gbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0
MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRob3JpdHkgRGVwLjEp
MCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxITAfBgkqhkiG9w0B
CQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEzMIIBLwYLKwYBBAGB
tTcBAQMwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50ZXJt
ZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBjUxpbWl0ZWQg
TGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhl
IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2Vy
dC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNv
bS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsGAQUFBzABhitodHRw
Oi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsGCCsGAQUFBzAChi9o
dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNhLmNydDARBglghkgB
hvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0ZWQgRW1haWwgQ2Vy
dGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jYS1j
cmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMt
Y3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGlj
eS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnMA0GCSqGSIb3DQEB
BQUAA4IBAQCL8rLcpCoY9GeZLLPuNvGpqHpwC/KyfqB3+i/h/OGkMcSgYRecoK36QTEbprmi
KDB7gvSiHwflCtsCubLwV/+W24SeHbMI2wSCUlJPPia9cqcVIEnr7IOPHvHiKvdYZn9VXl4f
yCylbR4ZDAokjNSaBS1m62UMUg1Xsh9vG/cApBjU0LKJFkSujMEayQfPSC1D6/2iZrUugmTJ
VCJT9Nb1y6M3J2aMEf70HZ9LniEtgw08mKPo4mql30nQ0C8SIOWqwn+DmnpxJNz6sGZopfYl
vjnXzHvK+hu1osfvFPDHXpkR7/ZCI3dGcFZ6wimsNGSNn2i8MACFWB7Tys21fulfMYIELDCC
BCgCAQEwgbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNVBAoTDVN0
YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5nMS8wLQYD
VQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8GCSqGSIb3
DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBQsEwCQYFKw4DAhoFAKCCAkkwGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzA0MjE1ODIyWjAjBgkqhkiG
9w0BCQQxFgQUsby7ofMPk1D/gKv2d7b2yMZXzQYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG
9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcN
AwICASgwgcgGCSsGAQQBgjcQBDGBujCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklz
cmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmlj
YXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBG
cmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwFCwTCBygYLKoZI
hvcNAQkQAgsxgbqggbcwga8xCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xIzAhBgNVBAsTGlNlY3VyZSBDZXJ0aWZpY2F0ZSBTaWduaW5n
MS8wLQYDVQQDEyZTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgRW1haWwgRnJlZSBDQTEhMB8G
CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnAgMBQsEwDQYJKoZIhvcNAQEBBQAEggEA
MePjf1FAZcMR3zOSBpCQeQo1JiArEpIXCXmc9deuyki9u5ZfW1++R1gThgSy5/LQLwwQa6VN
66jnEFdqWt1u+UXD2ypiSsdWhmWmnYIYBbpaOkyCexT29+Fnv6ylrcsblsHmT+J6itc9xccd
MbqLkSJIJ6a6xXpKAoW8hutQRNKvKwKn9s6CNxoFESlUk7cm1HQYGjkXQMIp6Z/qzWbMu1YT
LShtGgz/1GjvvEc4RqsEq7vWoi4Yr5HNqkjv1Dpw05Biu2vw7OP0la/KCRo23VFjvamEpFF6
sfweCy8lDF4t7nyE7LDOKOt2tduyYeba/6wn4N+g4kQESWodnAZFnwAAAAAAAA==
--------------ms050505090104080403060409--
0
Eddy
3/4/2008 9:58:22 PM
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
0
Ben
3/4/2008 10:19:03 PM
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


On 03/04/08 15:19, Ben Bucksch wrote:
> 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
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-thunderbird@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.Blackburn@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."


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

0
Stefanie
3/4/2008 11:08:21 PM
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.)

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

0
Eddy
3/4/2008 11:09:53 PM
Henrik Gemal wrote:
> 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.

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

Dan

0
Dan
3/4/2008 11:48:01 PM
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
0
Dan
3/5/2008 12:00:53 AM
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
0
Dan
3/5/2008 12:37:28 AM
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.

0
Simon
3/5/2008 12:51:37 AM
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...

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

0
Eddy
3/5/2008 12:52:27 AM
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_nigg@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.

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

0
Eddy
3/5/2008 1:03:19 AM
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

0
Dan
3/5/2008 1:08:22 AM
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_nigg@startcom.org <mailto:eddy_nigg@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
0
Ben
3/5/2008 1:44:28 AM
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_nigg@startcom.org <mailto:eddy_nigg@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.

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

0
Eddy
3/5/2008 2:47:28 AM
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
0
Chris
3/5/2008 5:30:54 AM
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.

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

0
Eddy
3/5/2008 10:07:41 AM
On Mar 4, 7:07=A0am, 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!
0
Henrik
3/5/2008 4:44:38 PM
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
0
Robert
3/5/2008 9:21:37 PM
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.

0
Simon
3/5/2008 9:29:29 PM
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.

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

0
Eddy
3/5/2008 9:34:19 PM
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.
0
Joshua
3/5/2008 10:59:41 PM
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 JohnDoe@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/
0
Peter
3/6/2008 8:46:38 AM
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)
-- 
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/
0
Peter
3/6/2008 11:28:01 AM
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
0
Robert
3/6/2008 11:42:11 AM
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 JohnDoe@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.

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

0
Eddy
3/6/2008 11:58:39 AM
Eddy Nigg (StartCom Ltd.) on 06.03.2008 12:58 wrote:
> 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 JohnDoe@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....

About what percentage of mail servers handle mail for the *same* domain 
name? ~80%? (AOL, Yahoo!, Hotmail, gmail, etc. should add up to quite a 
lot) Those are also ~100% of the users who can't set up their accounts 
on their own. IMO that would be enough to justify implementing the 
easier solution ASAP, and work out a solution for the uncommon and more 
complex cases later.
-- 
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/
0
Peter
3/6/2008 12:54:28 PM
Robert Kaiser on 06.03.2008 12:42 wrote:
> 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.

I didn't know about the "discussion" feature. Thanks for pointing it out.

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

Ah. That makes sense. Thanks.

(...goes off to fix discussion comment...)
-- 
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/
0
Peter
3/6/2008 12:57:46 PM
>
> 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.

I hadn't spotted this part of the proposal until now. As well as the  
security issues, how does this work in situations where a site has  
multiple MX records? It's entirely possible that machines listed as  
MXs for a given domain may purely act as 'store-and-forward' servers,  
and have no administrative connection with the site that they're  
MXing for. In this case, using their configuration would be  
completely the wrong thing to do.

S.

0
Simon
3/6/2008 1:26:52 PM
Peter Lairo:
> About what percentage of mail servers handle mail for the *same* domain 
> name? ~80%? (AOL, Yahoo!, Hotmail, gmail, etc. should add up to quite a 
> lot) Those are also ~100% of the users who can't set up their accounts 
> on their own. 
Lets take Google for example, which has a business offering for hosting 
mail for any domain name. I'm not informed about for how many of domain 
names Google serves mail, but I expect it to in the hundred of thousands 
of domain names and millions of users. Please note that these aren't the 
regular gmail users!

My proposal scales and would be implementable by small and large 
providers of mail services the same. I think this to be of importance in 
order to promote its usage (and other software vendors could adopt our 
format too). Anything else is IMO not implementable in larger scale 
(Just think about the overhead to configure a web site for the retrieval 
of the config file for each domain name a mail server might serve)
> IMO that would be enough to justify implementing the 
> easier solution ASAP, and work out a solution for the uncommon and more 
> complex cases later.
>   
I'm not sure about this approach. Easy setup for gmail is already 
covered today to some extend, but it's really about providing a good 
solution for years to come. I wouldn't support something which we'd have 
to scrap at the next major release again. There are millions of domain 
names which receive and send mail - the free providers like Google and 
others don't have such a high share as you claim (based on what 
exactly?)...it would be interesting however if there are some reliable 
statistics. David, do you have access to something like this? Maybe 
Google could provide us with some more information (Guess you know whom 
to talk to).

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

0
Eddy
3/6/2008 1:29:17 PM
Hi Simon,

Simon Wilkinson:
>>
>> 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.
>
> I hadn't spotted this part of the proposal until now. As well as the 
> security issues, how does this work in situations where a site has 
> multiple MX records?
Usually a DNS zone has about one or two MX records, with Google (and 
Google hosted domain names for mail) on the extreme having about five to 
six MX record. Each MX record should have a TXT entry for the specific 
MX record. The provider is free to point them all to the same 
configuration file location or to different ones (if he wants to spread 
the load to different servers for example).

> It's entirely possible that machines listed as MXs for a given domain 
> may purely act as 'store-and-forward' servers, and have no 
> administrative connection with the site that they're MXing for. In 
> this case, using their configuration would be completely the wrong 
> thing to do. 
Not really, because they can point all TXT entries to the same config 
file (and URL). The config file is the authority information for 
auto-setup feature. In that case even a forwarding mail server (meaning 
its MX record of course) can have a TXT record pointing to 
https://example.com/isp-conf.rdf exactly as the "real" mail server will 
have the same TXT entry again.

Example:

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


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


Here "mta2" is the forwarding and backup mail server...

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

0
Eddy
3/6/2008 1:41:26 PM
(a little out of it since i've gotten sick, resending this w/o attachment)

I think it might help if we separate out what I'm seeing as a couple 
distinct goals.

(1) Enable users of large web mail services to easily setup and use 
Thunderbird for their email.

(2) Enable smaller ISPs to provide an easy and custom setup script to 
help people use Thunderbird for their ISPs email

(3) Enable people on a custom mail server to easily share account settings.

((1))

I think we have a safe assumption that a large number of people are 
using a small number of web mail providers.  There is also a large 
number of people using a large number of mail systems, but that is case 
(2) or (3).

Since all the people in case (1) are using a small set of domain names, 
we could provide these domain names as choices.  See linked mockup [1].

The mockup is supposed to show a split [ username ] @ [ domain \/ ] 
entry in two different uses, autocomplete of known domain names and 
choosing from the list of known domain names.

In the autocompletion of a known domain name a person has entered their 
email username and is typing in the name of their domain name as an 
autocomplete list pops up helping them to avoid spelling errors.

With the drop down use a person can choose the domain name from the list 
of popular, known domain names.  There is a final choice, "Other..." 
which simply focuses the entry and allows a person to type in whatever 
domain.  Of course the person could have just typed in whatever domain 
name before selecting Other... and it would have worked the same.

So page 1 of the wizard looks something like this:

{Page 1}
Name:     [ Bryan Clark ]
Email:    [ clarkbw+spam ] @ [ gmail \/]

I know it's ideal to have fewer pages, but I think it would be fine to 
have 2 pages with the second page being either a confirm step or a 
manual config step if no auto-ISP configuration was found.

Though I'm not sure that we have it right now... people recognize the 
web URL of their web mail so I think it would be good to show on this 
confirm page.  I'm hoping this will help with tricky situations like 
google.co.uk, googlemail.com, and gmail.com possibly confusing people 
and here we can allow them to double check.

{Page 2}
Account Name:     GMail - clarkbw+spam
Web Mail:    http://mail.google.com/mail/

[ Manual Config ] [ Finish ]

I'd leave the password out for the later password prompt, both so people 
can choose to remember it with the check box and it allows people to 
double check their settings before sending their password off.

The manual config button would allow a person to step through the 
current configuration pages we have.  After stepping through them all 
they would end up back on {Page 2} again.

We might want to include something in {Page 2} showing were we pulled 
the account settings from. For lots of people it will mean nothing, but 
for some people it will be pretty important.  Ex:

Account Settings:    Mozilla Messaging Auto Config
             https://autoconfig.mozillamessaging.com/


I think we could maintain such a list at something like 
https://autoconfig.mozillamessaging.com/ ( perhaps that isn't a good 
assumption but I'd hope it's a decently secure method )

It might make sense to localize the config files so we can show more 
appropriate accounts for different locales, not sure it is necessary.  Ex:
     https://autoconfig.mozillamessaging.com/en-US/config.json


((2))

In this scenario we can assume that our short list of large web mail 
providers doesn't include the domain name our person is looking for.

Either we get the custom config somehow or the next step is the manual 
configuration pages.

For getting the custom configs I saw a lot of systems suggested, most of 
which are pretty technical and I'm not going to touch, but they sound 
cool.  :)

If it's possible to grab the local domain and get a custom config out of 
DNS or some other entry then perhaps we can insert that into the 
autocomplete list.  This way it will look just like all the other major 
providers and the steps are the same.

An alternate method for these ISPs is the extension:
     http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks

((3))

For people sharing their account settings ( a much smaller group of 
people ) I'd like to see a system in the future that allows people to 
easily share their account settings with other people.  This would be 
for the small group of people using a custom mail server system.

A [ Share These Account Settings... ] button on the Account settings 
page which creates an email that person can send to others with an ISP 
extension attached.  Or a way to save your account settings as the the 
extension somewhere on the filesystem.

There are lots of issues that will come up, we'd probably have to drop 
fields that are username / account specific and other things.  However 
there should be a way to empower these small sets of users to 
auto-create these extensions to help others.

Cheers,
~ Bryan

[1] http://clarkbw.net/tmp/large-web-mail-entry.png

Ben Bucksch 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:
0
Bryan
3/7/2008 4:11:58 AM
Peter Lairo wrote, on 2008-03-06 03:46:
> 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 JohnDoe@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.

The whole point of man in the middle attack is that the fake server 
*will* be responding as my-isp.com even though it really is evil-isp.com.

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

Scenario 1: User's computer has a virus on it that has changed the IP 
address of their DNS server to that of ns.evil-isp.com. Now when they 
send a query for the SRV and/or MX records for my-isp.com they get ones 
which say they are for smtp.my-isp.com and imap.my-isp.com but the IPs 
are really for the boxen at *.evil-isp.com.

Scenario 2: Somebody set up a rogue DHCP server on the network so even 
though the user's computer doesn't have a virus it's DNS server is still 
ns.evil-isp.com. Again evil-isp.com's boxen say they are my-isp.com. 
Same result as scenario 1.

Scenario 3: A bottle neck link between the user's computer and 
my-isp.com has been compromised. It's acting as a malicious NAT such 
that all outbound packets for for { smtp | imap }.my-isp.com are 
rerouted to { smtp | imap }.evil-isp.com. Since it is a NAT, the inbound 
packets are reverse altered to make it look like the came from the right 
place. Again evil-isp.com's boxen say they are my-isp.com. Even though 
the user's computer is using the trusted DNS server from my-isp.com, it 
is still contacting the wrong mail servers.

Auto-configuration via DNS records fails in these scenarios because the 
user agent DOES NOT KNOW that it is not talking to the proper servers, 
DNS or mail.

Evil-isp.com sets up a fake domain that pays for their intermediate 
certificate authority's SSL cert to be signed by Verisign, Thawte or any 
  other top level CA cert commonly included with operating systems or 
apps. Then evil-isp.com uses that fake CA to sing fake certs for 
imap.my-isp.com and smtp.my-isp.com. Now even after STARTTLS the 
evil-isp.com servers identify themselves as my-isp.com and there is no 
gotcha of a self-signed cert and the trail leads to a trusted root 
authority.

While auto-config sounds like a neat idea, it is simply too easy to 
spoof the mechanisms already mentioned in this thread.

One could possible make auto-config secure by using SSL certs to sign 
the data in DNS SRV or TX records and/or to verify the certificates 
presented in the secure versions of SMTP, POP3 or IMAP. However, this 
places an added layer of complexity on to the user because that have to 
know what a certificate is and where to install it before they set up 
their email client with their account. Given that your average computer 
user barely even knows what https and how it differs from http, much 
less what a certificate is, I can see how this would be a never-used 
feature.
0
Cory
3/7/2008 6:48:47 PM
On 2008-03-07 06:11, Bryan W Clark wrote:
> ((3))
>
> For people sharing their account settings ( a much smaller group of
> people ) I'd like to see a system in the future that allows people to
> easily share their account settings with other people. This would be for
> the small group of people using a custom mail server system.
>
> A [ Share These Account Settings... ] button on the Account settings
> page which creates an email that person can send to others with an ISP
> extension attached. Or a way to save your account settings as the the
> extension somewhere on the filesystem.

I agree there should be some kind of sharing option. The problem with sending it 
to other thunderbird users by mail is of course, to be able to receive the 
config file in thunderbird, you already must have your account set up.

The reason I would like a moz hosted repository instead, and as the main option, 
is that I have serious doubts ISPs in general would use advanced options like 
those discussed earlier in this group - like via DNS. Not unless we have a much 
larger market share. It's not very hard for ISPs to create an extension with the 
preconfig currently, but I haven't seen/heard many of them doing that.

  -Magnus
0
Magnus
3/7/2008 7:14:18 PM
Cory Albrecht:
> Scenario 1: User's computer has a virus on it that has changed the IP 
> address of their DNS server to that of ns.evil-isp.com. Now when they 
> send a query for the SRV and/or MX records for my-isp.com they get ones 
> which say they are for smtp.my-isp.com and imap.my-isp.com but the IPs 
> are really for the boxen at *.evil-isp.com.
>   
Just to correct you, your example above looks like a reverse lookup was 
preformed, which is obviously not needed. But a regular forward lookup 
would provide the wrong IP for the "my-isp.com" domain name, which in 
turn would send a fraudulent config file.

But at this stage it doesn't matter anymore because the next time you 
log into "my-isp.com" mail server, you are happily supplying the 
user/pass anyway...to the wrong server obviously. For that you don't 
need a fraudulent config file or setup first. It can happen to you right 
now when you reply to this mail. Except in case your settings are 
configured to use SSL secured protocols only (at which stage you would 
receive a warning from TB).
> Scenario 2: Somebody set up a rogue DHCP server on the network so even 
> though the user's computer doesn't have a virus it's DNS server is still 
> ns.evil-isp.com. Again evil-isp.com's boxen say they are my-isp.com. 
> Same result as scenario 1.
>
> Scenario 3: A bottle neck link between the user's computer and 
> my-isp.com has been compromised. It's acting as a malicious NAT such 
> that all outbound packets for for { smtp | imap }.my-isp.com are 
> rerouted to { smtp | imap }.evil-isp.com. Since it is a NAT, the inbound 
> packets are reverse altered to make it look like the came from the right 
> place. Again evil-isp.com's boxen say they are my-isp.com. Even though 
> the user's computer is using the trusted DNS server from my-isp.com, it 
> is still contacting the wrong mail servers.
>   
In short, anything that is compromised and not properly secured will 
have the same effect. Unintentional to this discussion, we should think 
about how to improve this, since on the web users are used and get 
trained over time not to submit anything in plain (default settings of 
Firefox). Why with mail sending passwords in plain is as accepted form I 
don't know, but it is about time to think about how we can improve that 
(for example a severe warning when setting up an account to send 
passwords in plain and unsecured protocols). In this respect I believe 
we should start to mimic the semantics of Firefox (v3).
> Auto-configuration via DNS records fails in these scenarios because the 
> user agent DOES NOT KNOW that it is not talking to the proper servers, 
> DNS or mail.
>
> Evil-isp.com sets up a fake domain that pays for their intermediate 
> certificate authority's SSL cert to be signed by Verisign, Thawte or any 
>   other top level CA cert commonly included with operating systems or 
> apps. Then evil-isp.com uses that fake CA to sing fake certs for 
> imap.my-isp.com and smtp.my-isp.com. Now even after STARTTLS the 
> evil-isp.com servers identify themselves as my-isp.com and there is no 
> gotcha of a self-signed cert and the trail leads to a trusted root 
> authority.
>   
WOWOWO....you have gone way to far here, this scenario isn't even a 
little bit close to reality. I suggest you join m.d.t.crypto for further 
discussion on this subject. But just to refute what you said above, this 
doesn't exists and never happened! Just forget about it, it's complete 
fantasy....
>
> One could possible make auto-config secure by using SSL certs to sign 
> the data in DNS SRV or TX records and/or to verify the certificates 
> presented in the secure versions of SMTP, POP3 or IMAP. However, this 
> places an added layer of complexity on to the user because that have to 
> know what a certificate is and where to install it before they set up 
> their email client with their account.
An added layer for whom? I guess that any operator of an ISP mail server 
has sufficient information to secure the various access points properly. 
The user doesn't have to install any certificate at all.
>  Given that your average computer 
> user barely even knows what https and how it differs from http, much 
> less what a certificate is, I can see how this would be a never-used 
> feature.
Then I suggest to look carefully how FF3 is going to handle this stuff. 
The user is going to be really protected for the first time without all 
this stupid warnings and popups which one clicks away anyway...

For David: In this respect I suggest to request the help of Johnathan 
Nightingale for shaping the next generation of TB. I think this subject 
deserves special attention, perhaps together with the help of the folks 
from the NSS team.

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

0
Eddy
3/7/2008 8:13:16 PM
Magnus Melin:
> The reason I would like a moz hosted repository instead, and as the main option, 
> is that I have serious doubts ISPs in general would use advanced options like 
> those discussed earlier in this group - like via DNS. 
Actually ISPs control DNS servers usually and this their bread and 
butter...What was suggested previously as a possible approach is not 
advanced at all...
> Not unless we have a much 
> larger market share. It's not very hard for ISPs to create an extension with the 
> preconfig currently, but I haven't seen/heard many of them doing that.
>
>   
Writing an extension has a sever overhead compared to adding a DNS 
record, editing and publishing a config file. As an ISP I'll happily use 
it for my clients. I will not write an extension in order to achieve the 
same effect however.

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

0
Eddy
3/7/2008 8:29:21 PM
Bryan W Clark:
> (a little out of it since i've gotten sick, resending this w/o attachment)
>
> I think it might help if we separate out what I'm seeing as a couple 
> distinct goals.
>
> (1) Enable users of large web mail services to easily setup and use 
> Thunderbird for their email.
>
> (2) Enable smaller ISPs to provide an easy and custom setup script to 
> help people use Thunderbird for their ISPs email
>
> (3) Enable people on a custom mail server to easily share account settings.
>   
I think 1 and 2 could/should be merged into one function.
> ((1))
>
> I think we have a safe assumption that a large number of people are 
> using a small number of web mail providers.  There is also a large 
> number of people using a large number of mail systems, but that is case 
> (2) or (3).
>   
This sounds about right. So I analyzed my address book of collected 
address a little bit and surprisingly gmail+yahoo+hotmail make out less 
then 10%. It would be really good if we'd have access to some more 
serious statistics.
>
> Though I'm not sure that we have it right now... people recognize the 
> web URL of their web mail so I think it would be good to show on this 
> confirm page.  I'm hoping this will help with tricky situations like 
> google.co.uk, googlemail.com, and gmail.com possibly confusing people 
> and here we can allow them to double check.
>   
Or confuse them? But they are typing the email in first place, like 
google.co.uk, so perhaps not..
>
> An alternate method for these ISPs is the extension:
>      http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks
>   
This is what we are discussing here all along :-)
Perhaps read the full thread at google groups....
> ((3))
>
> For people sharing their account settings ( a much smaller group of 
> people ) I'd like to see a system in the future that allows people to 
> easily share their account settings with other people.  This would be 
> for the small group of people using a custom mail server system.
>
> A [ Share These Account Settings... ] button on the Account settings 
> page which creates an email that person can send to others with an ISP 
> extension attached.  Or a way to save your account settings as the the 
> extension somewhere on the filesystem.
>
>   
This sounds like a good idea ( minus the password of course). This could 
generate an ISP config file, making it for ISPs even easier to produce 
one (instead of hand editing). That's just an added value to this 
idea...I like it...

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

0
Eddy
3/7/2008 8:40:24 PM
>> Evil-isp.com sets up a fake domain that pays for their intermediate
>> certificate authority's SSL cert to be signed by Verisign, Thawte  
>> or any
>>   other top level CA cert commonly included with operating systems or
>> apps. Then evil-isp.com uses that fake CA to sing fake certs for
>> imap.my-isp.com and smtp.my-isp.com. Now even after STARTTLS the
>> evil-isp.com servers identify themselves as my-isp.com and there  
>> is no
>> gotcha of a self-signed cert and the trail leads to a trusted root
>> authority.
>>
> WOWOWO....you have gone way to far here, this scenario isn't even a
> little bit close to reality.

Does NSS not allow certificate chains, then? Because in a X509 system  
which permits certificate chains, exactly this attack can happen if a  
root you trust signs arbitrary intermediate certificates (simple  
solution: don't trust roots that do that ...)

S.



0
Simon
3/7/2008 9:20:45 PM
Magnus Melin wrote:
> On 2008-03-07 06:11, Bryan W Clark wrote:
>> ((3))
>>
>> For people sharing their account settings ( a much smaller group of
>> people ) I'd like to see a system in the future that allows people to
>> easily share their account settings with other people. This would be for
>> the small group of people using a custom mail server system.
>>
>> A [ Share These Account Settings... ] button on the Account settings
>> page which creates an email that person can send to others with an ISP
>> extension attached. Or a way to save your account settings as the the
>> extension somewhere on the filesystem.
> 
> I agree there should be some kind of sharing option. The problem with 
> sending it to other thunderbird users by mail is of course, to be able 
> to receive the config file in thunderbird, you already must have your 
> account set up.

Actually I was wondering if you had thunderbird installed and someone 
sent you the account extension over web mail, then thunderbird should be 
the application handler for that account extension.  So if I clicked on 
the attachment in my gmail thunderbird would open up to creating my 
email account with those settings.

> The reason I would like a moz hosted repository instead, and as the main 
> option, is that I have serious doubts ISPs in general would use advanced 
> options like those discussed earlier in this group - like via DNS. Not 
> unless we have a much larger market share. It's not very hard for ISPs 
> to create an extension with the preconfig currently, but I haven't 
> seen/heard many of them doing that.

I like the moz hosted one as well, I think it will handle most cases.

~ Bryan
0
Bryan
3/7/2008 9:21:03 PM
Simon Wilkinson:
> Does NSS not allow certificate chains, then? Because in a X509 system  
> which permits certificate chains, exactly this attack can happen if a  
> root you trust signs arbitrary intermediate certificates (simple  
> solution: don't trust roots that do that ...)
>
>   
Simon, with all due respect, but there are no CAs in NSS which sign 
arbitrary intermediate certificates. If you know of any CA doing so 
please forward me the name of the CA and the chained CA certificate. I 
promise to work for its immediate removal from NSS if proven correct.

For now however I suggest to move this specific topic to m.d.t.crypto 
and continue the discussion there if needed. What Thunderbird concerns 
there is no such a thing and the NSS makes explicitly sure that 
something like this never happens.

(PS, I'm subscribed to both m.d.t.crypto and m.d.security and glad to 
answer any question)


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

0
Eddy
3/7/2008 9:50:36 PM
Eddy Nigg (StartCom Ltd.) wrote:
>
>    
> Writing an extension has a sever overhead compared to adding a DNS
> record, editing and publishing a config file. As an ISP I'll happily use
> it for my clients. I will not write an extension in order to achieve the
> same effect however.
>
>    
There's no need for this to be an either-or choice AFAICT.

--david

0
David
3/7/2008 10:54:06 PM
David Ascher:
> Eddy Nigg (StartCom Ltd.) wrote:
>   
>>    
>> Writing an extension has a sever overhead compared to adding a DNS
>> record, editing and publishing a config file. As an ISP I'll happily use
>> it for my clients. I will not write an extension in order to achieve the
>> same effect however.
>>
>>    
>>     
> There's no need for this to be an either-or choice AFAICT.
>
>   
Well, if the proposed "auto-setup-feature" doesn't get implemented we 
are left with what we have now, i.e. not much. Writing an extension 
isn't convenient for smaller to mid-sized ISPs, making it perhaps 
suitable only for the biggest ten or so. It was suggested before by 
somebody else that not many opted to do so in the past. In this respect 
it is an all or nothing approach.

This in turn however affects usage of TB directly because users will be 
left (as currently) to setup their accounts manually with all the trail 
and errors (and call to the helpdesk) included. If however any ISP can 
setup easily a config file and point their customers to Thunderbird, 
like: "Just download and setup Thunderbird, provide the email address 
you received from us and all the rest will be taken care of 
automatically", it might result in substantial gains for TB.

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

0
Eddy
3/7/2008 11:25:43 PM
Eddy Nigg (StartCom Ltd.) wrote:
> Well, if the proposed "auto-setup-feature" doesn't get implemented we 
> are left with what we have now, i.e. not much. Writing an extension 
> isn't convenient for smaller to mid-sized ISPs, making it perhaps 
> suitable only for the biggest ten or so. It was suggested before by 
> somebody else that not many opted to do so in the past. In this 
> respect it is an all or nothing approach.

You've read the thread, you've heard about the other alternatives.  I'm 
not saying that we won't do auto-configuration, only that it's not an 
"either we rely on people to write extensions or we rely on ISPs to do 
DNS tweaks".


> This in turn however affects usage of TB directly because users will 
> be left (as currently) to setup their accounts manually with all the 
> trail and errors (and call to the helpdesk) included. If however any 
> ISP can setup easily a config file and point their customers to 
> Thunderbird, like: "Just download and setup Thunderbird, provide the 
> email address you received from us and all the rest will be taken care 
> of automatically", it might result in substantial gains for TB.

Right.  My point is that for we may not _even_ require the ISP to do 
anything, only user communities to populate config files hosted 
centrally.  But if the ISPs want to help w/ the DNS approach, that's 
fine too.

--david
0
David
3/7/2008 11:30:24 PM
David Ascher:
> Right.  My point is that for we may not _even_ require the ISP to do 
> anything, only user communities to populate config files hosted 
> centrally.  But if the ISPs want to help w/ the DNS approach, that's 
> fine too.
>   
It's an idea which is/was on the table. But do you seriously believe 
that you have the manpower to manage such a repository? Not speaking 
about the added responsibility, overhead  for MoMsg, infrastructure, 
definitions etc etc...

If we can define a standard which scales, is reasonable secure, can be 
implemented by almost anybody running a mail server and can be  adopted 
by other software vendors, than this is IMO the way to go.

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

0
Eddy
3/7/2008 11:44:24 PM
Eddy Nigg (StartCom Ltd.) wrote:
> David Ascher:
>> Right.  My point is that for we may not _even_ require the ISP to do
>> anything, only user communities to populate config files hosted
>> centrally.  But if the ISPs want to help w/ the DNS approach, that's
>> fine too.
>>    
> It's an idea which is/was on the table. But do you seriously believe 
> that you have the manpower to manage such a repository? Not speaking 
> about the added responsibility, overhead  for MoMsg, infrastructure, 
> definitions etc etc...

Indeed I do.  Thus far, I still believe that if we keep the 
configuration data simple and secure, that what we're talking about here 
is a much, much, much simpler problem than AMO, for example.  I also 
know that Tb _today_ has the technology required to do a few HTTPS GETs, 
and that we know how to build a website which maps domains to 
configuration blobs, at scale.  The web works, let's use it.

Leaving aside any security implications, which I don't claim to 
understand fully yet, I think the biggest challenge would be to define 
the process by which these configurations get submitted, updated, etc.  
But I still think it's tractable and a very highly leveraged activity, 
because any motivated user could provide auto-configuration to all the 
other customers of the same ISP.

In terms of responsibility and overhead: I see that responsibility as in 
scope with MoMo's broader responsibility towards Thunderbird users -- 
we're responsible for much more than the code already.  Hence what you 
call overhead I just call "what we should be doing".

> If we can define a standard which scales, is reasonable secure, can be 
> implemented by almost anybody running a mail server and can be  
> adopted by other software vendors, than this is IMO the way to go.

I still maintain that you're framing this as an oppositional debate 
where there is no need.  In the ideal case where both systems are 
implemented, Tb could look for a DNS config, and fallback to the hosted 
one.  I personally don't think the DNS approach is as highly leveraged 
as the hosted one, but I won't stop you from working to define such a 
standard and implement it.

--david


0
David
3/8/2008 12:05:55 AM
Bryan W Clark wrote:
> (a little out of it since i've gotten sick, resending this w/o attachment)
>
> I think it might help if we separate out what I'm seeing as a couple
> distinct goals.
>
> (1) Enable users of large web mail services to easily setup and use
> Thunderbird for their email.
>
> (2) Enable smaller ISPs to provide an easy and custom setup script to
> help people use Thunderbird for their ISPs email
>
> (3) Enable people on a custom mail server to easily share account settings.

These three things seem to mix goals and implementation details, which 
is making it hard for me to think about.  It's also not clear to me what 
exactly a "custom mail server" refers to.  The wiki page also has a lot 
of implementation and goal mixing.  I believe it's going to be extremely 
difficult to try and discuss implementation, goals, and UI in detail all 
at once.

I'd like to propose that we really do have a single high-level goal: to 
make it as easy as possible for as many users as possible to get a 
working Tb configuration.  I suggest that it will be easier to discuss 
this if we segment them into users of:

a) large ISPs (google, yahoo, etc)

This set of users is very large.  Because the number of ISPs is small, a 
hard-coded list could work pretty well.  Having the list be updatable 
would be nice, but probably not a blocker.

b) smaller ISPs

I suspect this set of users is moderate-sized.  The number of ISPs in 
this set is seems likely to be large enough that if a set of config 
files is to be maintained, we'd want some set of shared infrastructure 
at MoMo to allow a larger community to submit, edit, and publish these.

c) non-public servers
c1) intranets
c2) personal servers

These require some other mechanism for provision of config files: 
perhaps DNS-based auto-discovery as discussed elsewhere in this thread. 
  Peer-to-peer config publishing via email, as proposed by Brian is also 
likely to be useful here, if the DNS admins don't prioritize setting up 
the necessary records, as sometimes happens in intranets.

Do people feel that this does a reasonable job of capturing the various 
needs to be met?

I haven't responded to any of the UI or implementation stuff yet, 
because I think we need to get some consensus here first.

Dan
0
Dan
3/8/2008 12:08:08 AM
David Ascher:
> In terms of responsibility and overhead: I see that responsibility as in 
> scope with MoMo's broader responsibility towards Thunderbird users -- 
> we're responsible for much more than the code already. 
Absolutely!
>  Hence what you 
> call overhead I just call "what we should be doing".
>   
OK, be my guest ;-)
>
> I still maintain that you're framing this as an oppositional debate 
> where there is no need.  In the ideal case where both systems are 
> implemented, Tb could look for a DNS config, and fallback to the hosted 
> one.  I personally don't think the DNS approach is as highly leveraged 
> as the hosted one, but I won't stop you from working to define such a 
> standard and implement it.
Actually what I proposed is a mix of the two and IMO obviously the right 
thing to do...For clarity I'm going to add it to the wiki page. It's 
still a hosted file over SSL with discovery via DNS. That's what it's 
all about.

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

0
Eddy
3/8/2008 12:21:52 AM
Dan Mosedale:
> These require some other mechanism for provision of config files: 
> perhaps DNS-based auto-discovery as discussed elsewhere in this thread. 
>   Peer-to-peer config publishing via email, as proposed by Brian is also 
> likely to be useful here, if the DNS admins don't prioritize setting up 
> the necessary records, as sometimes happens in intranets.
>
> I haven't responded to any of the UI or implementation stuff yet, 
> because I think we need to get some consensus here first.
>
>   
Dan, I've added the following to the 
http://wiki.mozilla.org/Tb:Autoconfiguration#DNS_based_discovery page. 
Please have a look.

I think this proposal has the following advantages:

1.) Unified standard for all ISPs.
2.) Unified UI implementation possible.
3.) Uses existing infrastructures, protocols and transport layers.
4.) Reasonable secure.
5.) Highly scalable for public Internet and Intranet alike.
6.) Decentralized and autonomous.

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

0
Eddy
3/8/2008 1:47:18 AM
On 8 Mar 2008, at 01:47, Eddy Nigg (StartCom Ltd.) wrote:

> Dan Mosedale:
>> These require some other mechanism for provision of config files:
>> perhaps DNS-based auto-discovery as discussed elsewhere in this  
>> thread.
>>   Peer-to-peer config publishing via email, as proposed by Brian  
>> is also
>> likely to be useful here, if the DNS admins don't prioritize  
>> setting up
>> the necessary records, as sometimes happens in intranets.
>>
>> I haven't responded to any of the UI or implementation stuff yet,
>> because I think we need to get some consensus here first.
>>
>>
> Dan, I've added the following to the
> http://wiki.mozilla.org/Tb:Autoconfiguration#DNS_based_discovery page.
> Please have a look.

As I've said before I think this proposal has two significant issues.  
It breaks (and breaks badly) for sites with complicated MX record  
setups, and the use of https provides no significant security benefit.

The first issue is that complicated mail domain configurations have  
no guarantee that listed MX records are actually endpoints for mail  
traffic for that site - sites may list non-local primary MXs to act  
as store-and-forward services, or have non-local secondary MXs which  
act as backups. In all cases these non-local MXs probably also handle  
mail for their own domains. In the proposed scheme if any of these  
non-local sites added TXT records for their own users, and the local  
site didn't have such records, then users of the local site would be  
directed to the wrong hosts. It also doesn't allow for ISPs which  
handle all incoming mail for vanity domains with a single mail  
server, but give each vanity domain its own pop3/imap server name -  
there's no way for them to configure such as system, because the MX  
records for all of the vanity domains would point at that single server.

I think you could work round that problem by simply avoiding the need  
to perform the MX record lookup. Just define the TXT record as being  
stored in the DNS root for that domain, in the same way as MX records  
are. That way, you've got one record per domain. There are, however,  
issues with the size of the root growing beyond the size of a UDP  
packet, which can cause some MTAs (well, qmail) to fail to deliver  
mail to that domain. The way around this is to look at the way that  
other IETF protocols using TXT records for autoconfiguration work -  
in general there is a known 'host tag' which is used (for example,  
kerberos realm information may be determined by looking up  
_kerberos.DNS.DOMAIN).

The second issue is one that lots of people have been pointing out.  
By failing to have a binding between the domain of the user, and the  
name of the server from which the configuration information is  
fetched, there's no advantage to requiring that SSL be used on this  
link - an attacker simply subverts the DNS, rather than the HTTP,  
connection.

Cheers,

Simon.
0
Simon
3/8/2008 11:17:41 AM
Simon Wilkinson:
>
> As I've said before I think this proposal has two significant issues. 
> It breaks (and breaks badly) for sites with complicated MX record 
> setups, and the use of https provides no significant security benefit.

I'm aware of your opposition and gladly willing to learn from your 
expertise...

> In the proposed scheme if any of these non-local sites added TXT 
> records for their own users, and the local site didn't have such 
> records, then users of the local site would be directed to the wrong 
> hosts. 

Which would be a failure by the operator obviously...

> It also doesn't allow for ISPs which handle all incoming mail for 
> vanity domains with a single mail server, but give each vanity domain 
> its own pop3/imap server name - there's no way for them to configure 
> such as system, because the MX records for all of the vanity domains 
> would point at that single server.
It could be made possible by having TB include referrer information in 
the GET header when fetching the config file. The config file could, 
based on the referrer information, be produced dynamically by a 
scripting language. This is actually an interesting point and I'm going 
to add it to the definition proposal.

>
> I think you could work round that problem by simply avoiding the need 
> to perform the MX record lookup. Just define the TXT record as being 
> stored in the DNS root for that domain, in the same way as MX records 
> are. That way, you've got one record per domain.

This would be very, very inconvenient and not needed. Larger ISPs would 
have to add for every domain name the mail server handles an extra 
record. Instead of adding one or two record to the corresponding MX 
pointer. For example, all a provider like Google would have to do is, 
add about 5 TXT records to their DNS zones. On the other hand you 
propose to have Google add for every domain name they handle such a 
record (or let the owner of the domain name handle it which is failure 
prone). This is a no-go...

> There are, however, issues with the size of the root growing beyond 
> the size of a UDP packet, which can cause some MTAs (well, qmail) to 
> fail to deliver mail to that domain.

This has nothing to do with this proposal. This is clearly defined in 
the relating RFCs.
>
> The second issue is one that lots of people have been pointing out. By 
> failing to have a binding between the domain of the user, and the name 
> of the server from which the configuration information is fetched, 
> there's no advantage to requiring that SSL be used on this link - an 
> attacker simply subverts the DNS, rather than the HTTP, connection. 
And it has been pointed out, that if this happened you are already 
doomed anyway, except in case the account is setup to strictly use SSL 
(no "use TLS if available" and such stuff). Requiring the site from 
which the config file is servedchained to a trusted root and a dialog 
with the config file location shown will improve it. Alternatively we 
could require to have the config file signed by a code signing 
certificate. Guess you don't want that.

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

0
Eddy
3/8/2008 12:09:46 PM
On 8 Mar 2008, at 12:09, Eddy Nigg (StartCom Ltd.) wrote:
>
>> In the proposed scheme if any of these non-local sites added TXT  
>> records for their own users, and the local site didn't have such  
>> records, then users of the local site would be directed to the  
>> wrong hosts.
>
> Which would be a failure by the operator obviously...

The problem is that it's not a failure that's under the control of  
the affected operator. In the situation I outline domain B may have  
MX records that list mail.A, mail.B, mail.C (in that order) as the  
mail servers for that domain. Only 'B' is directly under their  
control - they just have peering agreements with A and C. In your  
model, either A or C adding TXT records will break B.

>> It also doesn't allow for ISPs which handle all incoming mail for  
>> vanity domains with a single mail server, but give each vanity  
>> domain its own pop3/imap server name - there's no way for them to  
>> configure such as system, because the MX records for all of the  
>> vanity domains would point at that single server.
> It could be made possible by having TB include referrer information  
> in the GET header when fetching the config file.

Doing this through the referrer seems like a horrible kludge. You  
could add some mechanism for paramaterising the URL within the spec,  
but that should be explicit within the URL being fetched.

>> I think you could work round that problem by simply avoiding the  
>> need to perform the MX record lookup.
>
> This would be very, very inconvenient and not needed. Larger ISPs  
> would have to add for every domain name the mail server handles an  
> extra record. Instead of adding one or two record to the  
> corresponding MX pointer.

But it is needed. As I've outlined using MX records conflates  
delivery with access. On many networks these are two completely  
different tasks, handled by different hardware, configured in  
different ways. Overloading MX records to provide access information  
is conceptually broken.

>  Requiring the site from which the config file is servedchained to  
> a trusted root and a dialog with the config file location shown  
> will improve it.

It doesn't improve it. Ultimately, it's snake oil unless the user can  
be relied upon to correctly validate the information in the dialog -  
and all of the user experience testing that Firefox has done suggests  
that's not the case.

> Alternatively we could require to have the config file signed by a  
> code signing certificate. Guess you don't want that.

I don't mind the signing of the config file, if there's a way of  
verifying that the entity which signed the file is authorised to act  
on behalf of the domain that the file provides configuration for. I  
suspect that this would be unworkable in practice, and so it's hard  
to see what security value having the config file signed would  
actually convey.

To clarify: I  don't have strong views on the security requirements  
for obtaining the configuration file. I think that further discussion  
around this is required. However, I do think that if we are mandating  
certain security measures, then those security measures should  
actually have an effect on the overall security of the file's  
delivery. The requirement for https in this proposal has no such effect.

Simon.

0
Simon
3/8/2008 12:35:15 PM
Simon Wilkinson:
>
> The problem is that it's not a failure that's under the control of  

Simon, at this stage I suggest you make your own proposal for a better 
alternative.

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

0
Eddy
3/8/2008 1:15:13 PM
David Ascher wrote:
> Leaving aside any security implications, which I don't claim to
> understand fully yet, I think the biggest challenge would be to define
> the process by which these configurations get submitted, updated, etc.
> But I still think it's tractable and a very highly leveraged activity,
> because any motivated user could provide auto-configuration to all the
> other customers of the same ISP.

Well, you realize that a not-so-small number of ISPs have setups with 
i.e. my.real.name@isp.tld needing a login including the customer id 
number that is completely different from my.real.name on their mail 
server? Does that mean you will host a different file for every user and 
effectively the data of realting all customer IDs to their email 
addresses on your servers? Do you realize that this can be a privacy 
problem?

Or will entering the email not be enough to get configured and the user 
needs to enter the customer ID as well, or maybe even some additional 
info that we need to find the right config? Then, do we have a clue for 
a spec to make this generic enough?

The easier way for doing this would probably be to hand off the requests 
to the ISP which has all the data and can probably figure out all needed 
config from the user's email.

Robert Kaiser
0
Robert
3/8/2008 1:27:08 PM
On 8 Mar 2008, at 13:15, Eddy Nigg (StartCom Ltd.) wrote:

> Simon Wilkinson:
>>
>> The problem is that it's not a failure that's under the control of
>
> Simon, at this stage I suggest you make your own proposal for a better
> alternative.

I don't think that the problem is sufficiently clearly defined to  
design an implementation mechanism in detail. If we do end up looking  
to define a cross-agent technology, in particular one that hooks into  
existing systems such as the DNS, I think we should be seeking to  
involve external bodies when we do produce that design.

Before we move to implementation, I think a better scoping of the  
problem would be extremely beneficial. To that end, I'd like to pose  
a number of questions ...

1) What are the goals?

We've currently got:
"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."

This seems like a good high level goal, that we can all agree on. I  
think that it would be good to discuss the priority of some other  
issues here, too. Off the top of my head
*) Are we aiming for universal coverage? Is a simple solution that  
solves the problem for 80% of users preferable to a complex one that  
aims for 100% applicability?
*) Where do we place the trade off between configuration simplicity  
and user security? How worried are we about attacks that may occur  
during the configuration process?
*) Where do we place the trade off between centralisation and  
distribution? What level of support do we want to expect, or require,  
from individual ISPs?
*) Are we aiming for a cross-platform, or thunderbird specific,  
solution?

2) What information is necessary to achieve these goals?

A list of the fields that we seek to auto populate would be useful in  
order to get an idea of the kind of information we're intending on  
auto configuring. For example, are we going to permit all of the  
fields that are in the current isp RDF files, or are we only  
interested in a subset of these? Are we interested solely in features  
that control Thunderbird's initial discovery of the servers, or are  
we wanting to be able to control every aspect of that account's  
configuration?

3) What methods are available for discovering this information?

Many of the protocols we support allow auto-discovery of features. It  
would be good to get a handle on how many of the fields we wish to  
autofill can be populated soley by interacting with the end point  
server, or by deriving information from that submitted by the user  
(for example, assuming that username == email address). We should  
also consider the complications (for example, Robert Kaiser's point  
about ISPs where username == random customer ID).

I think that it's only once we've properly defined the problem space  
that we can clearly evaluate the benefits, and threats, of the  
various solutions.
My gut feeling is that there will be no one-size fits all solution,  
and it may be that a simple solution that solves the problem for 80%  
of users (especially if that 80% are the non-technically savvy users)  
is better than a complex solution that tries for 100% coverage.

Simon.

0
Simon
3/8/2008 1:54:55 PM
Eddy Nigg (StartCom Ltd.) wrote, on 2008-03-07 15:13:
> Cory Albrecht:
>> Scenario 1: User's computer has a virus on it that has changed the IP 
>> address of their DNS server to that of ns.evil-isp.com. Now when they 
>> send a query for the SRV and/or MX records for my-isp.com they get 
>> ones which say they are for smtp.my-isp.com and imap.my-isp.com but 
>> the IPs are really for the boxen at *.evil-isp.com.
>>   
> Just to correct you, your example above looks like a reverse lookup was 
> preformed, which is obviously not needed. But a regular forward lookup 
> would provide the wrong IP for the "my-isp.com" domain name, which in 
> turn would send a fraudulent config file.

No, it's not a reverse look up. A reverse lookup is where you have an IP 
address and you want to know what name goes with it. Doing an PTR 
request to the DNS server rather than an A or AAAA request.

The system's preferred DNS server IP has been replaced by the IP of a 
malicious server. I.e. the user's DNS Server was 1.2.3.4, which would be 
ns.my-isp.com, but the virus has changed it to 4.3.2.1, which is 
ns.evil-isp.com.

> But at this stage it doesn't matter anymore because the next time you 
> log into "my-isp.com" mail server, you are happily supplying the 
> user/pass anyway...to the wrong server obviously. For that you don't 
> need a fraudulent config file or setup first. It can happen to you right 
> now when you reply to this mail. Except in case your settings are 
> configured to use SSL secured protocols only (at which stage you would 
> receive a warning from TB).

Not necessarily. If evil-isp.com has made self-signed certificates for 
their malicious mail server Thunderbird isn't going to complain. I used 
to use self-signed certs for running my SMTP, POP3 & IMAP servers before 
I set up my own miniature certificate authority. I do not remember TB 
ever complaining or alerting me.

And if TB3 would complain about a self signed certificate, do you really 
think the Average Joe computer user is going to do anything but click on 
OK to continue? And if that complaint pops up every time the user 
connects to get their email it would become annoying very fast. Me, I'd 
probably stop using that mail client.

>> Scenario 2: Somebody set up a rogue DHCP server on the network so even 
>> though the user's computer doesn't have a virus it's DNS server is 
>> still ns.evil-isp.com. Again evil-isp.com's boxen say they are 
>> my-isp.com. Same result as scenario 1.
>>
>> Scenario 3: A bottle neck link between the user's computer and 
>> my-isp.com has been compromised. It's acting as a malicious NAT such 
>> that all outbound packets for for { smtp | imap }.my-isp.com are 
>> rerouted to { smtp | imap }.evil-isp.com. Since it is a NAT, the 
>> inbound packets are reverse altered to make it look like the came from 
>> the right place. Again evil-isp.com's boxen say they are my-isp.com. 
>> Even though the user's computer is using the trusted DNS server from 
>> my-isp.com, it is still contacting the wrong mail servers.

> In short, anything that is compromised and not properly secured will 
> have the same effect. Unintentional to this discussion, we should think 
> about how to improve this, since on the web users are used and get 
> trained over time not to submit anything in plain (default settings of 
> Firefox). Why with mail sending passwords in plain is as accepted form I 
> don't know, but it is about time to think about how we can improve that 
> (for example a severe warning when setting up an account to send 
> passwords in plain and unsecured protocols). In this respect I believe 
 > we should start to mimic the semantics of Firefox (v3).

While I agree with everything you say here, it really only is for 
communicating with a known & trusted server for which you have already 
set up an account in TB. Auto-configuration is different because you do 
not already know the server. There seem to me to be too many ways for 
things to be subverted in auto-config unless the user already has a 
trusted copy of the server's certificate in hand before starting.

>> Auto-configuration via DNS records fails in these scenarios because 
>> the user agent DOES NOT KNOW that it is not talking to the proper 
>> servers, DNS or mail.

>> Evil-isp.com sets up a fake domain that pays for their intermediate 
>> certificate authority's SSL cert to be signed by Verisign, Thawte or 
>> any   other top level CA cert commonly included with operating systems 
>> or apps. Then evil-isp.com uses that fake CA to sing fake certs for 
>> imap.my-isp.com and smtp.my-isp.com. Now even after STARTTLS the 
>> evil-isp.com servers identify themselves as my-isp.com and there is no 
>> gotcha of a self-signed cert and the trail leads to a trusted root 
>> authority.

> WOWOWO....you have gone way to far here, this scenario isn't even a 
> little bit close to reality. I suggest you join m.d.t.crypto for further 
> discussion on this subject. But just to refute what you said above, this 
> doesn't exists and never happened! Just forget about it, it's complete 
> fantasy....

Why is it complete fantasy? Maybe it is expensive, but there is nothing 
preventing me from doing that.

>> One could possible make auto-config secure by using SSL certs to sign 
>> the data in DNS SRV or TX records and/or to verify the certificates 
>> presented in the secure versions of SMTP, POP3 or IMAP. However, this 
>> places an added layer of complexity on to the user because that have 
>> to know what a certificate is and where to install it before they set 
>> up their email client with their account.

> An added layer for whom? I guess that any operator of an ISP mail server 
> has sufficient information to secure the various access points properly. 
> The user doesn't have to install any certificate at all.

An added layer for the user. The user has to have the their ISP's 
certificate to be able to verify the signature of the data returned in 
the TXT record used for auto-config. If the user does not have that 
certificate, they cannot verify that the data comes from a trusted source.

>>  Given that your average computer user barely even knows what https 
>> and how it differs from http, much less what a certificate is, I can 
>> see how this would be a never-used feature.

> Then I suggest to look carefully how FF3 is going to handle this stuff. 
> The user is going to be really protected for the first time without all 
> this stupid warnings and popups which one clicks away anyway...

> For David: In this respect I suggest to request the help of Johnathan 
> Nightingale for shaping the next generation of TB. I think this subject 
> deserves special attention, perhaps together with the help of the folks 
> from the NSS team.
0
Cory
3/8/2008 8:17:55 PM
Hi Cory,

Cory Albrecht:
>
>
> The system's preferred DNS server IP has been replaced by the IP of a 
> malicious server. I.e. the user's DNS Server was 1.2.3.4, which would be 
> ns.my-isp.com, but the virus has changed it to 4.3.2.1, which is 
> ns.evil-isp.com.
>   
Yes sorry, I didn't paid attention closely enough. However if the virus 
succeeded to change a file (or the IP of the DNS servers in memory) it's 
about too late anyway...DNS poisoning is still the preferred attack 
vector without compromising the systems of end users.
> Not necessarily. If evil-isp.com has made self-signed certificates for 
> their malicious mail server Thunderbird isn't going to complain. I used 
> to use self-signed certs for running my SMTP, POP3 & IMAP servers before 
> I set up my own miniature certificate authority. I do not remember TB 
> ever complaining or alerting me.
>   
Yes, it certainly will alert you! Your assumptions are not correct. Most 
likely you either accepted the server certificate forever at some point 
or imported the CA certificate. TB even screamed at me when the IMAP 
server didn't supplied the complete CA chain ;-)
> And if TB3 would complain about a self signed certificate, do you really 
> think the Average Joe computer user is going to do anything but click on 
> OK to continue? 
No, not really...if you give it such an option. Simply refusing to 
continue would solve that particular issue, or at least make it 
difficult to overcome.
> And if that complaint pops up every time the user 
> connects to get their email it would become annoying very fast. Me, I'd 
> probably stop using that mail client.
>   
I suggest you have a look at the upcoming FF3 about how SSL related 
errors are handled. The above is going to be a thing of the past and I 
expect other browser vendors to follow...
>
> While I agree with everything you say here, it really only is for 
> communicating with a known & trusted server for which you have already 
> set up an account in TB. Auto-configuration is different because you do 
> not already know the server. There seem to me to be too many ways for 
> things to be subverted in auto-config unless the user already has a 
> trusted copy of the server's certificate in hand before starting.
>   

Whatever I boiled up is reasonable secure, not 100% and not perfect. 
It's a risk TB is either to going to take or drop the idea altogether I 
guess.

Just a by-note, that TB ships with NSS and its set of approved CAs. I 
think this should be sufficient for now.
>
> Why is it complete fantasy? Maybe it is expensive, but there is nothing 
> preventing me from doing that.
>
>   
I replied to that already elsewhere and proposed, that if you found a CA 
certificate chained to one of the trusted roots in NSS which issues 
faked certificates please provide me with all the details you have.
>
> An added layer for the user. The user has to have the their ISP's 
> certificate to be able to verify the signature of the data returned in 
> the TXT record used for auto-config. If the user does not have that 
> certificate, they cannot verify that the data comes from a trusted source.
>   
I don't think that's necessary, rather require a valid certificate (in 
every respect ) for the web server and  visually displaying of the 
config/setup file location. I know, it's not perfect, but it's certainly 
better then just doing plain. Or what alternative would you suggest?

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

0
Eddy
3/8/2008 8:54:29 PM
Eddy Nigg (StartCom Ltd.) wrote, on 2008-03-08 15:54:
>> The system's preferred DNS server IP has been replaced by the IP of a 
>> malicious server. I.e. the user's DNS Server was 1.2.3.4, which would 
>> be ns.my-isp.com, but the virus has changed it to 4.3.2.1, which is 
>> ns.evil-isp.com.

> Yes sorry, I didn't paid attention closely enough. However if the virus 
> succeeded to change a file (or the IP of the DNS servers in memory) it's 
> about too late anyway...DNS poisoning is still the preferred attack 
> vector without compromising the systems of end users.

True enough. However, I was just trying to give examples of a 
man-in-the-middle attack which I felt that OP hadn't fully understood.

>> Not necessarily. If evil-isp.com has made self-signed certificates for 
>> their malicious mail server Thunderbird isn't going to complain. I 
>> used to use self-signed certs for running my SMTP, POP3 & IMAP servers 
>> before I set up my own miniature certificate authority. I do not 
>> remember TB ever complaining or alerting me.

> Yes, it certainly will alert you! Your assumptions are not correct. Most 
> likely you either accepted the server certificate forever at some point 
> or imported the CA certificate. TB even screamed at me when the IMAP 
> server didn't supplied the complete CA chain ;-)

No, I was thinking of that times I had reinstalled Windows XP from 0 and 
then proceded to reinstall all my favourite apps. I remember TB 
complaining if the certificate was for bytor.fenris.cjb.net and I was 
accessing it as mail.fenris.cjb.net, but not after I made a cert with 
the proper name in it. I hope I can remember to chethe next time when 
(not if!) I have to reinstall XP.

>> And if TB3 would complain about a self signed certificate, do you 
>> really think the Average Joe computer user is going to do anything but 
>> click on OK to continue? 

> No, not really...if you give it such an option. Simply refusing to 
> continue would solve that particular issue, or at least make it 
> difficult to overcome.

Yes, you're right, but I think that would instead be a barrier to use 
for average joe. "WTF? Whaddya mean you won't make my account? I'm going 
back to Outlook!"

>> And if that complaint pops up every time the user connects to get 
>> their email it would become annoying very fast. Me, I'd probably stop 
>> using that mail client.

> I suggest you have a look at the upcoming FF3 about how SSL related 
> errors are handled. The above is going to be a thing of the past and I 
> expect other browser vendors to follow...

I've tried TB3 recently, but I have yet to try FFX3 - thanks for the 
pointer.

>> While I agree with everything you say here, it really only is for 
>> communicating with a known & trusted server for which you have already 
>> set up an account in TB. Auto-configuration is different because you 
>> do not already know the server. There seem to me to be too many ways 
>> for things to be subverted in auto-config unless the user already has 
>> a trusted copy of the server's certificate in hand before starting.

> Whatever I boiled up is reasonable secure, not 100% and not perfect. 
> It's a risk TB is either to going to take or drop the idea altogether I 
> guess.

I will admit to being overly paranoid in this instance and grasping for 
"perfect" security, which is impossible, rather simply "acceptable" 
security. I'm addicted to being the devil's advocate and pointing out 
all problems no matter how small. :-)

>> An added layer for the user. The user has to have the their ISP's 
>> certificate to be able to verify the signature of the data returned in 
>> the TXT record used for auto-config. If the user does not have that 
>> certificate, they cannot verify that the data comes from a trusted 
>> source.

> I don't think that's necessary, rather require a valid certificate (in 
> every respect ) for the web server and  visually displaying of the 
> config/setup file location. I know, it's not perfect, but it's certainly 
> better then just doing plain. Or what alternative would you suggest?

Continuing as devil's advocate...

But what if the poisoned nameserver sends them to a false website in the 
TXT record? or what if they had a rogue DHCP server on the network which 
gave them a bad preferred DNS IP which again gave them a fake TX record? 
  So now TB requests that page and the cert matches the hostname in the 
URL and TB doesn't complain.

And what of small-biz.com having a TXT record like this:

small-biz.com.  IN TXT "mailconf=https://www.small-isp.com/mailconf"

Does TB say "Email domain and configuration url do not match. Continue 
anyways?" Because you know that virtually everybody will choose yes. And 
if you make TB refuse to continue, then that prevents the plethora of 
small businesses who have their email hosted by an ISP but who do not 
have a website of their own.

In normal situations I think this a neat idea, but it doesn't seem to 
offer much protection against compromise. So the server at the url has a 
valid cert, but what if TB, the above situations, got

small-biz.com.  IN TXT "mailconf=https://www.evil-isp.com/mailconf"

No doubt evil-isp.com has valid SSL certs for itself, and our intrepid 
user is pooched. Even if he does run a virus checker and cleans his 
system, TB is still going to the wrong place for his mail. Average Joe 
would never realize that he needs to reverify his email server.

This is why I suggest the digital signature in the TXT record. Give it a 
second parameter:

small-biz.com. IN TXT "mailconf=<https://www.evil-isp.com/mailconf>; 
security=..."

where signature= is the config URL encrypted with smal-isp.com's SSL cert.

As part of the auto-config, TB could ask "Do you have a digital 
signature to verify auto-config with?" Average Joe goes "Oh! My ISP gave 
me this CD...", pops it in the drive, selects "Yes". TB asks "What 
folder is it in?" and gives Joe a familiar browsing window so he can 
choose D: for his CD drive. TB looks for mail-auto-config.crt which is a 
copy of his ISP's public SSL certificate and uses that to decrypt the 
security field in the TXT record. If it matches the mailconf field 
things are OK. The hypothetical evil-isp.com could copy that static 
encrypted field but the decrypted result would never match their faked 
mailconf field. They could put some new encrypted data in the security 
field, but it would only result in gibberish when decrypted by the known 
key. TB could possibly add that known cert to the list of trusted 
authorities.

If Joe says "No" he doesn't have a cert, TB warns him that things can't 
be verified, blah, blah, blah. You know that Joe's going to chose the 
continue option, anyways, but that is probably the best which can be done.
0
Cory
3/8/2008 10:37:37 PM
Cory Albrecht:
>
> No, I was thinking of that times I had reinstalled Windows XP from 0 and 
> then proceded to reinstall all my favourite apps. I remember TB 
> complaining if the certificate was for bytor.fenris.cjb.net and I was 
> accessing it as mail.fenris.cjb.net, but not after I made a cert with 
> the proper name in it. I hope I can remember to chethe next time when 
> (not if!) I have to reinstall XP.
>   
No need to re-install. Just go to "Preferences -> Advanced -> 
Certificates -> View Certificates" and check at the "web sites" or 
"other peoples" tab, if you have a certificate for this domain. Remove 
it and see what happens. But guess you'll have the opportunity to 
reinstall your Windoze at some point anyway ;-)
> Yes, you're right, but I think that would instead be a barrier to use 
> for average joe. "WTF? Whaddya mean you won't make my account? I'm going 
> back to Outlook!"
>   
And how did Joe configure his Outlook? Manually? Do the same here then...

....but it really will teach operators to install the config file 
correctly. The same thing which is going to happen with FF3...which is 
the tendency of the industry to follow this path more or less.
>
> I've tried TB3 recently, but I have yet to try FFX3 - thanks for the 
> pointer.
>
>   
FF3 beta 4 should be out pretty soon...check next week ;-)
>
> I will admit to being overly paranoid in this instance and grasping for 
> "perfect" security, which is impossible, rather simply "acceptable" 
> security. 
>   
Thanks for admitting! It makes it easier to find a common ground.
Lets continue with your arguments below...
>
> But what if the poisoned nameserver sends them to a false website in the 
> TXT record? or what if they had a rogue DHCP server on the network which 
> gave them a bad preferred DNS IP which again gave them a fake TX record? 
>   So now TB requests that page and the cert matches the hostname in the 
> URL and TB doesn't complain.
>
> And what of small-biz.com having a TXT record like this:
>
> small-biz.com.  IN TXT "mailconf=https://www.small-isp.com/mailconf"
>
> Does TB say "Email domain and configuration url do not match. Continue 
> anyways?" 

Actually this will be the expected behavior (without poisoning the DNS 
cache), considering that MX records don't have to match the email 
address at all. There will be no such call as you mentioned above.

However we might think about ways how to improve it. I suggested a valid 
SSL secured host aka FF3 behavior and also to display the configuration 
URL before the account is actually setup. Helpful? Maybe...

> So the server at the url has a valid cert, but what if TB, the above situations, got
>
> small-biz.com.  IN TXT "mailconf=https://www.evil-isp.com/mailconf"
>   

We could try to find the MX and TXT records from multiple DNS servers 
(lets say three different sources) and if one of them doesn't match to 
consider it a failure. From experience this might improve against this 
sort of compromise since DNS poisoning are mostly short lived as far as 
I know. A third party server might have a cached result, prompting a 
failure.

What I'm trying to do is using the existing infrastructures. Obviously 
it's not helpful to expect signed DNS responses aka DNSSEC for our 
purpose...so I'm looking for a way around to make it stealth for you ;-)
> small-biz.com. IN TXT "mailconf=<https://www.evil-isp.com/mailconf>; 
> security=..."
>
> where signature= is the config URL encrypted with smal-isp.com's SSL cert.
>   

Actually this is a fine idea, but what prevents evil.com from doing the 
same?
> As part of the auto-config, TB could ask "Do you have a digital 
> signature to verify auto-config with?" Average Joe goes "Oh! My ISP gave 
> me this CD...", pops it in the drive, selects "Yes". TB asks "What 
> folder is it in?" and gives Joe a familiar browsing window so he can 
> choose D: for his CD drive. TB looks for mail-auto-config.crt which is a 
> copy of his ISP's public SSL certificate and uses that to decrypt the 
> security field in the TXT record. If it matches the mailconf field 
> things are OK. 
Well, this would be totally overkill. The overall goal of easy setup 
would be missed here...
> TB could possibly add that known cert to the list of trusted 
> authorities.
Oh no, we shouldn't encourage that without the user explicitly knowing 
what he does.


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

0
Eddy
3/9/2008 1:56:50 AM
Ben Bucksch skrev:
> Objective: Make my non-tech friends use Thunderbird, by making it 
> dead-simple to set up.
> 
> ...

Where I live there are two main types of e-mail accounts. The first is 
webmails like GMail and Hotmail. The second type and largest type are 
e-mails bound to ADSL connections. The biggest broadband ISPs in my 
country share around 50 domain names for e-mail addresses. That means 
that for one domain extracted from the e-mail address, there are at 
least five different possible ISPs with totally different account setups.

Ben Bucksch said:
> 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. 

Well, that kills allot of speculation about DNS and setup files provided 
by ISPs, I think.

I have another proposal. It does not go as far as other's, but I think 
it puts a much lower requirement on the ISPs while still making account 
setup simpler.

+--------------------------------------------------+
| *Account Setup*                                  |
~                                                  ~
| (o) E-Mail account                               |
|                                                  |
|      Account name:   [My E-mail account        ] |
|      Incoming URL:   [imaps://host:123/foo   |v] |
|      Username:       [me@host                  ] |
|      Password:       [******                   ] |
|                                                  |
|      Your name:      [John Smith               ] |
|      E-mail address: [me@host                  ] |
|      Outgoing URL:   [smtp://host            |v] |
|      Username:       [me@host                  ] |
|      Password:       [******                   ] |
|                                                  |
| ( ) RSS News Feeds and Blogs                     |
| ( ) Newsgroup account                            |
|                                                  |
|                            [ Done ]  [ Cancel ]  |
+--------------------------------------------------+


The setup is one page only.

Everything the user needs to get from the ISP is concatenated into one 
string (URL), except username and password. The username is often the 
only thing which changes from user to user, and we should neither 
require ISPs to make interactive guides nor require users to understand 
the URLs, thus it is a separate field.

In the URL fields, the user should be able to (a) copy-paste an account 
URL, (b) enter an ISP name and get suggestions from some Mozilla server, 
(c) click the drop down arrow to choose from a list of the X most 
popular ISPs or (d) click the dropdown and click "Manual configuration" 
to see the old wizard for ISPs which haven't updated their guides yet.

The username and password fields should be disabled for the outgoing 
server if the outgoing URL does not indicate that a username/password 
should be used.

The only thing ISPs has to do is to update their existing manuals.

The URL format should be standardized.

Thunderbird might register a sheme with the OS such that a link like
e-mail-account:imaps://host:123/foo
would bring up the account wizard with the URL prefilled.

(I have tried to read everything except the DNS security discussion. If 
I nave missed something essential and this has been said before, I 
apologize)
0
Jesper
3/9/2008 5:56:59 PM
Jesper Kristensen:
> Thunderbird might register a sheme with the OS such that a link like
> e-mail-account:imaps://host:123/foo
> would bring up the account wizard with the URL prefilled.
>   
This is usually exactly the part when regular users are calling their 
friends or the helpdesk to setup an email account (providing SMTP and 
IMAP/POP3 locations seems to be difficult). It would also require to 
provide the password upfront. Providing the email address only to fetch 
the config file is in my opinion still the preferred way, but I could 
live with providing a URL instead. But then again, the typing lengthy 
URLs are failure prone...
> (I have tried to read everything except the DNS security discussion. If 
> I nave missed something essential and this has been said before, I 
> apologize)
Not really, the DNS discussion is about discovering the config file by 
only entering the email address.

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

0
Eddy
3/9/2008 6:33:11 PM
Bryan W Clark schrieb:
> With the drop down use a person can choose the domain name from the 
> list of popular, known domain names.  There is a final choice, 
> "Other..." which simply focuses the entry and allows a person to type 
> in whatever domain.  Of course the person could have just typed in 
> whatever domain name before selecting Other... and it would have 
> worked the same.
>
> So page 1 of the wizard looks something like this:
>
> {Page 1}
> Name:     [ Bryan Clark ]
> Email:    [ clarkbw+spam ] @ [ gmail \/]

I intentionally chose not to use a drop-down, because
a) it's actually cumbersome to the user it's fast to just type 
"@gmail.com" as well than to use a dropdown, and they are used to having 
to type their email address correctly. I think even autocomplete would 
disturb more than it helps (e.g. complete to t-mobile.com, although 
t-mobile.de has an entirely different config, and the user thinks 
t-mobile.com is also fine, which may be wrong in this case, but right 
for aol.de/aol.com).
b) it does not provide any value to us. We will know the domain name of 
the providers we know, so we can select the right provider based on the 
domain entered.
c) we can also try to fetch a configuration based on the same data.
And we only enable the auto-config when we found a config, and we can 
use several means under the hood to find it.

> I think we could maintain such a list at something like 
> https://autoconfig.mozillamessaging.com/

Yes, that's what I proposed.

> It might make sense to localize the config files so we can show more 
> appropriate accounts for different locales, not sure it is necessary.  
> Ex:
>     https://autoconfig.mozillamessaging.com/en-US/

The servers will be the same, no matter where the user is. ISPs 
generally don't have different config based on country, not even AOL 
does (they use DNS tricks, if they want to). If they are different 
domains, we can have different configs, though.

>     http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks

Yes, that's the "legacy" (current) RDF files I mentioned in my proposal.

> For people sharing their account settings ( a much smaller group of 
> people ) I'd like to see a system in the future that allows people to 
> easily share their account settings with other people.  This would be 
> for the small group of people using a custom mail server system.
>
> A [ Share These Account Settings... ] button on the Account settings 
> page which creates an email that person can send to others with an ISP 
> extension attached.  Or a way to save your account settings as the the 
> extension somewhere on the filesystem.

That's a good idea.
We could let the user publish it to the mozilla config webservice, right 
from our account UI.
Potential for mis-chief is there, of course. A moderator or script would 
not be able to notice that the login method is deliberately wrong, 
preventing others from logging in when they use autoconfig. I think 
sharing config is the right direction, though, as that's essentially 
what we currently do manually, asking colleges whether they got 
Thunderbird to work with the company email server.

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/11/2008 12:52:50 AM
Dan Mosedale schrieb:
> I'd like to propose that we really do have a single high-level goal: 
> to make it as easy as possible for as many users as possible to get a 
> working Tb configuration.  I suggest that it will be easier to discuss 
> this if we segment them into users of:
>
> a) large ISPs (google, yahoo, etc)
>
> This set of users is very large.  Because the number of ISPs is small, 
> a hard-coded list could work pretty well.  Having the list be 
> updatable would be nice, but probably not a blocker.
>
> b) smaller ISPs
>
> I suspect this set of users is moderate-sized.  The number of ISPs in 
> this set is seems likely to be large enough that if a set of config 
> files is to be maintained, we'd want some set of shared infrastructure 
> at MoMo to allow a larger community to submit, edit, and publish these.
>
> c) non-public servers
> c1) intranets
> c2) personal servers
>
> These require some other mechanism for provision of config files: 
> perhaps DNS-based auto-discovery as discussed elsewhere in this 
> thread.  Peer-to-peer config publishing via email, as proposed by 
> Brian is also likely to be useful here, if the DNS admins don't 
> prioritize setting up the necessary records, as sometimes happens in 
> intranets.
>
> Do people feel that this does a reasonable job of capturing the 
> various needs to be met?
>
> I haven't responded to any of the UI or implementation stuff yet, 
> because I think we need to get some consensus here first.

Yes, I think you capture the problem well (and I should add that to the 
wiki page). (You're also offering solutions, though :) .)

I proposed solutions and UI for a) and b) and asked for ideas for c).

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/11/2008 1:08:33 AM
Robert Kaiser schrieb:
> David Ascher wrote:
>> Leaving aside any security implications, which I don't claim to
>> understand fully yet, I think the biggest challenge would be to define
>> the process by which these configurations get submitted, updated, etc.
>> But I still think it's tractable and a very highly leveraged activity,
>> because any motivated user could provide auto-configuration to all the
>> other customers of the same ISP.
>
> Well, you realize that a not-so-small number of ISPs have setups with 
> i.e. my.real.name@isp.tld needing a login including the customer id 
> number that is completely different from my.real.name on their mail 
> server?


> Does that mean you will host a different file for every user and 
> effectively the data of realting all customer IDs to their email 
> addresses on your servers?

No, of course not.

> The easier way for doing this would probably be to hand off the 
> requests to the ISP which has all the data and can probably figure out 
> all needed config from the user's email.

Exactly. We can send the email address to the ISP in the request for the 
config file (if they provide that server), allowing them to fill in the 
user name, if they wish so.

They may not do that to avoid the mapping from email address to login 
name, but then again, the T-Online a) uses the login name as 
pseudo-authentication at their hotline, and at the same time a) their 
outgoing SMTP and Usenet servers for this username into the header of 
every mail sent.

> Or will entering the email not be enough to get configured and the 
> user needs to enter the customer ID as well

Worse case, that's what it may end up with: One additional field for 
"username". The current RDF file can even provide the display name for 
that: "AOL screen name" vs. "username" vs. "login name", and I kept that 
feature in my XML proposal.

> or maybe even some additional info that we need to find the right config?

I don't think so. We can just look at the manual config and see which 
values are potentially user-specific. SMTP login and IMAP/POP login are 
the only ones there. And I have yet to see an ISP which ask the user to 
enter a different username for SMTP and POP servers each.

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/11/2008 1:19:54 AM
Jesper Kristensen schrieb:
> Ben Bucksch skrev:
>> Objective: Make my non-tech friends use Thunderbird, by making it 
>> dead-simple to set up.
>>
>> ...
>
> Where I live there are two main types of e-mail accounts. The first is 
> webmails like GMail and Hotmail. The second type and largest type are 
> e-mails bound to ADSL connections. The biggest broadband ISPs in my 
> country share around 50 domain names for e-mail addresses. That means 
> that for one domain extracted from the e-mail address, there are at 
> least five different possible ISPs with totally different account setups.

Huch? You're saying you have A Corp, B Corp and C Corp providing DSL 
services, and all of them use myregion.dk, mycity.dk, and depending on 
which DSL company I use, I have to change my mail config, although my 
email address stays the same?

How does that work technically? (And why?) How does the mail server find 
the mail store, or vice versa how does the receiving SMTP server for a 
certain domain know which ISP / mail server I am on? Do they share the 
incoming SMTP servers and forward to mail stores, which are then 
different per ISP, and the user tells the email address at ISP signup 
and the ISP changes the config for the user's email address?
I seriously wonder what's the point of that, why to separate email 
domain = incoming SMTP and mail store to dramatically.

Actually, this reminds me of MS Exchange. If I understood it right, a 
company I work for as foobar.com for all employees, but some of them are 
on server bla-1, while others are on bla-2, and I need to know which 
server I'm on to fetch my mail - the other server refuses me. Outlook 
and Exchange have some means to find out the configuration 
automatically, we should look into this.


-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/11/2008 1:32:45 AM
Ben Bucksch schrieb:
> I seriously wonder what's the point of that, why to separate email 
> domain = incoming SMTP and mail store to dramatically.

Actually, I can imagine that a government wants to provide 
jesper.kristensen@aalborg.dk as service (and affection) to their 
citizens, but they don't want to maintain the mail stores (disks), so 
they only provide mail forwarding services.

Indeed, my proposal for autoconfig fails entirely for any mail forwarding.
I'll just hope that it's not a common case, that a user would know when 
he has that. Apart from Denmark, apparently. Ideas?

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/11/2008 1:39:38 AM
David Ascher wrote:
> Right.  My point is that for we may not _even_ require the ISP to do 
> anything, only user communities to populate config files hosted 
> centrally.  But if the ISPs want to help w/ the DNS approach, that's 
> fine too.

That's exactly what I propose, yes.
I added the option for config by ISPs, because I think ISPs would be 
upset, if we offered the config of their servers without them being able 
to change it.
I made it optional for the ISP, precisely because I don't think many 
ISPs care about Thunderbird yet.

David Ascher wrote in another mail:
> I see that responsibility as in scope with MoMo's broader 
> responsibility towards Thunderbird users

Yes. One nice angle is that we could publish configs which use SSL, if 
the ISP server supports that, while I think today most users still read 
their mail via plaintext. Even if the ISP->ISP link is not secure, I 
think that helps a lot for privacy.

Ben
0
Ben
3/11/2008 2:07:31 AM
Ben Bucksch wrote:
> Dan Mosedale schrieb:
>> a) large ISPs (google, yahoo, etc)
>> b) smaller ISPs
>> c) non-public servers
>> c1) intranets
>> c2) personal servers
>>
[snip]
>> Do people feel that this does a reasonable job of capturing the
>> various needs to be met?

I really like this layout of assumptions so I took a stab at reworking 
the Goals section into a more common framework along with Dan's  user 
segmentation assumption list.

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

Feel free to work in any cleanups onto the wiki and we can keep the 
discussion going here.

You'll see I broke down the goals into some major and minor separations, 
of which could use some revision.  For instance having these two major 
goals makes this project quite a bit larger:

#  Shared system for community to submit, edit, and publish configurations
# Configuration settings pulled from shared system

It might make sense to rework the Account Creation system with those two 
in mind but keep them as our future goal.  This way we can develop a UI 
that will work for that system, but not get blocked on having an actual 
shared facility working.

>> I haven't responded to any of the UI or implementation stuff yet,
>> because I think we need to get some consensus here first.

Agreed, with out this set of assumptions and focus on what are the major 
goals it's going to be near impossible to agree on what the right detail 
bits are.

> Yes, I think you capture the problem well (and I should add that to the
> wiki page). (You're also offering solutions, though :) .)
>
> I proposed solutions and UI for a) and b) and asked for ideas for c).

We've got lots of great ideas going here, lets keep bouncing back and 
forth on them to  refine them into the wiki page and have a clear 
definition.

Cheers,
~ Bryan
0
Bryan
3/11/2008 4:06:32 PM
On 2008-03-11 04:07, Ben Bucksch wrote:
> I added the option for config by ISPs, because I think ISPs would be
> upset, if we offered the config of their servers without them being able
> to change it.

Well, we could offer domain owners a way to offer "confirmed" configuration 
options. Can't recall offhand which service, but I think it's Google using a 
simple way to confirm domain ownership: you get some simple file that you have 
to put in the domain root directory, they then verify that the file they gave 
has been put in the dir -> if it is, you have domain ownership.

  -Magnus
0
Magnus
3/11/2008 4:52:05 PM
Simon Wilkinson schrieb:
> As I've said before I think this proposal has two significant issues. 
> It breaks (and breaks badly) for sites with complicated MX record 
> setups, and the use of https provides no significant security benefit.
>
> The first issue is that complicated mail domain configurations have no 
> guarantee that listed MX records are actually endpoints for mail 
> traffic for that site - sites may list non-local primary MXs to act as 
> store-and-forward services, or have non-local secondary MXs which act 
> as backups.

Good point.

As I tried to explain before to Eddy, MX are inbound SMTP, i.e. about 
ISP->ISP, and have very little to do with the mail fetch (POP) and send 
(SMTP) of clients. Basing client config on MX is conceptually wrong.

You can have the same entries on the domain itself, *next* to the MX. 
That's not that bad, given that the MX needs to be set there, too.

Ben
0
Ben
3/11/2008 7:09:49 PM
Ben Bucksch:
> Simon Wilkinson schrieb:
>   
>> As I've said before I think this proposal has two significant issues. 
>> It breaks (and breaks badly) for sites with complicated MX record 
>> setups, and the use of https provides no significant security benefit.
>>
>> The first issue is that complicated mail domain configurations have no 
>> guarantee that listed MX records are actually endpoints for mail 
>> traffic for that site - sites may list non-local primary MXs to act as 
>> store-and-forward services, or have non-local secondary MXs which act 
>> as backups.
>>     
>
> Good point.
>
> As I tried to explain before to Eddy, MX are inbound SMTP, i.e. about 
> ISP->ISP, and have very little to do with the mail fetch (POP) and send 
> (SMTP) of clients. Basing client config on MX is conceptually wrong.

No, this is a bad point, since I can have multiple servers in base 
domain name. The MX record is REALLY the ideal point to nail this down. 
Why? Just think:

I have mail.startcom.org, mta1.startcom.org and mta2.startcom.org, each 
for a different purpose. Now as an ISP I can send at every server the 
same URL (in case these are backup servers) or have each server send a 
different configuration....or a mix of both. Even if the SMTP server 
doesn't have to be related to the retrieval point, it's still THE point 
in the DNS for mail, for every mail!!! It's about which config file to 
send, the content of the file is what makes up the details for the 
configuration.

Example: mta2.startcom.org send TB to config file 
https://www.startcom.org/mta2.cgi which produces a config file for the 
users of that server. The details can be something completely else, like 
IMAPS = wowow.startcom.org port 1234. It really has nothing to do with 
the MX record per se. It's still the best point to lookup the config URL.

I'm sorry, I have a backlog here and not read all messages yet. But in 
any case I think the argument why NOT to use https very lame...It's 
really like saying, common, lets get rid of every security benefit that 
can be...not better alternative was proposed either, my friends!

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

0
Eddy
3/11/2008 7:46:49 PM
Ben Bucksch wrote:

> Yes, I think you capture the problem well (and I should add that to the
> wiki page). (You're also offering solutions, though :) .)

Guilty as charged.  I should have phrased my objection better: I think a 
very high-level of implementation discussion is relevant at this phase, 
but it felt like we were ratholing on details before we had the problem 
well-defined.

> I proposed solutions and UI for a) and b) and asked for ideas for c).

Yep; it seems pretty clear that c) is a separable problem from the other 
two.

Dan

0
Dan
3/11/2008 8:28:08 PM
Bryan W Clark wrote:
> I really like this layout of assumptions so I took a stab at reworking
> the Goals section into a more common framework along with Dan's user
> segmentation assumption list.
>
> http://wiki.mozilla.org/Tb:Autoconfiguration#Goal

Great; thanks.

> Feel free to work in any cleanups onto the wiki and we can keep the
> discussion going here.

OK, I tweaked an indentation level.  The other thing that probably needs 
a change is that I suspect Proposal/UI should be a separate page, as 
should each of Config Files, Security, and DNS-based discovery.  That'll 
make this info a lot easier to digest, I think.  I'm going to leave that 
change to Ben, though, since he's driving the discussion here.

> You'll see I broke down the goals into some major and minor separations,
> of which could use some revision. For instance having these two major
> goals makes this project quite a bit larger:
>
> # Shared system for community to submit, edit, and publish configurations
> # Configuration settings pulled from shared system
>
> It might make sense to rework the Account Creation system with those two
> in mind but keep them as our future goal. This way we can develop a UI
> that will work for that system, but not get blocked on having an actual
> shared facility working.

Sounds like a good strategy.

Dan
0
Dan
3/11/2008 9:05:07 PM
Ben Bucksch wrote:
> Ben Bucksch schrieb:
>> I seriously wonder what's the point of that, why to separate email
>> domain = incoming SMTP and mail store to dramatically.
>
> Actually, I can imagine that a government wants to provide
> jesper.kristensen@aalborg.dk as service (and affection) to their
> citizens, but they don't want to maintain the mail stores (disks), so
> they only provide mail forwarding services.

I believe this is a reasonably common scenario for large intranets as well.

> Indeed, my proposal for autoconfig fails entirely for any mail forwarding.
> I'll just hope that it's not a common case, that a user would know when
> he has that. Apart from Denmark, apparently. Ideas?

This would probably need some cooperation from the ISP.  As someone 
pointed out earlier in this thread, if the forwarding server can host 
the config files for this case, we're probably ok, since the config file 
query can include things like the username.

I think we're already on the right track of breaking the high-level 
problem down into smaller pieces, prioritizing those, and solving them 
individually.

Dan
0
Dan
3/11/2008 9:09:09 PM
Ben Bucksch skrev:
> Jesper Kristensen schrieb:
>> Ben Bucksch skrev:
>>> Objective: Make my non-tech friends use Thunderbird, by making it 
>>> dead-simple to set up.
>>>
>>> ...
>>
>> Where I live there are two main types of e-mail accounts. The first is 
>> webmails like GMail and Hotmail. The second type and largest type are 
>> e-mails bound to ADSL connections. The biggest broadband ISPs in my 
>> country share around 50 domain names for e-mail addresses. That means 
>> that for one domain extracted from the e-mail address, there are at 
>> least five different possible ISPs with totally different account setups.
> 
> Huch? You're saying you have A Corp, B Corp and C Corp providing DSL 
> services, and all of them use myregion.dk, mycity.dk, and depending on 
> which DSL company I use, I have to change my mail config, although my 
> email address stays the same?
> 
> How does that work technically? (And why?) How does the mail server find 
> the mail store, or vice versa how does the receiving SMTP server for a 
> certain domain know which ISP / mail server I am on? Do they share the 
> incoming SMTP servers and forward to mail stores, which are then 
> different per ISP, and the user tells the email address at ISP signup 
> and the ISP changes the config for the user's email address?
> I seriously wonder what's the point of that, why to separate email 
> domain = incoming SMTP and mail store to dramatically.
> 
> Actually, this reminds me of MS Exchange. If I understood it right, a 
> company I work for as foobar.com for all employees, but some of them are 
> on server bla-1, while others are on bla-2, and I need to know which 
> server I'm on to fetch my mail - the other server refuses me. Outlook 
> and Exchange have some means to find out the configuration 
> automatically, we should look into this.
> 
> 

I don't know. And I don't know if it is still this way. It is probably 5 
to 10 years since I changed ISP. And I don't know how many ISPs it works 
between. I had to delete my e-mail-address at my old ISP, wait for some 
time and then recreate it at my new ISP.
0
Jesper
3/11/2008 9:18:44 PM
Ben Bucksch skrev:
> Jesper Kristensen schrieb:
>> Ben Bucksch skrev:
>>> Objective: Make my non-tech friends use Thunderbird, by making it 
>>> dead-simple to set up.
>>>
>>> ...
>>
>> Where I live there are two main types of e-mail accounts. The first is 
>> webmails like GMail and Hotmail. The second type and largest type are 
>> e-mails bound to ADSL connections. The biggest broadband ISPs in my 
>> country share around 50 domain names for e-mail addresses. That means 
>> that for one domain extracted from the e-mail address, there are at 
>> least five different possible ISPs with totally different account setups.
> 
> Huch? You're saying you have A Corp, B Corp and C Corp providing DSL 
> services, and all of them use myregion.dk, mycity.dk, and depending on 
> which DSL company I use, I have to change my mail config, although my 
> email address stays the same?

Well, it turns out I should have done my homework propably before 
posting. It doesn't work this way, at least not any more. It was 
probably some transition agreement originating back when the Danish 
government decided to break the monopoly on phone and internet.
0
Jesper
3/11/2008 9:27:48 PM
Magnus Melin:
> On 2008-03-11 04:07, Ben Bucksch wrote:
>   
>> I added the option for config by ISPs, because I think ISPs would be
>> upset, if we offered the config of their servers without them being able
>> to change it.
>>     
>
> Well, we could offer domain owners a way to offer "confirmed" configuration 
> options. Can't recall offhand which service, but I think it's Google using a 
> simple way to confirm domain ownership: you get some simple file that you have 
> to put in the domain root directory, they then verify that the file they gave 
> has been put in the dir -> if it is, you have domain ownership.
>
>   
Any domain name validated server certificate issued by the certification 
authorities shipped with TB offer similar ways to claim ownership of a 
domain name. Such SSL certificates can give you exactly that (compared 
to higher level validation). Hence they are useful also to third parties 
which need/want to confirm the same.

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

0
Eddy
3/11/2008 9:57:52 PM
Eddy Nigg (StartCom Ltd.) schrieb:
> No, this is a bad point, since I can have multiple servers in base 
> domain name.

That's exactly why the config should not be in MX, as Steve pointed out.
bucksch.org
10 MX  mymail.bucksch.org
100 MX mailbackup.myprovider.net

mailbackup.myprovider.net goes to imap.myprovider.net, while 
mymail.bucksch.org has its own IMAP server. mailbackup.myprovider.net 
has its own IMAP server, or a delayed forwarder, or both and the user 
can choose.
Which config do you take? Clearly the MX with the highest priority, so 
you have to evaluate that. OK, your spec requires that already.

Many providers have, though:
t-online.de.            21292   IN      MX      10 mx00.t-online.de.
t-online.de.            21292   IN      MX      10 mx01.t-online.de.
t-online.de.            21292   IN      MX      10 mx02.t-online.de.
t-online.de.            21292   IN      MX      10 mx03.t-online.de.
aol.com.                756     IN      MX      15 mailin-02.mx.aol.com.
aol.com.                756     IN      MX      15 mailin-03.mx.aol.com.
aol.com.                756     IN      MX      15 mailin-04.mx.aol.com.
aol.com.                756     IN      MX      15 mailin-01.mx.aol.com.

So, as a provider, you have to set up the config for each of these hosts 
and it being identical.

> The MX record is REALLY the ideal point to nail this down. Why? Just 
> think:
>
> I have mail.startcom.org, mta1.startcom.org and mta2.startcom.org, 
> each for a different purpose.

I only see
startcom.org.           7200    IN      MX      10 apache-5.startcom.org.
:-)

Seriously, you can't have different MX for different purposes on the 
same domain (unless you count backup as different purpose). The sender 
is allowed to take a random MX (of the best available priority).


> Example: mta2.startcom.org send TB to config file 
> https://www.startcom.org/mta2.cgi which produces a config file for the 
> users of that server. The details can be something completely else, 
> like IMAPS = wowow.startcom.org port 1234.

You cannot have both mta1 and mta2 as MX, and them being responsible for 
different users.

Ben
0
Ben
3/12/2008 1:22:47 AM
Dan Mosedale schrieb:
> This would probably need some cooperation from the ISP.  As someone 
> pointed out earlier in this thread, if the forwarding server can host 
> the config files for this case, we're probably ok, since the config 
> file query can include things like the username.

Good point.
It does mean, though, that the ISP has to host the server offering the 
client config, we cannot weasel out and use the the mozilla webservice 
for ISP-provided configs as well and ask ISPs to update that like a 
sharing user would (just with higher privileges/precedence), because the 
mapping needs information from the provider's database.

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/12/2008 1:27:56 AM
Ben Bucksch:
> I only see
> startcom.org.           7200    IN      MX      10 apache-5.startcom.org.
> :-)
>
> Seriously, you can't have different MX for different purposes on the 
> same domain (unless you count backup as different purpose). The sender 
> is allowed to take a random MX (of the best available priority).
>   
Ohoommm, I think I should have explained that differently ;-) Sorry, 
this is a failure of my part. Lets try this again:

domain1, domain2 , domain3, domain4 , domain5, domain6 are served by 
mail.startcom.org, giving me config URL https://xyz. Alternatively I can 
parse the referrer and create a config dynamically.

domain7, domain8 are served by mta1.startcom.org and obviously as you 
pointed out correctly (can be) served by a different config file or the 
same as the one of above. This depends on what I need...

domain9 - domain100 are served by mta2.starcom.org etc etc...

I'm claiming that this would allow - as in the scenario above, give the 
most flexible and scalable options for any/most ISPs and smaller server 
operators. It might be true that some very specific setups will not work 
except with some tweaking and/or by creating the config dynamically on 
the fly. On the other hand, you guys suggested to only use the base 
domain for the same??? Which gives? How should *that* scale better and 
solve your specific problem you mentioned?


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

0
Eddy
3/12/2008 2:20:13 AM
Continued....

Ben Bucksch:
> Which config do you take? Clearly the MX with the highest priority, so 
> you have to evaluate that. OK, your spec requires that already.
>
> Many providers have, though:
> t-online.de.            21292   IN      MX      10 mx00.t-online.de.
> t-online.de.            21292   IN      MX      10 mx01.t-online.de.
> t-online.de.            21292   IN      MX      10 mx02.t-online.de.
> t-online.de.            21292   IN      MX      10 mx03.t-online.de.
> aol.com.                756     IN      MX      15 mailin-02.mx.aol.com.
> aol.com.                756     IN      MX      15 mailin-03.mx.aol.com.
> aol.com.                756     IN      MX      15 mailin-04.mx.aol.com.
> aol.com.                756     IN      MX      15 mailin-01.mx.aol.com.
>
> So, as a provider, you have to set up the config for each of these hosts 
> and it being identical.
>   
That's correct! That's about 4 or 5 edits in a DNS zone. That's not bad 
for large providers such a Google, AOL and T-Online....That's done in 
less than a minute...

On the other hand, what did you propose again? Having the config file at 
the DNS zone of the base domain? Think again....

.....for how many domain names does Google serve mail? Or 1and1? Or even 
smaller providers which just a couple of hundred domain names....They 
will tell you "no thanks" if they have to edit every zone to add another 
TXT entry, not speaking about that it's failure prone.

The MX record can be tested and will work for all users of that mail 
server the same. Not so if the entry will be at each domain...
> You cannot have both mta1 and mta2 as MX, and them being responsible for 
> different users.
>
>   
startcom.org            IN SOA
MX      10 mta1.startcom.org.

mozilla.org            IN SOA
MX      10 mta2.startcom.org.

mozilla.com            IN SOA
MX      10 mta2.startcom.org.

mta1 IN A 192.192.202.201

       IN    MX 10    mta1.domain.com.
       IN    TXT     "mailconf=https://someurl/somepath/somefile"


mta2 IN A 192.192.202.202

       IN    MX 20    mta2.domain.com.
       IN    TXT     "mailconf=https://someurl/somepath/somefile"




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

0
Eddy
3/12/2008 3:04:43 AM
Ben Bucksch wrote:
> Good point.
> It does mean, though, that the ISP has to host the server offering the
> client config, we cannot weasel out and use the the mozilla webservice
> for ISP-provided configs as well and ask ISPs to update that like a
> sharing user would (just with higher privileges/precedence), because the
> mapping needs information from the provider's database.

Agreed.  One could imagine defining a format for ISPs to publish 
forwarding information, but I'm not convinced that too many providers 
are going to want to do that.  This sounds like a significantly lower 
bang for the buck anyway, and something we could address in a future 
iteration if we become convinced that it's likely to pay off.

Dan
0
Dan
3/12/2008 4:28:34 PM
On 2008-03-11 23:57, Eddy Nigg (StartCom Ltd.) wrote:
> Magnus Melin:
>> On 2008-03-11 04:07, Ben Bucksch wrote:
>>> I added the option for config by ISPs, because I think ISPs would be
>>> upset, if we offered the config of their servers without them being able
>>> to change it.
>>
>> Well, we could offer domain owners a way to offer "confirmed"
>> configuration options. Can't recall offhand which service, but I think
>> it's Google using a simple way to confirm domain ownership: you get
>> some simple file that you have to put in the domain root directory,
>> they then verify that the file they gave has been put in the dir -> if
>> it is, you have domain ownership.
>>
> Any domain name validated server certificate issued by the certification
> authorities shipped with TB offer similar ways to claim ownership of a
> domain name. Such SSL certificates can give you exactly that (compared
> to higher level validation). Hence they are useful also to third parties
> which need/want to confirm the same.
>

How exactly would you implement that, in a simple way? I was thinking we would 
make a web page where you fill in/upload a configuration which is automatically 
checked. How would certificates help you ensure the user making those changes is 
an "admin" of that organization?

  -Magnus
0
Magnus
3/12/2008 7:11:52 PM
Magnus Melin:
> On 2008-03-11 23:57, Eddy Nigg (StartCom Ltd.) wrote:
>> Any domain name validated server certificate issued by the certification
>> authorities shipped with TB offer similar ways to claim ownership of a
>> domain name. Such SSL certificates can give you exactly that (compared
>> to higher level validation). Hence they are useful also to third parties
>> which need/want to confirm the same.
>>
>>     
>
> How exactly would you implement that, in a simple way? I was thinking we would 
> make a web page where you fill in/upload a configuration which is automatically 
> checked. How would certificates help you ensure the user making those changes is 
> an "admin" of that organization?
>   
First of all tend to prefer a decentralized system over a centralized 
one. But here to answer the question:

Instead of having upload somebody some content to a web site and ping 
for that file after a while, you can simply ping (and verify) the https 
URL of that domain name. I can of course help to implement that which 
isn't all that difficult.

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

0
Eddy
3/12/2008 11:50:31 PM
On 2008-03-13 01:50, Eddy Nigg (StartCom Ltd.) wrote:
> Magnus Melin:
>> On 2008-03-11 23:57, Eddy Nigg (StartCom Ltd.) wrote:
>>> Any domain name validated server certificate issued by the certification
>>> authorities shipped with TB offer similar ways to claim ownership of a
>>> domain name. Such SSL certificates can give you exactly that (compared
>>> to higher level validation). Hence they are useful also to third parties
>>> which need/want to confirm the same.
>>>
>> How exactly would you implement that, in a simple way? I was thinking
>> we would make a web page where you fill in/upload a configuration
>> which is automatically checked. How would certificates help you ensure
>> the user making those changes is an "admin" of that organization?
> First of all tend to prefer a decentralized system over a centralized
> one. But here to answer the question:
>
> Instead of having upload somebody some content to a web site and ping
> for that file after a while, you can simply ping (and verify) the https
> URL of that domain name. I can of course help to implement that which
> isn't all that difficult.

How would that tell me a random config about that domain is the one that the 
domain admins would like to see as blessed?

  -Magnus
0
Magnus
3/14/2008 9:09:51 PM
Magnus Melin:
>> First of all tend to prefer a decentralized system over a centralized
>> one. But here to answer the question:
>>
>> Instead of having upload somebody some content to a web site and ping
>> for that file after a while, you can simply ping (and verify) the https
>> URL of that domain name. I can of course help to implement that which
>> isn't all that difficult.
>>     
>
> How would that tell me a random config about that domain is the one that the 
> domain admins would like to see as blessed?
>
>   
The context leading to this was the suggestion, that a domain owner 
would have to be pinged via some uploaded file to the server. Obviously 
a config file for a mail server of mozilla.org would have to prove 
domain ownership of that domain. Similar pinging the SSL secured server 
of mozilla.org could achieve the same effect.

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

0
Eddy
3/14/2008 10:00:12 PM
Magnus Melin:
>
> How would that tell me a random config about that domain is the one that the 
> domain admins would like to see as blessed?
Sorry for the multiple replies....but to the answer, by receiving a 
digital certificate, a subscriber must prove domain ownership anyway via 
various ways, so we could just check for it. But this works of course 
only with certificates issued by CAs approved to the NSS store.

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

0
Eddy
3/14/2008 10:03:20 PM
Magnus Melin:
>
> How would that tell me a random config about that domain is the one that the 
> domain admins would like to see as blessed?
Sorry for the multiple replies....but to the answer, by receiving a 
digital certificate, a subscriber must prove domain ownership anyway via 
various ways, so we could just check for it. But this works of course 
only with certificates issued by CAs approved to the NSS store.

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

0
Eddy
3/14/2008 10:03:36 PM
Ben Bucksch schrieb:
>> The easier way for doing this would probably be to hand off the 
>> requests to the ISP which has all the data and can probably figure 
>> out all needed config from the user's email.
>
> Exactly. We can send the email address to the ISP in the request for 
> the config file (if they provide that server), allowing them to fill 
> in the user name, if they wish so.
>

Added email address as parameter for ISP config fetch (but not mozilla 
service). They can use it or not.

>> Or will entering the email not be enough to get configured and the 
>> user needs to enter the customer ID as well
>
> Worse case, that's what it may end up with: One additional field for 
> "username". The current RDF file can even provide the display name for 
> that: "AOL screen name" vs. "username" vs. "login name", and I kept 
> that feature in my XML proposal.
>
>> or maybe even some additional info that we need to find the right 
>> config?
>
> I don't think so.

I added a generic 'custom text fields' feature to the config file, where 
the label is supplied by the file, and the user-entered value can be 
used as placeholder in any setting. This should allow for both usernames 
(with ISP specific name) and even separate POP and SMTP username, if the 
ISP wants to be so freaky. I expect that most ISPs will either use the 
email address or the first part of it as username, or require the 
username and only that (i.e. one field) to be entered.

-- 
When responding privately, please remove the ".news" from the email address.
0
Ben
3/18/2008 2:00:27 AM
Dan Mosedale schrieb:
> I suspect Proposal/UI should be a separate page, as should each of 
> Config Files, Security, and DNS-based discovery.  That'll make this 
> info a lot easier to digest, I think.  I'm going to leave that change 
> to Ben, though, since he's driving the discussion here.

Done.
0
Ben
3/18/2008 2:08:23 AM
Ben Bucksch schrieb:
>> For people sharing their account settings ( a much smaller group of 
>> people ) I'd like to see a system in the future that allows people to 
>> easily share their account settings with other people.  This would be 
>> for the small group of people using a custom mail server system.
>>
>> A [ Share These Account Settings... ] button on the Account settings 
>> page which creates an email that person can send to others with an 
>> ISP extension attached.  Or a way to save your account settings as 
>> the the extension somewhere on the filesystem.
>
> That's a good idea.
> We could let the user publish it to the mozilla config webservice, 
> right from our account UI.

Added to 
http://wiki.mozilla.org/Thunderbird:Autoconfiguration:MozillaWebservicePublish
0
Ben
3/18/2008 2:36:18 AM
On 2008-03-15 00:03, Eddy Nigg (StartCom Ltd.) wrote:
> Magnus Melin:
>>
>> How would that tell me a random config about that domain is the one
>> that the domain admins would like to see as blessed?
> Sorry for the multiple replies....but to the answer, by receiving a
> digital certificate, a subscriber must prove domain ownership anyway via
> various ways, so we could just check for it. But this works of course
> only with certificates issued by CAs approved to the NSS store.
>

Yes, of course the owner of the certificate is known. But how do you check that 
user A who has a valid cert for company A is in fact the admin of company A?

(In programming, and in an easy way, manually checking with the cert issuer or 
something sounds not as easy.)

  -Magnus
0
Magnus
3/26/2008 9:52:22 PM
Magnus Melin:
>
> Yes, of course the owner of the certificate is known. But how do you check that 
> user A who has a valid cert for company A is in fact the admin of company A?
>   

Well, the best I can think of, is to display the URL download location 
which obviously matches the certificate. Should there be a problem with 
the certificate like wrong sub domain and similar stuff, the download 
should fail.

> (In programming, and in an easy way, manually checking with the cert issuer or 
> something sounds not as easy.)
>
>   
As with the browser, where the URL is displayed in the address bar, the 
URL should be displayed in a similar fashion. If a user at the browser 
doesn't check the URL, a valid certificate is pretty useless. Similar 
here...


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

0
Eddy
3/26/2008 10:21:41 PM
On 2008-03-27 00:21, Eddy Nigg (StartCom Ltd.) wrote:
> Well, the best I can think of, is to display the URL download location
> which obviously matches the certificate. Should there be a problem with
> the certificate like wrong sub domain and similar stuff, the download
> should fail.

Don't really see why a certificate would do any difference. And since the 
question here was how to let someone say "I'm the admin for this domain, use 
these settings", we still have to have check a file in the root dir of the 
domain, otherwise anyone with a use dir somewhere under the root could say they 
are the admin. (Though the www.example.org/~foo/ type accounts are getting more 
rare).

  -Magnus
0
Magnus
3/28/2008 3:29:05 PM
Magnus Melin:
> On 2008-03-27 00:21, Eddy Nigg (StartCom Ltd.) wrote:
>   
>> Well, the best I can think of, is to display the URL download location
>> which obviously matches the certificate. Should there be a problem with
>> the certificate like wrong sub domain and similar stuff, the download
>> should fail.
>>     
>
> Don't really see why a certificate would do any difference.

Mmmhhh, can you tell me why certificates make a difference then at all 
on the Internet? I mean, you click on a link which directs you to a 
secure site. You look at the address bar if this is really the site you 
expect and the certificate confirms this certificate to be issued to 
that site.

>  And since the 
> question here was how to let someone say "I'm the admin for this domain, use 
> these settings", we still have to have check a file in the root dir of the 
> domain, otherwise anyone with a use dir somewhere under the root could say they 
> are the admin.
This would hurt adoption and make it almost unusable. The operator of 
the mail server is many times not the same one controlling the web 
space, not to speak about having to install X times the same files at 
different hosts in order to have it work...


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

0
Eddy
3/30/2008 10:45:47 PM
On 2008-03-31 01:45, Eddy Nigg (StartCom Ltd.) wrote:
> Magnus Melin:
>> On 2008-03-27 00:21, Eddy Nigg (StartCom Ltd.) wrote:
>>> Well, the best I can think of, is to display the URL download location
>>> which obviously matches the certificate. Should there be a problem with
>>> the certificate like wrong sub domain and similar stuff, the download
>>> should fail.
>>
>> Don't really see why a certificate would do any difference.
>
> Mmmhhh, can you tell me why certificates make a difference then at all
> on the Internet? I mean, you click on a link which directs you to a
> secure site. You look at the address bar if this is really the site you
> expect and the certificate confirms this certificate to be issued to
> that site.

Sure, but that has nothing to do with who's the admin for the domain or not.

>> And since the question here was how to let someone say "I'm the admin
>> for this domain, use these settings", we still have to have check a
>> file in the root dir of the domain, otherwise anyone with a use dir
>> somewhere under the root could say they are the admin.
> This would hurt adoption and make it almost unusable. The operator of
> the mail server is many times not the same one controlling the web
> space, not to speak about having to install X times the same files at
> different hosts in order to have it work...

It doesn't have to be the same person, but to make the system work in any 
reasonable way one would have to assume admins within the same entity can get 
along.

Note that "confirm domain settings" was only suggested as an addition to the 
user submitted data. There is no /need/ for adaption of this feature, user 
submitted data will likely do just fine in most cases.

  -Magnus
0
Magnus
3/31/2008 11:47:22 AM
Magnus Melin:
> On 2008-03-31 01:45, Eddy Nigg (StartCom Ltd.) wrote:
>> Mmmhhh, can you tell me why certificates make a difference then at all
>> on the Internet? I mean, you click on a link which directs you to a
>> secure site. You look at the address bar if this is really the site you
>> expect and the certificate confirms this certificate to be issued to
>> that site.
>>     
>
> Sure, but that has nothing to do with who's the admin for the domain or not.
>   
Well, being responsible for the DNS zone is reasons enough I guess. 
That's the same as with web pages. Or with sending mail (MX record), etc 
etc...
>> This would hurt adoption and make it almost unusable. The operator of
>> the mail server is many times not the same one controlling the web
>> space, not to speak about having to install X times the same files at
>> different hosts in order to have it work...
>>     
>
> It doesn't have to be the same person, but to make the system work in any 
> reasonable way one would have to assume admins within the same entity can get 
> along.
>   
Supposed I have a mail server with 1000 domain names, this is simply 
unusable...

> Note that "confirm domain settings" was only suggested as an addition to the 
> user submitted data. There is no /need/ for adaption of this feature, user 
> submitted data will likely do just fine in most cases.
>   
Not sure to what this relates, I think I'm missing the context now. Not 
sure if you responded to that, but did you see 
http://wiki.mozilla.org/Thunderbird:Autoconfiguration:DNSBasedLookup ?


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

0
Eddy
3/31/2008 1:47:59 PM
Reply:

Similar Artilces:

[svn:parrot-pdd] r14888
Author: coke Date: Tue Oct 10 19:16:37 2006 New Revision: 14888 Modified: trunk/docs/pdds/clip/pddXX_cstruct.pod (props changed) trunk/docs/pdds/clip/pddXX_pmc.pod (props changed) Changes in other areas also in this revision: Modified: trunk/ (props changed) trunk/apps/p3/README (props changed) trunk/apps/p3/cgi-pir/slides.pir (props changed) trunk/apps/p3/index.html (props changed) trunk/apps/p3/p3p.css (props changed) trunk/apps/p3/p3p.html (props changed) trunk/apps/p3/slides.js (props changed) trunk/cage/consting.pod (pro...

Thunderbird auto-configuration XML setup
Hi folks, following the directions at https://developer.mozilla.org/en/Thunderbird/Autoconfiguration has landed me against a brick wall.. Currently I have a config XML file located at autoconfig.<mydomain>.com/mail/tb3.xml Beyond having the xml file available, what else should I setup to have thunderbird detect that XML file? thanks so much in advance! -J- On 10-06-23 2:46 PM, Jeff Sdummy wrote: > Hi folks, > following the directions at https://developer.mozilla.org/en/Thunderbird/Autoconfiguration > has landed me against a brick wall.. > Currently I have a ...

App manager and Dev Apps
Hello, I am experiencing problems to debug apps loaded in the App Manager. I don't have this problem if the App is downloaded from the Marketpalce and debugged with the App Manager. Is there a known problem to debug Dev Apps, loaded from a directory in your computer? Thanks, Juanma ...

Proposal: Stage based app bootstrap process (cross-post from dev.gaia)
Hi guys, that's a cross-post from dev.gaia - guys there pointed out that th= ere may be more work for Gecko here than I anticipate. :) =3D=3D=3D Problem =3D=3D=3D FirefoxOS apps bootstrap code is quite messy and incoherent. Lack of API that would enable an App to control the System's behavior (like= firstPaint) results in a lot of dirty hacks intended to provide decent app= startup user experience. Preventing FOUC's, flickering, on-screen layout composition, both for apps = and for the System itself (think - runtime localization) requires a lot of = trickery and...

W3C Proposed Recommendation: Packaged Web Apps (Widgets)
W3C recently published the following Proposed Edited Recommendation Packaged Web Apps (Widgets) - Packaging and XML Configuration (Second Edition) http://www.w3.org/TR/2012/PER-widgets-20120925/ If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) The dead...

App needs to open other app (dev help)
Hi there, I have this app, which needs to open another app, and minimize the current = app. Its like you have a link to the app and when you click on it, it opens= it. How to do that in FF OS app? Would creating a href link a good idea? I= f not, then what is the correct way to do it? Thanks ...

superreview denied: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current bran
Mark Mentovai <mark@moxienet.com> has denied Josh Aas <joshmoz@gmail.com>'s request for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ------- Additional Comments from Mark Mentovai <mark@moxienet.com> The app bundle's name is ThunderbirdDebug during a debug build. I'd be pleased to...

superreview granted: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP_D
Mark Mentovai <mark@moxienet.com> has granted David Bienvenu <bienvenu@nventure.com>'s request for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from Mark Mentovai <mark@moxienet.com> This comment isn't necessary: +# Executable should match ...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current b #3
Josh Aas <joshmoz@gmail.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 217422] Patch against current b #2
Josh Aas <joshmoz@gmail.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 217422: Patch against current branch files https://bugzilla.mozilla.org/attachment.cgi?id=217422&action=edit ------- Additional Comments from Josh Aas <joshmoz@gmail.com> I know mark isn't sr, but I want him to review this and I can't request another normal review via flags... I suspect this won't be as sa...

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP #2
Chris Andrichak <chris@grope.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from Chris Andrichak <chris@grope.com> Getting the executable name from the variable at mark's suggestion, the make file now swaps it into the plist file also....

superreview requested: [Bug 273977] Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) : [Attachment 220339] Patch that uses MOZ_APP #3
David Bienvenu <bienvenu@nventure.com> has asked for superreview: Bug 273977: Thunderbird does not identify itself correctly to iListen voice rec application (Thunderbird.app vs thunderbird-bin ?) https://bugzilla.mozilla.org/show_bug.cgi?id=273977 Attachment 220339: Patch that uses MOZ_APP_DISPLAYNAME for executable https://bugzilla.mozilla.org/attachment.cgi?id=220339&action=edit ------- Additional Comments from David Bienvenu <bienvenu@nventure.com> you need to request reviews of people - bugzilla should really complain about that! ...

Thunderbird configuration
Name: Rick Ward Product: Thunderbird Summary: Thunderbird configuration Comments: Could we please have Thunderbird for Windows with an option for the user to specify where the mailboxes will go? Right now there seems no option but to have them in C:\Documents and Settings\<username>\Application Data\Thunderbird\Profiles, and that's not where I want them. The first rule of OS design, which Windows violates in hundreds of ways, is that the system, the applications, and the users, be kept separate from each other. Windows doesn't really allow you to do that, but a...

Configuring Thunderbird
I have installed version 2.0.0.9. The mail client will send mail but not receive it. I have verified the address for the pop mail server (mail.swcmail.net) and have verified my username and password. I get the following message: "Sending of password did not succeed. Mail server mail.swcmail.net responded: authorization failed." I have read the blurb on the Windows Firewall in the installation instructions and followed the recommendations. It does not seem to be blocking Thunderbird. As a test, I have turned off the firewall to no avail. I have been using Outloo...

Web resources about - Proposal: Auto-configuration - mozilla.dev.apps.thunderbird

Auto-configuration - Wikipedia, the free encyclopedia
Auto-configuration is the automatic configuration of devices without manual intervention, without any need for software configuration programs ...

Auto-configuration - Wikipedia, the free encyclopedia
Auto-configuration is the automatic configuration of devices without manual intervention, without any need for software configuration programs ...

Resources last updated: 12/30/2015 6:10:29 PM