LINUX.ORG.RU
ФорумAdmin

Простейшая почтовая система, которую при этом нельзя сделать


0

0

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

Собственно, появилась необходимость развернуть почтовую систему для небольшой фирмы. Была произведена базовая настройка Postfix + Dovecot, всё чудно работает, почта бегает, пользователи довольны. И вот чёрт меня дёрнул захотеть сделать из почтовой системы конфетку. И начались проблемы. В связи с этим и хочу поднять эту тему. В сети масса информации о настройках postfix, но практически нет ничего по поводу некоторых крайне полезных и подчас необходимых плюшек, которые я и опишу. Вкратце что хочется:

Хочется простую в использовании (для пользователя) почтовую систему с доступом откудаприспичитпользователю, но при этом максимально безопасным. Теперь конкретика по пожеланиям:

  1. У пользователя должен быть единый логин и пароль для SMTP и IMAP сервера, и должен быть один Maildir++ ящик на серваке.
  2. Почтовых адресов на пользователя может быть навешено сколько угодно, с каждого из них пользователь должен иметь возможность почту отправлять и почта для каждого из них должна складываться в единый Maildir++, закреплённый за пользователем.
  3. На SMTP и IMAP серваках авторизация должна быть по логину в TLS сессии внутри внутренней сети (192.168.0.х), при подключении же извне кроме логина и пароля клиент пользователя должен предоставить сертификат, иначе в соединении отказывать.
  4. Вся исходящая почта пользователя должна складываться в подпапочку его Maildir'а, дабы она была доступна из любого почтового клиента.
  5. Ну и наконец вся почта должна полностью надёжно бекапится.

Всё просто, разумно и ИМХО полностью необходимо для любой уважающей себя конторы. Как сделал это я:

  1. Dovecot выступает в качестве LDA и в качестве сервера аутентификации для Postfix, все домены обслуживаются через virtual_domains, все адреса для одного пользователя замапины на основной через virtual_alias_maps, а разрешение на отсылку через SMTP выдаётся после сверки по smtpd_sender_login_maps. Итого - задача решена полностью, единственная проблема - при коннекте через клиент (Thunderbird) если пользователь захочет отсылать почту с разных своих адресов ему надо будет вручную добавить несколько аккаунтов с одним логином, но разными адресами отправителя, все они будут смотреть в один и тот же maildir. Немного неудобно из-за дублирования одного и того же ящика, но это ограничение клиентов и его никак не побороть.
  2. Ну собственно см. п. 1 - проблема решена почти идеально.
  3. И Postfix, и Dovecot можно настроить на отказ в обслуживании при отсутствии у клиента правильного сертификата. Увы, сделать внутреннюю сеть свободной от требования сертификата по крайней мере в dovecot невозможно, а значит и в Postfix не будем пытаться, леший с ним. Хочу тогда чтобы почта ходила только если пользователь предоставил правильный сертификат и указал правильный логин и пароль. В конце концов раздать всем внутренним клиентам сети по сертификату можно, хоть и геморно. С Dovecot проблем не возникает. С Postfix же - напротив. Есть два разрешения в smtpd_recirient_restrictions - permit_sasl_authenticated и permit_tls_clientcerts. Первое разрешает отправку через SMTP почты залогиненным, второе - предоставившим правильный сертификат. Вопрос: как их объединить в одно? Чтобы разрешение выдавалось только если и залогинился, и предоставил сертификат. Итого - проблема открыта. Почему я хочу и сертификат и логин? Потому что сертификат легко украсть, и пользователь спокойно может залогиниться в кафешке и забыть выйти, как следствие ни сертификат, ни логин по отдельности от блондинок-пользователей не спасают, а вместе уже хоть что-то, надо постараться, чтобы пропалить и логин, и сертификат.
  4. Собственно вообще не знаю, как на постфиксе такое организовать. Теоретически всё просто до жути: почта от одного из адресатов из списка должна перед посылкой в внешний мир отсылаться так же в dovecot с пометкой положить в папочку out. При этом ещё надо не забыть про алиасы. На практике же я вообще не нашёл хоть какого-то решения столь простой и необходимой задачи.
  5. Бекап - узкое место maildir. Бекап по крону - не вариант, ибо надо гарантировать сохранность всех писем, а не только основной массы. Настраивать отдельные демоны для контроля изменений в директориях - сущий бред. Самый простой вариант - вместе с пересылкой на dovecot все письма пересылать на внутренний postfix сервак, который их тупо сложит у себя. Но тут проблема синхронизации. Ибо письма должны храниться в бекапе определённое время после удаления их пользователем из ящика, а не после их доставки. Ну да ладно, скрипт синхронизации наваяю. Итого - осталось понять, как распараллелить транспорт. То есть чтобы одно письмо одновременно отправлялось по двум транспортам. Этого я тоже не нарыл в документации к постфиксу.

В общем и целом, все мои пожелания не критичны, но с другой стороны крайне необходимы для нормальной почтовой системы. Поэтому буду благодарен любым направленным посылам в сторону полезной для решения поставленной проблемы информации. Да, postfix и dovecot - не панацея, выбраны были просто как одни из самых безопасных и стабильных.

> 3. На SMTP и IMAP серваках авторизация должна быть по логину в TLS сессии внутри внутренней сети (192.168.0.х), при подключении же извне кроме логина и пароля клиент пользователя должен предоставить сертификат, иначе в соединении отказывать.

так в чём проблема, запускаешь два postfix, один для локалки, один для внешней сети, каждый со своими настройками и каждый слушает свой интерфейс

http://www.postfix.org/postconf.5.html#inet_interfaces

On a multi-homed firewall with separate Postfix instances listening on the «inside» and «outside» interfaces, this can prevent each instance from being able to reach servers on the «other side» of the firewall. Setting smtp_bind_address to 0.0.0.0 avoids the potential problem for IPv4, and setting smtp_bind_address6 to :: solves the problem for IPv6.

A better solution for multi-homed firewalls is to leave inet_interfaces at the default value and instead use explicit IP addresses in the master.cf SMTP server definitions. This preserves the Postfix SMTP client's loop detection, by ensuring that each side of the firewall knows that the other IP address is still the same host. Setting $inet_interfaces to a single IPv4 and/or IPV6 address is primarily useful with virtual hosting of domains on secondary IP addresses, when each IP address serves a different domain (and has a different $myhostname setting).

pupok ★★
()



qmail-ldap+courier-imap+tcpserver

Зачем третий пункт - непонятно, другие mx сервера каким образом будут вам извне почту слать? Они с таким же успехом сделать вам и DoS и DDoS или вы и им сертификаты выпишите?

4. Это к почтовому клиенту, будет складывать на сервер - будут на сервере, не будет складывать - не будет на сервере.

5. Это вообще к почтовой системе не имеет отношения. Более того, чем вам не нравится Maildir - тоже непонятно.

zgen ★★★★★
()
Ответ на: комментарий от zgen

> Зачем третий пункт - непонятно, другие mx сервера каким образом будут вам извне почту слать?

для imap понятно зачем авторизация нужна, а для smtp — если конечный адресат локальный то клиенты/другие mx сервера могут коннектиться без авторизации, она нужна только для исходящей почты.

pupok ★★
()
Ответ на: комментарий от zgen

> 4. Это к почтовому клиенту, будет складывать на сервер - будут на сервере, не будет складывать - не будет на сервере.

он хочет как в gmail, там не спрашивают, и копии всех исходящих писем кладутся в «Sent», и не надо закачивать на сервер две копии одного и того же письма (одну по smtp, вторую по imap). В принципе удобно.

pupok ★★
()
Ответ на: комментарий от pupok

Именно. Я хочу как в гмыле. Ну то есть чтобы для пользователя моя система была как гмыло по функционалу))) Я не знаю, с какого клиента будут коннектиться пользователи, единственное что я знаю, что отправлять они почту будут через SMTP, а значит именно он должен обеспечивать сохранение исходящих.

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

Да, always_bcc и прочие bcc - это всего лишь пересылка почты на определённый адрес, а мне надо складывание в Maildir именно для каждого пользователя в свой ящичек.

Да, и с двумя серваками. В принципе это вариант, но всё равно надо объединить действие двух разрешений в одно, а вот это у меня уже не получается.

Malamut
() автор топика
Ответ на: комментарий от pupok

Хочет как в гмыле - поднимает roundcube в качестве web клиента, вешает imapd на localhost и все сразу супер.

zgen ★★★★★
()
Ответ на: комментарий от Malamut

«входящая почта на локальные ящики вообще не требует авторизации»=DoS, который вы не хотите по условию задачи.

а бекап - это всё же часть почтовой системы, ибо бекапим-то мы почту)))

С таким подходом - в сад.

zgen ★★★★★
()

При отправке из клиента, использующего IMAP, почта кладется в «Отправленные», а то, что нагорожено с кучей ящиков у одного пользователя - добавить кучу идентов (а не ящиков) для отсыли в почтовом клиенте.

Так же - правильно подметили на счет web-морды. https+клиентский сертификат+login :)

Marmirus ★★
()
Ответ на: комментарий от zgen

>> для smtp — если конечный адресат локальный то клиенты/другие mx сервера могут коннектиться без авторизации

И устроят ему DoS и DDoS, от которого он хочет избавиться.

именно так postfix настроен по умолчанию, когда smtpd вообще не принимает нелокальную исходящую почту, а входящая без авторизации. А как по-другому? Если кто-то посылает почту с gmail на vasya@mydomain, откуда mx.gmail.com узнает пароль для mx.mydomain? Мы должны разрешить входящую почту без авторизации, хотя конечно можно сделать дополнительную проверку чтобы например IP-шник mx.gmail.com имел reverse-DNS запись mx.gmail.com, но это не обязательно, и тот же gmail такой проверки не делает и принимает входящие соединения от всех желающих.

pupok ★★
()
Ответ на: комментарий от zgen

> Хочет как в гмыле - поднимает roundcube в качестве web клиента, вешает imapd на localhost и все сразу супер.

не web-морду как gmail, а smtp как в gmail. Повторюсь: если я локальным клиентом (alpine) отправляю почту через «smtp-server=smtp.gmail.com:587/tls/user=vasya@gmail.com», то я загружаю исходящее письмо в google только один раз через smtp, нет необходимости грузить тоже самое на «default-fcc={imap.gmail.com/ssl/user=vasya@gmail.com}Sent», google его туда скопирует автоматически, и это неотключаемо.

pupok ★★
()
Ответ на: комментарий от pupok

самому стало интересно,

в /etc/postfix/main.cf добавляем

sender_bcc_maps = regexp:/etc/postfix/sender_bcc

в /etc/postfix/sender_bcc пишем

/(.*)@.*/   ${1}+sentMailTag@mydomain.ru

в /etc/procmailrc пишем

SHELL=/bin/sh
:0
* ^Delivered-To:.*+sentMailTag@
$HOME/mail/sent-mail

минус — если какой-нибудь хакер узнает как называется таг «+sentMailTag» — он может посылать вам письма с доставкой в sent-mail folder а не в INBOX.

pupok ★★
()
Ответ на: комментарий от pupok

Лучше сделать по-другому: в /etc/postfix/sender_bcc пишем

/(.*)@.*/   ${1}@[127.0.0.1]
и пользователей просим прописать в $HOME/.procmailrc (можно и сразу в /etc/skel положить)
:0
* ^X-Original-To:.*@\[127.0.0.1\]
$HOME/mail/sent-mail
где «$HOME/mail/sent-mail» — файл в котором пользователь хранит исходящую почту. Если он этого не сделает или не отправит в «/dev/null», то исходящие сообщения просто будут дублироваться в INBOX. С «@[127.0.0.1]» уже никакие хакеры доступа к «sent-mail» иметь не будут.

pupok ★★
()
Ответ на: комментарий от pupok

> С «@[127.0.0.1]» уже никакие хакеры доступа к «sent-mail» иметь не будут.

нет, к сожалению будут — точно также можно соединяться к mx.mydomain.ru и посылать письмо vasya@«[127.0.0.1]» :(.

pupok ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.