Dovecot's 2.4 settings refactor drops the SQL escape its own passdb asked for

Two layers each assumed the other was doing the escaping. The username a client supplies at login gets reused in SQL and LDAP queries and in file paths through `%u`, `%n` and `%d` substitution ^[10]. `auth_username_chars` filters the bytes. The SQL passdb has its own escape hook, because filtering allowed bytes is the wrong tool for quoting a query string built from a template like `SELECT username, password FROM users WHERE username = '%u'` ^[11]. Both defences exist, but the source comparison shows only one of them was actually running.

The whitelist literal in `src/auth/auth-settings.c` is 67 characters long but sets 66 distinct entries in the 256-byte map, because the digit run is written `01234567890` and repeats the zero ^[5][17]. So the default rejects 190 of the 256 possible byte values ^[18]. Clearing the setting flips all 190 to accepted in a single `memset` ^[7]. The empty-string branch even carries the comment `/* all chars are allowed */`, so the inversion is documented, just not anywhere an administrator would read it ^[7].

Now look at the caller. `sql_lookup_pass` fills `struct settings_get_params` with `.escape_func = passdb_sql_escape` and the database handle as context, and that function calls the driver's `sql_escape_string()` for MySQL, PostgreSQL or SQLite ^[12][13]. The header documents the contract: if the function is non-NULL, all `%variables` are escaped with it ^[14]. Anyone reviewing `passdb-sql.c` in isolation signs it off. According to the dev.to analysis, the request is discarded one layer down in `settings_var_expand_init()` in `src/lib-settings/settings.c`, where the settings system can take a var-expand escape function from two different places ^[15].

That distinction decides what you do this week. Read the advisory literally and the remedy is to put the whitelist back, since a cleared `auth_username_chars` is what the one-line summary blames ^[1]. Under the regression reading it is only the precondition, and restoring the whitelist removes the trigger on the path you already thought about while leaving the dropped escape in place ^[3]. The material we have does not enumerate which other callers pass an `escape_func` through the same code, so I would not assume the SQL passdb is the only one, and I would read the 2.4.2-to-2.4.3 diff before deciding otherwise ^[4].

There is a cheap local check. `sql_lookup_pass` logs the fully expanded query at debug level before handing it to `sql_query()` ^[16]. On a 2.4.2 build you can send a username containing a quote and see in the auth debug log whether it arrived escaped. That check settles which reading applies to your binary, but settling it does not patch anything.

For the misconfiguration framing to be the whole story, the escape hook would have to have been honoured, in which case clearing the whitelist would still be a question about file paths and `%u` in filenames but not an authentication bypass ^[10]. The analysis says it was not honoured ^[3]. Treat `auth_username_chars` as an input-shape policy, keep it populated because unicode support is not worth an unfiltered byte range, and take the package.