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?
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.
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.
Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
