411898 - Thunderbird should have auto-discovery for mail account creation

Status: RESOLVED DUPLICATE of bug 342242

(Thunderbird :: Account Manager, defect)

Description

[Tomer Cohen :tomer]

The internal mail client on my PDA (Windows Mobile) has a nice feature - instead of requiring me to enter the account details (servers etc.) it asks for my mail address and than query the destination server for the required servers information. 

I don't know if it comes from a protocol specification or just an add-on on the server, but I find it useful as it doesn't require me to enter all the details for Gmail (POP3 or IMAP) accounts. I think it is much easier than to use Tb2.0 Account Wizard, even when dealing with server providers add-ons. 

If you find it useful, I can try to reverse engineer the protocol.

Comment 1

[Magnus Melin [:mkmelin]]

You'd be welcome to reverse engineer it, but I don't think there is such a protocol - on a general level. Maybe they have some vendor type repository of known providers.

Comment 2

[Phil Ringnalda (:philor)]

According to http://www.syncgeeks.com/forum/showthread.php?t=8957 that's it exactly, a third-party database.

http://wiki.mozilla.org/Thunderbird:Easy_Account_Setup talks about doing one ourselves, but verifying user-supplied data, filtering out garbage, and keeping it up-to-date will all be "fun."

Comment 3

[Tomer Cohen :tomer]

If it is hosted-database, can we think about creating our one for the benefit of Thunderbird users? It won't be with very massive traffic, as it is only visible during first-time mail account creation.

Or even better, we can implement support for mail server over DNS SRV records (much like how Jabber servers operate), so each mail provider will have full control over its server definitions, and other mail clients will follow. 

Comment 4

[Magnus Melin [:mkmelin]]

At least according to wikipedia (for SRV_record), that's discouraged. 

On the other hand a brute force attempt could very well succeed. I think probing {pop,imap,smtp}@domain on the usual ports would find a very large part of the servers, and those could be suggested to the user for click-through. xref bug 387421.

Comment 5

[Tomer Cohen :tomer]

(In reply to comment #4)
> At least according to wikipedia (for SRV_record), that's discouraged. 
Why dicouraged? We can implement it, and it will be much better that brute-force, as most of the time the mail server sits in a different machine than the domain itself or the SMTP server.

Brute force won't help you at all while the mail server is mail.example.com, pop.example.com, imap.example.com, or even mail.MotherCompany.com. DNS solution will. 

Comment 6

[David Ascher (:davida)]

This bug feels like a dupe of some combination of bugs 422814, 342242, and 450710.

Comment 7

[Ben Bucksch (:BenB)]

Tomer prefers the DNS approach, so DUPing against bug 342242.

Comment 8

[Yves Goergen]

Interesting to see that someone else also had the idea with DNS SRV. I have started to play with my own MUA application some time ago, but never finished by now. It also has DNS SRV auto-discovery of mail services. It works pretty well, you just enter your e-mail address and password and the programme does the rest. It looks up hostname and port for the domain, then tries IMAP then POP3, both with SSL first, then without. I have configured my clients' domains zonefile like that already. At us, the mail services reside on the same machine as the web domains, so they're accessible at the mail address domain itself as well as our primary domain, but the SSL cert only works with the primary domain. Mozilla's current proposal would fail with that - and many other small single-server hosters.

Comment 9

[[:Aureliano Buendía]]

Cleanup *dupeme* whiteboard flag from bugs that are marked as Resolved Duplicate!