search

nextcloud / mail

💌 Mail app for Nextcloud
https://apps.nextcloud.com/apps/mail
GNU Affero General Public License v3.0
831 stars 257 forks source link

Don't check MX records for autoconfig #2265

Open lsbbs opened 4 years ago

lsbbs commented 4 years ago

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!](https://www.bountysource.com/issues/84142185-don-t-check-mx-records-for-autoconfig?utm_campaign=plugin&utm_content=tracker%2F44154351&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F44154351&utm_medium=issues&utm_source=github).
ChristophWurst commented 4 years ago

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 commented 4 years ago

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

klatka commented 1 year ago

Still an issue

ChristophWurst commented 1 year ago

@klatka as long as the ticket is open it's fair to assume nobody has changed this. Simply add your :+1: to https://github.com/nextcloud/mail/issues/2265#issue-525929484.