[Bug 308181] Re: xmpp4moz doesn't read SRV DNS records

Bug Watch Updater 308181 at bugs.launchpad.net
Thu Nov 25 12:45:47 UTC 2010


Launchpad has imported 48 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=342242.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2006-06-21T03:03:39+00:00 L. David Baron wrote:

This enhancement request depends on having DNSSEC (see
http://www.dnssec.net/ ) support, which we don't currently have,
although there is a project at http://www.dnssec-tools.org/ working on
adding some to Mozilla.  It is in some ways similar to bug 242867, but
would be even easier for users.

I propose that Thunderbird implement a not-yet-existant standard for
auto-configuration of email via DNS which would operate only when the
DNS records could be verified via DNSSEC.  It could be a single DNS
record that defines what servers can be used for handling email from a
domain so that a user doesn't have to enter the information into the
account manager.  For example, given a DNSSEC-verified DNS record that
looked something like
"imaps:outgoing.example.com;smtptls:incoming.example.com;ldaps:directory.example.com"
the user could enter "john at example.com" in the account wizard and
everything else could be filled in for him.  This is one step less than
what bug 242867 would get you.

I'm not sure exactly what information would go in such an
autoconfiguration format, but at least some of the advantages include:

 * Making it much easier for users to start using Thunderbird.

 * Getting users to use secure SMTP and secure IMAP (either via STARTTLS
or via the SSL-specific ports) rather than insecure (which greatly
reduces the chances of their password being sniffed).

 * getting users to use authenticated SMTP (preferably secure, and
preferably on the smtps (465) or submission (587) port), which can help
make it easier for servers to block things spammers do.

The autoconfiguration format would probably also need to contain
information about how to form the IMAP and SMTP login name from the user
part of the email address, i.e., whether the user should log in as
"john" or "john at example.com"; this might be specified as "%u", "%u@%d",
or "%u at example.com", or something like that.

It probably also needs some additional information that I'm not thinking
about.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/41

------------------------------------------------------------------------
On 2006-06-21T05:59:07+00:00 Mscott-mozilla wrote:

Thanks for taking the time to file this in such detail David.

I'll put this in the Thunderbird 3 bucket for right now while we watch
dnssec get added to mozilla (is there a bug for that part of this
feature?)

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/42

------------------------------------------------------------------------
On 2006-06-21T06:48:36+00:00 L. David Baron wrote:

I couldn't find a bug on DNSSEC.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/43

------------------------------------------------------------------------
On 2007-03-03T09:24:04+00:00 Ben-bucksch wrote:

Nice idea.

> Getting users to use secure SMTP and secure IMAP

How do you set up the finer details of the account (see Server Settings,
including esp. Advanced... for IMAP)? Outlook Express config files
contain a lot of info (usually 10-20 lines long, and a lots more
optional).

> information about how to form the IMAP and SMTP login name from the user part
> of the email address

There are quite a number of large ISPs where the login name has no
relation to the email address. IIRC that the case for both T-Online
(Germany, maybe 50% market share) and France Telecom / Orange (maybe 80%
market share).

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/57

------------------------------------------------------------------------
On 2007-03-03T09:25:40+00:00 Ben-bucksch wrote:

> login name has no relation to the email address

Sorry, more concretely: login name is numeric and generated by ISP, e.g.
858675467; email address username part can be freely chosen by user
(e.g. ben.bucksch).

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/58

------------------------------------------------------------------------
On 2007-10-15T18:59:47+00:00 Shopik wrote:

Most great idea for next major release. DNS SRV records do half of this job and this is where it should starts. Mostly in controlled environments (enterprise, university, etc) this do great job not everything like ISP hooks but most and with almost no efforts at all.
Probably I ask one coder to contribute code as extension for TB.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/66

------------------------------------------------------------------------
On 2008-04-04T18:30:28+00:00 Shopik wrote:

current implementation for next generation of TB lies here
http://wiki.mozilla.org/Thunderbird:Autoconfiguration
also maybe bug 242867 dup of this one, I'm not sure about this!

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/72

------------------------------------------------------------------------
On 2008-05-06T19:00:48+00:00 Shopik wrote:

Wayne, could you put url in comment #6 to bug url

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/75

------------------------------------------------------------------------
On 2008-07-07T19:11:36+00:00 Mkmelin+mozilla wrote:

Please leave setting the Priority to assignees.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/79

------------------------------------------------------------------------
On 2008-07-10T15:09:18+00:00 Shopik wrote:

*** Bug 242867 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/80

------------------------------------------------------------------------
On 2008-07-10T17:30:00+00:00 Morz wrote:

Taken from my comment to bug 389275, this proposal has the following
disadvantages:

- Uses DNSSEC, which is not widely deployed and has well-known
deployment and operational issues (like DNS root and most TLDs not being
signed).

- Requires an effort of DNS coordination when a single e-mail provider wants to
deliver automation for accounts under multiple domains, as opposed to providing
auto-config for a single (own) domain.

- Forces the user to enter his own data, and hence does not cover the important
case where you provide a configuration file with ALL the account's
configuration (including e-mail address, IMAP/POP user id, default folder
names, and perhaps even password), to prevent users from making mistakes.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/81

------------------------------------------------------------------------
On 2008-08-13T18:48:54+00:00 Shopik wrote:

David can we have this in beta1 or beta2? This is one of major thing we
like to introduce in TB3. But its seems it need lots work and probably
can't make it for b1.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/82

------------------------------------------------------------------------
On 2008-08-13T19:58:24+00:00 Ben-bucksch wrote:

Nikolay, I planned to start with this soonish.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/83

------------------------------------------------------------------------
On 2008-08-13T20:12:46+00:00 David-ascher wrote:

FYI, there is some forward motion on the dialog for auto-configuration
w/o DNS/DNSSEC, as per the design here:

  http://clarkbw.net/designs/account-wizard/account-dialog/account-
dialog-2.html

in bug 422814.  Bienvenu has some of the backend code working, and I've
got a start on the front-end (I'll attach a screenshot of the WIP).

IMO, that is relatively low-hanging fruit, based on port sniffing &
heuristics for domain names.  There are a bunch of added layers that we
can put on, including DNS/DNSSEC-based approaches, hosting a database of
known configurations, etc.


Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/84

------------------------------------------------------------------------
On 2008-08-13T20:13:39+00:00 David-ascher wrote:

Created attachment 333621
screenshot of WIP, with no logic behind it yet

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/85

------------------------------------------------------------------------
On 2008-08-13T20:36:07+00:00 Dmose wrote:

Note that the DNS stuff we have in necko is not really a resolver, but
just a wrapper around the host OS getaddrinfo() implementation.  In
order to do anything interesting that's DNS-based, we'd need a real
resolver in Gecko, which is a non-trivial amount of work.  If someone
wants to do that, we should investigate the license & code compatibility
of the various available open-source resolvers.  For the Tb3 time frame,
though, doing something DNS-based seems a little impractical.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/86

------------------------------------------------------------------------
On 2008-08-14T05:27:06+00:00 Ben-bucksch wrote:

FYI, I am planning to fetch the configuration from a webservice database
via http for now, not DNS. The most I may do via DNS is to lookup a
certain predefined hostname. See
https://wiki.mozilla.org/Thunderbird:Autoconfiguration, Section
"Proposal", Step 2 ("contact a mail configuration server of the
provider"), Alternative 2: "just try to contact
https://autoconfig.emailaddressdomain/mail/mozilla.xml?emailaddress=emailaddress
and see whether that host/URL exists"

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/87

------------------------------------------------------------------------
On 2008-08-14T07:43:08+00:00 Shopik wrote:

Thanks David, I also keep track of bug 422814.
Ben, that's great, I'll be glad to do QA for this.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/88

------------------------------------------------------------------------
On 2008-08-15T00:17:59+00:00 David-ascher wrote:

The DNS/DNSSEC parts of auto-configuration will most likely not make 3,
but other forms of autoconfig likely will.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/89

------------------------------------------------------------------------
On 2008-08-15T02:14:55+00:00 Dmose wrote:

(In reply to comment #16)
> FYI, I am planning to fetch the configuration from a webservice database via
> http for now, not DNS. The most I may do via DNS is to lookup a certain
> predefined hostname. 

Comment 0 is pretty clear about the scope of this bug.  It sounds like
the work you're doing should be tracked in another bug.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/90

------------------------------------------------------------------------
On 2008-08-15T04:33:10+00:00 Ben-bucksch wrote:

OK, filed bug 450710 about what I want to implement.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/91

------------------------------------------------------------------------
On 2008-08-20T07:16:04+00:00 Ben-bucksch wrote:

*** Bug 411898 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/92

------------------------------------------------------------------------
On 2009-09-05T15:58:15+00:00 Mozilla7 wrote:

The proposal "that Thunderbird implement a not-yet-existant [sic]
standard" is fine and all, but there is an existent standard that we
should be seriously looking at, already supported in Outlook 2007, and
theoretically also in Apple Mail on Mac OS X 10.6 "Snow Leopard" and the
iPhone (although I have filed bugs with Apple because I can't get it to
work).

Word document:  http://office.microsoft.com/download/afile.aspx?AssetID=AM102105061033
Exchange 2007 whitepaper:  http://technet.microsoft.com/en-us/library/bb332063.aspx
Autodiscover reference:  http://msdn.microsoft.com/en-us/library/aa581522.aspx

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/99

------------------------------------------------------------------------
On 2009-09-05T22:02:31+00:00 Ben-bucksch wrote:

First, Exchange autodiscover is not a standard by any means. It's only
supported by Microsoft. Second, we have been looking at Autodiscover
closely, even discussing with Microsoft at length. Third, Autodiscover
does not work via DNS. That's what this bug is about.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/100

------------------------------------------------------------------------
On 2009-09-05T22:03:28+00:00 Ben-bucksch wrote:

s/only supported by Microsoft/only supported by Microsoft Exchange
(server side)/

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/101

------------------------------------------------------------------------
On 2009-09-05T23:20:38+00:00 Mozilla7 wrote:

Most of the documentation for server-side implementation is for
Exchange, but I've implemented it myself with a Perl script.  I've seen
a PHP script for it floating around as well.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/102

------------------------------------------------------------------------
On 2009-11-03T07:55:29+00:00 Andre Schild wrote:

Yes, of course exchange auto discovery is not a standard, but it is a
specification which is used in outlook 2007, apple mail and iPhone.

Why not use it, instead of building our own ?

Here a example of a PHP (serverside) script for generation the config
file: http://www.andrewyager.com/content/view/52/27/

It is very simple to configure the web server to provide such a script.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/107

------------------------------------------------------------------------
On 2009-11-03T11:38:34+00:00 Ben-bucksch wrote:

Andre,
a) This is offtopic here, because this bug is specifically about DNS, and the MS protocol is based on XML. (Outlook can also look up DNS SRV records, but only when explicitly enabled by pref.)
b) Microsoft itself dropped the protocol that Exchange 2007 uses, because they didn't like it anymore. Exchange 2010 uses a different, SOAP-based protocol.
c) Both protocols require the user not only to know the username in advance, but also to authenticate to Exchange, before the server returns any configuration (even though it's just hostnames etc.). I find myself often not knowing how exactly my username is expected (with @ or //, with or without domain, email address or other username), so that alone is a no-go. We go from only realname, email address and password.

That the XML-based protocol has already been implemented in Thunderbird 3.
This bug is about finding servers via DNS.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/108

------------------------------------------------------------------------
On 2009-11-03T13:46:01+00:00 Mozilla7 wrote:

I filed bug 521538 for supporting Microsoft's autodiscovery protocol;
please go there for that. :-)

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/109

------------------------------------------------------------------------
On 2009-11-03T14:12:59+00:00 Morz wrote:

(In reply to comment #27)
> That the XML-based protocol has already been implemented in Thunderbird 3.

Could you post an URL with the specification for such protocol?

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/110

------------------------------------------------------------------------
On 2009-11-03T14:15:02+00:00 Ben-bucksch wrote:

I did, in comment 16. Please read before writing, thanks.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/111

------------------------------------------------------------------------
On 2009-11-03T14:20:28+00:00 Morz wrote:

(In reply to comment #30)
> I did, in comment 16. Please read before writing, thanks.

The stuff in https://wiki.mozilla.org/Thunderbird:Autoconfiguration has
some implementation notes, but is not a specification.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/112

------------------------------------------------------------------------
On 2009-11-03T14:23:01+00:00 Ben-bucksch wrote:

That and <https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat>
(linked there) is sufficient to implement it.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/113

------------------------------------------------------------------------
On 2009-11-03T14:53:05+00:00 Morz wrote:

(In reply to comment #32)
> That and
> <https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat>
> (linked there) is sufficient to implement it.

I am aware of the subpages, but:

1) All the IMAP stuff is missing.
2) A lot of things are undefined or unclear, including very basic things (for example the defaults handling, or how to deal with multiple identities).
3) "All settings and enum values" are also in the TODO list, which does not sound as "sufficient to implement it".

In any case, apparently it has the same design faults that were pointed
out for the Autoconfig RDF files in TB2, years ago. For example, linking
the identity of the email provider with the domain of such provider
(although this is also unclear, as it is unknown the role of the 'id'
attribute in the 'emailProvider' element).

If this has been already implemented following the lines shown in these
notes, IMHO this is a lost opportunity for a highly important feature.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/114

------------------------------------------------------------------------
On 2009-11-03T15:22:29+00:00 Ben-bucksch wrote:

morz, please email me about concrete problems you see (in more detail
than above). I don't want to respond here, because it would be offtopic.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/115

------------------------------------------------------------------------
On 2009-11-11T14:17:13+00:00 Ben-bucksch wrote:

After many years, DNSSEC is starting to be deployed. ICANN and IETF plan
that in 2 months from now, the first public root server publishes a
DNSSEC-signed root. TLD .org is already signed.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/120

------------------------------------------------------------------------
On 2010-01-06T22:26:04+00:00 Chris-newman wrote:

I'm voting for the bug, but only on the condition it uses a standard
mechanism such as the approaching finalized IETF proposal:

  http://tools.ietf.org/html/draft-daboo-srv-email

I don't see that it's necessary to wait for DNSSEC to implement that.
DNSSEC will deploy when it deploys and we'll get the extra security bump
when it shows up.

I consider central-server based architectures such as the Mozilla ISPDB
to be a poor design that introduces a single-point of failure.  One
customer is correctly worried about the extra dependency that creates.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/121

------------------------------------------------------------------------
On 2010-01-06T23:28:39+00:00 Jesse-thompson wrote:

Am I the only one who thinks that Mozilla's new centralized approach of
client autoconfiguration is a poor idea?

https://wiki.mozilla.org/Thunderbird/ISPDB/Requirements
http://ispdb.mozillamessaging.com/
https://wiki.mozilla.org/MailServerList

It allows for unverified users to submit the information (which has
already happened for our domain, but they mostly got it right.)

It is also kind of a pain to manage if you host lots of domains (we host
270 domains.)

It also makes mozilla.org a dependency, which leads to concerns about
their reliability and longevity.

How can we ensure that this mozilla-centric model won't interfere with
other clients that want to implement autoconfiguration.  If we have to
backfill this information for 270 domains, I don't want to do it again
for each client that chooses to implement their own centralized
database.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/122

------------------------------------------------------------------------
On 2010-01-06T23:29:45+00:00 Jesse-thompson wrote:

Coincidentally, the XMPP folks are struggling with the same problem.
XMPP client SRV records work wonderfully, but they rely on the server
using Start-TLS with a signed certificate that matches the virtual
domain.  This has been a complaint of mine for some time, because
obtaining certificates for all of our 270 domains is the biggest
obstacle to enabling all of the email domains within our chat service.
They have recognized the shortfall in this methodology (no doubt Google
Apps Talk had something to do with this) and are working on the
following draft to solve the problem.

http://tools.ietf.org/html/draft-hildebrand-dna-00

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/123

------------------------------------------------------------------------
On 2010-01-07T10:44:36+00:00 Shopik wrote:

(In reply to comment #36)
> I'm voting for the bug, but only on the condition it uses a standard mechanism
> such as the approaching finalized IETF proposal:
> 
>   http://tools.ietf.org/html/draft-daboo-srv-email

I do agree with you Chris, but you may look into bug 356104 and bug
14328, these are showstoppers. Necko doesn't have code right now to
resolve SRV records.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/124

------------------------------------------------------------------------
On 2010-01-07T10:56:45+00:00 Ben-bucksch wrote:

> Am I the only one who thinks that Mozilla's new centralized approach of
> client autoconfiguration is a poor idea?

No, you're not. It wasn't intended for the use case you mention. Please
see https://wiki.mozilla.org/Thunderbird:Autoconfiguration and bug
534722.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/125

------------------------------------------------------------------------
On 2010-01-07T14:09:02+00:00 L. David Baron wrote:

(In reply to comment #36)
> I don't see that it's necessary to wait for DNSSEC to implement that.  DNSSEC
> will deploy when it deploys and we'll get the extra security bump when it shows
> up.

I'd agree that it's not necessary to wait for DNSSEC if all servers
found in this manner require SSL/TLS (i.e., the connection is configured
to fail if TLS can't be initiated or if the cert doesn't match).

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/126

------------------------------------------------------------------------
On 2010-01-07T15:34:25+00:00 Jesse-thompson wrote:

> (i.e., the connection is configured to fail if TLS can't be initiated
or if the cert doesn't match)

Requiring that certs match the domain will be a show stopper for
services that host lots of domains.  We are an EDU, and we host 270
domains.  Just think about services that host thousands of domains!

Supposing it is practical for email service administrators to maintain
hundreds or thousands of valid signed matching certificates for domains
that they don't own - it isn't practical, IMHO - do we know if the major
MTAs support the ability to present a different cert for the individual
domain during the Start-TLS negotiation?  If not, that will also be a
show stopper.

Is it feasible to abandon plain old TLS?  Outlook still seems to work
better with port 465/TLS.  Start-TLS would be a new requirement since
the domain needs to be known before the server can present a matching
cert.

Take a look at http://tools.ietf.org/html/draft-hildebrand-dna-00 for
some ideas on other methods of asserting domain ownership without the
need for DNSSEC.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/127

------------------------------------------------------------------------
On 2010-01-07T15:42:48+00:00 Jesse-thompson wrote:

> Please see https://wiki.mozilla.org/Thunderbird:Autoconfiguration and
bug 534722.

Yes, step 2 is a more rational approach.  I still think that step 3 is
problematic just in its existence.  I see that there is mailing list
http://groups.google.com/group/ispdb so I'll voice my concerns there.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/128

------------------------------------------------------------------------
On 2010-02-13T00:15:35+00:00 Usenet-tonal wrote:

See bug 14328 for the work being done on extending DNS support to
include the resolution of SRV records, which seems to me to be closely
related to the work being discussed here.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/131

------------------------------------------------------------------------
On 2010-02-13T12:11:02+00:00 Ben-bucksch wrote:

Yes, I filed bug 545866 (arbitrary DNS queries in Mozilla) based on that
and made it block this bug.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/132

------------------------------------------------------------------------
On 2010-03-10T19:21:37+00:00 Ben-bucksch wrote:

Narrowing bug summary to DNS SRV records, to differentiate from DNS MX,
which I filed as bug 551519.

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/133

------------------------------------------------------------------------
On 2010-07-27T20:34:51+00:00 Shopik wrote:

*** Bug 536915 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/sameplace/+bug/308181/comments/134


** Changed in: thunderbird
       Status: Unknown => Confirmed

** Changed in: thunderbird
   Importance: Unknown => Wishlist

-- 
xmpp4moz doesn't read SRV DNS records
https://bugs.launchpad.net/bugs/308181
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to Mozilla.




More information about the Ubuntu-mozillateam-bugs mailing list