[bug]: config-v1.1.xml returning 400 on missing emailaddress in query

[johansmitsnl]

What happened?

When you configure a e-mail account with Thunderbird (Android) it queries the endpoint, but it returns a http 400.

How can we reproduce the problem?

I can reproduce the problem by doing the following steps:

1. Setup the auto discover as documented
2. Install Thunderbird
3. Add account based on the e-mail

On the discover step it tries:

1."domain.net" "GET /.well-known/autoconfig/mail/config-v1.1.xml HTTP/1.1" 404 125 "-" "okhttp/4.12.0"
2. "domain.net" "GET /.well-known/autoconfig/mail/config-v1.1.xml HTTP/2.0" 400 107 "-" "okhttp/4.12.0"
3. "autoconfig.domain.net" "GET /mail/config-v1.1.xml HTTP/2.0" 400 107 "-" "okhttp/4.12.0"
4. "autoconfig.domain.net" "GET /mail/config-v1.1.xml HTTP/1.1" 400 107 "-" "okhttp/4.12.0"

And then it gives you the option to fill in the details by manually.

Version

v0.10.x

What database are you using?

RocksDB

What blob storage are you using?

RocksDB

Where is your directory located?

LDAP

What operating system are you using?

Linux

Relevant log output

ERROR Bad resource parameters (resource.bad-parameters) listenerId = "http", localPort = 8080, remoteIp = 127.0.0.1, remotePort = 53970, details = Missing domain in email address

### Code of Conduct

- [X] I agree to follow this project's Code of Conduct

[mdecimus]

Based on the error message your client is not providing a valid email address on the request. This is required for autodiscover to work.

[johansmitsnl]

@mdecimus I git this reply from Evolution#2941. Is this something that Stalwart can support?

The on-boarding experience is pretty poor for many clients in this scenario. But all seem to have a strong opinion not to improve it. Stalwart could provide some correct details like server name, auth options except username? Or support the emailmd5 option from the param?

[mdecimus]

I believe this is a bug in Evolution. If the 'email' address field is present it has to contain an email address, not a username. Also, most users won't know what's their username.
Using an MD5HASH in the email parameter has several issues: (1) is not a mechanism covered by the autoconfig draft, (2) MD5 is a poor choice as a hashing algorithm and (3) relying on hashes for autoconfig will require storing extra information in the index.

Edit: Also regarding the comment on the Evolution thread. They're not exposing email addresses to random servers, when a user enters user@domain.org as their email address, the client has to contact the autoconfig endpoint of domain.org, not send queries to a "random servers".

[oddlama]

Edit: Also regarding the comment on the Evolution thread. They're not exposing email addresses to random servers, when a user enters user@domain.org as their email address, the client has to contact the autoconfig endpoint of domain.org, not send queries to a "random servers".

I think they ment if a user mistypes firstname.lastname@theirdomain.tld as for example firstname.lastname@theirdomaim.tld then the potentially malicious server theirdomaim.tld would get sent the firstname.lastname and possibly the password if they set up autoconfiguration which succeeds. What I don't understand is why they think this will increase security, since when autoconfig would fail, a user would probably try to proceed with manual configuration and they can just as easily mistype the address there, which then also sends the username and password to the mailicious server.

Using a hashing scheme also doesn't even make this more secure, since a malicious server would just answer with arbitrary information so the user can proceed entering their password. And deriving the username from the entered email address is usually quite trivial except someone has an exotic setup. So the password is the more valuable piece of information, which isn't protected here. Therefore, I think their argument is a bit moot - they should just follow the spec.

[johansmitsnl]

There is a draft available on this matter.

Makes me thinking how is Microsoft with Outlook and auto-discover making it simply work. And as @oddlama mentioned continuing with the typo will also not prevent a potentially malicious server receive the credentials.

@mdecimus I don't this this issue should be closed since there are some paths in the draft that are not working with Stalwart.