Dovecot/Plugins

Материал из ALT Linux Wiki

Опыт в работе с плагинами Dovecot

Оригинальная статья: http://wiki2.dovecot.org/Plugins

Плагин mail_crypt

Оригинальная статья: http://wiki2.dovecot.org/Plugins/MailCrypt

Доступен в dovecot с версии 2.2.27-alt1 (Sisyphus)

doveadm mailbox cryptokey

Инструмент для консоли администрирования dovecot. Для его использования обязательно в главном конфигурационном файле (dovecot.conf) явно включить плагин (иначе данная команда будет недоступна, как впрочем и вызов man doveadm-mailbox-cryptokey): 

mail_plugins = $mail_plugins mail_crypt

Использование глобальных ключей для шифрования

Основной целью использования плагина mail_crypt является шифрование писем в локальном хранилище. Для этого могут использоваться RSA и ECDSA ключи (разработчики "сильно" советуют использовать именно второй тип).

В документации к этому плагину указано как сгенерировать необходимые ключи, и поместить их в конфигурационный файл в описание плагина (не важно RSA или ECDSA): 

mail_plugins = $mail_plugins mail_crypt
plugin {
   mail_crypt_global_private_key = <privkey.pem
   mail_crypt_global_public_key = <pubkey.pem
   mail_crypt_save_version = 2
}

В данном случае при отправке письма с логах следующее сообщение (от типа ключей работоспособность не зависит): 

Error: User initialization failed: mail_crypt_plugin: mail_crypt_global_public_key: Couldn't parse public key: Unknown key format

Это является багом (подробности в рассылке - https://www.dovecot.org/list/dovecot/2017-January/106729.html). Решение такое - поместить в поля mail_crypt_global_*_key не путь к файлу, а ключ в виде base64-строки. Также возможно использовать и описанный в данной статье метод (указав дополнительно значение атрибута mail_attribute_dict): 

passdb {
   driver = static
   args = password=pass mail_crypt_global_public_key=<content of ecpubkey.pem> mail_crypt_global_private_key=<content of ecprivkey.pem>
}
mail_attribute_dict = file:%h/Maildir/dovecot-attributes #в документации не указан, но обязателен (см. ниже - folder keys)
mail_plugins = $mail_plugins mail_crypt
plugin {
   mail_crypt_save_version = 2
}

Использование Folder keys

В данном случае для каждого пользователя и для каждой папки в его почтовом ящике генерируются свои ключи шифрования, которые записываются в файл, определенный параметром mail_attribute_dict, например: 

mail_attribute_dict = file:%h/Maildir/dovecot-attributes

Однако был обнаружен очередной баг при использовании данного способа шифрования: при перемещении письма в другую папку (или удалении его) - его содержимое в новом расположении нечитаемо (если вернуть в прежнее - все ОК). Ошибка в логе: 

imap(cloud): Error: read() failed: read(/home/cloud/Maildir/.Sent.test/cur/1485528498.M838579P2267....) failed: 
Decryption error: no private key available (uid=5, box=Sent.test, read reason=)
imap(cloud): Info: Internal error occurred. Refer to server log for more information.

https://www.dovecot.org/list/dovecot/2017-January/106814.html

Quota

Оригинальная статья: http://wiki2.dovecot.org/Quota

Имеется почтовый сервер c dovecot с авторизацией доменными пользователями (машина введена в домен с помощью SSSD/AD)

Как назначить квоту для определенных пользователей? Официальная документация - https://wiki2.dovecot.org/Quota/Configuration#Per-user_quota - сообщает о данной возможности только при использовании в качестве userdb ldap, sql или passwd-file. Так как же быть, если базой данных паролей является PAM (соответственно БД имен пользователей passwd): 

................
passdb {
  driver = pam
}
userdb {
  driver = passwd
  override_fields = home=/var/vmail/glu_vrem/%u
}
................

Исходя из документации: 

passwd
The passwd userdb doesn't support extra fields. That's why you can't directly set users'
quota limits to passwd file. One possibility would be to write a script that reads quota limits
from another file, merges them with passwd file and produces another passwd-file,
which you could then use with Dovecot's userdb passwd-file.

Поэтому решением проблемы квот в данном случае будет именно переключение userdb с passwd на passwd-file (по этой настройке последняя ссылка в процитированном абзаце), причем данный файл, как указано, должен формироваться скриптом, который берет системный passwd и файл с квотами, совмещает пользователей и квоты примерно в таком виде: 

user3:{plain}pass3:1002:1002::/home/user3::userdb_mail=maildir:~/Maildir userdb_quota_rule=*:bytes=300M

Однако в конфигурации SSSD по умолчанию команда getent passwd не выдает доменных юзеров: > $ getent passwd administrator > administrator:*:95400500:95400513:Administrator:/home/DOM/administrator:/bin/bash > $ getent passwd | grep administrator > <пусто>

За это отвечает опция SSSD enumerate - для ее включения необходимо в файле /etc/sssd/sssd.conf указать: 

enumerate = true
Примечание: Опцию enumerate (подробнее здесь) на больших конфигурациях использовать не рекомендуется,

в силу уменьшения производительности/скорости мапирования из pam в passwd.

Однако в случае почтового сервера ввиду единичных его перезагрузок это не является критическим моментом.

После перезапуска службы sssd все уже намного лучше: 

$ getent passwd
......
administrator:*:95400500:95400513:Administrator:/home/DOM/administrator:/bin/bash
wtestsssd$:*:95401107:95400515:WTESTSSSD:/home/DOM/wtestsssd$:/bin/bash
client1$:*:95401103:95400515:CLIENT1:/home/DOM/client1$:/bin/bash
testuser:*:95401106:95400513:testuser:/home/DOM/testuser:/bin/bash
wtest$:*:95401105:95400515:WTEST:/home/DOM/wtest$:/bin/bash
krbtgt:*:95400502:95400513:krbtgt:/home/DOM/krbtgt:/bin/bash
12345:*:95401104:95400513:12345:/home/DOM/12345:/bin/bash
guest:*:95400501:95400514:Guest:/home/DOM/guest:/bin/bash
dc1$:*:95401000:95400516:DC1:/home/DOM/dc1$:/bin/bash

Теперь если перенаправить вывод, например в файл /etc/imap.passwd, его можно попробовать указать в dovecot как userdb - driver = passwd-file (предварительно прописав квоты). Лучше все же конечно автоматизировать это скриптом, например создать файл /etc/imap.quota примерного содержимого: 

administrator::userdb_quota_rule=*:bytes=10G
client1::userdb_quota_rule=*:bytes=300M
testuser::userdb_quota_rule=*:bytes=300M

затем при прочтении этого файла скрипт припишет указанный extra field нужному пользователю в /etc/imap.passwd

Примечание: Однако может возникнуть ситуация, и скорее всего точно возникнет, что авторизация работает, квоты применяются, а почта не ходит, так как в файле passwd-file dovecot не видит email и не знает кому и от кого послать почту. Решением данной проблемы было бы приведение passwd-file к формату - два поля на пользователя, в одном - его login, во втором email: 
administrator:*:95400500:95400513:Administrator:/home/DOM/administrator:/bin/bash::userdb_quota_rule=*:bytes=10G userdb_mail=maildir:/var/vmail/glu_vrem/administrator/Maildir
adm@email.dom:*:95400500:95400513:Administrator:/home/DOM/administrator:/bin/bash::userdb_quota_rule=*:bytes=10G userdb_mail=maildir:/var/vmail/glu_vrem/administrator/Maildir

Но вводить такой формат passwd-file - это практически отказаться от АД. Было найдено следующее решение - passwd-file добавлен как дополнительная userdb (к passwd), в котором указываются пользователи с отличающейся от умолчаний квотой, в формате указанном выше.


Проверено - работает: 

................
passdb {
  driver = pam
}
userdb {
  args = /etc/dovecot/imap.passwd
  driver = passwd-file
  override_fields = home=/var/vmail/glu_vrem/%u
}
userdb {
  driver = passwd
  override_fields = home=/var/vmail/glu_vrem/%u
}
................