the same config, but with a more stripped down userdb response shows the problem in action too:
auth: Debug: master userdb out: USER 1535246337 b@x.com mail=maildir:/mail/mailstore03/492/177/b@b.com/:INDEX=/mail/index03/492/177/b@b.com/ home=/mail/mailstore03/492/177/b@b.com/ namespace=inbox namespace/inbox/separator=/ auth_mech=PLAIN auth_token=08c7b084f58d76b028a96eed55f16c57ce3c7ff8 script-login(b@x.com)<59977><>: Debug: Added userdb setting: mail=maildir:/mail/mailstore03/492/177/b@b.com/:INDEX=/mail/index03/492/177/b@b.com/ script-login(b@x.com)<59977><>: Debug: Added userdb setting: namespace=inbox script-login(b@x.com)<59977><>: Debug: Added userdb setting: namespace/inbox/separator=/ imap(b@x.com)<59976><Kc80nMbjXoQKyAUI>: Debug: Added userdb setting: mail=maildir:/mail/mailstore03/492/177/b@b.com/:INDEX=/mail/index03/492/177/b@b.com/ imap(b@x.com)<59976><Kc80nMbjXoQKyAUI>: Debug: Added userdb setting: namespace=inbox imap(b@x.com)<59976><Kc80nMbjXoQKyAUI>: Debug: tc_empty_notify_plugin init imap(b@x.com)<59976><Kc80nMbjXoQKyAUI>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:/mail/mailstore03/492/177/b@b.com/:INDEX=/mail/index03/492/177/b@b.com/
i don't get an error here since i'm only passing the one namespace, but the same thing occurs: the script-login event logs both namespace settings, but the imap event only logs the "namespace=inbox" one - the "namespace/inbox/separator=/" one never gets applied and the inbox namespace still has the default separator
the same thing occurs if i try and send prefix/hidden/list/subscriptions - the imap process just ignores them
i finally tracked down the issue here. we had an imap-postlogin script running and it was the source of the issue. it had been set up to use /bin/sh, and between debian 10 and 11, debian changed /bin/sh from bash to dash. dash, it appears, does not allow environment variables containing slashes. running env from the postlogin script showed it was missing the keys that contained a /: brendan@imap-p2-01:~$ sudo grep NAMESPACE /tmp/dovecot.login.env.dash USERDB_KEYS=NAMESPACE/SHARE/SUBSCRIPTIONS HOME QUOTA QUOTA-RULE5 QUOTA_RULE NAMESPACE/SHARE/PREFIX NAMESPACE/SHARE/LOCATION NAMESPACE/SHARE/SEPARATOR QUOTA-RULE3 MAIL NAMESPACE/INBOX/SEPARATOR QUOTA_RULE2 SIEVE NAMESPACE/SHARE/LIST SIEVE_DIR NAMESPACE QUOTA-RULE4 NAMESPACE/SHARE/TYPE AUTH_MECH AUTH_TOKEN NAMESPACE=inbox,share but, after explicitly switching to bash, all the env variables show up correctly: brendan@imap-p2-01:~$ sudo grep NAMESPACE /tmp/dovecot.login.env.bash NAMESPACE/SHARE/TYPE=shared NAMESPACE/SHARE/LOCATION=maildir:%h:INDEX=/mail/index01/492/177/b@b.com/shared/%u:INDEXPVT=/mail/index01/492/177/b@b.com/shared_pvt/%u NAMESPACE/SHARE/LIST=children NAMESPACE/SHARE/SUBSCRIPTIONS=no NAMESPACE/SHARE/SEPARATOR=/ NAMESPACE/INBOX/SEPARATOR=/ NAMESPACE/SHARE/PREFIX=shared/%u/ NAMESPACE=inbox,share USERDB_KEYS=HOME SIEVE_DIR NAMESPACE/SHARE/SUBSCRIPTIONS NAMESPACE/SHARE/TYPE NAMESPACE/SHARE/LOCATION NAMESPACE/INBOX/SEPARATOR SIEVE NAMESPACE/SHARE/LIST MAIL QUOTA-RULE5 NAMESPACE/SHARE/SEPARATOR NAMESPACE/SHARE/PREFIX QUOTA QUOTA-RULE4 QUOTA_RULE QUOTA-RULE3 QUOTA_RULE2 NAMESPACE AUTH_MECH AUTH_TOKEN so with dash, a bunch of the namespace/ keys would get stripped out and never make it to the imap process being exec'd after the post-login script. then i'd get namespace errors as a result of the extra userdb directives not making it through. i'm not really sure how to commit changes to the git documentation, but here's a diff with a suggested note about this issue: --- post_login_scripting.rst 2021-09-22 19:53:21.698740730 +0000 +++ post_login_scripting.rst.new 2022-08-24 17:56:22.107188780 +0000 @@ -76,6 +76,11 @@ You can change any Dovecot settings using the above method. +NOTE: certain shells may not permit environment variable names that contain +slashes (/) - if you need to pass userdb keys that contain a / (ie. +NAMESPACE/inbox/separator), ensure that you are using a shell that supports +them (bash and perl do, dash does not). + Changing user's password after login ====================================