honey, i just need that mail from a week ago. let me just go down to the hotel lobby and log in to my mail account. oh, they are using win xp with ie6... ok, let me use your sketchy device.

you certainly know moments like these, where you desperately need access to your mails, but did not bring your own or any other trusted device with you. and even if you did, in some cases you really can't tell if your device is secure.

since you don't want to expose your personal password to any foreign device, especially not if you use some kind of password scheme, application specific passwords can be a very nice thing. the basic idea here is to generate a password for each device or application which accesses your mailbox. that way you can thorougly check which device did access your mailbox and conduct countermeasures if needed. those passwords can be as complex as you wish, as you probably will enter them only once. if needed, you can revoke and set a new password for that application.

justin buchanan already provided a very detailed guide on how to set up dovecot with application specific passwords. the only downside is that he uses a sql database to store the passwords. i however use passwd files as password storage.

dovecot passwd files usually looks something like this. the only required fields in our scenario are user, password and extra fields.

# user:password:uid:gid::home::extra_fields
foo@example.com:{CRYPT}abcdef123456...

if you try to add a second account with the same username you will get an error:

dovecot: auth(default): passwd-file: User foo@example.com exists more than once

bummer... so it does not seem possible to add several passwords for the same account? well, if you are adventurous, there is a way. first of all you have to allow dovecot to permit any user name and only do a passdb lookup when doing a login. don't worry, nobody will be able to log in without the right combination of a username and password. adding the allow_all_users=yes instruction will ignore the user lookup from the userdb and entirely rely on the passdb lookup. make sure to add the following lines to your dovecot configuration file /etc/dovecot/dovecot.conf. of course you can also use the very same passdb file as a userdb in which case you have to add the home and, depending on your setup, the uid and gid variables to the passwd file.

userdb static {
  args = home=/var/mail/vhosts/%d/%n allow_all_users=yes
}
passdb passwd-file {
  args = /var/mail/vhosts/%d/passwd
}

the passwd file will be located in /var/mail/vhosts/%d/passwd, where %d stands for your domain, in our case example.com. the home variable tells dovecot to set up a maildir in /var/mail/vhosts/%d/%n, which in our example will resolve to /var/mail/vhosts/example.com/foo. of course you are welcome to change these settings to match your setup. adding a uid and gid to the userdb arguments is also a very good idea.

the extra fields section in a passwd file allows to change several parameters of a user. luckily they also allow us to change the user name. that way, we can add as many different user names and matching passwords for each and every application. when logging in however, dovecot will transparently remap to your primary user.

foo@example.com:{CRYPT}abcdef123456...
mobile@example.com:{CRYPT}123456789...::::::user=foo@example.com
webmail@example.com:{CRYPT}0123abcd...::::::user=foo@example.com
tablet@example.com:{CRYPT}987654321...::::::user=foo@example.com

and voilá, you can easily add as many application specific accounts as you wish. dovecot is clever enough to log the original user name when accessing the mailbox which provides you with a clever mechanism to check when, how and how often an application specific user logged in.

finally you have to set the identity in your mail program back to your original address in order to send mails with that address.

as always, i would be more than happy for any corrections or suggestions!

update: with dovecot 2.2.6 and above you can use %{orig_user}, %{orig_username} and %{orig_domain} in login_log_format_elements which expand to the username exactly as sent by the client, before any changes made by the auth process. that way you can keep track of which user names were used.