add support for RFC 6186 for server autoconfiguration

[monperrus]

Many users do not know the IMAP/SMTP servers of their email provider.

RFC 6186, Use of SRV Records for Locating Email Submission/Access Services solves this problem, by using DNS SRV records to provide this information.

I don't see RFC 6186 in the list of supported standards by deltachat

What about adding support for RFC 6186 for server autoconfiguration?

[EchedelleLR]

Was not Autoconfigure already for that?
Well, Idk about this, just asking.

[monperrus]

Thuderbird's style autoconfigure (https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration) addresses the same problem, but this is not a standard.

[monperrus]

For the record, support of RFC 6186 has been added in K9: thunderbird/thunderbird-android#4719

[EchedelleLR]

Thank you for the info. Let's wait for devs to see.

[r10s]

Thuderbird's style autoconfigure [...] addresses the same problem, but this is not a standard.

well although not being an RFC, it is widely used, isn't it? :)

however, autoconfigure is not good at custom-domains, is that better handled by RFC 6186 ? so if you have a custom-email-address at, say gmail.com or outlook? and is it actually used by at least some providers offering custom-domains?

i'd say that would be a good reason to push that forward :)

[EchedelleLR]

Thuderbird's style autoconfigure [...] addresses the same problem, but this is not a standard.

well although not being an RFC, it is widely used, isn't it? :)

however, autoconfigure is not good at custom-domains, is that better handled by RFC 6186 ? so if you have a custom-email-address at, say gmail.com or outlook? and is it actually used by at least providers offering custom-domains?

i'd say that would be a good reason to push that forward :)

Maybe sections 3.4 and 4 from the RFC specification could help to understand?

[monperrus]

yes, some email providers for custom domains support RFC 6186, such as Axigen, see https://www.axigen.com/documentation/dns-based-service-discovery-p3277117

[ben-mor]

Should this issue be moved to core? Then we would have that for all platforms at once.

[EchedelleLR]

Should this issue be moved to core? Then we would have that for all platforms at once.

I agree with it but must be someone with permissions to do it.

[r10s]

ftr, you can test a provider on the commandline using, eg.

$ dig SRV _submission._tcp.yandex.ru
$ dig SRV _submission._tcp.migadu.com  

this returns the settings for smtp, using _imap, _imaps, _pop3, _pop3s should return different values (thanks @link2xt on irc)

[Hocuri]

Is there any way to be sure that the answer is authentic? I mean, what if Eve sends a faked answer, stating that the imap server is eve.com?

Shall we enforce Dnssec to prevent this?

[link2xt]

Shall we enforce Dnssec to prevent this?

See "Security Considerations" section: "In the absence of a secure DNS option, MUAs SHOULD check that the target FQDN returned in the SRV record matches the original service domain that was queried. If the target FQDN is not in the queried domain, MUAs SHOULD verify with the user that the SRV target FQDN is suitable for use before executing any connections to the host."

Probably just implementing this is enough, e.g. allow mail.example.org or imap.example.org for example.org, but not example.net.

_submission._tcp.ya.ru. SRV points to smtp.yandex.ru, so the user should be asked in this case if it is really the domain they want to use.