On 27/07/14 19:15, Jan Kundrát wrote: > On Sunday, 27 July 2014 09:57:10 CEST, Matt Richardson wrote: >> At the moment, though, your class only checks for the domain from the >> email address, which I have found doesn't work for email handled by >> shared hosting, where the domain of the mail exchange often doesn't >> match the email domain. >> For example, the ISPDB has nothing for my email (si5spymissions.com) but >> if I use 'secureserver.net' (from the MX records) as the domain, it >> finds the correct configuration. > > If I understand correctly, this code assumes that if you're using an > ISP's MX servers for your incoming e-mail, you are also using them for > message submission. It does not necessarily assume that MX == > submission, which is a good thing. The other assumption makes sense, I > guess, but I wonder if other MUAs are doing the same. Are they, or is > this your invention? >
The code first searches for an autoconfiguration using the user's email address domain (EAD for brevity). If it can't find an autoconfiguration for the EAD, it checks the MX records for the EAD to locate the mail server domain. It then tries to find an autoconfiguration using the mail server domain. As it stands, the code only looks at the ISPDB, which also lists host names, so (assuming I understand your question correctly) no it doesn't necessarily assume that MX == submission. It should be noted that when the code fails to identify a record, it strips a subdomain (remove anything left of the first instance of ".") and tries again. This is because I found in testing that the MX records for my EAD list mailstore1.europe.secureserver.net but the ISPDB listing is for secureserver.net. I couldn't think of a better way to check each possible domain, but there is a glaring error in that the method continues as long as there is more than one instance of ".". The result is that e.g example.co.uk would be checked for 'example.co.uk' and 'co.uk', which wastes time. If someone has a better method I am open to suggestions :) The idea to look at the MX records came from [1] <https://wiki.mozilla.org/Thunderbird:Autoconfiguration:DNSBasedLookup> and the method of doing it came from Qt examples. Re-looking at the process I have identified one particularly major flaw. At the moment the MX record lookup only uses the first record, ignoring any others and ignoring any priority setting. This is clearly wrong and I will change it. >> I agree about SRV not being widely adopted as of yet, but since it is >> only another set of DNS lookups it wouldn't be that hard to implement, >> and would potentially add future-proofing. >> On top of that, it means that auto-configuration is not wholly dependent >> on a third-party service. > > It's also the standardized way of doing this, unlike the .well-known > hacks or the ISPDB. I'm gonna be blunt here -- in any > autoconfiguration patch that I merge, the SRV lookup must be tried > first. I won't accept an autoconfig patch which does not implement the > SRV lookups as long as that RFC isn't deprecated or someone persuades > me that I'm crazy. I tend to be hard to persuade in that way. Don't panic, I fully intend to implement SRV lookup as the default and only subsequently query the ISPDB if necessary. > >> Once the changes have been made, the next step is to think about how >> auto-configuration will be handle with respect to UI / UX. >> The only thing I would want to make sure of UX-wise is that >> auto-configuration is non-blocking. i.e. the user does not have to wait >> until auto-configuration has failed before they can choose to manually >> enter details. For that purpose, a stop() function needs to be added. > > Seems that the configuration should be done in a wizard-like style, > prompting for name and mail, and offering the rest automatically, yet > still being able to pass the details by hand. > That seems fair but I would definitely want the user to be able to click stop at any point. IMHO no automatic process should block me from using my own knowledge whilst it takes forever to fail :) > Cheers, > Jan > [1] https://wiki.mozilla.org/Thunderbird:Autoconfiguration:DNSBasedLookup
