Adding Migadu

[colinmahns]

Migadu is a hosted mail provider, and allows IMAP connectivity to any of its customer's domains.

[flub]

IIRC the only way to detect if a custom domain has email hosted by migadu is to look at the MX record:

$ dig -t MX custom.example.com
...
;; ANSWER SECTION:
custom.example.com.		3000	IN	MX	20 aspmx2.migadu.com.
custom.example.com.		3000	IN	MX	10 aspmx1.migadu.com.

Does this configuration make deltachat detect this? That would be cool as this has annoyed me in the past. I'm not very familiar with how the provider db works though.

[link2xt]

Does this configuration make deltachat detect this? That would be cool as this has annoyed me in the past. I'm not very familiar with how the provider db works though.

I have created a test account, and it says I need to bring my own domain to use it:

So this configuration is not useful for Delta Chat as we need a way to detect the provider for custom domains. Currently the best solution for custom domains is to setup an XML autoconfig like https://testrun.org/.well-known/autoconfig/mail/config-v1.1.xml

MX records are currently used only for Gmail for security reasons: https://github.com/deltachat/deltachat-core-rust/blob/3efbe5b1ef5a7afe9ba66fc41042d9afe22883a8/src/provider.rs#L215-L249
We may add Migadu as an exception as well if needed, but overall trusting MX records retrieved over insecure DNS does not scale as it is too easy to redirect the client during configuration to one compromised provider and the client will send the password there.

[link2xt]

Domain should not include www here, it is the domain that appears in the email address, e.g. [email protected].

[link2xt]

Migadu supports STARTTLS on 587 as well, I would add this to the list as a backup. It is still listed as an option on https://www.migadu.com/guides/outlook_android/:

smtp.migadu.com:465 or smtp.migadu.com:587

[flub]

MX records are currently used only for Gmail for security reasons: https://github.com/deltachat/deltachat-core-rust/blob/3efbe5b1ef5a7afe9ba66fc41042d9afe22883a8/src/provider.rs#L215-L249 We may add Migadu as an exception as well if needed, but overall trusting MX records retrieved over insecure DNS does not scale as it is too easy to redirect the client during configuration to one compromised provider and the client will send the password there.

So what is the implication of an exception? Trusting that it's "always" safe to send a password to migadu.com servers and that they won't try and steal it if it isn't for them?

I know the XML autoconfig is the best option, but it requires an http server and this is not handled by migadu, while they do help you setup the other aspects (my migadu domain doesn't even have an http server).

[link2xt]

So what is the implication of an exception? Trusting that it's "always" safe to send a password to migadu.com servers and that they won't try and steal it if it isn't for them?

Yes, because your ISP can hijack MX record request and say that any provider not in the provider database is handled by migadu, then you will try to connect to migadu and send them the password.

[r10s]

Yes, because your ISP can hijack MX record request and say that any provider not in the provider database is handled by migadu, then you will try to connect to migadu and send them the password.

to get it right: to get the password finally, your ISP needs to work together with Migadu (or Gmail) then?

[link2xt]

Yes, because your ISP can hijack MX record request and say that any provider not in the provider database is handled by migadu, then you will try to connect to migadu and send them the password.

to get it right: to get the password finally, your ISP needs to work together with Migadu (or Gmail) then?

Yes

[flub]

Basically the question here is whether we'd worry for migadu to ever become a malicious actor. My guess is that this would only be the case if they are legally compelled, but what do I know.

More generally I'm not sure why gmail did get this exception. My slightly more liberal exception would be to allow any "reputable" email provider to be on the exception list. That still stops a MITM attack with a custom server setup just for the purpose of the MITM. But I see little value in disallowing using MX records entirely.

[adbenitez]

this PR is stale for more than 1 year, maybe time to close it until there is activity,

my opinion: I don't think it is a good idea the MX record thing, how days it is better/easier to use a chatmail server than using such a provider that needs your own domain etc. so the impact of this is too low (only for a few people) while the MX querying affects most users that don't care about this

[link2xt]

Replaced with #308 which has fixed syntax and port 587.