Dovecot/Plugins: различия между версиями

Материал из ALT Linux Wiki
(Опыт в работе с плагинами Dovecot)
 
Нет описания правки
 
(не показаны 4 промежуточные версии 1 участника)
Строка 1: Строка 1:
{{stub}}
'''Опыт в работе с плагинами Dovecot'''
 
= Опыт в работе с плагинами Dovecot =


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


== mail_crypt ==
== Плагин mail_crypt ==


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


Доступен в {{pkg|dovecot}} с версии 2.2.27-alt1 (Sisyphus)
Доступен в {{pkg|dovecot}} с версии 2.2.27-alt1 (Sisyphus)
=== doveadm mailbox cryptokey ===
Инструмент для консоли администрирования dovecot. Для его использования обязательно в главном конфигурационном файле (dovecot.conf) явно включить плагин (иначе данная команда будет недоступна, как впрочем и вызов {{cmd|man doveadm-mailbox-cryptokey}}):
mail_plugins = $mail_plugins mail_crypt
=== Использование глобальных ключей для шифрования ===
Основной целью использования плагина ''mail_crypt'' является шифрование писем в локальном хранилище. Для этого могут использоваться RSA и ECDSA ключи (разработчики "сильно" советуют использовать именно второй тип).
В документации к этому плагину указано как сгенерировать необходимые ключи, и поместить их в конфигурационный файл в описание плагина (не важно [http://wiki2.dovecot.org/Plugins/MailCrypt#RSA_key RSA] или [http://wiki2.dovecot.org/Plugins/MailCrypt#EC_key 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 не путь к файлу, а ключ в виде [http://wiki2.dovecot.org/Plugins/MailCrypt#Base64_encoded_keys 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
}
=== Использование [http://wiki2.dovecot.org/Plugins/MailCrypt#Folder_keys 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):
<pre>
................
passdb {
  driver = pam
}
userdb {
  driver = passwd
  override_fields = home=/var/vmail/glu_vrem/%u
}
................
</pre>
Исходя из документации:
passwd
The [https://wiki2.dovecot.org/AuthDatabase/Passwd 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 [https://wiki2.dovecot.org/AuthDatabase/PasswdFile 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
{{note|Опцию enumerate (подробнее [https://linux.die.net/man/5/sssd.conf здесь]) на больших конфигурациях использовать не рекомендуется,
в силу уменьшения производительности/скорости мапирования из pam в passwd.
Однако в случае почтового сервера ввиду единичных его перезагрузок это не является критическим моментом.}}
После перезапуска службы sssd все уже намного лучше:
<pre>$ 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</pre>
Теперь если перенаправить вывод, например в файл /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
{{note|Однако может возникнуть ситуация, и скорее всего точно возникнет, что авторизация работает, квоты применяются, а почта не ходит, так как в файле passwd-file dovecot не видит email и не знает кому и от кого послать почту. Решением данной проблемы было бы приведение passwd-file к формату - два поля на пользователя, в одном - его login, во втором email:
<pre>
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
</pre>
Но вводить такой формат passwd-file - это практически отказаться от АД.
Было найдено следующее решение - passwd-file добавлен как дополнительная userdb (к passwd), в котором указываются пользователи с отличающейся от умолчаний квотой, в формате указанном выше.
}}
Проверено - работает:
<pre>
................
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
}
................
</pre>
[[Категория:FAQ]] [[Категория:HOWTO]]
{{Category navigation|title=HOWTO|category=HOWTO|sortkey={{SUBPAGENAME}}}}

Текущая версия от 12:39, 10 марта 2018

Опыт в работе с плагинами 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
}
................