Don't check MX records for autoconfig

[lsbbs]

Expected behavior

It should query the autoconfig server for the domain of the email address.

Actual behavior

The MX record of the domain is queries and then autoconfig.MX is queried which is wrong.
The MX record is only for other mail SERVERS. It has absolute no meaning for mail clients. The server for mail clients can be a total different server in a different domain. A mail client should not care at all about the MX record.
The correct address would be autoconfig.domain. See https://wiki.mozilla.org/Thunderbird:Autoconfiguration
The actual implementation might work for some bogous setups. I have here especially Cpanel administrated domians in mind. In most setups Cpanel is setting the MX record to the domain name which is wrong. According to the SMTP RFC the MX record has to be a full qualified hostname and not a domain name.

Mail app

Mail app version: 0.18.1

Mailserver or service: Own setup with postfix and dovecot spread over 4 servers and 3 domains.

Server configuration

Operating system: Ubuntu 16.04

Web server: Apache 2.4

Database: MariaDB

PHP version: 7.2

Nextcloud Version: 17.0.1

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[ChristophWurst]

Good point. I've seen that this is indeed quite unreliable and thus useless. I have this long-time idea of reworking the autoconfig anyway. The problem right now is that we just send the data to the server and wait for its results. Which often takes ages because it has to await lots of timeouts on configurations that don't work.
Instead of doing everything on the server, we should build the test matrix on the client and send simultaneous requests to the server to tests. In JS we have full concurrency and can finish as soon as the first working configuration was found. Or just benefit from the concurrent checking and speeding up the process a lot.

[lsbbs]

Nice to hear that a redo is planned.
I had a very short look on the code.
In ImapConnectivityTester.php port 585 is probed. This port can surely safely removed. Is deregistered. [1]
The whole procedure should take only seconds. It is only a few DNS lookups. They take short time instead of trying direct to connect. This is causing a big delays.
Thunderbird scheme or Apple mobileconfig:
Thunderbird: autodiscover.domain -> http://autoconfig.domain/mail/config-v1.1.xml?emailaddress=$mailaddress
Apple mobileconfig: autodiscover.domain -> https://autodiscover.domain/mobileconfig

Microsoft scheme:
autoconfig.domain -> https://autodiscover.domain/autodiscover/autodiscover.xml

Additional the RFC 6186 SRV records can be probed.
_submission._tcp.domain
_imap._tcp.domain
_imaps._tcp.domain
_pop3._tcp.domain
_pop3s._tcp.domain
If _submission._tcp.domain fails you don't have to waste time on the other 4 SRV records.

Only a few DNS lookups.

[1] https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt