Wandering Thoughts archives

Ignoring the domain when authenticating your Dovecot users

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.)

Firefox 57 and the state of old pre-WebExtensions addons

Back in June I wrote an entry about the current state of pre-WebExtensions addons and what I thought was the likely future of them. Based on Mozilla's wiki page on this, which said that legacy extensions could still be loaded on Nightly builds with a preference, I said I expected that they would keep working well into the future. As far as I can currently tell, I was wrong about that and my optimistic belief was completely off.

As of right now given the ongoing state of Firefox Nightly, it appears that Mozilla has abandoned practical compatibility with many old addons. With the preference set, Mozilla may allow Nightly to load them, but Mozilla won't necessarily keep them working; in fact, available evidence suggests that Mozilla has been cheerfully breaking old extension APIs left and right. The only old APIs that we can probably count on continuing to work are the APIs that Mozilla needs for their own use (the 'signed by Mozilla internally' status of legacy extensions in the wiki page), and it's clear that these APIs are not sufficient for many addons.

In particular, all of my addons remain in various states between broken and completely non-functional on Nightly. This situation has not been improving since the preference change landed; if anything they've been getting worse in more recent Nightly versions. Since this has persisted for weeks and weeks, I have to assume that Mozilla no longer cares about general legacy extensions on Nightly and they're either landing code improvements that have no support for them or are actively removing the code that supports legacy extension APIs. Or both. I can't blame Mozilla for this, since they've been saying for years now that they wanted to get rid of the old APIs and the old APIs were holding back Firefox development.

One implication of this is that Mozilla is now fairly strongly committed to their Firefox 57 extension plans, come what may. With legacy extensions broken in practice, Mozilla cannot simply re-flip the preference the other way to back out of the transition and return legacy extensions to operation. Nor do I think they have time to fix the code should they decide they want to. If I'm reading the Firefox release calendar correctly, we're about one or two weeks from Firefox Nightly transmuting into the Firefox 57 beta version, and then six weeks more until Firefox 57 is actually released.

The personal implication for me is that I've now reached the last Nightly version I can use, although it happened perhaps a month later than I thought it would way back when. Now that I look at the dates of things, I think my current Firefox 'Nightly' versions are actually before Firefox 56 branched off, so I should probably switch over to Firefox 56 and freeze on it. That way I'll at least get security fixes until November or so.