OAUTH2 Not being picked up by clients

[SpeedyCraftah]

Hello,

I enabled OAUTH2 via mailserver.env and provided an authentication URL, and when I manually tested it with telnet, everything works: the IMAP client announces the support for OAUTH2 bearer and XOAUTH2 and I was able to authenticate with it just fine with a manually constructed command (A001 AUTHENTICATE XOAUTH2 token_here).
However, for some reason when I try to connect with OAUTH2 with email clients like Thunderbird, they claim my server doesn't support OAUTH2 when it clearly does.

Is there something I'm missing that I need to do for mail clients to pickup that my IMAP server supports OAUTH2? I'm not even sure how I would announce the authorization URL to use for the clients.

It's also important to note I am hosting a test instance, so there isn't an actual domain yet, only a fake domain I use and a Ubuntu server instance running on VMWare on the same network.

For reference, here is the IMAP banner: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN AUTH=LOGIN AUTH=OAUTHBEARER AUTH=XOAUTH2] Dovecot (Debian) ready.

Thanks.

[SpeedyCraftah]

After a bit of research, I figured out that OAUTH2 only seems to work with Thunderbird with registered providers, aka providers that had their OAUTH2 related details hard-coded into the application (at least that's what I think).

I can't find an email client that supports the OAuth 2.0 Dynamic Client Registration Protocol standard which would allow OAUTH2 with unregistered servers by exposing metadata on some agreed-upon URL (/.well-known/openid-configuration).

So the question is, why does docker-mailserver support OAUTH2 if you can't even use it with custom mail servers on mail clients?

I hope I'm wrong since OAUTH2 authentication would be awesome to have working.

[polarathene]

OAUTH2 with email clients like Thunderbird
OAUTH2 only seems to work with Thunderbird with registered providers, aka providers that had their OAUTH2 related details hard-coded into the application

Yeah, sorry I know I've relayed that information somewhere before. I thought I had that explained in the docs regarding Thunderbird.

---

So the question is, why does docker-mailserver support OAUTH2 if you can't even use it with custom mail servers on mail clients?

If you follow our docs, it's supported with the Roundcube webmail client. Other clients (notably those that are not webmail based) would need to implement support for XOAUTH2 or OAUTHBEARER. That requires supporting an auth flow with the auth provider to authenticate with and retrieve an Access Token.

The access token is then provided via IMAP protocol like you have done directly.

I haven not tried it, but this approach might work for you?: https://github.com/simonrob/email-oauth2-proxy

---

For reference:

• Our test-suite has a mock web service that would generate the IMAP commands and mock an auth service endpoints for the access token / userinfo (Dovecot would interact with that).
• Here is the related test case, which shows how to use curl to authenticate. The test mentions a bug, but newer curl releases have since fixed that IIRC. Curl should be able to interact with Dovecot as a mail client, it's just a bit awkward. It works since we provide the token to the command, your mail client needs to add support for acquiring that token.

If the devs of your mail client are only willing to add hard-coded provider support, then you could try pushing for support of an open-source self-host provider (Keycloak, Authentik, Casdoor, Ory Hydra, etc). Thunderbird I think I came across the hard-coded source at one point and cited it somewhere, so it might be possible to patch it if you have the technical chops or are able to finance a bounty to get someone who does.

They lack of adoption may be due to it being less straight-forward for devs to implement and test vs the existing provider support. If that friction can be minimized, you can probably get them onboard :)

---

DMS supports the feature because it was contributed by the community, went through our review process and has test coverage. I don't know how many other competitors to DMS make it as easy to enable OAuth2 / OIDC support, but it's probably a good step towards getting broader mail client support adoption? So we're doing our part 😅

Mailcow and Stalwart both have OAuth2 / OIDC support implemented too. Those projects seem to be more popular than DMS these days, with more to offer and developer time, but AFAIK you won't have a different experience on this issue, it's down to mail clients adding support.

[SpeedyCraftah]

it's supported with the Roundcube webmail client

I did see this but I glanced over it since I wasn't aware Roundcube was a mail client!

But this does make a lot of sense.
Anyhow, I thought of a couple of options that could make some of this still work.

• Use a webmail client as the documentation suggests and disable remote IMAP/SMTP, making it the only point of access to the mail server, which would make the OAUTH2 flow seamless, this is looking like the best option right now.
• Fork the source code of one of the open source clients and add OAUTH2 support for my specific mail server and use this custom binary, but this might be a bit overkill and require a lot of time, but a fun project nevertheless.
• Place some kind of reverse-proxy on the front-end for both SMTP/IMAP which requires users to follow the OAUTH2 flow to whitelist their device+IP pair, the reverse-proxy would then allow network packets to reach the actual SMTP/IMAP servers where they can login with a password.
• This may be a bit messy, but I could write a script which removes the passwords from all of the users in the passwd file, which effectively disables logging in with SMTP/IMAP, users can then obtain a password which lasts a week by following the internal OAUTH2 flow, which will add a password to the passwd file for the user to be able to login.

As you can tell, I am very against passwords as the only means of authentication as I think they're clunky and easily become a single point of failure for security.

[polarathene]

disable remote IMAP/SMTP, making it the only point of access to the mail server, which would make the OAUTH2 flow seamless

You don't have to disable other clients if you want to allow login with other methods. There are some caveats with webmail clients I've seen reported, such as DMS is only aware of the IP from roundcube for all users connecting through it. That affects the IP in the logs if you have monitoring tools like Fail2Ban, so that failed auths for example trigger a ban to the entire roundcube container.

I think some users might have identified a way around that. Roundcube does offer something to pass on the client IP but I recall at least one approach was a bit non-standard (custom Dovecot plugin?) vs proper use of PROXY protocol.

That said the Fail2Ban service in DMS only applies bans within the container itself apparently, so this wouldn't matter when clients are connecting indirectly to DMS (reverse proxy / roundcube). You'd need to find a way to adjust our config to ban on the host, or handle that outside of DMS. Not my area of expertise 😅

Just have a quick search/browse over our issues and discussions and you should be able to get an idea of any reported issues you might need to consider.

---

this might be a bit overkill and require a lot of time

Maybe. I think it'll be easier if you're familiar enough with integrating custom OAuth2/OIDC providers into a project. I've not done this myself, although I'm aware some programming languages make it much easier with packages, might depend on the mail client source for how viable that is.

Getting that support upstreamed rather than carrying a fork would probably be ideal, at the very least an open issue / feature request for it with some guidance for the devs to implement, like DMS / MailCow / Stalwart having support on the mail server side that they can test against.

---

reverse-proxy would then allow network packets to reach the actual SMTP/IMAP servers where they can login with a password

Not entirely sure what this one is describing. Note that reverse proxy for mail server protocols differs from web. See our docs example for proxy config where I cover that in more detail (Traefik specific). A proxy often can't terminate TLS or proxy StartTLS, so passthrough is required.

Perhaps this one was referring to the project I linked you to earlier. I haven't looked into it enough to comment any concerns there.

---

I could write a script which removes the passwords from all of the users in the passwd file, which effectively disables logging in with SMTP/IMAP

/etc/passwd is only for internal system accounts. DMS delegates auth to Dovecot by default which is configured with a UserDB (the login username and mailbox associated to it) and a PassDB (the user login with hashed password). Oh you were probably referring to the PassDB anyway since we're using the passwd-file driver... you could just disable that one in the Dovecot config, or point to an empty file.

It's also possible to use an alternative driver, allowing you to perform an SQL query or run Lua scripts (see our example docs, there is a guide for lua based auth).

I don't quite follow with the temporary password obtained for OAuth2, if the user is meant to keep that on hand to input into a password field themselves? There is an open issue/feature request for app passwords, vaguely sounds like what you're describing.

---

I am very against passwords as the only means of authentication
I think they're clunky and easily become a single point of failure for security.

Depends on the users really. A password manager makes this less of a problem in my experience.

Passwords don't need to be complicated to be secure detailed snail summons slim lab coat is quite secure (as an example, obviously this exact one is no longer secure), in that it'd take 6+ years with a modern GPU. The cost of scaling the attack to complete it sooner doesn't change the fact that it's expensive to attack, it'd only be used on a target worth the investment, also assumes direct access to the password hash.

All lowercase and only a few words that form a structured sentence to use as a passphrase 👍 Random doesn't have to look obscure and be difficult to remember/input.

More modern authentication is better when available, especially for users that may have insecure (low entropy) passwords.

[SpeedyCraftah]

That affects the IP in the logs if you have monitoring tools like Fail2Ban, so that failed auths for example trigger a ban to the entire roundcube container.

Can imagine I can probably figure something out, even if it means not using Fail2Ban and opting in for something more custom - Fail2Ban isn't strictly a necessity but it's nice to have as a precaution against annoying bots scanning the IPv4 range and trying to find open servers.

A proxy often can't terminate TLS or proxy StartTLS, so passthrough is required.

Yep, I had something more along the lines of a passthrough rather than a proxy, something along the lines of the front-end server/proxy deciding whether to allow the IMAP connection through, and if it succeeds passing it through to the backend IMAP server, although yeah, TLS might be a challenge to passthrough properly as well as being annoying to implement if I want the same for SMTP, so probably not a great idea.

Oh you were probably referring to the PassDB anyway since we're using the passwd-file driver... you could just disable that one in the Dovecot config, or point to an empty file

I was! I did attempt to setup Postfix+Dovecot on my own at one point and figured using the Dovecot passwdDB/userDB or however it's called is possible here.

I don't quite follow with the temporary password obtained for OAuth2, if the user is meant to keep that on hand to input into a password field themselves? There is an open issue/feature request for app passwords, vaguely sounds like what you're describing.

I meant as in the passdb file would have a password unset for the user initially, so they cannot login at all via IMAP or SMTP, once they login using some backend service via the OAUTH2, the backend service will set a temporary password that lasts a week for the users entry in the passdb file and give it to them, allowing them to authenticate IMAP and SMTP for a week by changing the password to this in their IMAP/SMTP client, although I'd imagine this would just annoy users (and me), unless there is a way to automatically set the IMAP/SMTP password in their client by modifying the database it uses to store the passwords by using a custom app on the users machine?

All lowercase and only a few words that form a structured sentence to use as a passphrase 👍 Random doesn't have to look obscure and be difficult to remember/input.

That's true, I think it might be a better bet to scrap OAUTH2 for SMTP/IMAP anyways and instead enforce reasonable passwords, not by requiring 10 symbols, at least 3 numbers and 5 letters, none of which can be consecutive for more than 2 characters at a time, but rather enforcing length to encourage something as simple as a song lyric and maybe a random symbol for good measure, this is especially secure enough considering SMTP/IMAP have long backoff periods for invalid attempts.

[polarathene]

Account passwords

Oh you were probably referring to the PassDB anyway since we're using the passwd-file driver... you could just disable that one in the Dovecot config, or point to an empty file

I was! I did attempt to setup Postfix+Dovecot on my own at one point and figured using the Dovecot passwdDB/userDB or however it's called is possible here.

You could just use our existing postfix-accounts.cf / setup email update command to update the password for an account too.

I meant as in the passdb file would have a password unset for the user initially, so they cannot login at all via IMAP or SMTP, once they login using some backend service via the OAUTH2, the backend service will set a temporary password that lasts a week for the users entry in the passdb file and give it to them

Oh ok. right so the OAuth2 feature allows login without an actual DMS account so this wouldn't make any difference really. You'd need to configure Dovecot to restrict authentication to OAuth2 accounts with some scope or some status from the auth service to determine which users are allowed to login that way. DMS presently has no official documentation for that, but I think it's possible (from a glance of the Dovecot OAuth2 docs).

As the OAuth2 feature only matters for authentication, it's unrelated to having a mailbox configured with an address to receive mail to in DMS. That requires account provisioning, which by default we have a password for (allowing login via the password if the user knows it).

allowing them to authenticate IMAP and SMTP for a week by changing the password to this in their IMAP/SMTP client, although I'd imagine this would just annoy users (and me), unless there is a way to automatically set the IMAP/SMTP password in their client by modifying the database it uses to store the passwords by using a custom app on the users machine?

Well the OAuth2 support should be covering that already? Tokens should be issued with a validity / expiry time, you'd need to configure that and require the token to be refreshed or for the user to authenticate through the identity provider again to have a new token issued. The mail client should handle that sort of thing (prompting the user when necessary), and hand that off to Dovecot which will check against the identity provider that the token is valid for the user before authenticating successfully.

If you need normal password access, you can update via the appropriate source config for the configured ACCOUNT_PROVISIONER, or with the file provisioner (default), use the setup email update CLI command as noted earlier. DMS has nothing to offer regarding third-party software like mail clients syncing passwords, and that'd probably defeat the entire purpose of the rotation. Better to just raise the entropy of your passwords and hope they don't leak, or leverage OAuth2 support (effectively shifts the password rotation to the SSO account password, but that'll probably have better integration for password managers which can accomplish what you want for a more seamless experience).

There is an open issue discussing adding SCIM API support for DMS, which would allow compatible identity providers to sync accounts and passwords into DMS accounts. That doesn't really help with the concern you expressed, but would shift the issue out of DMS.

Security

but rather enforcing length to encourage something as simple as a song lyric and maybe a random symbol for good measure

It's not about length, it is about entropy.

I provided a link with my example passphrase.

You can generate ones like it from this website, which has the source on Github, nothing dodgy going on there and could be run locally. There's other software for "Diceware" or similar methods to generate passphrases. Password managers usually offer them too.

I want to emphasize that it's totally secure to use all lower case letters like I demonstrated, so long as the generator is entropy focused (like the one I linked to). getapassphrase.com lets you select the entropy (like 44-bit), and the lower sizes aren't necessarily strong enough on their own, but they can be when paired with services that implement a KDF (bcrypt/argon2/etc) that augments the entropy computationally. I like this generator I link to because the phrases are more natural in structure, easier to remember than a sequence of random words that you might see elsewhere.

If you make a password too difficult to remember, users will forget it or degrade the security by storing it somewhere (eg: post-it note). Even with the kind I'm encouraging, I've found some struggle with that length. Apps like 1Password are a bit convenient to abstract all that away and make using passwords easy, along with MFA for unlocking access to passwords with your fingerprint on a phone for example, which still asks for the master password every couple weeks to keep it fresh in the users head. 1Password is quite secure with their additional secret key, but that adds friction to device portability. Bitwarden lacks that, but would be less friction for users to adopt.

---

especially secure enough considering SMTP/IMAP have long backoff periods for invalid attempts.

You don't usually take this into consideration for such attacks. That's interactive login, there's additional latency over a network and any logic between comparing to the stored password hash, along with effects like Fail2Ban to limit attempts.

Kerckhoffs's principle is a way to assess the security strength by assuming the attacker knows all the parameters related to the password generation, and focuses on this as a worst case attack. That's why entropy is relevant, there is a known size of possibilities, and without any bias (random selection via generator) the attacker has no advantage but to try each possibility until successful (average 50% of all possible inputs tried).

The attack generally assumes they have the stored hash of the password for the user and how that hash was derived (eg bcrypt at a work-factor of 10), which is usually part of the stored hash format, along with any salt. Thus it's down to the attackers resources (cost to invest in the attack with their hardware and time), which tends to only allow for a small budget to target low-hanging fruit (weak passwords, aka low entropy) or if targeting a specific user of known value, that the cost to attack is feasible to perform and that there are not any more affordable options that could be pursued instead.

So you want high entropy and an approach that is still a good UX for users, it needs to be simple to avoid behaviours that degrade that security. SSO with OAuth2/OIDC helps.

Rotating passwords / secrets can be good, but if the entropy is high enough it's more to do with precaution of those secrets being leaked (post-it note, sharing a secret over a chat/link, malware, etc). Rotating passwords for users is known to often have a negative impact on security when it's passwords the user must keep track of and input (along with decide on the new password), an issue largely resolved with password managers (although some users have relied on browsers features to remember passwords, and those have had some attacks in the past IIRC).