Proposal: Auto-configuration
Ben Bucksch
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:
- The legacy rdf files in <installdir>/isp/, like we have for Google Mail right now. (This may be dropped.)
- Try to contact a mail configuration
server of the provider, e.g. define an
DNS TXT record or similar on domain example.net (for
my.ac...@example.net) which contains an URL like https://mailconfig.example.net/mozilla.xml .
That file contains the mail configuration, essentially the same as in RDF files, just the format a bit cleaned up. The email address (before @ or with domain) that the user can be used as placeholder in the config file, so the file is the same for all users (i.e. static).
The protocol should be https (otherwise a MITM can direct my traffic and login request to him by just telling me his server as config). - 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. - Other ways, esp. for company email accounts? Avoid heuristics!
- If all fails, we ask the user to enter
the configuration, using the existing wizard. We should also provide an
option to ignore the autoconfig and go into manual config, e.g. using a
new radio button "Email account, manual configuration".
Unless we go into manual config, the "Next" button turns into "Done", on the first page already. In that case, there is no second page, not even the summary screen. The user ends up directly in his inbox. (The password dialog does not need to come up either, as the password has already been entered by the user and the wizard filled it in using the password manager.)
-- When responding via mail, please remove the ".news" from the email address.
Eddy Nigg (StartCom Ltd.)
Ben Bucksch:
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
>
+1
> 1. The legacy rdf files in <installdir>/isp/, like we have for Google
> Mail right now. (This may be dropped.)
>
Should be dropped in this scenario, IMO.
> 2. Try to contact a mail configuration server of the provider, e.g.
> define an DNS TXT record or similar on domain example.net (for
> my.ac...@example.net) which contains an URL like
> https://mailconfig.example.net/mozilla.xml .
>
Something like this:
mta1.mozilla.org. IN TXT
"misp=http://www.mozilla.com/isp/config.rdf"
If we'd use a unique extension for the RDF file (something like .mrdf,
we could also try to trigger the account setup if clicked on)?
> The protocol should be https (otherwise a MITM can direct my
> traffic and login request to him by just telling me his server as
> config).
>
This is a MUST not SHOULD...IMO.
>
> Unless we go into manual config, the "Next" button turns into "Done", on
> the first page already. In that case, there is no second page, not even
> the summary screen. The user ends up directly in his inbox. (The
> password dialog does not need to come up either, as the password has
> already been entered by the user and the wizard filled it in using the
> password manager.)
>
There might be a need to let the user select different server types if
the ISP offers them, like POP3, IMAP and it's secured equivalents.
--
Regards
Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org>
Jabber: star...@startcom.org <xmpp:star...@startcom.org>
Blog: Join the Revolution! <http://blog.startcom.org>
Phone: +1.213.341.0390
Joey Minta
from rdf to json. That doesn't alter much of the logistics of this
proposal, more just a technical correction though. See bug 418693.
-Joey
On Tue, Mar 4, 2008 at 1:07 AM, Ben Bucksch <ben.buck...@beonex.com>
wrote:
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
>
> Most people are using webmail these days, mainly because it's so easy.
> You only need to know the URL (usually linked from the provider's
> homepage) and email address and password, and there's your inbox
> already. ISPs, although all of them provide POP/IMAP, are leading users
> to webmail because of that ease of use (and free mail providers do so
> for the advertizing revenue).
>
> Goal: Setting up Thunderbird should be as easy as download/install and
> entering real name, email address and password. The Account Setup Wizard
> consists of only one screen.
>
> Proposal:
> In the Account Setup wizard, if the "Email account" radio button is
> selected (which is the default), 3 text fields are visible and enabled:
> real name, email address and password.
>
> Email address is properly syntax-checked, and the existance of the
> domain in DNS is checked.
>
> The domain if the email address is used to determine the configuration
> (POP/IMAP and SMTP server names, SSL yes/no, authentication methods
> etc.), via several mechanisms:
>
> 1. The legacy rdf files in <installdir>/isp/, like we have for Google
> Mail right now. (This may be dropped.)
> 2. Try to contact a mail configuration server of the provider, e.g.
> define an DNS TXT record or similar on domain example.net (for
> my.ac...@example.net) which contains an URL like
> https://mailconfig.example.net/mozilla.xml .
> That file contains the mail configuration, essentially the same as
> in RDF files, just the format a bit cleaned up. The email address
> (before @ or with domain) that the user can be used as placeholder
> in the config file, so the file is the same for all users (i.e.
> static).
> The protocol should be https (otherwise a MITM can direct my
> traffic and login request to him by just telling me his server as
> config).
> 3. If the email provider does not provide the configuration, we try
> to find it at mozillamessaging.com, e.g.
> https://autoconfig.mozillamessaging.com/example.net/config.xml .
> This service will have the configuration for all the major ISPs
> and email providers, so there's a 90+% hit rate.
> It will not work for company email addresses.
> If a provider disagrees with a setting there, it can override the
> configuration by simply providing the config server in step 2.
> 4. Other ways, esp. for company email accounts? Avoid heuristics!
> 5. If all fails, we ask the user to enter the configuration, using
> the existing wizard. We should also provide an option to ignore
> the autoconfig and go into manual config, e.g. using a new radio
> button "Email account, manual configuration".
>
>
> Unless we go into manual config, the "Next" button turns into "Done", on
> the first page already. In that case, there is no second page, not even
> the summary screen. The user ends up directly in his inbox. (The
> password dialog does not need to come up either, as the password has
> already been entered by the user and the wizard filled it in using the
> password manager.)
>
> --
> When responding via mail, please remove the ".news" from the email
> address.
>
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
Peter Lairo
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
>
> entering real name, email address and password. The Account Setup Wizard
> consists of only one screen.
>
> Proposal:
> In the Account Setup wizard, if the "Email account" radio button is
> selected (which is the default), 3 text fields are visible and enabled:
> real name, email address and password.
>
> Email address is properly syntax-checked, and the existance of the
> domain in DNS is checked.
>
> The domain if the email address is used to determine the configuration
> (POP/IMAP and SMTP server names, SSL yes/no, authentication methods
> etc.),
Good idea. I proposed another possibility iyesterday in another thread:
+-------------------------------------------------+
| Account Wizard |
~ ~
| (o) E-Mail account |
| (o) Pre-configured e-mail providers (ISPs) | <--- NEW
| +-------------------------------------+ |
| | fastmail.fm /\| |
| | freenet.de ||| |
| | Google Mail (gmail) ||| |
| | gmx.de \/| |
| +-------------------------------------+ |
| ( ) Import settings from a file | <--- NEW
| ( ) Manual Configuration |
| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next ] [ Cancel ] |
+-------------------------------------------------+
The pre-configured list could either be hard-coded into the current
Thunderbird release (requires no internet connection but is not
up-to-date), or it could be downloaded from a server (requires internet
connection but is up-to-date). Perhaps the list could also auto-filter
on whatever locale the OS reports (e.g., German users get only German
ISPs plus the major international ISPs).
Combining your and my methods could yield:
+--------------------------------------------------+
| *Account Wizard* |
~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |
| (o) Auto-detect:[ ] [Refresh] | <-- yours
| ( ) Pre-configured e-mail providers (ISPs) | <-- and mine
| +-----------------------------------+ |
| | fastmail.fm /\| |
| | freenet.de ||| |
| | Google Mail (gmail) ||| |
| | gmx.de \/| |
| +-----------------------------------+ |
| ( ) Import settings from a file |
File: [ ] [Browse] |
| ( ) Manual configuration |
| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+
Since the three fields apply to all e-mail setup options, I have placed
them above the three radio buttons.
If the ISP offers both POP and IMAP, I hope Thunderbird will choose IMAP.
If the user selects "Newsgroup account", the name and email fields would
appear there:
| (o) Newsgroup account |
| Full name: [ ] |
| E-Mail address: [ ] |
PS. I'm not sure if the suddenly appearing fields and thereby vertically
shifting radio buttons would be a source of confusion/distraction to the
inexperienced user.
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Dangers of Islam (German): http://www.pi-news.net/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Peter Lairo
> | (o) E-Mail account |
> | |
> | Full name: [ ] |
> | E-Mail address: [ ] |
> | Password: [ ] |
> | |
> | (o) Auto-detect:[ ] [Refresh] | <-- yours
Perhaps the auto-detect filled could start auto-detecting when it
detects that the e-mail address field has data in it. Either by pinging
the e-mail field every second (or so) or if the user "exits" the e-mail
field.
IANAP (i am not a programmer)
Peter Lairo
> Perhaps the auto-detect filled ...
s/filled/field :-[
Tuukka Tolvanen
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
Ooh.
> Proposal:
> In the Account Setup wizard, if the "Email account" radio button is
> selected (which is the default), 3 text fields are visible and enabled:
> real name, email address and password.
I feel a bit wary about asking for and using a password without running
the server details past the user first.
> Unless we go into manual config, the "Next" button turns into "Done", on
> the first page already. In that case, there is no second page, not even
> the summary screen. The user ends up directly in his inbox. (The
> password dialog does not need to come up either, as the password has
> already been entered by the user and the wizard filled it in using the
> password manager.)
I think skipping to the summary screen would be more appropriate, and
allowing the user to go back and customize stuff from there if they want
to, so "advanced" users can do their personal weird thing while getting
the benefits of the autoconfig. I suppose skipping wizard pages that
might be of interest would require showing what pages exist... there's
probably a better way to do that flow but that's details :)
(Just pre-filling would be helpful, but wouldn't go that far in
dispelling the "this is complicated" and avoiding preventable user
errors even if it's just next next next finish.)
't.
Ben Bucksch
> I just wanted to note that I'm in the process of changing the ISP rdf files
> from rdf to json. That doesn't alter much of the logistics of this
> proposal, more just a technical correction though. See bug 418693.
>
Thanks for the hint.
I see the desire to get rid of RDF, but I chose XML intentionally,
because it's a clear description format, and easy and safe to process.
With JSON, you need to start to either parse it manually or it gets
dangerous with security (even when you try to run it unprivileged) when
it's loaded from the network.
Also, last but not least, the configuration files in my proposal should
be usable by other email clients as well and not be specific to
Thunderbird. Although it's possible to parse JSON with other languages,
I think XML is a more accepted general data format than JSON, and would
have a higher chance of being adopted by other clients.
My ideal is to get rid of the current rdf files entirely. The shipping
google.rdf would be replaced by the website service. We could include a
step to try to get the XML config file (same format as from the net)
from the harddisk. Then, companies deploying Thunderbird would have the
option of either putting the config on a server and modify their DNS, or
to include the config file in their own Thunderbird distribution.
The concrete format for the XML file would probably be very close to the
current RDF files, just the namespace and element names some nesting
cleaned up to remove the Mozilla-specific parts. Most of the current
nesting/structure seems reasonable to me, though.
Ben
Ben Bucksch
The idea is to make things very simple... The more options there are,
the more scared people are.
The "preconfigured" option is not needed, this is already automatically
used in my proposal. The provider is selected based on the domain of the
email address.
So, my proposal would be:
+--------------------------------------------------+
| *Account Setup* |
~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |
| ( ) E-Mail account, manual configuration |
| ( ) RSS News Feeds and Blogs |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+
where "Email account, manual configuration" does exactly what "Email
account" does today, while the new "Email account" is the automatic
setup, using the logic I posted, using the preconfigured providers, the
provider's config file on the net, or the mozilla config web service.
The current "Google mail" option goes away and is used automatically
when the user enters his...@gmail.com or googlemail.com/de in automatic
setup option.
Ben
Peter Lairo
> The idea is to make things very simple... The more options there are,
> the more scared people are.
Good point.
> +--------------------------------------------------+
> | *Account Setup* |
> ~ ~
> | (o) E-Mail account |
> | |
> | Full name: [ ] |
> | E-Mail address: [ ] |
> | Password: [ ] |
> | |
> | ( ) E-Mail account, manual configuration |
> | ( ) RSS News Feeds and Blogs |
> | ( ) Newsgroup account |
> | |
> | [ Back ] [ Next/Done ] [ Cancel ] |
> +--------------------------------------------------+
I don't like that there are two top-level radio buttons for e-mail.
Also, there is no visual indication if the auto-detect was successful
(or if it is even doing anything). That is why I suggest a morph between
your current dialog and mine:
+--------------------------------------------------+
| *Account Wizard* |
~ ~
| (o) E-Mail account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Password: [ ] |
| |
| (o) Auto-detect:[ ] [Refresh] |
| |
| ( ) Manual configuration |
| |
| ( ) RSS News Feeds and Blogs |
| |
| ( ) Newsgroup account |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+
I think this arrangement is more logical (e-mail settings sub-types are
grouped in sub-radio-buttons under e-mail account).
I've eliminated the "Pre-configured" and the "Import settings from a file".
The "Import settings from a file" could (should?) be possible from the
"Manual configuration".
BTW: Should selecting "Newsgroup account" yield:
+--------------------------------------------------+
| *Account Wizard* |
~ ~
| ( ) E-Mail account |
| |
| ( ) RSS News Feeds and Blogs |
| |
| (o) Newsgroup account |
| |
| Full name: [ ] |
| E-Mail address: [ ] |
| Newsgroup server:[ ] |
| |
| [ Back ] [ Next/Done ] [ Cancel ] |
+--------------------------------------------------+
That would show all info in *one dialog* (user feels less "lost") (which
I think is a big improvement), but would cause the radio buttons to
"jump" vertically, depending on the selection. In any case, the height
of the dialog should *never* change. What ya think?
PS. Should required entries be somehow marked?
Kent James
> 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.
>
hate RDF" philosophy, down the street at SRI a major, well-funded
RDF-based initiative has adapted the mozilla mailnews and browser into
OpenIris for an integrated desktop.
- rkent
Eddy Nigg (StartCom Ltd.)
efficiently should be used. We should take into account that it's the
ISPs which have to understand and prepare the discovery file, so lets
make it most friendly for them in every respect. It looks to me as if
both options mentioned are simple XML, so....?
Henrik Gemal
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
>
Would also be nice if Thunderbird supported being called from a
webpage to setup accounts. This way ISP could setup account when users
register with the service.
Tuukka Tolvanen
> Peter Lairo schrieb:
>> Ben Bucksch on 04.03.2008 07:07 wrote:
>>> Objective: Make my non-tech friends use Thunderbird, by making it
>>> dead-simple to set up.
> The idea is to make things very simple... The more options there are,
Current wizard pages, assuming email selected on first page:
1. new acct setup: email / feeds / newsgroups [cancel] [next]
2. identity: name, address [cancel] [back] [next]
3. server: pop / imap, server, global inbox [cancel] [back] [next]
4. user names: incoming, outgoing [cancel] [back] [next]
5. account name [cancel] [back] [next]
6. verify, download now? [cancel] [back] [finish]
Here's my suggestion:
1. new acct setup: email / feeds / newsgroups [cancel] [next]
2. identity: name, address [cancel] [back] [next]
6a. (progress meter isn't optional since we're networking...)
A: service autoconf found
6b. verify, download now? [cancel] [back] [customize] [finish]
B: service autoconf not found, or customize pressed
6c. (sorry, autoconf not found, or this could just skip forward)
3. server: pop / imap, server, global inbox [cancel] [back] [next]
4. user names: incoming, outgoing [cancel] [back] [next]
5. account name [cancel] [back] [next]
6. verify, download now? [cancel] [back] [finish]
I.e. use current pages, insert a page similar to 6 that indicates
progress and then confirms account data. If autoconf is successful and
customize is selected, values are prefilled on the subsequent wizard
pages. That's two wizard page more than your suggestion, but you
* know which server you send the password to
* don't have to choose between getting easy configured values and
being able to customize whatever
* the first page stays neat, putting in an address is applicable to
the other choices as well so it only appearing under email for its fast
case would be weird
The suggested fast case flow would be identical to what the first page
gmail selection does now.
't.
Ben Bucksch
> Would also be nice if Thunderbird supported being called from a
> webpage to setup accounts. This way ISP could setup account when users
> register with the service.
Outlook Express can do that. They have such provider files, IIRC in INI
file form, and a special file extension for that. We could register that
file extension in the OS and try to parse that file.
I don't think many ISPs are using that, though. I have never seen it in
my real-world usage.
The advantage of this proposal is that ISPs can use it, but it works
without their support.
We could support both.
Simon Wilkinson
On 4 Mar 2008, at 19:03, Henrik Gemal wrote:
> Would also be nice if Thunderbird supported being called from a
> webpage to setup accounts. This way ISP could setup account when users
> register with the service.
Can SRV records offer us anything here? They require effort on behalf
of the ISPs to set up, but provide a relatively standard mechanism
for service location.
Simon.
Eddy Nigg (StartCom Ltd.)
> I don't think many ISPs are using that, though. I have never seen it in
> my real-world usage.
Eddy Nigg (StartCom Ltd.)
> 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.
>
>
our purpose well. It would have to look something like this:
_mail_isp._tcp IN SRV 0 100 80 mail.mozilla.org.
But in this case the discovery file would have to be always at the same
known location, like http://mail.mozilla.org/isp.rdf
Whereas with a TXT record we could use:
mail IN TXT "misp=http://mail.mozilla.org/somewhere/myisp.rdf"
Obviously both records would be discovered using the MX record of the
email address first. The parent of both records is mozilla.org.
Simon Wilkinson
On 4 Mar 2008, at 19:54, Eddy Nigg (StartCom Ltd.) wrote:
> Simon Wilkinson:
>> Can SRV records offer us anything here? They require effort on behalf
>> of the ISPs to set up, but provide a relatively standard mechanism
>> for service location.
>>
> So SRV records are made for service discovery, I think it will not
> serve
> our purpose well.
I don't think that SRV records could be used as a replacement for
your RDF discovery files, but they could prove a useful alternative
to them. In cases where all you want to be able to do is say "where
is the IMAP server for the domain 'example.com'", they can provide a
lightweight alternative.
Once you've found whether you're supposed to be using IMAP or POP,
you can auto-discover pretty much everything else by talking to the
server. In particular, the SASL refactoring I'm working on should
provide a mechanism to pick the 'best' SASL mechanism supported by
the server, and record that for future use. This is particularly
important for mechanisms like GSSAPI.
S.
Eddy Nigg (StartCom Ltd.)
>
> 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.
>
known standard for lets say pop3, imap, smtp like:
_pop3._tcp IN SRV 0 100 110 mail.mozilla.org.
_pop3s._tcp IN SRV 0 100 995 mail.mozilla.org.
_imap._tcp IN SRV 0 100 143 mail.mozilla.org.
_imaps._tcp IN SRV 0 100 993 mail.mozilla.org.
_smtp._tcp IN SRV 0 100 25 mail.mozilla.org.
Or is there? And what about STARTTLS for SMTP? Perhaps _starttls._tcp ?
But SRV discovery would be COOL!!! :-)
Eddy Nigg (StartCom Ltd.)
> 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!!! :-)
>
http://www.dns-sd.org/ServiceTypes.html
Ben Bucksch
a bit of the XML file format:
http://wiki.mozilla.org/Tb:Autoconfiguration
Simon Wilkinson
On 4 Mar 2008, at 20:53, Ben Bucksch wrote:
> Proposal placed on wiki, incorporating some of the feedback, and
> adding
> a bit of the XML file format:
>
> http://wiki.mozilla.org/Tb:Autoconfiguration
You say...
"The protocol should be https (otherwise a MITM can direct my traffic
and login request to him by just telling me his server as config)"
This actually makes no difference from a security perspective,
because the URL was originally obtained via a TXT record. It's as
easy to spoof DNS records, as it is to redirect http connections.
This is the main issue with obtaining any form of service location
information through DNS, be it A, SRV, or TXT, records.
S.
Ben Bucksch
I am not very clear on service discovery, somebody with knowledge of the
pros/cons please fill in.
So far, I have as options:
* favicon approach: Look up a certain defined hostname in the DNS like
mailconfig.<emaildomain>, e.g. mailconfig.example.net , assume that it's
an https server and contact a hardcoded URL like
https://mailconfig.example.net/config/mozilla.xml
I hate favicons. I think it's arrogant to assume and dictate that a
certain URL is valid. This here will spam the DNS system, not http
servers. Put off by the fact that setting up an account is a rare action.
* DNS TXT record
Look up all TXT records for example.net and pick the one starting with
"mailconfig=".
* DNS SRV record
Your proposal.
I have no idea how hard it is for admins to set up such custom DNS
records, in the various DNS server implementations. If the admin doesn't
know how to do it (and many are clueless Windows click click admins,
even in big companies), or simply refuses because he doesn't like it
("company policy"), then whoever at the ISP is in support for this will
be blocked.
More info and proposals welcome.
Eddy Nigg (StartCom Ltd.)
> You say...
>
> "The protocol should be https (otherwise a MITM can direct my traffic
>
> 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.
>
>
Ben Bucksch
>
> On 4 Mar 2008, at 19:54, Eddy Nigg (StartCom Ltd.) wrote:
>
>> Simon Wilkinson:
>>> Can SRV records offer us anything here? They require effort on behalf
>>> of the ISPs to set up, but provide a relatively standard mechanism
>>> for service location.
>>>
>> So SRV records are made for service discovery, I think it will not serve
>> our purpose well.
>
> I don't think that SRV records could be used as a replacement for your
> RDF discovery files, but they could prove a useful alternative to
> them. In cases where all you want to be able to do is say "where is
> the IMAP server for the domain 'example.com'", they can provide a
> lightweight alternative.
Ah. No, that's not sufficient. There are many fine options that the
config files set, some of them critical, like SSL/TLS, the
authentication method, the mailbox folder root and inbox path for IMAP,
how to compose the login name etc.. Server name/port is not sufficient.
> Once you've found whether you're supposed to be using IMAP or POP, you
> can auto-discover pretty much everything else by talking to the server.
I would not like to rely on the IMAP or POP or SMTP server
implementation supporting that, because that requires a whole bunch of
other software support.
Simon Wilkinson
On 4 Mar 2008, at 21:03, Eddy Nigg (StartCom Ltd.) wrote:
> LOL! That's why it should be secured over https in order to avoid
> spoofing.
This doesn't help. Which was my point, if you'd read carefully. https
is not a universal panacea.
The proposal involves getting the URL from a TXT record. In the
absence of DNS-SEC, TXT records are insecure.
So, an attacker can subvert the DNS, and have the TXT record for
mozilla.org point to, say, https://nasty.evil.git/autoconfig.rdf
Providing they have a valid certificate for nasty.evil.git (and why
shouldn't they, if they own that domain), then the client will see no
SSL verification errors, and happily download the autoconfiguration
file. You might as well just use http, and save the processor overhead.
S.
Eddy Nigg (StartCom Ltd.)
> 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.
1.) The file MUST be over SSL/TLS
2.) The wizard must prompt first before continuing, similar to package
installation, e.g. "Do you want to download and configure....blah,
blah...(with the usual 2 seconds delay)
> You might as well just use http, and save the processor overhead.
No, lets do it right from the beginning...
Simon Wilkinson
On 4 Mar 2008, at 21:21, Eddy Nigg (StartCom Ltd.) wrote:
> Simon Wilkinson:
>>
>> On 4 Mar 2008, at 21:03, Eddy Nigg (StartCom Ltd.) wrote:
>>>
>>> LOL! That's why it should be secured over https in order to avoid
>>> spoofing.
>> This doesn't help. Which was my point, if you'd read carefully.
>> https is not a universal panacea. The proposal involves getting
>> the URL from a TXT record.
> The same way you get A records and any other one...
But when you get an A record, and then use that for https, there is a
process that binds the IP layer (the address) with the security layer
(the TLS certificate). Nothing in the current proposal achieves this
binding, and so everything else is just snake oil.
> 1.) The file MUST be over SSL/TLS
> 2.) The wizard must prompt first before continuing, similar to
> package installation, e.g. "Do you want to download and
> configure....blah, blah...(with the usual 2 seconds delay)
This falls foul of all of the 'goal motivated user' problems. If you
want to do this properly, then you have to tie the domain of the
server being configured with the domain from which the configuration
is fetched. This will inevitably cause problems for ISPs which
support a large number of 'vanity' domains.
S.
Ben Bucksch
> "The protocol should be https (otherwise a MITM can direct my traffic
> and login request to him by just telling me his server as config)"
>
> This actually makes no difference from a security perspective, because
> the URL was originally obtained via a TXT record. It's as easy to
> spoof DNS records, as it is to redirect http connections. This is the
> main issue with obtaining any form of service location information
> through DNS, be it A, SRV, or TXT, records.
Yes, unfortunately.
The favicon approach would not have that problem.
Any kind of security check that can use only the email address domain as
trust root has the problem that there are email providers with countless
domains (coolpeople.com etc.).
Ben Bucksch
you cced ben.b...@beonex.com, in a posting that's on
news.mozilla.org, which is gated to the Usenet. Now that address is on
Usenet and will get spammed more :-( .
Ben
Ben Bucksch
> you cced <removed>, in a posting that's on news.mozilla.org, which is
> spammed more :-( .
An idiotic as I am, I post this private mail to Usenet.
Eddy Nigg (StartCom Ltd.)
> 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.
>
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.
host your mail at google and it asks to download the config from an
unknown location? No, it's not perfect, but perhaps as good as it gets...
Ben Bucksch
> Huuu? And why not exactly? Maybe I'm missing something here, but I
> understand that this is just about how the config file is fetched
> (over https), nothing more....why should TB "bind" any different? TB
> has NSS and can connect to a https socket...I'm not seeing what's
> wrong with that..
https on the web would be just snake oil, if the browser did not enforce
that the domain "subject" in the cert matches the domain of the URL that
the user entered or clicked on originally. I think that's what he means
with "binding".
Here, the trust root that the user entered is the email address domain.
It's possible to match the cert with that, but that poses a problem for
vanity email providers with a few thousand dozen, hundred or thousand
domains. Not to even start with those offers where people get their own
domain name (which everyone should!). Of course you're from an CA, so
that's not a problem from your perspective, but it's a serious
deployment problem for ISPs, if not financial. https also needs one IP
address per cert.
I added a security section at the wiki page documenting the mentioned
problems.
Ben
Stefanie Blackburn
framework support/replace the existence of the autoconfig.jsc file if
this is being used by companies running this internally?
Thanks
> _______________________________________________
> dev-apps-thunderbird mailing list
> dev-apps-t...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-thunderbird
>
--
********************************************************************
Stefanie Blackburn
Product Manager, Netscape Messenger
Productivity Tools & Services
Corporate Resources IT Tel: (303) 223-7619
Sun Microsystems Inc. Fax: (303) 272 6703
500 Eldorado Blvd BRM02
Broomfield, CO 80021 mailto:Stefanie....@Sun.Com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The information contained in this electronic transmission is
intended only for the use of the recipient and may be Sun
Microsystems, Inc. or its Subsidiaries, confidential,
attorney-client privileged, and/or constitute inside
information. Unauthorized use, disclosure, or reproduction is
strictly prohibited, and may be unlawful. If you have received
this electronic transmission in error, please notify the sender
immediately and delete all copies from your system."
********************************************************************
Eddy Nigg (StartCom Ltd.)
> 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".
>
the URL we are going to use to download the config file. So far so good
I guess. Now, by visually having the user confirm this like:
"You are about to download a configuration file from
*https://www.mozilla.org/config.rdf* which Thunderbird found for your
email address. The address above provided a valid certificate for this
purpose. Do you want to continue or configure your account manually?"
[ Yes ] [ Configure Manually ] [ Cancel ]
> Here, the trust root that the user entered is the email address domain.
> It's possible to match the cert with that, but that poses a problem for
> vanity email providers with a few thousand dozen, hundred or thousand
> domains. Not to even start with those offers where people get their own
> domain name (which everyone should!). Of course you're from an CA, so
> that's not a problem from your perspective, but it's a serious
> deployment problem for ISPs, if not financial. https also needs one IP
> address per cert.
>
No only that, but also from an ISP for mail and web. Now lets look at
this more carefully...not saying there is a perfect solution, but I
guess we should do the obvious or drop the idea altogether....
As an ISP I provide the user with his account details which he in turn
uses to configure is mail client. Supposed the DNS server of the ISP or
the ones the user is using gets poised, he might end up either way at
the wrong server, offering generously his password for his mail account.
This is nothing new, it can happen every time, everyday! Every time a
mail client authenticates against the server, sometimes every ten
minutes or so (with SMTP auth and POP3) does this happen. However it is
less likely if the mail server uses SSL for IMAP,POP and SMTP.
Lets continue to the next step. We should only offer account setup via
config files when the following conditions are met:
1.) An MX record for the email address exists.
2.) There is a TXT entry as proposed by you for the config file. (At
this stage please note that one mail server handles multiple domain
names, hence the requirement for an MX record (even so an A record is
allowed as well according to RFC)).
3.) The URL found in the TXT record is an SSL secured site and uses the
https:// prefix (it is allowed to use a different port then 443).
4.) The site is correctly secured and the certificate can be chained to
a trusted root.
5.) The user confirms the download (See above).
If we follow this rule, the likelihood for misuse is limited to a
reasonable extend. Certainly better than just dropping SSL and download
via plain any file, no questions asked (As Simon proposes it). Also ways
better than any authentication via the regular POP3, IMAP and SMTP
services in plain text.
ISPs which operate one or more mail servers will still need only ONE
configuration file (see for example google mail configuration when
hosting mail with them). Therefore the TXT record for domain1.com,
domain2.com and domain3.com will all use the same config file, i.e. the
only one for the responsible mail server (mail.domain.com as per MX
record of the domain in question). There is no need for more than one
secured host. It can be any URL, perhaps an existing SSL site.
(** Somewhat off-topic: The requirement for unique IP addresses per
(sub)domain for SSL is coming to an end pretty soon. IIS supports DNS
entries via Alt Names extension for a long time already and the newest
Apache-to-come will supports it as well. All modern browsers support it
too. All you need is a certificate will all domain names and/or wild
cards or any combination thereof.)
Dan Mosedale
This is an interesting use case. Seems like it wouldn't be hard to do
by using a MIME-type for autoconfig files.
Dan
Dan Mosedale
> Joey Minta schrieb:
>> I just wanted to note that I'm in the process of changing the ISP rdf
>> files from rdf to json. That doesn't alter much of the logistics of this
>> proposal, more just a technical correction though. See bug 418693.
>
> Thanks for the hint.
>
> I see the desire to get rid of RDF, but I chose XML intentionally,
> because it's a clear description format, and easy and safe to process.
I'm not sure what you mean by "clear", here. I find XML notably harder
for my eyes to read than JSON.
> With JSON, you need to start to either parse it manually or it gets
> dangerous with security (even when you try to run it unprivileged) when
> it's loaded from the network.
You are correct that parsing it manually is required. Fortunately, such
parsers have been written for every language imaginable. See
<http://json.org/> for one list.
> Also, last but not least, the configuration files in my proposal should
> be usable by other email clients as well and not be specific to
> Thunderbird. Although it's possible to parse JSON with other languages,
> I think XML is a more accepted general data format than JSON, and would
> have a higher chance of being adopted by other clients.
This is a little hard to guess. XML is certainly used in non-web
contexts more than JSON, but JSON is pretty huge these days. I
personally lean towards JSON a bit, but it's not clear to me that which
format is chosen matters all that much.
> My ideal is to get rid of the current rdf files entirely. The shipping
> google.rdf would be replaced by the website service. We could include a
> step to try to get the XML config file (same format as from the net)
> from the harddisk. Then, companies deploying Thunderbird would have the
> option of either putting the config on a server and modify their DNS, or
> to include the config file in their own Thunderbird distribution.
This sounds about right to me.
Dan
Dan Mosedale
>> Well, maybe you are right, but I'm not aware that there is convention
>> or known standard for lets say pop3, imap, smtp like:
>>
>> _pop3._tcp IN SRV 0 100 110 mail.mozilla.org.
>> _pop3s._tcp IN SRV 0 100 995 mail.mozilla.org.
>> _imap._tcp IN SRV 0 100 143 mail.mozilla.org.
>> _imaps._tcp IN SRV 0 100 993 mail.mozilla.org.
>> _smtp._tcp IN SRV 0 100 25 mail.mozilla.org.
>>
>> Or is there? And what about STARTTLS for SMTP? Perhaps _starttls._tcp
>> ? But SRV discovery would be COOL!!! :-)
> Actually there is, albeit not complete:
> http://www.dns-sd.org/ServiceTypes.html
While I agree that using SRV or TXT records feels like the part of the
"right" solution, it does require that someone sign up to extend the DNS
service. Right now, nsIDNSService only exposes an API analogous to
getaddrinfo(), it's not currently possible to get SRV or TXT records at
all. It's not clear to me how big a piece of work this is likely to be.
Dan
Simon Wilkinson
On 4 Mar 2008, at 22:19, Ben Bucksch wrote:
>
> I think that's what he means with "binding".
Bindings are the accepted term in the security community for
describing the security linkages between different layers. See, for
example, RFC5056
> Here, the trust root that the user entered is the email address
> domain.
> It's possible to match the cert with that, but that poses a problem
> for
> vanity email providers with a few thousand dozen, hundred or thousand
> domains. Not to even start with those offers where people get their
> own
> domain name (which everyone should!). Of course you're from an CA, so
> that's not a problem from your perspective, but it's a serious
> deployment problem for ISPs, if not financial. https also needs one IP
> address per cert.
Yup. It's not at all clear that requiring that domain of the server
pointed to by the TXT record match the domain of the user is a
scalable solution, for exactly the reasons you outline above.
S.
Eddy Nigg (StartCom Ltd.)
> 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.
>
>
Guess this should be added to the wiki page...
Eddy Nigg (StartCom Ltd.)
>
> 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.
>
>
>
the DNS. This isn't web per se, the TXT must be obtained from the
matching MX record:
Email address: eddy...@startcom.org
Mail server (MX record): mta1.startcom.org
ISP config discovery must be a TXT record of mta1.startcom.org and not
that of startcom.org! Hence the entry would be
mta1 IN A 192.116.202.202
IN MX 10 mta1.startcom.org.
IN TXT "mailconf=https://someurl/somepath/somefile"
And obviously not what you mentioned above. Mail servers and domain
names of mail accounts are scalable. There can be even multiple mail
servers for multiple domain names with failover and priority backups all
using the same config.
Dan Mosedale
> Please forgive me if I missed this in the thread - but - will this new
> framework support/replace the existence of the autoconfig.jsc file if
> this is being used by companies running this internally?
This is unrelated to autoconfig.jsc.
Dan
Ben Bucksch
>> 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:
>
> Mail server (MX record): mta1.startcom.org
> ISP config discovery must be a TXT record of mta1.startcom.org and not
> that of startcom.org! Hence the entry would be
>
> mta1 IN A 192.116.202.202
> IN MX 10 mta1.startcom.org.
> IN TXT "mailconf=https://someurl/somepath/somefile"
First, I would look up TXT startcom.org, not MX startcom.org ->
mta1.startcom.org -> TXT mta1.startcom.org, because a domain can and
should have several, if not many MX, and you don't want to configure
them for each MX, just for the domain. Also, MX is about incoming mail
(SMTP->SMTP), not about fetching or sending mail.
Second, in any case, this doesn't help. As Simon pointed out, you cannot
rely on DNS. As I said, you need to check the domain that the *user
entered* against the SSL cert of the config file server.
Eddy, do certificates exist (and are supported by Mozilla) that list
several unrelated domains, i.e. one server, one IP, one cert, but valid
for coolpeople.com, cansas.us, green.org and 300 other domains?
Ben
Eddy Nigg (StartCom Ltd.)
>> But you are perhaps forgetting that mail is handled via MX records in
>> the DNS. This isn't web per se, the TXT must be obtained from the
>> matching MX record:
>>
>> Email address: eddy...@startcom.org <mailto:eddy...@startcom.org>
>> Mail server (MX record): mta1.startcom.org
>> ISP config discovery must be a TXT record of mta1.startcom.org and not
>> that of startcom.org! Hence the entry would be
>>
>> mta1 IN A 192.116.202.202
>> IN MX 10 mta1.startcom.org.
>> IN TXT "mailconf=https://someurl/somepath/somefile"
>>
>
> First, I would look up TXT startcom.org, not MX startcom.org ->
> mta1.startcom.org -> TXT mta1.startcom.org, because a domain can and
> should have several, if not many MX, and you don't want to configure
> them for each MX, just for the domain. Also, MX is about incoming mail
> (SMTP->SMTP), not about fetching or sending mail.
>
discovery). You don't have a better hint than the MX record. Even so A
records are valid, MX has priority over the A record. And then it
doesn't scale. So you should search for it the same way mail would
search for it, i.e. 1.) MX record, 2.) A record and not the other way
around.
And then, SMTP is part of the configuration, so the MX record makes
discovery easier...why do you want to go the hard/non-natural way? And
then, wasn't it you that proposed to scan each and every TXT record of
the DNS zone? Now you are complaining about having to check maybe two MX
records?
> Second, in any case, this doesn't help. As Simon pointed out, you cannot
> rely on DNS. As I said, you need to check the domain that the *user
> entered* against the SSL cert of the config file server.
>
Of course, this is what NSS does...it does it for web, it does it also
for STMP, IMAPS and POP3S. I proposed to visually show the download
location to the user (not that it means to everybody would realize a
spoof, but it might help. The same users would click also on every XPI
file etc. instead...)
> Eddy, do certificates exist (and are supported by Mozilla) that list
> several unrelated domains, i.e. one server, one IP, one cert, but valid
> for coolpeople.com, cansas.us, green.org and 300 other domains?
>
Yes! I think many CAs can support that. https://www.startssl.com/
supports it to a certain extend after performing Class 2 identity
validation. The fee is US$ 25 for identity validation, another 25 for
organization validation. (Sorry for the advertisement, but you asked for
it ;-) )
However as I explained above, this isn't the way mail is handled and
there is no need for it! Lets say I've got a mail server which handles a
few hundred different domain names and a few thousand users, all of them
are handled from the same mail server. All users configure their client
THE SAME WAY. They would download the very same config file for the
setup. There is no need to have for each domain name a different config
file.
More than that, just forget a second about SSL. Do you really think if I
have a few hundred domain names to handle I'm going to create a config
file for each domain name in my hosting department? It's easier to send
the standard notices and point to the FAQ pages how to configure the
mail. Nonono...If I can add a TXT record into the DNS zone of the mail
server, pointing to one or two different config files, then I'd do it,
because it saves me time and headache. With and without SSL it should be
handled that way.
Chris Ilias
> you cced <removed>, in a posting that's on
> news.mozilla.org, which is gated to the Usenet. Now that address is on
> Usenet and will get spammed more :-( .
<nitpick>
Mozilla newsgroups are not actually fed to Usenet. It's a local
hierarchy, only available through news.mozilla.org and Google Groups.
You'll still get spam though. :-(
</nitpick>
--
Chris Ilias <http://ilias.ca>
List-owner: support-firefox, support-thunderbird, test-multimedia
Henrik Gemal
> Objective: Make my non-tech friends use Thunderbird, by making it
> dead-simple to set up.
>
Two things that I think is missing:
1) Some kind of icon or graphics that the provider can have
2) a way to specify a URL for help/support etc
Otherwise super!
Eddy Nigg (StartCom Ltd.)
> 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>
>
as a user. So robots aren't picking it up.
Robert Kaiser
>
> On 4 Mar 2008, at 20:53, Ben Bucksch wrote:
>
>> Proposal placed on wiki, incorporating some of the feedback, and adding
>> a bit of the XML file format:
>>
>> http://wiki.mozilla.org/Tb:Autoconfiguration
>
> You say...
>
> "The protocol should be https (otherwise a MITM can direct my traffic
> and login request to him by just telling me his server as config)"
>
> This actually makes no difference from a security perspective, because
> the URL was originally obtained via a TXT record. It's as easy to spoof
> DNS records, as it is to redirect http connections. This is the main
> issue with obtaining any form of service location information through
> DNS, be it A, SRV, or TXT, records.
Actually, is _anything_ transferred there that requires strong security?
That is, as in "any stronger security than the usually non-encrypted
SMTP traffic"?
Robert Kaiser
Simon Wilkinson
On 5 Mar 2008, at 21:21, Robert Kaiser wrote:
>
> Actually, is _anything_ transferred there that requires strong
> security?
> That is, as in "any stronger security than the usually non-encrypted
> SMTP traffic"?
The danger is with transferring server location information. In the
current model, the user enters the identity of all of the servers
they'll use. SSL is then used to ensure that the identity of the
server they're connected to matches what they entered.
In the new model, the user enters their email address, and this is
then used to obtain configuration information. However, there isn't a
verifiable trust relationship between the server they're connecting
to, and the email address. This means that an attacker can simply
replace the server name in the configuration data (or replace the
entire configuration data). TLS will still think this is a valid
connection, because the server name in the users configuration
matches the certificate the server presents.
So, you make it very easy for man in the middle attacks which capture
the user's password.
S.
Eddy Nigg (StartCom Ltd.)
>> "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"?
giving good examples and lead the way. In relation to that TB does a
good job thanks to the NSS module etc....and supports STARTTLS, SSL,
IMAPs and POP3s. I think we should provide a secure mechanism if
possible in order to facilitate providers which take security seriously.
The "auto-setup-feature" should not be the weak link for such providers.
Joshua Cranmer
> Now that address is on
> Usenet and will get spammed more :-( .
>
> Ben
I think you overestimate the amount of spam generated by Usenet. I used
my ISP email address for well over a year on c.l.j.*--and publicly
posted nowhere else by myself--and the total amount of spam I get is at
best 1 every few weeks. Oh wait, I'm still posting on my actual email
address here.
Peter Lairo
> Actually, is _anything_ transferred there that requires strong security?
> That is, as in "any stronger security than the usually non-encrypted
> SMTP traffic"?
If the user enters Joh...@myISP.com as his e-mail address, and the
server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
traffic is then between the user and the server at myISP.com, then how
can a MITM attack even occur.
If the (MITM) server responds with anything BUT myISP.com (e.g.,
evilISP.com) then Thunderbird would NOT auto-complete the setup but
could bring up a dialog telling the user that there is a mismatch and a
POTENTIAL MITM issue and ask him to confirm.
Wouldn't this solve the problem? (and let us proceed to implementing
this feature - http://wiki.mozilla.org/Tb:Autoconfiguration)
--
Regards,
Peter Lairo
The browser you can trust: www.GetFirefox.com
Reclaim Your Inbox: www.GetThunderbird.com
Israel - Myths & Facts: http://www.JewishVirtualLibrary.org/
Dangers of Islam (German): http://www.pi-news.net/
Church of the Flying Spaghetti Monster: http://www.venganza.org/
Peter Lairo
> Proposal placed on wiki, incorporating some of the feedback, and adding
> a bit of the XML file format:
>
> http://wiki.mozilla.org/Tb:Autoconfiguration
There's related information on "Thunderbird ISP hooks" at
http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks.
(Which probably should be moved to http://wiki.mozilla.org)
Robert Kaiser
> Ben Bucksch on 04.03.2008 21:53 wrote:
>> Proposal placed on wiki, incorporating some of the feedback, and
>> adding a bit of the XML file format:
>>
>> http://wiki.mozilla.org/Tb:Autoconfiguration
>
> There's related information on "Thunderbird ISP hooks" at
> http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks.
> (Which probably should be moved to http://wiki.mozilla.org)
First of all, NEVER put questions about a wiki article on the top of the
article itself, there is a discussion page for every wiki page that is
intended for just that.
Then, this MDC page describes the current integration of ISP hooks that
_is already_ in stable Thunderbird versions. This is documentation about
available functionality in Thunderbird, and therefore belongs on MDC.
wiki.mozilla.org is for development planning, and the new stuff about
"autoconfiguration" goes much further than the already existing "ISP
hooks" feature and is in a planning phase, and therefore belong on the
"scratchpad" that wikimo is.
Robert Kaiser
Eddy Nigg (StartCom Ltd.)
Peter Lairo:
> Robert Kaiser on 05.03.2008 22:21 wrote:
>
>> Actually, is _anything_ transferred there that requires strong security?
>> That is, as in "any stronger security than the usually non-encrypted
>> SMTP traffic"?
>>
>
> If the user enters Joh...@myISP.com as his e-mail address, and the
> server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
> traffic is then between the user and the server at myISP.com, then how
> can a MITM attack even occur.
>
> If the (MITM) server responds with anything BUT myISP.com (e.g.,
> evilISP.com) then Thunderbird would NOT auto-complete the setup but
> could bring up a dialog telling the user that there is a mismatch and a
> POTENTIAL MITM issue and ask him to confirm.
>
> Wouldn't this solve the problem? (and let us proceed to implementing
> this feature - http://wiki.mozilla.org/Tb:Autoconfiguration)
>
This isn't really feasible since mail servers handle mail for many
different domain names usually. This would mean that the config file
must be hosted at the host of that domain name. Sometimes domain names
don't even have a web site....
However discovery for mail servers in order to reach a particular user
[at] domain, MX records are used in the DNS zone. Many different domains
can point to one and the same mail server. I suggested to use the MX
record to retrieve the config file if the MX domain also has a TXT
record with a URL and location of the config file. This makes sense,
since all users of all domains handled by that mail server will use the
very same configuration anyway.
Peter Lairo
> Hi Peter,
>
> Peter Lairo:
>> Robert Kaiser on 05.03.2008 22:21 wrote:
>>
>>> Actually, is _anything_ transferred there that requires strong
>>> security? That is, as in "any stronger security than the usually
>>> non-encrypted SMTP traffic"?
>>>
>>
>> If the user enters Joh...@myISP.com as his e-mail address, and the
>> server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
>> traffic is then between the user and the server at myISP.com, then how
>> can a MITM attack even occur.
>>
>> If the (MITM) server responds with anything BUT myISP.com (e.g.,
>> evilISP.com) then Thunderbird would NOT auto-complete the setup but
>> could bring up a dialog telling the user that there is a mismatch and
>> a POTENTIAL MITM issue and ask him to confirm.
>>
>> Wouldn't this solve the problem? (and let us proceed to implementing
>> this feature - http://wiki.mozilla.org/Tb:Autoconfiguration)
>>
> This isn't really feasible since mail servers handle mail for many
> different domain names usually. This would mean that the config file
> must be hosted at the host of that domain name. Sometimes domain names
> don't even have a web site....
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.
Peter Lairo
> 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...)
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? 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.
Eddy Nigg (StartCom Ltd.)
> 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.
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).
Eddy Nigg (StartCom Ltd.)
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...
Bryan W Clark
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:
Cory Albrecht
> Robert Kaiser on 05.03.2008 22:21 wrote:
>> Actually, is _anything_ transferred there that requires strong
>> security? That is, as in "any stronger security than the usually
>> non-encrypted SMTP traffic"?
>
> If the user enters Joh...@myISP.com as his e-mail address, and the
> server responds with IMAP.myISP.com and SMTP.myISP.com, and the e-mail
> traffic is then between the user and the server at myISP.com, then how
> can a MITM attack even occur.
>
> If the (MITM) server responds with anything BUT myISP.com (e.g.,
> evilISP.com) then Thunderbird would NOT auto-complete the setup but
> could bring up a dialog telling the user that there is a mismatch and a
> POTENTIAL MITM issue and ask him to confirm.
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.
Magnus Melin
> ((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
Eddy Nigg (StartCom Ltd.)
> 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.
>
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.
Eddy Nigg (StartCom Ltd.)
> 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.
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.
>
>
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.
Eddy Nigg (StartCom Ltd.)
> (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).
>
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.
>
google.co.uk, so perhaps not..
>
> An alternate method for these ISPs is the extension:
> http://developer.mozilla.org/en/docs/Thunderbird_ISP_hooks
>
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.
>
>
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...
Simon Wilkinson
>> 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.
>>
> 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.
Bryan W Clark
> 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
Eddy Nigg (StartCom Ltd.)
> 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 ...)
>
>
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)
David Ascher
>
>
> 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.
>
>
--david
Eddy Nigg (StartCom Ltd.)
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.
David Ascher
> 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
Eddy Nigg (StartCom Ltd.)
> 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 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.
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
Dan Mosedale
> (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
Eddy Nigg (StartCom Ltd.)
> 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".
>
>
> 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.
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.
Eddy Nigg (StartCom Ltd.)
> 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.
>
> because I think we need to get some consensus here first.
>
>
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.
Simon Wilkinson
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.
Eddy Nigg (StartCom Ltd.)
>
> 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.
Simon Wilkinson
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.
Eddy Nigg (StartCom Ltd.)
>
> 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.
Robert Kaiser
> 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.rea...@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
Simon Wilkinson
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.
Cory Albrecht
> 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.
Eddy Nigg (StartCom Ltd.)
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?
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.
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.
Eddy Nigg (StartCom Ltd.)
>
> 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.
>
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!"
>
...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.
Jesper Kristensen
> 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)
Eddy Nigg (StartCom Ltd.)
> 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.
>
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)
only entering the email address.
Ben Bucksch
> 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.
Ben Bucksch
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).
Ben Bucksch
> 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.rea...@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.
Ben Bucksch
> 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.
Ben Bucksch
> 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.k...@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?
Ben Bucksch
> 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
Bryan W Clark
> Dan Mosedale schrieb:
>> a) large ISPs (google, yahoo, etc)
>> c) non-public servers
>> c1) intranets
>> c2) personal servers
>>
>> 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
Magnus Melin
> 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
Ben Bucksch
> 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
Eddy Nigg (StartCom Ltd.)
> 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!