Hi Boren, Working together sounds good :) Two things your class does which mine doesn't currently are check 'autoconfig.domain...' and 'domain/.well-known...' and also handles redirects, which is something I hadn't thought of.
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. Because of the extra work to include DNS lookup etc. into your class I suspect it would be easier to add redirect handling and the other autoconfig locations into mine. 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. 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. Thanks, Matt On 25/07/14 14:44, Boren Zhang wrote: > I have made something for Ubuntu at > http://bazaar.launchpad.net/~dpniel/dekko/trunk-1/view/head:/src/Ubuntu/backend/MailConfig/MailConfigUtils.cpp. > > It is not following the interface mentioned here, I just found out this > thread today. > > SRV(DNS lookup) is only setup on gmail. Few email host adopt it. So it is > not included here. > > Hi Matt Richardson, hopefully, it can be helpful to you or we can work on > auto-configuration together. > >
