chatmail
feat: try getting autoconfig info from http://autoconfig.[domain]
The RFC cites the http:// endpoint as a third optional source for autoconfig information. This is useful for offline/LAN environments where the mail server is not able to obtain an SSL certificate for serving HTTPS -- something we at Rapidspace encounter with our ORS 4G networks when hosting a Delta.Chat server.
Insecure HTTP is excluded on purpose. Otherwise an attacker may provide an autoconfig XML file with own IMAP and SMTP server domains pointing to attacker's server or MITM reverse proxy and this configuration will be used forever afterwards because we only run the configuration once. Simply accepting this change will reduce security for everyone else who does not need HTTP autoconfiguration.
We may allow HTTP if TLS configuration is set to "accept invalid certificates". I guess if you cannot obtain valid TLS certificates, you want to disable TLS checks anyway? Even then, maybe a self-signed certificate is better than using HTTP.
There is also a request https://github.com/chatmail/core/issues/7460 to use system TLS certificate storage where you can install your own CA certificate. This configuration might work if you run your own CA, e.g. with step-ca. I am also not sure we want to depend on system certificate store by default.
If you have intermittent connectivity, and can download TLS certificates from another host, maybe obtaining them on a separate host and then copying the key and certificate over once per month is possible. You don't need "global" connectivity to use the TLS certificate while it is valid. This is also an option that works offline but does not require running your own CA.
You might also not need autoconfig. at all, default domains and subdomains like mail. are tried by default.
You might also not need autoconfig. at all, default domains and subdomains like
mail.are tried by default.
This is a nice feature, however my need for autoconfig is based on the fact that the ports used for IMAP and SMTP might be other than the standard ones (since a single server can host multiple mail servers). Also, on some internal networks, no SSL is used, so this need to be transmitted too. Currently, logging in to Delta.Chat in our environment is quite time-consuming since one has to enter: email, password, IMAP server, IMAP port, IMAP security, SMTP server, SMTP port, and finally SMTP security.
Would it be acceptable and/or technically feasible, after the first two HTTPS endpoints have been fetched and didn't yield anything, to simply check for the existence of the HTTP endpoint (i.e. check that it returns 200 and valid XML) to prompt the user for something like "An automatic configuration file has been found on plain HTTP. Deltachat cannot guarantee the security of such a configuration, and attacks are possible on an unsecured network" along with a checkbox saying "Yes, I'm sure" so the user can choose to use that configuration? With this, logging in would be down to email, password, send, check the box, accept.
You might also not need autoconfig. at all, default domains and subdomains like
mail.are tried by default.This is a nice feature, however my need for autoconfig is based on the fact that the ports used for IMAP and SMTP might be other than the standard ones (since a single server can host multiple mail servers). Also, on some internal networks, no SSL is used, so this need to be transmitted too. Currently, logging in to Delta.Chat in our environment is quite time-consuming since one has to enter: email, password, IMAP server, IMAP port, IMAP security, SMTP server, SMTP port, and finally SMTP security.
To simplify this setup, we can do a change to accept invalid certificate for https://autoconfig. URL if during configuration the user has already selected "accept invalid certificates". So you will need to deploy HTTPS with self-signed certificate (not plaintext HTTP) and the user during onboarding will have to click "create new profile" → "use other server" → "use classic email as transport" and there type email address, password and set "certificate checks" to "accept invalid certificates" without typing any ports.
Would it be acceptable and/or technically feasible, after the first two HTTPS endpoints have been fetched and didn't yield anything, to simply check for the existence of the HTTP endpoint (i.e. check that it returns 200 and valid XML) to prompt the user for something like "An automatic configuration file has been found on plain HTTP. Deltachat cannot guarantee the security of such a configuration, and attacks are possible on an unsecured network" along with a checkbox saying "Yes, I'm sure" so the user can choose to use that configuration?
We never ask users questions like "something is wrong, do you want to continue?". As a rule of thumb you can assume users don't read anything and will click "ok", "yes" or "continue".