mjl- / mox

modern full-featured open source secure mail server for low-maintenance self-hosted email
https://www.xmox.nl
MIT License
3.52k stars 99 forks source link

Not able to create account in Thunderbird #140

Open pmarini-nc opened 6 months ago

pmarini-nc commented 6 months ago

Running a v0.0.10 mox server and trying to access the email from Thunderbird, I get this error

ksnip_20240311-114048

Notice that the previous step gives an OK message.

ksnip_20240311-114046

The account is accessible from other clients:

Thunderbird is 115.8.1 and the issue was present with mox v0.0.9.

As a side note, it is worth mentioning that automatic configuration works fine in Nextcloud Mail but not in K9 or Thunderbird.

Please let me know if and which logs I should provide.

Thanks!

mjl- commented 6 months ago

I tried to reproduce just now, with thunderbird 115.7.0, but I don't get any errors. The second screenshot with green text shows that autoconfigure is returning a config. The error message in the first screenshot seems to indicate something is going wrong with resolving a name (DNS I presume). Could you go to the admin page for the domain that checks the DNS settings? If there is anything wrong, it should also find it. Perhaps it's related to the ClientSettingsDomain. Have you seen autoconfigure work with other mail clients?

Can you check https://autoconfig.$yourdomain/mail/config-v1.1.xml?emailaddress=$you@$yourdomain and check if the settings seem correct? If it all checks out, we may want to dive into what happens when requesting the DNS records for the listed IMAP/SMTP servers on the machine that runs thunderbird.

pmarini-nc commented 6 months ago

On 11/3/24 12:19, Mechiel Lukkien wrote:

I tried to reproduce just now, with thunderbird 115.7.0, but I don't get any errors. The second screenshot with green text shows that autoconfigure is returning a config.

I think this is because I specified the SMTP / IMAP parameters manually. Automatic configuration fails: image

The error message in the first screenshot seems to indicate something is going wrong with resolving a name (DNS I presume). Could you go to the admin page for the domain that checks the DNS settings? If there is anything wrong, it should also find it. Perhaps it's related to the ClientSettingsDomain.

Here a summary of the DNS check page:


> DNS records and domain configuration check
> DNSSEC It looks like the DNS resolvers configured on your system do not verify DNSSEC, or aren't trusted (by having loopback IPs or through "options trust-ad" in /etc/resolv.conf). Without DNSSEC, outbound delivery with SMTP uses unprotected MX records, and SMTP STARTTLS connections cannot verify the TLS certificate with DANE (based on public keys in DNS), and will fall back to either MTA-STS for verification, or use "opportunistic TLS" with no certificate verification.
> IPRev OK
> MX OK
> TLS OK
> DANE    DANE is inactive because MX records are not DNSSEC-signed.
> SPF OK
> DKIM OK
> DMARC OK
> Host TLSRPT
>     Looking up TLSRPT record: tlsrpt: no tlsrpt dns txt record
>     Configure a host TLSRPT localpart in static mox.conf config file.
> TLSRPT is an opt-in mechanism to request feedback about TLS connectivity from remote SMTP servers when they connect to us. It allows detecting delivery problems and unwanted downgrades to plaintext SMTP connections. With TLSRPT you configure an email address to which reports should be sent. Remote SMTP servers will send a report once a day with the number of successful connections, and the number of failed connections including details that should help debugging/resolving any issues. Both the mail host (e.g. mail.domain.example) and a recipient domain (e.g. domain.example, with an MX record pointing to mail.domain.example) can have a TLSRPT record. The TLSRPT record for the hosts is for reporting about DANE, the TLSRPT record for the domain is for MTA-STS.
> Domain TLSRPT OK
> MTA-STS OK
> MTA-STS record: v=STSv1; id=20230821T123307
> MTA-STS policy:
> version: STSv1
> mode: enforce
> max_age: 604800
> mx: 
> SRV conf OK
> Autoconf OK
> Autodiscover OK

Have you seen autoconfigure work with other mail clients?

Yes, as mentioned above autoconfig works fine with Nextcloud Mail, but not with K9.

Can you check https://autoconfig.$yourdomain/mail/config-v1.1.xml?emailaddress=$you@$yourdomain and check if the settings seem correct? If it all checks out, we may want to dive into what happens when requesting the DNS records for the listed IMAP/SMTP servers on the machine that runs thunderbird.

I get a "403 - forbidden - no session" error when opening from the browser. autoconfig.mydomain.com is a CNAME entry pointing to the SMTP / IMAP host. A reverse proxy is listening on port 443, terminate TLS and pass on the connections host-based to port 81 and 82 of the system hosting mox.


My MOX Config file:

DataDir: /moxdata

LogLevel: info

User: mox

Hostname: mydomain

CheckUpdates: true

AdminPasswordFile: adminpasswd

Listeners:
        internal:
                IPs:
                        - 10.246.192.25

                AccountHTTP:
                        Enabled: true
                        Port: 81

                AdminHTTP:
                        Enabled: true
                        Port: 81

                WebmailHTTP:
                        Enabled: true
                        Port: 81

                MetricsHTTP:
                        Enabled: true
        public:

                IPs:
                        - 10.246.192.25

                NATIPs:
                        - my-public-ip
                TLS:
                        KeyCerts:
                                -
                                        CertFile: /etc/ssl/certs/cert.pem
                                        KeyFile: /etc/ssl/private/key.pem

                SMTP:
                        Enabled: true

                Submissions:
                        Enabled: true

                IMAPS:
                        Enabled: true

                MTASTSHTTPS:
                        Enabled: true
                        Port: 82
                        NonTLS: true

Postmaster:
        Account: admin

        # E.g. Postmaster or Inbox.
        Mailbox: Postmaster
mjl- commented 6 months ago

Thanks. The DNS info looks good.

To get autoconfig working, you'll need to explicitly enable autoconfig endpoints in mox.conf, see AutoconfigHTTPS, https://www.xmox.nl/config/#cfg-mox-conf-Listeners-x-AutoconfigHTTPS.

But that doesn't explain why Thunderbird cannot login with manual configuration.

Have you looked at logging by mox? There could be useful hint in there.

pmarini-nc commented 6 months ago

To get autoconfig working, you'll need to explicitly enable autoconfig endpoints in mox.conf, see AutoconfigHTTPS, https://www.xmox.nl/config/#cfg-mox-conf-Listeners-x-AutoconfigHTTPS.

I was reading it this morning.. what happens if I want to enable HTTP (not HTTPS), like other services I have as shown in the configf file? Just

AutoconfigHTTP: 
            Enabled: true
            Port: 81
            NonTLS: true

?

But that doesn't explain why Thunderbird cannot login with manual configuration.

And also why Nextcloud Mail autoconfig works...

Have you looked at logging by mox? There could be useful hint in there.

I'll check and let you know

mjl- commented 6 months ago

I was reading it this morning.. what happens if I want to enable HTTP (not HTTPS), like other services I have as shown in the configf file?

Autoconfig should require HTTPS for security (otherwise a single DNS response pointing autoconfig.<rcptdom> could redirect you to another host, which can give a profile with another mail server, where you'll be sending your password. Requiring autoconfig.<rcptdom> at least ensures that host has a PKI TLS certificate. So clients shouldn't be requesting plain http for autoconfig.

I think you should have AutoconfigHTTPS on the internal listener, with NonTLS set, and configure the https webserver for autoconfig.<rcptdom> and pass the traffic on to the internal ip on the configured port (81 in your snippet).

And also why Nextcloud Mail autoconfig works...

Indeed. I thought it could be related to the "regular password" setting. I think that means plaintext password. I don't think mox would reject that.

pmarini-nc commented 6 months ago

So if I put the following in my internal listener, it works as expected:

AutoconfigHTTPS:
                        Enabled: true
                        Port: 81
                        NonTLS: true

Autoconfig is fine in Thunderbird and I can create the account.

I don't understand your comment about security. In front of this listener I have an HAProxy that does TLS termination and 443->81 port redirection, so not sure whether I need to do something more or leave things as they are right now.

This check is worth documenting if it is not already: https://autoconfig.$yourdomain/mail/config-v1.1.xml?emailaddress=$you@$yourdomain

mjl- commented 6 months ago

I don't understand your comment about security. In front of this listener I have an HAProxy that does TLS termination and 443->81 port redirection, so not sure whether I need to do something more or leave things as they are right now.

No need to do more, this should be enough.

I made the comment because I thought you asked about autoconfig on plain http because you used AutoconfigHTTP in your snippet, instead of AutoconfigHTTPS (note the "S"). But I probably read too much in that.

Indeed good to mention the autoconfig URLs somewhere. Perhaps in the DNS check page... Will have a look, thanks.

pmarini-nc commented 6 months ago

I also noted the S in AutoconfigHTTPS, this is why I was asking. With AutoconfigHTTP I get an Unknown key error and the service fails to start. Actually I was expecting to use AutoconfigHTTP in phase of what happens with all the other listeners.

mjl- commented 6 months ago

It's grown a bit like this, it's not great... The rationale is: The listener keys are named after how they are publicly access. And the NonTLS: true is then a modifier that indicates requests are coming in without TLS. That's why it's also MTASTSHTTPS. With things like WebmailHTTP and WebmailHTTPS, both are available so it wouldn't make much sense to also add NonTLS to the WebmailHTTPS variant, the non-S variant can be used.