Working with group mailboxes under your own password

Prelude

Every organization has role-based email addresses (such as info@company.com or order@company.com) with which a group of employees collectively works. In some mail systems (such as MS Exhange), support for such addresses is already hardwired into the software logic. In other cases, you have to choose different technical approaches yourself. Let’s look at them in more detail.

Postal “alias”, which is assigned to the mailing list for personal addresses of employees.
Automated mailing lists (mailman and similar) also allow you to send a letter incoming to a role address according to the list, but they support additional functionality: access control, moderation, archiving.
A shared mailbox that is connected to employees’ mail clients (using the IMAP protocol).

If in your case it is a general mailbox that is required and you are experiencing certain difficulties with its organization, then, as they say, “we are coming to you)”

Kolkhozim general mailbox

The most primitive approach is to simply distribute the password to the employees of the shared mailbox, while getting a fair amount of headaches with security and the procedure for changing this very password. We pass by and move on.

In our organization, the mail system is organized on the basis of the popular Postfix + Dovecot + LDAP bundle.

DISCLAIMER

The previous version of this article was rejected by the moderators of the HABR resource who saw it as an advertisement for my product (or company). I have no idea where they found her here. Unfortunately, the system interface does not allow you to contact the moderator directly for clarification. It remains only to speculate, and to answer use this slightly strange form of communication. Therefore, here I responsibly declare that Postfix (c), Dovecot (c) and the LDAP directory access protocol are open products and protocols. They are available in source code on the respective sites, and binary builds are present in almost all major versions of Linux. Neither I nor my organization have a direct relationship with them and do not pursue here commercial or any other benefit. Something like this. I apologize for the banality.

Dovecot mail server, for sharing mail folders offers shared mailbox engine (Shared Mailboxes)but if you look closely, it’s not so much a shared mailbox mechanism as public mail folders. In general, this procedure is quite troublesome. Without diving into technical subtleties, we can say that it requires the following actions:

In the Dovecot configuration, configure access to the inbox and outbox of the role account.
Mount these folders in the employee mailbox settings.
Set up email profiles of employees so that replies to the role address are saved to the shared folder of outgoing messages.

It would be much easier to connect to the role-based mailbox using the password from your account. That is exactly what we did. After spending some time looking for solutions on the net and not finding anything suitable, the Dovecot settings mechanism was developed, which is described below.

Configuring Dovecot for group access to role-based mailboxes

The Dovecot server supports a fairly flexible user authentication and authorization system. For this purpose, user registries are used (userdb) and password registries (passweb). When the user enters their credentials in the form of a username and domain name (name@domain) two service variables are initiated in the system %n=<name>And %d=<domain> . After that, the server sequentially checks the presence of the user in the password registries. If authentication in the password registry is successful, an advising entry in the user registry is searched for and mailbox settings are retrieved from it.

The password registry setup looks like this:

[Файл /etc/dovecot/dovecot.conf]: passdb { args = /etc/passdb-ldap-args-file.conf driver = ldap .... } [Файл /etc/passdb-ldap-args-file.conf]: ... pass_filter = ... pass_attrs = ...

The form and content of the argument file (args) depends on the authentication driver. In our case, this ldap. To search for a user entry in the ldap database, use the attribute pass_filterA that contains the ldap query filter expression. In attribute pass_attrs are set between the attributes of the found ldap object and the Dovecot user’s internal variables (password, allow_nets etc.), which are involved in the process of authentication and authorization. In addition, it is possible to overwrite the value of the innermost variable userwhich specifies the username.

In my opinion the attribute syntax is pass_attrs somewhat chaotic and poorly documented, so it makes sense to consider it in more detail with an example:

pass_attrs = =user=%n@mydomain.com,userPassword=password

In this case, the value of the ldap attribute userPassword will be loaded into an internal variable password. In addition, the user variable will take on the value %n@mydomain.comthat is, the domain will be added to the username mydomain.com

Now let’s move on to an example of settings for solving our problem. Let there be a role box info@company.com and users user1@company.com And user2@company.comthat you need to connect the mailbox info.

Do times:

In configuration dovecot.conf create a special password registry:

passdb { args = /etc/dovecot/dovecot-ldap-company-shadow.conf driver = ldap username_filter = user1@info user2@info }

In the config you can notice the filter username_filter, which in this case works as a mailbox access authorization info. If the user user1 wants to connect to the box info under his password, he must use the name user1@info.

Case two (dovecot-ldap-company-shadow.conf):

hosts = ... base = ... ... pass_filter = ...(uid=%n) pass_attrs = =user=%d,userPassword=password, ...

Consider the logic of the settings. When a user logs in (user1@info) the system verifies the password for the user in the name user1 (uid=%n). If the verification is successful, then the username is changed to the “domain part” info (user=%d).

If the mail system does not use the user’s name to log in, but his postal address, then the settings will be approximately as follows:

pass_filter = ...(mail=%n@company.ru) pass_attrs = =user=%d@company.ru,userPassword=password, ...

Conclusion

I can say that I liked the result, so I hasten to share it with a grateful public. To add or remove access to role mailboxes, just edit the attribute username_filter and kindly ask the dovecot server to re-read the configuration.