- dovecot - dovecot.org

Safe upgrade path from 2.4.1 to 2.4.4 (CVE-2026-40020) on Debian 13
by Artem Ignatov 22 Aug '26

22 Aug '26

Hello, (Redirected here from support(a)dovecot.org - I understand that address is for commercial/Pro support, and this is a Community Edition question.) We run a production mail server on Debian GNU/Linux 13 (trixie), using the Dovecot package currently shipped in the Debian 13 stable repository: dovecot-core 1:2.4.1+dfsg1-6+deb13u6 We are affected by CVE-2026-40020 ("IMAP folders can be shared-spammed to everyone"), which as far as we understand is fixed upstream in Dovecot 2.4.4. Debian 13 stable does not yet ship a backported fix, so we are currently working around the issue by not using shared/ACL mailbox access at all, and waiting for an official Debian security update. We would appreciate the community's guidance on a few points: 1. Is a safe, supported upgrade path from 2.4.1 to 2.4.4 recommended for a production instance currently installed from Debian's own package (rather than compiling from source or using a third-party repository)? 2. Are there any breaking changes between 2.4.1 and 2.4.4 we should be aware of - configuration syntax, Maildir index file format compatibility, or anything that would require downtime or re-indexing on a live mail store? 3. Our setup uses SQL-based virtual users/passdb (via PostfixAdmin/MySQL), Sieve filtering, and per-user quotas. Are there any known interactions between these features and the 2.4.4 update that we should test for before rolling it out? 4. Do you have a general recommendation on whether to wait for the Debian security team to backport the fix into 13 stable, versus updating manually ahead of that? Any guidance, or a pointer to relevant release notes/changelog entries between 2.4.1 and 2.4.4, would be very helpful. Thank you, Artem Ignatov IT Administrator, GK INVEST

3 3

Global sieve variables don't work in 2.4.4
by inaugurator＠ya.ru 22 Aug '26

22 Aug '26

Hi everyone! I have created a minimal reproducible setup. First, let's prepare the environment and create the necessary directories: ```shell getent group vmail >/dev/null \ || groupadd -g 500 vmail; \ getent passwd vmail \ | awk -F: '$3 == "500" && $4 == "vmail"' >/dev/null \ || { id vmail >/dev/null 2>&1 && usermod -u 500 -g vmail vmail \ || useradd -u 500 -g vmail -M -s /usr/sbin/nologin vmail; } mkdir -p /mail && chown vmail:vmail -R /mail cat > /mail/global_bug.sieve <<EOF require ["variables", "include"]; global "global_var"; set "global_var" "hello"; EOF cat > /mail/before_bug.sieve <<EOF require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :global :optional "global_bug"; debug_log "\${global_var}"; EOF ``` Then, we configure dovecot.conf: ``` dovecot_config_version = 2.4.4 dovecot_storage_version = 2.4.4 auth_allow_cleartext = yes mail_driver = maildir mail_home = /mail/%{user} mail_inbox_path = .INBOX mail_uid = vmail mail_gid = vmail first_valid_uid = 500 protocols { imap = yes } mail_plugins { imap_sieve = yes } service imap-login { inet_listener imaps { port = 0 } } passdb anypass { driver = static fields { nopassword = yes } } sieve_global_extensions { vnd.dovecot.debug = yes } sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = global } namespace inbox { inbox = yes separator = / mailbox INBOX { auto = subscribe sieve_script before_bug { driver = file path = /mail/before_bug.sieve cause = APPEND type = before } } } ``` If we run an APPEND command to the INBOX directory: ```shell curl -v -u "user1:hello" -k "imap://localhost:143/INBOX" --upload-file /tmp/test.eml ``` the log shows an empty message. ``` imap(user1)<3155434><YNISPNZYHtV/AAAB>: sieve: DEBUG: ``` However, if we change the configuration and the Sieve script by replacing "global" with "personal", I see my hello in debug log: ``` ... sieve_script global_bug { driver = file path = /mail/global_bug.sieve type = personal # !!! } ... require ["variables", "include", "vnd.dovecot.debug"]; global "global_var"; include :personal :optional "global_bug"; # !!! debug_log "\${global_var}"; ... imap(user1)<3155659><iiiIhNZYgpl/AAAB>: sieve: DEBUG: hello ``` Why am I unable to import a global variable into a before script if it is defined in a global script? Thank You in advance!

1 1

Dovecot 2.4: possible bug in quota-status service
by Othmar Truniger 21 Aug '26

21 Aug '26

Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is ,\0' for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at ,\0' when quota_status_toolarge is equal ,\0'. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar Hi, I'm testing dovecot 2.4 (2.4.1 on debian trixie) after migrating from 2.3. When checking the quota-status service (quota-status -p postfix) over telnet, the response for new mail over quota returns an empty text for action. Example: # telnet 127.0.0.1 10022 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. recipient=mailtest(a)truniger.ch size=13000000 action= recipient=mailtest(a)truniger.ch size=12000000 action=OK ^] telnet> quit The manual says that an empty value for "quota_status_toolarge" defaults to "quota_status_overquota". But when looking a the actual source code of quote-status.c this does not seem to be the case - the return value is '\0` for action: Code from line 231: switch (qret) { case QUOTA_ALLOC_RESULT_OK: /* under quota */ value = set->quota_status_success; break; case QUOTA_ALLOC_RESULT_OVER_MAXSIZE: /* even over maximum quota */ case QUOTA_ALLOC_RESULT_OVER_QUOTA_LIMIT: value = set->quota_status_toolarge; if (value[0] == '\0') break; /* fall through */ case QUOTA_ALLOC_RESULT_OVER_QUOTA: case QUOTA_ALLOC_RESULT_OVER_QUOTA_MAILBOX_LIMIT: value = set->quota_status_overquota; break; case QUOTA_ALLOC_RESULT_TEMPFAIL: case QUOTA_ALLOC_RESULT_BACKGROUND_CALC: ret = -1; break; } value = t_strdup(value); settings_free(set); if I'm reading this correctly the value of "value" stays at '\0` when quota_status_toolarge is equal '\0`. I can solve the problem by explicitly setting any value for quota_status_toolarge in the configuration. Regards, Othmar

1 0

[BUG] IMAP hibernation fails on FreeBSD 15.x with "Invalid peer_dev_major value"
by Jordan Ostrev 20 Aug '26

20 Aug '26

Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: IMAP hibernation is effectively non-functional on FreeBSD 15.x Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: Disable hibernation at compile time for kqueue systems, or Add validation for major()/minor() return values before serialization? Thanks, Jordan Hi, IMAP hibernation compiles and attempts to run on FreeBSD 15.x (tested with Dovecot 2.4.4 and FreeBSD 15.1), but fails at runtime with: plain imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap-hibernate: Error: conn unix:imap-hibernate (uid=125): Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Jun 24 21:27:08 classic dovecot[36888]: imap(jordan(a)ostreff.info)<37120><ExaV/gNVAdt/AAAB>: Error: Couldn't hibernate imap client: /var/run/dovecot/imap-hibernate returned failure: Failed to parse client input: Invalid peer_dev_major value: 18446744073709551615 Root cause: In src/imap/imap-client-hibernate.c, the code serializes peer_dev_major and peer_dev_minor using major() and minor() macros: c str_printfa(cmd, "\tpeer_dev_major=%lu\tpeer_dev_minor=%lu\tpeer_ino=%llu", (unsigned long)major(peer_st.st_dev), (unsigned long)minor(peer_st.st_dev), (unsigned long long)peer_st.st_ino); On FreeBSD, major() and minor() can return UINT64_MAX (18446744073709551615) for file descriptors that are not block/character devices (such as sockets on tmpfs/devfs). This value exceeds UINT_MAX and cannot be parsed by str_to_uint() in imap-master-client.c. Historical context: This was discussed on the Dovecot mailing list in July 2019 (thread: "Hibernation errors") but apparently never resolved upstream. The same failure mode persists in Dovecot 2.4.4. Impact: o IMAP hibernation is effectively non-functional on FreeBSD 15.x o Processes remain running indefinitely instead of being hibernated Documentation note: The Dovecot 2.4 documentation states that hibernation "is not supported on kqueue based systems currently, such as FreeBSD." However, the code still compiles and attempts to run, producing these errors rather than being disabled at compile time or gracefully skipped at runtime. Would it make sense to either: 1. Disable hibernation at compile time for kqueue systems, or 2. Add validation for major()/minor() return values before serialization? Thanks, Jordan

3 12

IMAP access marking new messages as "old" for mutt
by Marc Haber 19 Aug '26

19 Aug '26

Hi, this might be a stupid question asked by someone who does not know enough about IMAP, but I'm going to tell you my user story anyway: tl;dr: can I keep dovecot from moving all "NEW" message to· "OLD" state when the Mailbox was opened once and nothing actually read? long version: My mail is delivered to a maildir on a machine I also have a shell account on. That Maildir is huge, it holds half a million messages. I usually access it directly with mutt accessing the spool. In the Mailbox, new messages automatically get the N flag and once I have opened it in mutt, I can mark it as "O" (old). I use that flag for messages that still need further work, I usually have a couple of hundred messages in that state. There is also a third state (I would call it "read") that doesnt display any flags in mutt. Occasionally, I need access to an attachment directly on my work box. In the past, I have moved that message to a sub-maildir which I then access with Thunderbird or neomutt via IMAP and dovecot (configured via userdb). I now want to give neomutt direct IMAP access to the BIG mailbox. I am impressed how quickly the neomutt/dovecot acesses this mailbox. However, once I have once opened that mailbox, all messages that had the N flag in the mutt-on-spool lose that flag immediately, replaced by the O flag. That destroys my method of seeing "O" messages as "needs work". Since that happens with both Thunderbird and neomutt when testing, I suspect, this is either mandated by the protocol (which would be a showstopper for me), or a dovecot issue, maybe even a thing that I could configure in dovecot. Hence, my question, can I configure dovecot to move a "NEW" message to "OLD" only if the message was actually READ/body-displayed by an IMAP client? And, if yes, how do I do that. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

2 1

RE: ai dovecot
by Marc 16 Aug '26

16 Aug '26

No I am curious if they use llms, because I am getting more and more impressed by it. I see suggestions referring to RFC compliant code, which I have been missing in quite a few developers working for me. I think if you are full time developer this can be really helpful. Not to mention those news items where software is ported and scanned for vulnerabilities. > > So you'd like the developers to subject their code to LLMs for audit? > What idiocy is that! > > On Sun, Aug 16, 2026 at 1:33 AM Marc <Marc(a)f1-outsourcing.eu > <mailto:Marc@f1-outsourcing.eu> > wrote: > > > > > > > > > I am just a bit curious, are llm's being used to check the > code or > > help in any other way? > > > > > > > > Why does it bother you? > > > > > > > ??? Can't you read? I am curious, not bothered. > > > > > -- > > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > In an Internet failure case, the #1 suspect is a constant: DNS. > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) > [How to ask smart questions: http://www.catb.org/~esr/faqs/smart- > questions.html]

1 0

mbox - maildir transition using dovecot lmtp local user auth struggles
by "Tóth Attila" 14 Aug '26

14 Aug '26

Approaching age 49 I passed the time long before when I was excited about a new version or a software upgrade. Why poke something that works? From time to time I'm forced to upgrade hardware and software against my will otherwise could serve many more years. I became the victim of mbox -> maildir transition. First I converted the good old Sendmail to Postfix. Initially it still used procmail delivering in mbox mailboxes, now I converted the mboxes to maildir and changed the way of delivery by dovecot lmtp, since that is the software I use for IMAP access. At least there seem to be no data-loss after a couple of doveadm backup and sync retries. There are just 4 local users, so dovecot was set for pam authentication and it worked (for 20+ years, although there were some bumps while upgrading from 2.3 to 2.4 syntax). Now dovecot lmtp started bouncing mails, because it was trying to authenticate a username including the domain name as well and the backend returned unknown user, since expected local user names. This wasn't a problem with mbox/procmail. I asked AI for help and first suggested to use auth_username_format = %Ln. It soon turned out, that this syntax is obsolete. So I dig into it myself and tried auth_username_format = %{user | lower}. It wasn't picked up by dovecot, symptoms persisted. I also tried auth_username_translation = %{user | split('@') | list_first}, which turned out to be also unsuccessful. I also tried to solve the issue on the postfix side by introducing regex handling, but either lmtp_generic_maps = regexp:/etc/postfix/lmtp_generic or recipient_canonical_maps = regexp:/etc/postfix/recipient_canonical had no influence on the symptoms (regex was: /^([^@]+)@atoth\.sote\.hu$/ ${1}). Also tried virtual conversion and lda. Nothing solved the fricking problem. I ended up using a workaround I'm ashamed to share. I kept passdb pam, but for userdb I created a userdb-file, where I included users both with the local name only and the full email address. This shameful concept is functional, but I have to admit it is disappointing: several ways back and forth for solving an issue were all unsuccessful. And it is exhausting. Any ideas appreciated. BR: Dw. -- dr Tóth Attila, Radiológus, 06-20-825-8057 Attila Toth MD, Radiologist, +36-20-825-8057

1 0

Debian 13 Dovecot 2.4.1 LMTP Error Absent ~/sieve
by Conrad T. Pino 14 Aug '26

14 Aug '26

Hello Dovecot List, Our upgrade from Debian 9 Dovecot 2.2.27 to Debian 13 Dovecot 2.4.1 went well. Only recently we added a new mailbox and LMTP delivery failed. Dovecot redacted error from Postfix log: 451 4.2.0 <user@domain> Temporarily unable to access necessary Sieve scripts (in reply to end of DATA command)) Dovecot redacted errors from Dovecot log: dovecot[736]: lmtp(user@domain): Error: sieve: file storage: Performing t_readlink() on active sieve symlink '(null)' failed: readlink() failed: Bad address dovecot[736]: lmtp(user@domain): Error: sieve: Failed to access active Sieve script in parsonal storage 'default': Internal error occurred. Refer to server log for more information. [2026-08-13] (temporary failure) LMTP delivery works after manually creating ~/sieve directory with correct permissions. I know a PostfixAdmin postcreation script can automate directory creation. Have I overlooked Dovecot setting to have Dovecot create ~/sieve directory during LMTP delivery? Best regards, Conrad T. Pino

1 0

ai dovecot
by Marc 14 Aug '26

14 Aug '26

I am just a bit curious, are llm's being used to check the code or help in any other way?

1 0

BUG 2.4 regression: a wrong password over PLAIN is reported as a temporary failure, and the invalid_grant branch is now dead code
by Ihor Rusyn 14 Aug '26

14 Aug '26

Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot *2.4.4 (8b687aa65c)*, the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against *2.3.21*. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as §5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} *2.3.21:* NO [AUTHENTICATIONFAILED], logged at info level. *2.4.4:* NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In *2.3.21*, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON *parser* failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In *2.4.4*, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is *optional* in RFC 6749 §5.2 — so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters - Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. - Monitoring reads a user error as a service failure — on a farm this is the difference between a quiet log and a page. - RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping. Summary With passdb oauth2 doing a password grant, a wrong password makes dovecot answer the IMAP client a NO [UNAVAILABLE] Temporary authentication failure. and log it at Error: level. 2.3 answered AUTHENTICATIONFAILED for the same exchange. PASSDB_RESULT_PASSWORD_MISMATCH is still in db-oauth2.c, but for the password grant it can no longer be reached. Environment Dovecot 2.4.4 (8b687aa65c), the official dovecot/dovecot:2.4.4-root image, unmodified. Compared against 2.3.21. Reproduction Any RFC 6749 compliant authorization server. Point passdb oauth2 at its token endpoint with grant_type=password and attempt an IMAP LOGIN with a wrong password. The server answers, as S5.2 prescribes: HTTP 400 {"error":"invalid_grant","error_description":"Invalid credentials"} 2.3.21: NO [AUTHENTICATIONFAILED], logged at info level. 2.4.4: NO [UNAVAILABLE] Temporary authentication failure, logged as auth(user,ip,sasl:plain): Error: oauth2-grant: oauth2 failed: Password grant failed: Invalid credentials imap-login: Login aborted: Logged out (auth service reported temporary failure, 1 attempts in 3 secs) (temp_fail) Cause src/auth/db-oauth2.c is identical in both versions: passdb_result = PASSDB_RESULT_INTERNAL_FAILURE; if (result->error != NULL) error = result->error; else { error = db_oauth2_field_find(result->fields, "error"); if (error == NULL) error = "OAuth2 server returned failure without error field"; else if (strcmp("invalid_grant", error) == 0) passdb_result = PASSDB_RESULT_PASSWORD_MISMATCH; } What changed is what reaches result->error. In 2.3.21, src/lib-oauth2/oauth2-request.c:113-129 set error only when the JSON parser failed. A well-formed error body parsed fine, so error was NULL, res.error stayed NULL, and db-oauth2.c took the else branch, found invalid_grant among the fields and returned PASSWORD_MISMATCH. In 2.4.4, src/lib-oauth2/oauth2-request.c:136-149 added: /* check if fields contain error now */ const struct oauth2_field *error_field = array_lsearch(&req->fields, "error", request_field_cmp); if (error_field != NULL) { error = error_field->value; /* "invalid_grant" */ /* check for detailed error */ error_field = array_lsearch(&req->fields, "error_description", request_field_cmp); if (error_field != NULL) error = error_field->value; /* overwritten: "Invalid credentials" */ } req->json_parsed_cb(req, error); oauth2_request_continue() then does if (error != NULL) res.error = error;, so result->error is always set on failure and db-oauth2.c never reaches the branch that recognises invalid_grant. The machine-readable code is replaced by the human-readable description before anything can act on it. Note that error_description is optional in RFC 6749 S5.2 -- so a fully compliant server triggers this simply by being helpful. Omitting it does not help either: error would then hold invalid_grant and still be assigned to res.error, taking the same branch. Why it matters o Mail clients treat [UNAVAILABLE] as a server problem and retry rather than prompting for the password, so users are not told their password is wrong. o Monitoring reads a user error as a service failure -- on a farm this is the difference between a quiet log and a page. o RFC 5530 defines AUTHENTICATIONFAILED for a failed authentication and UNAVAILABLE for a temporarily unavailable server. Reporting the former as the latter tells the client something untrue about the server. There is no anti-enumeration benefit in the current behaviour: the same provider response is returned for a wrong password and for a non-existent account, so both are indistinguishable to the client under either mapping.

1 0