What to do with custom domain providers?

[missytake]

We already have 4 issues which want to add providers which offer custom domains: https://github.com/deltachat/provider-db/issues?q=is%3Aissue+label%3Acustom-domains

Most issues (like #159) get closed, because the providers don't offer mail accounts without a custom domain; but some like #208 get added, when they have a free offer for which you don't get a domain.

It would be cool if we could make onboarding with a custom domain easier. Is there an automated way to determine the hosting provider?

e.g. in #159 it was suggested to look up the MX entry of the domain, which points to an URL associated with hosting.com, and if we find that URL in the providerDB, the app could get use the corresponding entry. Not sure if this works, and not sure whether it works for every custom domain provider (but does it have to?)

For this we could add a new key/value pair to the database structure, something like MXdestination or so?^^

Thoughts on this? I would like to keep this issue around to collect ideas on how to proceed on this.

[Simon-Laux]

if they have an auto configure file hosted on the server it just works, though the documentation on how to create that file is not that easy to find, so I suggest that we document it too or create a guide how to create such an autoconfig xml file

[EchedelleLR]

In some IM clients, there is a select to choose the server and I guess something that could help a bit.

A select could exist in Delta Chat with the first option of the select being auto-detection. So, if someone write an email address later, custom-automatic workarounds or self-detection (autoconfigure, etc) are tried first.

Away of that, the select would have a list of servers which pointed to specific tweaks/configurations to be applied to the email address written later.

After auto-detection failure, this specific tweaks/configurations could be suggested to the user before trying a fully manual procedure.

[missytake]

we could identify the custom domain provider based on the MX entry of the custom domain. Since deltachat/deltachat-core-rust#2123 the core can do this during setup, but right now it's only hardcoded for Google Workspace domains.

For example, the domain n0.computer is handled by the custom domain provider fastmail.com. It has the following MX entries:

n0.computer.		300	IN	MX	10 in1-smtp.messagingengine.com.
n0.computer.		300	IN	MX	20 in2-smtp.messagingengine.com.

Those are actually the same MX entries which will turn up if you run dig MX fastmail.com, but it does not work in reverse. So what we could do, we could add a field to the provider.yml with "known MX entries", so if we find an MX entry for the custom domain, we could look in the database if it belongs to a custom domain provider we know. (Not sure how it's handled with GSuite right now, a hardcoded exception I guess?)

So fastmail.com.md would get these additions:

known-mx:
- in1-smtp.messagingengine.com.
- in2-smtp.messagingengine.com.

And if a user wants to configure an account with n0.computer during the account setup, and it can't find a providerDB entry or autoconfig.xml or similar, it would:

1. run a DNS query for its MX entries
2. search the provider database for the provider which is responsible for the (highest priority?) MX server, in this case fastmail.com
3. use the server settings of this provider (whatever is in fastmail.com.md in this repository), as it seems to be the custom domain provider for n0.computer

This would enable us to add custom domain provider to the providerDB, without having to know every single domain they are managing for a customer.

[EchedelleLR]

I think that my proposal over the front-end would be compatible with this too.