Ignoring the domain when authenticating your Dovecot users

September 15, 2017

In this recent entry, I wrote about how some of our users periodically try to authenticate to our Dovecot IMAP server with the user name '<user>@<our domain>' instead of simply '<user>', and said that we were probably going to switch our Dovecot configuration to ignore the domain name. We've now done that so here is an early experience report.

Dovecot is somewhat underdocumented, at least online and in manual pages. Your best source of information for what specific configuration settings do appears to be the various pieces of the example configuration in the source code, which have comments. Quite possibly your OS's packaging of Dovecot reuses these as the standard configuration files, so you can just read the documentation comments there. The comments in the authentication configuration file explains things this way:

# Username formatting before it's looked up from
# databases. You can use the standard variables here,
# eg. %Lu would lowercase the username, %n would drop away
# the domain if it was given, or "%n-AT-%d" would change
# the '@' into "-AT-". This translation is done after
# auth_username_translation changes.
#auth_username_format = %Lu

If you're willing to ignore all domains, so that '<user>@<random garble>' is treated as '<user>', then you can simply set this to:

auth_username_format = %Ln

This is what we did and it works. In current versions of Dovecot this changes Dovecot's view of the username for everything, not just for authentication. And by this I mean that we have some Dovecot settings that use '%u', and after this auth_username_format change they see the username as '<user>', not '<user>@<domain>'. It also changes what Dovecot shows as the username in log messages, stripping out any domain that was originally there. For our purposes this is what we want with only the minor downside of the log message change.

(For a concrete example, we have set mail_location to something that specifies '...:INDEX=/var/local/dovecot/%u' in order to keep Dovecot indexes on the IMAP server instead of on NFS. If you log in as '<user>@<domain>', your index files continue to use just /var/local/dovecot/<user>'.)

Based on what I've read, the Dovecot people are aware of this but don't consider it a bug as such, although they've considered changing it someday. Personally I hope that they don't, or if they do they provide a username_format setting to do this global username change.

If you want to strip only a single domain but leave other domains untouched, so that '<user>@<your domain>' becomes '<user>' but '<user>@<random thing>' stays unchanged, I think that you can do it with a conditional variable expansion. The Dovecot documentation says that conditional expansions can be nested, so you could do this for multiple domains if you were sufficiently determined.

I can see points for either side of being selective here. On the one hand, being selective doesn't help your own users as far as I know, because I believe that regardless of whether they use the wrong domain or the wrong password (or the wrong login), the only error they'll ever get from Dovecot is 'authentication not accepted' (aka 'bad password'). On the other hand, not altering completely wrong domain names means that they will appear in Dovecot's logs intact, so that you can spot people that are trying to use them. If using certain domains are a sign of attackers, preserving these in logs may be valuable.

(My experience from looking at our Dovecot logs was that attackers always tried to use the same domain name that our users did, which is not really surprising. Attackers tried them much more than users did, but that's not much help here.)

Written on 15 September 2017.
« Firefox 57 and the state of old pre-WebExtensions addons
Why I didn't use the attrs module in a recent Python project »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Sep 15 23:52:11 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.