Share and vote for eM Client ideas!
Please send your suggestions in English - it’s okay to use auto-translate, but having one common language will make the process of looking up existing ideas and voting more efficient 😊
Changelog
Please send your suggestions in English - it’s okay to use auto-translate, but having one common language will make the process of looking up existing ideas and voting more efficient 😊
Feedback
Please send your suggestions in English - it’s okay to use auto-translate, but having one common language will make the process of looking up existing ideas and voting more efficient 😊
This would slow down the account setup for everyone for the benefit of a few cases.
There's new IETF specification in the making that should eventually replace it.
Our recommended solution is to use Exchange Autodiscover, 3rd-party open source software like AutoMX / AutoMX 2 can be used to implement it
If the DNS SRV entries are tested only if the other ways of automatic detection don't get a match it would not slowdown the account setup but helps in the case that e.g. autodiscover is not set up.
Compared with DNS SRV entries, setting up an Autodiscover server will add a higher level of complexity to the whole mailserver setup. For smaller companies it's like taking a sledgehammer to crack a nut.
Do you have more information or a link about the new IETF specification? I could not found something about that in a first search.
@steffenl I consulted our devs to give you more exact explanations:
We did make a large scale test of how successful the Autodiscover methods are. It simply doesn't make sense to try the IMAP/SMTP/POP3 SRV records because they are not widespread enough. Even for the providers who publish these records, they often support the other autodiscover methods too and we end up using them - so there would not be many cases when no other automatic detection is available.
"Compared with DNS SRV entries, setting up an Autodiscover server will add a higher level of complexity to the whole mailserver setup."
This argument actually goes both ways. We usually hear that setting up DNS SRV records is an additional chore that many people are not willing to do or outright not able to do. Another problem is that often the [mail] server software comes as one big package that bundles also implementations of CalDAV, CardDAV, XMPP and other protocols. This greatly increases the number of DNS records that need to be maintained and it also means that protocols that get implemented after the initial software installation often don't get the DNS records setup. Later on, when migrating to a new provider people often forget to update all the records which results in stale information and this has generally been problematic. Even if we try to verify the information is not stale this adds additional waiting time to the automatic setup which is undesirable.
"For smaller companies it's like taking a sledgehammer to crack a nut."
We're sorry you feel that way, but there are ready-to-install packages that accomplish the task (eg. AutoMX). Integrated email solutions usually bundle the Autodiscover implementation themselves. Newer email servers, like Stalwart (https://stalw.art/) are literally installed with 2 commands in terminal, can be configured via web UI, and list all the DNS records to setup for the broadest client autoconfiguration possible.
IETF specification - It's still in the making, so no link at the moment. It is driven by FastMail and the people around https://makebetter.email. There's no published draft yet. The goal is to provide something simple, extensible and also supporting modern authentication (OAuth2 and two-factor authentication). The most likely implementation will be a DNS SRV record pointing to a JSON document hosted on HTTPS server. This is in principle similar to the Exchange Autodiscover and Thunderbird Autoconfig, and it's likely to be added to solutions like AutoMX once the specification is written and published.
@steffenl @olivia_rust Thanks alot for that detailed explantion and informations! It helps me to understand the background of your decisions.
As written in an other answer, it would be great if eM Client could document which options of autodiscover it supports and perhabs give an example in the documentation for an autodiscover.xml. Because it's hard to find information about how to create an autodiscover.xml if the server does not support automatic creation of it.
But despite everything I still think it would be a good idea to support not only proprietary service detection mechanisms, but also the official internet standards. If not the actual rfc6186 then hopefully in the future the new one you talked about.