chatmail
provider-info for invalid email address "tt" returns "gmail"
entering tt as the email address on login shows the provider-information for google.
entering rr or ss or ttt returns no provider-information as expected.
i first encountered that behavior on ios and thought it was a ui-bug, but it is the same for android using core52:
desktop using core50 does not have that issue, probably as MX-lookup was added later.
EDIT: investigate a bit more: the function dc_provider_new_from_email() takes an email-address which is passed to rust's provider::get_provider_info() which wants a domain and states that the email-address is only accepted for "compatibility reasons" - therefore, the function does not check for an email address and treats tt as the domain.
for whatever reason, resolver.mx_lookup() returns gmail for that tt domain. but also the corresponding command tool says so,
> nslookup -q=MX tt
Server: 192.168.178.1
Address: 192.168.178.1#53
Non-authoritative answer:
tt mail exchanger = 10 ALT1.ASPMX.L.GOOGLE.COM.
tt mail exchanger = 1 ASPMX.L.GOOGLE.COM.
first thought that is my wifi, but also online tools return that result.
might be tt is actually a valid fqdn ...
but anyway, maybe the fix is just to check that the parameter given to dc_provider_new_from_email() is actually an email address (contains a @) - either by changing get_provider_info() or by adding a dedicated function.
Just tried it now, Delta Chat on Android is completely freezed for some time and then says to give a valid email address. My DNS also does not give MX answer for tt, seems to be something with your DNS configuration.
Update: it shows the gmail note after that, hmm.
If I query via 8.8.8.8 or 1.1.1.1, it returns MX record:
$ dig MX @8.8.8.8 tt
$ dig MX @1.1.1.1 tt
Delta Chat core uses 8.8.8.8 too.
The solution is probably not to query for MX record if a valid address with @ is not entered.
I think we should set a timeout for the mx lookup and instead of returning fire an event with the result string/json. We just disabled provider info on desktop as it's causing too much trouble here. And such a bug is really critical as user face it in their first minute of using deltachat.
