Comments 15
А может кто пояснить, в чем смысл использовать локальные почтовики с учетом что отправить то письмо с вложением больше 25 мб можно, только его никто не примет зачастую.
Или сейчас можно поднять почтовик+файлообменик чтобы туда скидывались вложения со сгенеренной на него ссылкой для скачки?
По работе просто вижу что отправляются сканы и по 250 мб и уменьшить эту информацию никак нельзя и такой информации довольно много.
в чем смысл использовать локальные почтовики
Если у вас например 1000-2000 ящиков, то своя почта может сэкономить вам уже значительные средства, по крайней мере если и так есть админ, которому вы уже платите зарплату. Ну и вся почта у вас, можете хранить ее хоть вечно, что может помочь, если какой-то работник 3 месяца назад удалил очень важное, и только сейчас понял, насколько оно важное.
У нас для этих целей используется корпоративный web-диск (Seafile). Объемные файлы сохраняются туда, а по почте передается ссылка на загрузку. Учетные данные пользователей для доступа к корпоративной почте и web-диску хранятся в общем каталоге LDAP.
Или сейчас можно поднять почтовик+файлообменик чтобы туда скидывались вложения со сгенеренной на него ссылкой для скачки?
Перечитал внимательно комментарий. Идея действительно стоящая. Например вложения размером скажем 5МБ не прикрепляются к письму при отправке, а автоматически сохраняются в файлообменник, а в отравленном письме прикрепления заменяются на ссылки для скачивания. Интересно было бы посмотреть, если это где-то уже реализовано.
В почтовом клиенте Thunderbird это можно сделать с помощью плагина (FileLink Provider for OwnCloud and NextCloud) и Nextcloud. Также есть плагины для Seafile. Но как они работают не проверял.
в чем смысл использовать локальные почтовики
В том, что данные, хранящиеся не on-premise - не ваши данные
За идею спасибо, как направление для дальнейших мыслей полезно. Но для себя ещё несколько моментов отмечу (не говорю, что это всем нужно, но я бы сделал так):
всё-таки правильно, чтобы единой точкой раздачи пользователям прав был LDAP-сервер, т.е. лучше бы на нём создавать группу, а в конфиге dovecot уже давать членам этой группы доступ к общему ящику; на первый взгляд, это несложно сделать;
IMAP хорошо, но нужен ещё ActiveSync (а если общий ящик - это не только почта, то ещё и CalDAV / CardDAV) и веб-интерфейс. SoGo с LDAP-сервером общается отдельно, надо ещё с этим разобраться;
что-то надо делать и с SMTP, чтобы от имени info@ отправлять почту могли тоже только уполномоченные пользователи;
надо подумать, как реализовать autodiscover в такой схеме...
В общем это так, мысли вслух. У меня пока только общие папки, но общий ящик тоже полезно будет завести.
По 1 полностью согласен, memberof например. По 3 если smtp например postfix то sasl на dovecot и всё заработает автоматически вроде. Либо smtpd_sender_login_maps ЕМНИП
На статью надо смотреть как на "technology preview". Готовое решение уже можно по ходу докурить )
Насчет авторизации SMTPD -- все правильно, в нашем Postfix (от Iredmail(с)) именно так и сделано:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/dovecot-auth
virtual_transport = dovecot
По пункту 1 тут вообще на любителя. Конечно, самое технологичное -- все делать в LDAP, но немного стремно. Есть вероятность накосячить и случайно дать доступ к чужому личному ящику. Предложение от @aborouhin компромиссное, но тут придется рулить в двух местах одновременно: config+LDAP. По мне так не совсем удобно.
В целом благодарю за дельные советы.
Не эксперт, но кажется тут только читать почту можно, отправлять же не получится
Реализация с помощью masteruser
auth_master_user_separator = *
...
passdb {
args = /etc/dovecot/dovecot-ldap-shared.conf
driver = ldap
master = yes
result_success = continue
}
pass_filter = (&(objectClass=person)(sAMAccountName=%{auth_user})(memberof:1.2.840.113556.1.4.1941:=CN=Access %{login_username},OU=Shared,OU=Mail,OU=Security,DC=domain,DC=local)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
pass_attrs = userPassword=password
Соответственно на каждый общий ящик создаётся группа Access {mailbox}
и все её члены получат доступ к ящику с помощью входа {mailbox}*{samaccountname}
У нас везде используется авторизация по логину (samaccountname) но я думаю не сложно доработать для mail. Переменные все здесь https://doc.dovecot.org/configuration_manual/config_file/config_variables/#authentication-variables
Для отправки postfix, наверное можно запилить и LDAP, но у нас уже есть табличка в SQL для рассылок и нужно было разрешить некоторым отправлять от имени рассылки. Доработали табличку чтоб она работала для общих ящиков
smtpd_sender_login_maps =
...
proxy:mysql:/etc/postfix/sql_sender_login_maps.cf
query = SELECT allowed_sender FROM virtual_aliases WHERE alias='%s' AND ((NOW() BETWEEN `date_start` AND `date_end`) OR (`date_start` IS NULL AND `date_end` IS NULL) OR (`date_start` IS NULL AND NOW() <= `date_end`) OR (`date_end` IS NULL AND NOW() >= `date_start`)) AND `enabled`='1' AND `allowed_sender` IS NOT NULL;
В колонке alias полный mail адрес от которого разрешается отправлять, в колонке allowed_sender логин пользователя которому разрешается отправлять.
Dovecot: Работа с групповыми почтовыми ящиками под своим паролем