Как стать автором
Обновить

Комментарии 15

А может кто пояснить, в чем смысл использовать локальные почтовики с учетом что отправить то письмо с вложением больше 25 мб можно, только его никто не примет зачастую.
Или сейчас можно поднять почтовик+файлообменик чтобы туда скидывались вложения со сгенеренной на него ссылкой для скачки?
По работе просто вижу что отправляются сканы и по 250 мб и уменьшить эту информацию никак нельзя и такой информации довольно много.

в чем смысл использовать локальные почтовики

Если у вас например 1000-2000 ящиков, то своя почта может сэкономить вам уже значительные средства, по крайней мере если и так есть админ, которому вы уже платите зарплату. Ну и вся почта у вас, можете хранить ее хоть вечно, что может помочь, если какой-то работник 3 месяца назад удалил очень важное, и только сейчас понял, насколько оно важное.

Если мне надо повесить тяжелую полочку на акнер в бетон, то 2000 гвоздей мне тут не помогут никак.

У нас для этих целей используется корпоративный web-диск (Seafile). Объемные файлы сохраняются туда, а по почте передается ссылка на загрузку. Учетные данные пользователей для доступа к корпоративной почте и web-диску хранятся в общем каталоге LDAP.

Или сейчас можно поднять почтовик+файлообменик чтобы туда скидывались вложения со сгенеренной на него ссылкой для скачки?

Перечитал внимательно комментарий. Идея действительно стоящая. Например вложения размером скажем 5МБ не прикрепляются к письму при отправке, а автоматически сохраняются в файлообменник, а в отравленном письме прикрепления заменяются на ссылки для скачивания. Интересно было бы посмотреть, если это где-то уже реализовано.

В почтовом клиенте Thunderbird это можно сделать с помощью плагина (FileLink Provider for OwnCloud and NextCloud) и Nextcloud. Также есть плагины для Seafile. Но как они работают не проверял.

Спасибо за наводку, будем пробовать

Спасибо за статью )

Варианты с линком на файл (из того, что знаю):

  • nextcloud + nextcloud mail;

  • carbonio \ zimbra

Работают хорошо.Чуть надо приучиться логике, но работают.
Так же там есть руссификация, лично прописывал перевод на гитхабе.
Но давно не заглядывал.

в чем смысл использовать локальные почтовики

В том, что данные, хранящиеся не 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 логин пользователя которому разрешается отправлять.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории