Сегодня поговорим о почтовых серверах на Linux. Мы расскажем о том, как настроить сервер, о широко распространённом в интернете протоколе SMTP, а также о других протоколах, таких, как POP и IMAP. В итоге вы окажетесь обладателем полноценной системы для работы с электронной почтой.
Начнём с SMTP-сервера на Linux
SMTP-сервер
Протокол SMTP (Simple Mail Transfer Protocol) определяет правила пересылки почты между компьютерами, при этом, он не регламентирует правила хранения или визуализации сообщений. Это системно-независимый протокол, то есть, отправитель и получатель почты могут иметь различные ОС.
SMTP требует лишь чтобы сервер был способен отправлять обычный ASCII-текст другому серверу, используя порт 25, который является стандартным портом SMTP.
Сегодня в большинство дистрибутивов Linux встроены две наиболее распространённых реализации SMTP: sendmail и postfix.
Sendmail — это популярный почтовый сервер с открытым кодом, используемый во многих дистрибутивах Linux. К его минусам можно отнести несколько усложнённую архитектуру и недостаточно высокий уровень защиты.
Postfix — система немного более продвинутая, при разработке этого почтового сервера особое внимание было уделено вопросам безопасности.
Компоненты почтовой службы
Типичная почтовая служба состоит из трёх основных компонентов:
Почтовый клиент, который ещё называют почтовым агентом (Mail User Agent, MUA). Именно с ним взаимодействует пользователь, например — это почтовые клиенты Thunderbird или Microsoft Outlook. Они позволяют пользователю читать почту и писать электронные письма.
Почтовый сервер, или агент пересылки сообщений (Mail Transport Agent, MTA). Этот компонент ответственен за перемещение электронной почты между системами, этим занимаются, например, Sendmail и Postfix.
Агент доставки электронной почты (Mail Delivery Agent, MDA). Этот компонент ответственен за распределение полученных сообщений по почтовым ящикам пользователей. Например, это Postfix-maildrop и Procmail.
Установка почтового сервера
Для настройки нашего сервера был выбран пакет Postfix. Это — популярный среди системных администраторов выбор, стандартный почтовый сервер в большинстве современных дистрибутивов Linux.
Начнём, проверив, установлен ли Postfix в системе:
$ rpm -qa | grep postfixЕсли обнаружить Postfix не удалось, установить его, например, в дистрибутивах, основанных на Red Hat, можно с помощью такой команды:
$ dnf -y install postfixЗатем запустим службу postfix и организуем её автозапуск при загрузке системы:
$ systemctl start postfix
$ systemctl enable postfixВ дистрибутивах, основанных на Debian, вроде Ubuntu, установить Postfix можно так:
$ apt-get -y install postfixВ ходе установки будет предложено выбрать конфигурацию сервера. Среди доступных четырёх вариантов (No configuration, Internet site, Internet with smarthost, Satellite system and Local only), мы выберем No configuration, что приведёт к созданию необходимых Postfix учётных записей пользователя и группы.
Настройка сервера
После установки почтового сервера Postfix, его нужно настроить. Большинство конфигурационных файлов находятся в директории /etc/postfix/.
Главный конфигурационный файл Postfix можно найти по адресу /etc/postfix/main.cf. Здесь имеется множество параметров, рассмотрим самые важные.
myhostname
Этот параметр используется для указания имени хоста почтовой системы. Это — имя хоста в интернете, для которого Postfix будет получать почту.
Типичные примеры имён хостов почтовых серверов — mail.example.com и smtp.example.com.
Настраивают этот параметр так:
myhostname = mail.example.commydomain
Эта настройка позволяет указать почтовый домен, обслуживанием которого занимается сервер, например — example.com:
mydomain = example.commyorigin
Этот параметр позволяет указать доменное имя, используемое в почте, отправленной с сервера. Присвоим ему значение $mydomain:
myorigin = $mydomainВ настройках можно ссылаться на параметры, добавляя знак
$ перед именем переменной.mydestination
Этот параметр содержит список доменов, которые сервер Postfix будет считать конечными пунктами назначения для входящей почты.
В нашем случае здесь будут имя хоста сервера и доменное имя, но данный параметр может содержать и другие имена:
mydestination = $myhostname, localhost.$mydomain, $mydomain, mail.$mydomain, www.$mydomainmail_spool_directory
Почтовый сервер Postfix может использовать два режима доставки почты:
- Непосредственно в почтовый ящик пользователя.
- В центральную директорию очередей, при этом почта попадает в папку /var/spool/mail, где имеется файл для каждого пользователя.
mail_spool_directory = /var/spool/mailmynetworks
Эта переменная — важный параметр настройки. Она позволяет указывать то, какие сервера могут пересылать почту через сервер Postfix.
Обычно разрешают передачу почты только от локальных клиентских компьютеров. В противном случае вашим сервером могут заинтересоваться спамеры.
Если неправильно настроить параметр mynetworks, спамеры вполне смогут воспользоваться сервером как ретранслятором почты. Это очень быстро приведёт к тому, что какая-нибудь система борьбы со спамом поместит его в один из чёрных списков, вроде DNS Blacklist (DNSBL), или Realtime Blackhole List (RBL). Как только сервер попадёт в подобный список, очень немногие смогут получить письма, отправленные с его помощью.
Вот как может выглядеть настройка этого параметра:
mynetworks = 127.0.0.0/8, 192.168.1.0/24smtpd_banner
Эта переменная позволяет задать ответ, который возвращает сервер при подключении клиентов.
Лучше всего поменять это значение так, чтобы оно не указывало на то, какой именно используется почтовый сервер.
inet_protocols
Эта переменная позволяет задавать версию IP, которую будет использовать Postfix при установлении соединений.
inet_protocols = ipv4Для того, чтобы изменения, внесённые в конфигурационные файлы, вступили в силу, службу Postfix надо перезагрузить:
$ systemctl reload postfixНа самом деле, в конфигурационном файле Postfix можно ещё много чего настроить. Например — управлять уровнями безопасности, задавать опции отладки и другие параметры.
Возможно, настраивая сервер, вводя значения параметров, вы допустите ошибку. Проверить правильность настроек можно с помощью такой команды:
$ postfix checkС помощью этого средства можно найти строку, в которой допущена ошибка, и исправить её.
Проверка очереди сообщений
Иногда очередь почтовых сообщений переполняется. Это может быть вызвано множеством факторов, вроде сетевой ошибки, или по любой причине, способной задержать отправку почты.
Для того чтобы проверить очередь сообщений, воспользуйтесь такой командой:
$ mailqОна выведет сообщения, находящиеся в очереди. Если очередь переполнена и на отправку сообщения уходит по несколько часов, можно инициировать процесс отправки сообщений такой командой:
$ postfix flushЕсли теперь проверить очередь, она должна оказаться пустой.
Тестирование почтового сервера
После настройки сервера на Postfix, его надо протестировать. Первый шаг в тестировании — использование локального почтового клиента, вроде mailx или mail (это — символьная ссылка на mailx).
Попробуйте отправить письмо кому-нибудь, чей адрес обслуживается на том же сервере, а если это сработает — отправьте письмо на адрес, который находится где-нибудь ещё.
$ echo "This is message body" | mailx -s "This is Subject" -r "likegeeks<likegeeks@example.com>" -a /path/to/attachment someone@example.comЗатем попробуйте принять письмо, отправленное с другого сервера.
Если вы столкнётесь с проблемами — проверьте логи. В дистрибутивах, основанных на Red Hat, то, что вам надо, можно найти по адресу /var/log/maillog. В Debian-дистрибутивах нужный файл можно найти здесь: /var/log/mail.log, или же по пути, заданному в настройках rsyslogd. Вот, если нужно, материал о логировании в Linux, и о том, как настраивать rsyslogd.
Если проблемы всё ещё не решены, попытайтесь проверить настройки DNS, взгляните на MX-записи, используя сетевые команды Linux.
Борьба со спамом
Существует немало решений для выявления среди почтовых сообщений нежелательных писем — спама. Одно из лучших — проект с открытым исходным кодом SpamAssassin.
Установить его можно так:
$ dnf -y install spamassassinЗатем надо запустить соответствующую службу и добавить её в автозагрузку:
$ systemctl start spamassassin
$ systemctl enable spamassassinПосле установки SpamAssassin, взгляните на его настройки в файле /etc/mail/spamassassin/local.cf.
SpamAssassin умеет отличать обычные письма от спама, основываясь на результатах исследования корреспонденции с помощью различных скриптов. Результаты проверок оцениваются в баллах.
Чем выше итоговая оценка письма — тем выше и вероятность того, что оно является спамом.
В конфигурационном файле параметр required_hits 5 указывает на то, что SpamAssassin пометит сообщение как спам, если его рейтинг составляет 5 или выше.
Параметр report_safe принимает значения 0, 1, или 2. Установка его в 0 означает, что письма, помеченные как спам, пересылаются в исходном виде, но их заголовок модифицируется с указанием на то, что они являются спамом.
Если этот параметр установлен в значение 1 или 2, SpamAssassin сгенерирует отчёт и отправит его получателю.
Разница между значениями 1 и 2 заключается в том, что в первом случае спам-сообщение будет закодировано в формате message/rfc822, а во втором — в формате text/plain.
Кодирование text/plain безопаснее, так как некоторые почтовые клиенты исполняют сообщения формата message/rfc822, что при определённых условиях может привести к заражению клиентского компьютера вирусом.
После установки и настройки SpamAssassin, нужно интегрировать его с Postfix. Пожалуй, легче всего это сделать с помощью использования procmail.
Создадим файл /etc/procmailrc и добавим в него следующее:
:0 hbfw
| /usr/bin/spamc Затем отредактируем файл настроек Postfix — /etc/postfix/main.cf, задав параметр mailbox_command следующим образом:
mailbox_command = /usr/bin/procmailИ, наконец, перезапустим службы Postfix и SpamAssassin:
$ systemctl restart postfix
$ systemctl restart spamassassinНадо сказать, что SpamAssassin не всегда распознаёт спам, что ведёт к наполнению почтовых ящиков ненужными письмами.
К счастью, сообщения, прежде чем они достигнут почтового сервера на Postfix, можно фильтровать, используя Realtime Blackhole Lists (RBLs). Это снизит нагрузку на почтовый сервер и поможет сохранить его в чистоте.
Откройте конфигурационный файл Postfix /etc/postfix/main.cf, измените параметр smtpd_recipient_restrictions и настройте другие параметры следующим образом:
strict_rfc821_envelopes = yes
relay_domains_reject_code = 554
unknown_address_reject_code = 554
unknown_client_reject_code = 554
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 554
unknown_relay_recipient_reject_code = 554
unverified_recipient_reject_code = 554
smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client dsn.rfc-ignorant.org,
reject_rbl_client dul.dnsbl.sorbs.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net,
permit Затем перезагрузите сервер Postfix:
$ systemctl restart postfixВышеприведённые чёрные списки используются чаще всего, но вы можете найти и другие подобные сервера.
Защита SMTP-соединения
Лучше всего передавать SMTP-трафик по TLS для защиты его от атаки через посредника.
Для начала нужно сгенерировать сертификат и ключ с использованием команды openssl:
$ openssl genrsa -des3 -out mail.key
$ openssl req -new -key mail.key -out mail.csr
$ cp mail.key mail.key.original
$ openssl rsa -in mail.key.original -out mail_secure.key
$ openssl x509 -req -days 365 -in mail_secure.csr -signkey mail_secure.key -out mail_secure.crt
$ cp mail_secure.crt /etc/postfix/
$ cp mail_secure.key /etc/postfix/Затем надо добавить в файл настроек Postfix /etc/postfix/main.cf следующее:
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/mail_secure.crt
smtpd_tls_key_file = /etc/postfix/mail_secure.key
smtp_tls_security_level = mayИ, наконец, нужно перезагрузить службу Postfix:
$ systemctl restart postfixТеперь, при подключении клиента к серверу, нужно выбрать TLS. Тут вы, при первой отправке почты после изменении настроек, увидите предупреждение, так как сертификат не подписан.
Основы протоколов POP3 и IMAP
Итак, мы наладили процесс отправки и получения электронных писем по SMTP, но на этом организация полноценной почтовой службы не заканчивается. Рассмотрим следующие ситуации:
- Пользователям нужны локальные копии электронных писем для их просмотра без подключения к интернету.
- Почтовые клиенты пользователей не поддерживают формат файлов mbox. Это — простой текстовый формат, который могут читать многие консольные почтовые клиенты, вроде mailx и mutt.
- Пользователи не могут постоянно пользоваться быстрым подключением для доступа к файловой системе сервера и для работы с mbox-файлами, в итоге нужно сделать локальную копию для работы с ними без подключения к сети.
- Ограничения безопасности указывают на то, чтобы у пользователей не было прямого доступа к шлюзу электронной почты, например, не допускается работа с общедоступными папками очередей сообщений.
Для того, чтобы учесть все эти особые случаи, были созданы другие протоколы. Их можно описать как протоколы для доступа к электронной почте.
Сильнее всего распространены два популярных протокола доступа к почте — POP (Post Office Protocol), и IMAP (Internet Message Access Protocol).
В основе POP лежит очень простая идея. Центральный почтовый сервер на Linux всё время подключён к интернету, он получает и сохраняет письма для всех пользователей. Все полученные письма остаются в очереди на сервере до тех пор, пока пользователь не подключится к нему по протоколу POP и не загрузит письма.
Когда пользователь хочет отправить письмо, почтовый клиент обычно передаёт его через центральный сервер по SMTP.
Обратите внимание на то, что SMTP-сервер и POP-сервер могут без проблем работать на одной и той же машине. В наши дни это — обычная практика.
Возможности, вроде хранения исходных экземпляров писем пользователей на сервере с хранением на клиенте лишь кэшированных копий, в POP отсутствуют. Это привело к разработке протокола IMAP.
Используя IMAP, сервер будет поддерживать три режима доступа к почте:
- Онлайн-режим похож на прямой доступ к файловой системе на почтовом сервере.
- Оффлайн-режим похож на то, как работает POP, когда клиент отключается от сети после получения своих писем. В этом режиме сервер обычно не хранит копии писем.
- Автономный режим позволяет пользователям хранить кэшированные копии своих писем, а сервер так же хранит копии этих писем.
Существуют различные реализации IMAP и POP, в этой сфере весьма популярен сервер Dovecot, который позволяет работать с обоими протоколами.
Сервера POP3, POP3S, IMAP, и IMAPS слушают, соответственно, порты 110, 995, 143, и 993.
Установка Dovecot
Большинство дистрибутивов Linux содержат предустановленный Dovecot, однако, его можно установить и самостоятельно. В системах, основанных на Red Hat, это делается так:
$ dnf -y install dovecotВ системах, основанных на Debian, функционал IMAP и POP3 предоставляются в двух разных пакетах:
$ apt-get -y install dovecot-imapd dovecot-pop3dТут вам предложат создать самозаверенный сертификат для работы с IMAP и POP3 по SSL/TLS. Ответьте на вопрос yes и, при появлении соответствующего запроса, введите имя хоста вашей системы.
Затем можно запустить соответствующую службу и добавить её в автозагрузку:
$ systemctl start dovecot
$ systemctl enable dovecotНастройка Dovecot
Главный файл настроек Dovecot расположен по адресу /etc/dovecot/dovecot.conf. В некоторых дистрибутивах Linux этот файл размещается в папке /etc/dovecot/conf.d/ и, для подключения файлов настроек, используется директива include.
Вот некоторые из параметров, используемых для настройки Dovecot.
protocols: протоколы, которые надо поддерживать.
protocols = imap pop3 lmtpЗдесь lmtp означает Local Mail Transfer Protocol. listen: IP-адрес, который будет слушать сервер.
listen = *, ::Здесь звёздочка означает все интерфейсы IPv4, двойное двоеточие означает все интерфейсы IPv6.
userdb: база данных пользователей для аутентификации.
userdb {
driver = pam
}
mail_location: это запись в файле /etc/dovecot/conf.d/10-mail.conf. Выглядит она так:
mail_location = mbox:~/mail:INBOX=/var/mail/%uDovecot поставляется со стандартными SSL-сертификатами и файлами ключей, которые используются в файле /etc/dovecot/conf.d/10-ssl.conf.
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pemКогда пользователь пытается подключиться к Dovecot, сервер покажет предупреждение, так как сертификаты не подписаны. Если нужно, подписанные сертификаты можно приобрести в подходящем центре сертификации.
Не забудьте открыть порты сервера Dovecot на файрволе.
$ iptables -A INPUT -p tcp --dport 110 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 995 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 143 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 993 -j ACCEPTИ про SMTP-порт не забудьте.
$ iptables -A INPUT -p tcp --dport 25 -j ACCEPTЗатем сохраните правила. Если хотите освежить в памяти особенности работы с iptables в Linux, взгляните на этот материал.
Или, если вы используете firewalld, можете поступить так:
$ firewall-cmd --permanent --add-port=110/tcp --add-port=995
$ firewall-cmd --permanent --add-port=143/tcp --add-port=993
$ firewall-cmd --reloadА, если что-то пошло не так, посмотрите лог-файлы /var/log/messages, /var/log/maillog, и /var/log/mail.log.
Итоги
Теперь вы можете настроить почтовую службу на своём Linux-сервере. Как видите, много времени это не займёт. Конечно, у рассмотренных здесь пакетов, вроде Postfix, уйма настроек, но если вы освоили описанную здесь последовательность действий и разобрались с основами, то всё, что вам понадобится, несложно будет выяснить из документации.
Уважаемые читатели! А как вы настраиваете почтовые сервера на Linux?
Комментарии (80)
linjan
31.03.2017 16:42+13В статье не хватает упоминания о настройке SPF, DKIM, DMARC, FBL без которых жизнь почтового сервера в современном мире почти невозможна — добавьте хотя бы ссылки. В раздел Итоги прекрасно бы вписался mail tester.
iwonz
31.03.2017 17:25+3Поддерживаю! Сам сталкивался когда с настройкой, не раз убеждался, что сам сервер поднять до рабочего состояния не так и сложно, а вот учесть всё необходимое, чтобы получить 10 из 10 — сложновато.
xenon
31.03.2017 23:32Мало того, чтобы он взлетел, мало того чтоб тест выдал хороший результат. Непредвиденные (и невидимые) вещи часто бывают такими важными, именно потому, что они непредвиденные.
Случай из недавнего. Запустили грейлистинг на почтовике, давно уже. Все отлично работает. Тут один клиент говорит, что к нему письма очень долго идут, дает примеры. Смотрим логи — о, и правда! Оказывается, домен с которого шли письма имеет много серверов для исходящей почты, и шлют каждый раз разные, поэтому грейлистинг считает, что это новые сервера и заворачивает их. Мы этот фактор не учитывали, когда ставили грейлистинг.
У postgrey есть два решения на этот случай. Первое — белый список. Мы внесли тот домен в белый список и проблема решена. Но решена — через несколько лет, после того как мы запустили его! (Никто не жаловался, и нам все выглядело хорошо).
Второе решение — он считает сервер «одним и тем же» если совпадают 3 первых октета IPv4 адреса. Так что, такой проблемы не должно быть если все рассыльщики в одной Class C сети. Но… во-первых у крупных компаний они в разных сетях. И во вторых, мы по логами видели — что у нас вроде он сконфигурирован как должен, но тем не менее были две попытки из одной /24 подсети, и он вторую не принял почему-то (вопреки документации и ручным тестам).
Пока мы этого не видели — спали спокойно. Сейчас увидели — и приходится и ручками его тестить и в сорцы лезть и скрипты для анализа лога писать, чтобы эту чертовщину отловить.
Так что по гайду — можно сделать, но будет как китайский шуруповерт — вроде работает. А для долгой работы — нужно не только чтобы «вроде работал», а быть твердо уверенным что все возможные проблемы исключены, а для этого гайд не поможет, тут и тестить надо, и мониторить и даже в сорцы лазить иногда.
cebka
01.04.2017 15:44Вот поэтому в Rspamd делается грейлистинг не только по ip/mask (по дефолту /19), но и по содержимому письма. Иначе всякие gmail могут слать даже из разных Class A сетей.
ClausMark
31.03.2017 21:34Да, это было бы отличным дополнением. Думаю, рассказ об этих вещает заслуживает отдельной статьи.
ideological
31.03.2017 16:47Я понимаю что это перевод и спасибо за него.
Однако у автора статьи я бы спросил как он относится к iRedMail и почему он не упомянул хотя бы кратко DKIM?
zuek
31.03.2017 16:50+5Помимо SPF и прочих бантиков, упомянутых выше, по-моему, идея использования самоподписанного сертификата на публичном почтовике — не самый правильный совет. Да и RBL за последние годы изрядно себя дискретитировали…
Я бы не рекомендовал бы никому данную статью в качестве инструкции по настройке почтового сервера (в том числе и по причине неполноты описания связки SELinuix+SpamAssassin+Postfix).ildarz
31.03.2017 17:49+1идея использования самоподписанного сертификата на публичном почтовике — не самый правильный совет.
На коннекторе, который отправляет почту в инет или принимает её оттуда, можно любой сертификат использовать, потому что он применяется исключительно в целях шифрования канала, а не для проверки подлинности клиента или сервера. Вот если тот же коннектор используется и для аутентифицированного трафика (подключение клиентов, например), там уже могут быть вопросы.
xenon
31.03.2017 23:34При наличии бесплатного и удобного Lets Encrypt — разве есть смысл в самоподписных?
Даже если мы не возлагаем серьезных задач по проверке подлинности на него, все равно этот милый бонус очень приятен, если забесплатно.ildarz
03.04.2017 10:53+1Смысл есть как минимум в понимании того, какой сертификат для чего используется, и какими свойствами (исходя из своего предназначения) он должен обладать. Когда такое понимание есть, пусть человек уже сам решает, какой вариант выбрать. А когда выбор делается просто из соображений "ну так в гайде написано" или "в комментах на хабре написали, что некошерно" — это не есть хорошо.
Что же до конкретно Lets Encrypt — у меня к этому смешанное отношение. Идея менять сертификаты раз в пару месяцев при отсутствии стандартных средств автоматизации этого процесса мне не очень нравится.
grossws
03.04.2017 13:44А каких средств автоматизации для этого вам не хватает? Certbot (или любая другая реализация acme protocol) + crond/systemd.timer прекрасно справляются с этой задачей.
ildarz
03.04.2017 15:36Мне всего хватает. У нас, вероятно, немного различные представления о прекрасном и разное мнение об осмысленности форсирования выдачи сертификатов с таким сроком действия, а такая дискуссия явно не для этой ветки.
madest92
31.03.2017 17:25+1Одно из лучших — проект с открытым исходным кодом SpamAssassin.
Очень старый проект, последняя версия которого вышла аж в 2015. Сейчас набирает популярность Rspamd, который активно развивается. Работает в разы быстрее и лучше SpamAssassin.
icCE
31.03.2017 19:12Кстати, а как там Dspam ?
Давно просто не поднимал почтовые сервера.madest92
31.03.2017 20:09DSPAM работает только с телом сообщения, чего не всегда хватает. Хочется проверять еще заголовки, dkim/spf/dmark, спам базы, сколько писем уже пришло с этого ip(настройка рейтлимитов) и прочие параметры.
К Rspamd можно прикрутить антивирус для проверки вложений, что так же является плюсом. Но больше всего радует его скорость работы
Плюс он легко маштабируется и имеет вебку для просмотра статистики(раньше скриптовать приходилось).
Благодаря Rspamd удалось большую часть работы по обработки сообщений переложить на него. Exim+dovecot лишь принимают/кладут письма.
vlad49
01.04.2017 09:32Для того, чтобы антиспам работал более-менее адекватно, требуется его постоянное обучение и администрирование, что для небольшого сервера может быть проблемой. Поэтому очень важно наличие общей глобальной базы спама, с которой антиспам бы сверялся либо в онлайне, либо выгружал обновления каждые 5-10 минут. Есть ли подобные свободные решения? Пока попадались только коммерческие.
cebka
01.04.2017 15:49Проект Rspamd бесплатно предоставляет базу хешей спама: https://rspamd.com/doc/modules/fuzzy_check.html, которая включена по умолчанию. Bayes статистика — это слишком, скажем так, личная вещь, которую очень сложно сделать универсальной для всех языков и всех пользователей.
cebka
01.04.2017 15:47Я бы еще отметил такие вещи, которые многим оказываются полезными, как dkim подпись и встроенная работа с исходящими сообщениями, а также ответами. Ну и различные современные средства машинного обучения и анализа потоков почты.
ChiefPilot
31.03.2017 17:54-1Хорошо бы ещё и прикручивание антивируса добавить, чтобы уже совсем более-менее полный комплект получился. Спасибо!
kt97679
31.03.2017 18:27Коллеги, а кто как защищает postfix от флуда клиентов? Я пробовал использовать smtpd_client_connection_rate_limit = 600 но исходя из того, что я вижу, эта установка не сильно помогает.
mxms
31.03.2017 18:45-1две наиболее распространённых реализации SMTP: sendmail и postfix
Ога. Только почему-то доля Exim в сети превышает суммарную долю их обоих примерно раза в 2.
EvgenT
31.03.2017 20:12-2Итак, мы наладили процесс отправки и получения электронных писем по SMTP,
О как. Так что же мы настроили по SMTP?
CaptainFlint
31.03.2017 20:38А я не понял, что такое параметр mynetworks, можете рассказать поподробнее? Что такое «пересылка»? То же, что и отправка, или что-то другое? Если я на сервере поднял SMTP и пытаюсь с его помощью отправить почту со своего локального компа через почтовый клиент, значит ли это, что мне надо добавлять свой IP в список доверенных в mynetworks?
icCE
31.03.2017 21:31+1Можно начать читать с
http://www.postfix.org/postconf.5.htmlCaptainFlint
31.03.2017 22:46Первым же делом туда полез, только там тоже ничего не понял. Мануал лишь усилил ощущение, что здесь должны быть перечислены разрешённые адреса для любых коннектов извне, но если так, то это противоречит информации в посте о том, что публичный доступ к SMTP-серверу крайне опасен, его тут же захавают спамлисты и вообще. Как им тогда предполагается пользоваться — вносить в список все адреса, с которых я когда-либо могу захотеть отправить почту? И перед каждой поездкой в другой город или страну надо изучать, какие там провайдеры и какие у них диапазоны адресов, чтобы их тоже заранее разрешить?
icCE
31.03.2017 23:07Ну в общем по фразе
The list of «trusted» remote SMTP clients that have more privileges than «strangers».
In particular, «trusted» SMTP clients are allowed to relay mail through Postfix. See the smtpd_relay_restrictions parameter description in the postconf(5) manual.
итд
и примеру
mynetworks = 127.0.0.0/8 168.100.189.0/28
примерно становится очевидно.
Если коротко — то mynetworks = 127.0.0.0/8 это все, что там нужно.
Есть книга по postfix которую советую купить и почитать.
— За исключением тех случаев, когда вы по какойто странной причине
хотите разрешить некоторым пользователям Интернета использовать
ваш Postfixсервер в качестве ретранслятора (см. главу 16), вам следу
ет ограничить ретрансляцию интерфейсом локальной сети и интер
фейсом обратной связи (loopback) в файле main.cf. Покажем, как это
можно сделать для частной сети 192.168.0.0/24:
mynetworks = 192.168.0.0/24, 127.0.0.0/8
—CaptainFlint
31.03.2017 23:18Ну, то есть, как я и спрашивал с самого начала: ретрансляция — это что-то особенное, и это не то, что происходит, когда мой почтовик подключается к SMTP-серверу для отправки почты, правильно?
P.S. Я пока не планировал настраивать свой почтовик, поэтому глубоко вдаваться в детали не было намерения. Но какое-то самое общее представление хочется получить.icCE
31.03.2017 23:27Все зависит от задач.
Например у вас может быть внешний шлюз для почты, но почту он пересылает от другого почтового сервера, который например находится в DMZ зоне. Это может быть группа серверов итд итп.
Просто при непонимании процесса, можно легко сделать open relay :)CaptainFlint
01.04.2017 00:42Немного погуглил на эту тему — теперь у меня полная каша в голове. :-( Распишу, что я понял, и прошу поправить, если где ошибся.
Предположим, у меня задача отказаться от яндекса/гмыла и настроить свою собственную почтовую систему на своём VPS со своим доменом. Чтобы я мог в почтовике указать smtp.mydomain.com и отправлять любую почту, как делаю сейчас со своим гмыловским ящиком. Из гуглежа я понял, что ретрансляция — это приём и пересылка любых писем, направленных на домен, отличный от «родного» для текущего SMTP-сервера. То есть, в моём случае все письма, кроме тех, у которых адресат на mydomain.com, будут считаться ретрансляционными, и чтобы они были корректно доставлены, мне необходимо разрешить ретрансляцию в своём SMTP-сервере, причём в mynetworks прописать 0.0.0.0, потому что я не знаю заранее, на каком IP-адресе будет сидеть мой компьютер в тот момент, когда мне понадобится отправить почту. То есть, фактически, сделать open relay, чего категорически рекомендуется ни в коем случае не делать.
Вопросы:
1. Правильно ли я уяснил ситуацию? Если да, то как разрешить противоречие из последнего предложения?
2. Являются ли SMTP-серверы smtp.yandex.ru и smtp.gmail.com открытыми ретрансляторами? Или не открытыми? Я же могу через них отправлять почту на любой другой домен.
3. Бывают ли не-открытые ретрансляторы? Если я сделают открытый ретранслятор и добавлю какую-нибудь авторизацию (как на тех же гмылояндексах), будет ли это нормальной конфигурацией, не порицаемой общественно и не рискующей вляпаться в спамлисты?icCE
01.04.2017 18:34+1У вас полная каша в голове. Советую просто сесть и расписать, что происходит с письмом от одного клиента к другому и какие цепи он проходит.
Вы в MX записи можете указать любой сервер, который готов вашу почту ПРИНЯТЬ!
Его имя может быть вообще вася_пупкин.рф.
Описание openrelay вполне нормально написано на вики
https://en.wikipedia.org/wiki/Open_mail_relay
P.S. Yandex может пересылать почту для вашего домена, после того, как вы пропишите MX сервера yandex/google и кто там еще дает почту для доменов.CaptainFlint
01.04.2017 23:23У вас полная каша в голове. Советую просто сесть и расписать, что происходит с письмом от одного клиента к другому и какие цепи он проходит.
Так я же и написал, что при самостоятельных попытках разобраться я получил кашу. Как я сяду и распишу, если ни шиша не понимаю, что вообще происходит, и не уверен даже, что самая базовая базовая терминология обозначает то, что я думаю она обозначает.
Описание openrelay вполне нормально написано на вики
И это, и все прочие описания, которые мне попадались, слишком абстрактные. Я пока не нашёл ни одного внятного объяснения, что к чему подключается, что как называется и что как для этого должно быть настроено. Либо самые общие сведения «для домохозяек», либо, наоборот, зубодробительные подробности с кучей невнятных и необъясняемых терминов, без единого примера.
https://en.wikipedia.org/wiki/Open_mail_relay
P.S. Yandex может пересылать почту для вашего домена, после того, как вы пропишите MX сервера yandex/google и кто там еще дает почту для доменов.
Именно так у меня сейчас и сделано. Меня как раз интересует, что надо делать, если я захочу полностью отказаться от Яндекса и поднять свою инфраструктуру.icCE
02.04.2017 01:42+1>либо, наоборот, зубодробительные подробности с кучей невнятных и необъясняемых терминов, без единого примера.
Делайте свою лабу и начинайте смотреть в ней как все работает.
Термины всегда можно спросить или посмотреть их значение.
>Меня как раз интересует, что надо делать, если я захочу полностью отказаться от Яндекса и поднять свою инфраструктуру.
Не воспринимайте как издевательство но:
Чтение документации и попытка разобраться во всей этой чехарде.
Можете начинать изучать курсы LPI-1 и LPI-2. Во втором как раз про почту вроде.
Да и книгу про postfix заодно и про dns/bind.
P.S. Удивительно, но сейчас при доступном интернете, литературу, видео — курсов и вообще учебном материале — люди умудряются не изучать? Остается только задать вопрос самому себе, как же мы все это настраивали лет так 20 назад?CaptainFlint
02.04.2017 03:02-2Интересно, когда у вас спрашивают, сколько сейчас времени, вы отправляете в мануалы по компасу, секстанту и географии, чтобы спрашивающий сам определил время по положению солнца? Я же говорил, что у меня нет задачи поднимать свой сервер и досконально во всём разбираться. Просто возникла конкретная мелкая непонятка по конкретной статье. Фиг с ней, раз такое дело, перебьюсь как-нибудь.
grossws
03.04.2017 02:33+1Посмотрите в документацию, там всё нормально описано: http://www.postfix.org/BASIC_CONFIGURATION_README.html#relay_from:
By default, Postfix will forward mail from clients in authorized network blocks to any destination. Authorized networks are defined with the mynetworks configuration parameter. The current default is to authorize the local machine only. Prior to Postfix 3.0, the default was to authorize all clients in the IP subnetworks that the local machine is attached to.
… snip…
By default, Postfix will forward mail from strangers (clients outside authorized networks) to authorized remote destinations only. Authorized remote destinations are defined with the relay_domains configuration parameter. The default is to authorize all domains (and subdomains) of the domains listed with the mydestination parameter.Почта от клиентов из авторизованной сети отправляется на любой адрес, от "чужаков" — только на
relay_domains. Если хочется иного, то смотрим далее в http://www.postfix.org/SASL_README.html:
SMTP servers need to decide whether an SMTP client is authorized to send mail to remote destinations, or only to destinations that the server itself is responsible for. Usually, SMTP servers accept mail to remote destinations when the client's IP address is in the "same network" as the server's IP address.
SMTP clients outside the SMTP server's network need a different way to get "same network" privileges. To address this need, Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it "same network" privileges.Что обычно в том или ином варианте происходит на smtp серверах различных провайдеров. Пользователь должен авторизоваться, чтобы отправить почту наружу с данного сервера. Плюс делается ограничение на то, чтобы пользователь мог отправить почту только от своего имени, но не от имени соседнего Васи Пупкина.
Вам это взрывает мозг? Мне, честно, не очень понятно, что тут сложного? Если язык — то эти readme/howto уже десяток-другой раз переводили. От версии к версии там отличия минорные.
CaptainFlint
03.04.2017 15:36Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it «same network» privileges.
ВОТ ОНО! Мне это не могло взрывать мозг просто по той причине, что вплоть до этого момента у меня не было этого кусочка информации, и я безуспешно пытался его получить (не зная, что мне нужен именно он). Непонятно, почему в моих поисках оно мне ни разу не попалось (наоборот, были статьи, где утверждалось, что SMTP принципиально не поддерживает аутентификацию — видимо, устаревшая инфа), но наличие аутентификации, которая перекидывает клиента в список доверенных, всё переворачивает с головы на ноги.
Спасибо за объяснение.grossws
03.04.2017 15:41Непонятно, почему в моих поисках оно мне ни разу не попалось (наоборот, были статьи, где утверждалось, что SMTP принципиально не поддерживает аутентификацию — видимо, устаревшая инфа), но наличие аутентификации, которая перекидывает клиента в список доверенных, всё переворачивает с головы на ноги.
Не знаю, где вы искали информацию, касающуюся SMTP. У меня складывается впечатление, что в статьях, подобных этой.
Т. к. если бы вы заглянули в RFC4954 или просто загуглили smtp auth, то наткнулись бы на ту же википедию в первых трёх ссылках.
CaptainFlint
03.04.2017 15:58Искал в гугле и да, ориентировался именно на статьи типа этой, чтобы были достаточно дружественными к человеку, который ни разу в жизни не поднимал почтовик (да и не собирается пока этого делать). RFC в эту категорию, увы, не попадают. Мне их тяжело читать, даже когда они по тематике, с которой я знаком довольно твёрдо, что уж говорить о предмете, в котором я даже базовую терминологию не был уверен, что правильно понимаю.
А чтобы загуглить smtp auth, надо было сначала магическим образом узнать, что мне надо гуглить именно smtp auth.icCE
04.04.2017 07:51+1>что мне надо гуглить именно smtp auth.
те мысль об аутентификация почты в голову не приходила?CaptainFlint
04.04.2017 12:11-2О её существовании мысль, разумеется, приходила. Не приходила мысль, что эта аутентификация может перекрывать собой жёстко заданный в настройках постфикса список IP-адресов, считающихся разрешёнными. Обычно бывает в точности наоборот: сначала решаем, принимать ли вообще соединение с этого IP, а уж потом, если всё-таки приняли, запускать процедуру аутентификации.
icCE
04.04.2017 13:59> сначала решаем, принимать ли вообще соединение с этого IP
Меняйте логику на, проверяем — не заблокирован этот ip или маска ip.
Это мы с портами обычно все запрещаем, потом нужные порты открываем. Но уж точно не к IP и уж точно не к массовым сервисам.
icCE
03.04.2017 12:52> Просто возникла конкретная мелкая непонятка по конкретной статье. Фиг с ней, раз такое дело, перебьюсь как-нибудь.
Это вам она кажется мелкой и незначительной, я же вижу, что у вас вообще все хромает. Я вам дал четкие ответы, на вполне конкретные вопросы.
Увы но это не время спросить. Время спросить, это например спросить какой пакет для спама поставить, а не рассказывать вам о типов часов, какие бывают механизмы и как они устроенны.
StiflerWEN
03.04.2017 12:56Нельзя просто так взять и в двух словах объяснить Вам эту «конкретную мелкую непонятку», когда у Вас нет представления о том, что происходит с письмом после нажатия на клиенте кнопки «отправить». С другой стороны, если бы такое представление было, никаких непоняток бы не возникло. Советую прочитать «Postfix. Подробное руководство», даже если нет задачи поднимать почтовый сервер, книга сама по себе интересна, поскольку написана не в стиле технического мануала.
icCE
01.04.2017 18:49и да — еще раз
The list of «trusted» remote SMTP clients that have more privileges than «strangers»
и 0.0.0.0 там точно не должно быть :)
Scorry
03.04.2017 12:05mynetworks = 192.168.0.0/24, 127.0.0.0/8
Локалку, конечно, можно заносить в mynetworks, но не нужно.
nulled
31.03.2017 21:35-5Уже очень давно поднимаю почтовые сервера в docker, на самом деле все очень просто. За нас уже все сделали.
https://github.com/tomav/docker-mailservergrossws
03.04.2017 02:36+3Почтовый сервер, как и любая другая мало-мальски сложная система, настраивается под задачу. Глобально вариантов конфигурации, может, и немного, но для осознанного выбора и подкручивания настроек надо быть способным понять и настроить руками.
В контейнер можно загонять уже после, для удобства распространения этого окружения. Бездумный деплой контейнера — полная глупость.
icCE
03.04.2017 12:53+1>Бездумный деплой контейнера — полная глупость.
Это вообще общая тенденция.grossws
03.04.2017 13:41+1К сожалению, да. Хотя использование тех же публично доступных образов крайне удобно для экспериментов и dev-окружения. Порой сильно экономит время и нервы.
nulled
04.04.2017 13:02Это очевидно, никто не говорил про бездумный деплой. Вам же не запрещают довести конфигурацию до ума, правда? А если так судить то любой bootstrap — зло.
icCE
04.04.2017 14:00Вопрос про доверяя к данному контейнеру.
Я в жизни не буду использовать чужие контейнеры. Сам и только сам.
Минимум можно посмотреть на примерную его конфигурацию.
grossws
04.04.2017 16:08А базовые (debian/ubuntu/centos/fedore/alpine)?
К контейнерам из пользовательского неймспейса доверие исходно низкое. Исключением здесь вполне может быть контейнер от знакомого доверенного вендора. Как пример, от PMC какого-нибудь Apache'вского проекта. Или от RedHat.
nulled
04.04.2017 16:31Как показывает моя практика, контейнеры от официальных вендоров тоже далеко не всегда оптимально настроены.
icCE
04.04.2017 16:42alpine — неплохо минимизирован. Считаю годнотой, но когда есть понимание зачем оно надо.
Это вообще одно из главных условий. Другой момент, что у меня так и не сложилась любовь с докером. Обхожусь kvm и lxc. lxc пришел на замену openvz.
Вендер, вендору рознь и надо смотреть. Недавно, что-то смотрел и волосы шевелились во всех местах.grossws
04.04.2017 18:09Обхожусь kvm и lxc. lxc пришел на замену openvz.
Кстати при актуальной версии
systemdещёsystemd-nspawnможет быть неплохой заменойlxc. Пробовал для сборки сишных/плюсовых библиотек под centos (хост — archlinux).
Ну и для простых случаев типа ограничения по cgroups и namespaces можно делать в самих юнитах. Но, правда, это только на актуальной инфраструктуре.
a8k4
31.03.2017 21:35+1mailcow под докер разворачивается за минуты через docker-compose. На выходе получаем: postfix, dovecot, rspamd, sogo, веб-панель Администрирования, и другие плюшки.
cebka
01.04.2017 15:51+1Вот плюсану за mailcow. При всей моей нелюбви к php, разрабатывает ее достаточно адекватный человек, который, к тому же, помогает с работой над web мордой Rspamd.
AranelOfDoriath
01.04.2017 09:32Еще бы добавить в статью пару слов об интеграции MTA и MDA с базой данных и о postfixadmin.
Да, я в курсе что все это в изобилии есть в интерете, но раз уж тут такая обзорная статья…
ALexhha
01.04.2017 22:19+1Откройте конфигурационный файл Postfix /etc/postfix/main.cf, измените параметр smtpd_recipient_restrictions и настройте другие параметры следующим образом:
и никаких комментариев или объяснений почему именно эти параметры и почему в таком порядке, а ведь порядок имеет значение.
Вспоминается картинка с совой
vitalvas
01.04.2017 22:22+6Могу написать пост об моем опыте связки postfix + dovecot + rspamd + clamav с использованием dkim, dmarc и некоторых своих разработках для этого чуда. Ну еще о том, как это дело кластеризовать в несколько датацентров и пережить падения половину машин.
Если, конечно, будет кому-либо это интересно.icCE
01.04.2017 23:12+2Конечно интересно. Особенно если будут еще нормально и внятно объяснятся параметры и зачем мы их меняем, если меняем. Толковых how-to на самом деле очень мало. Особенно сейчас, когда народ тупо использует чужие докер контейнеры, да же не позаботившись посмотреть, а что там внутри?
grossws
03.04.2017 02:40В принципе, можно вполне толковыми считать таковые на сайте postfix'а. Вот
postconf(5)— тихий ужас, для базового понимания куда удобнее взять дефолтный конфиг из любого нормального дистрибутива и почитать комментарии в нём. К сожалению, только для базового.
rader90
01.04.2017 22:22+1Заранее буду благодарен автору, если он подредактирует материал под пожелания комментариев выше. Тоже хотелось увидеть актуальные на данный момент, настройки и фичи. Хотя и могу понять автора, если у него мало времени будет.
NoRegrets
01.04.2017 22:43Как в 2000 году побывал. Когда-то почта настраивалось на каждом втором никсовом сервере, опеннеты были завалены подобными мануалами, и, кстати, гораздо более подробными. Но вот уже лет 10 прошло как это стало уделом профессионалов, т.е. тех, для кого почта является основной деятельностью, ИМХО. Сейчас настройка почты сводится к запуску dpkg-reconfigure exim4-config или dpkg-reconfigure postfix и прописыванием в /etc/aliases своей почты.
Хотя до сих пор встречаю одминов юзающих нешифрованную почту на 25 порту. Видимо неофитам не объяснили, что это уже легаси, либо это фря 4.8 на 100 пне, которую уже лет 20 никто не админит.
grossws
03.04.2017 02:05+1$ firewall-cmd --permanent --add-port=110/tcp --add-port=995
$ firewall-cmd --permanent --add-port=143/tcp --add-port=993
$ firewall-cmd --reloadЗачем так странно, если можно использовать
--add-service=pop3и аналогичноpop3s,imap,imaps,smtp/smtps?
grumbler66rus
05.04.2017 18:29+1В этой статье написаны дурные советы.
К счастью, сообщения, прежде чем они достигнут почтового сервера на Postfix, можно фильтровать, используя Realtime Blackhole Lists (RBLs). Это снизит нагрузку на почтовый сервер и поможет сохранить его в чистоте.
Особенно поможет сохранить сервер в чистоте от писем клиентов и прочих контрагентов. Погуглите на предмет блокировки серверов gmail майкрософтовским RBL. В меньших масштабах подобное происходит ежедневно.
Спамер арендует shared хостинг за доллар, рассылает миллионы писем в час, хостер блокирует спамовый аккаунт, но релеи хостера, а то и вся подсеть попадают в RBL и почта клиентов хостера оказывается в ловушке на несколько дней. Спамер же после блокировки аккаунта повторяет трюк на другом хостинге.
В 2017 году RBL не защищает от спама, но регулярно нарушает связность электронной почты.
Для начала нужно сгенерировать сертификат и ключ с использованием команды openssl
Именно чтобы избежать такого костыля, умные люди придумали и поддерживают сервис Let's Encrypt. Самый простой в установке и настройке вариант — скрипт dehydrated.
Про отсутствие в статье DKIM, SPF и антивируса (к примеру, clamav присутствует во всех GNU/Linux. которые я видел) тут уже много раз прокомментировали.
В статье не описаны преимущества IMAP: хранение писем на сервере, где есть (должно быть!) резервное копирование и возможен доступ из браузера (roundcube, squirrelmail, ...).
Не упомянуты Exim и Qmail. Последний ещё ладно, он не в тройке лидеров, но Exim устанавливается по умолчанию в популярных дистрибутивах GNU/Linux.
Насчёт dovecot. В конфигурации по умолчанию (mbox!) нормально работает только с маленькими объёмами почтовых ящиков. Это означает, что пользователи либо забирают почту по POP3, либо следят за количеством почты в IMAP. Когда возникнут проблемы, изменить конфигурацию будет проблематично.
Вы никогда не встречались с почтовыми ящиками размеров в 15-20 Гб? Сравните время удаления письма из начала-середины файла и удаление файла из каталога в случае maildir.
Кроме того, в dovecot через жопу делаются виртуальные домены и виртуальные пользователи, касательно imap нет публичных (shared) папок и сильно ограничена вложенность папок.
Из-за этих его недостатков я выбрал Cyrus-IMAP. Он чуть сложнее управляется, зато даёт широчайшие возможности, в том числе элементарно даётся доступ одного сотрудника к почте другого в том же домене. Например, сотрудник, подменяющий заболевшего коллегу, видит его почту и отвечает на письма от своего имени.
Касательно postfix.
К сожалению, сделать фильтрацию почты в postfix в процессе обработки входящего соединения крайне затруднительно. В sendmail для этого используется milter, но в postfix milter не так развит, создаёт большую нагрузку на сервер, поэтому традиционно используется фильтрация через pipe. Эффективность фильтров в результате низкая, нагрузка на сервер высокая. Простого решения проблемы до сих пор не существует, приходится использовать сервис-прокладку: фильтрующий релэй.ildarz
06.04.2017 11:06В 2017 году RBL не защищает от спама
Практика говорит об обратном. Вот смотрю на статистику на одном из серверов — почти 90% писем через RBL отсеиваются. Ложноположительных случаев за несколько лет не припомню, хотя понимаю, что для какой-то другой организации статистика может быть иной. Случаи, когда контрагент попадает в RBL за дело, а почту от него принимать всё равно надо, были, но все они в рабочем порядке решаются, благо белые списки никто не отменял.
Плюсы и минусы RBL могут весить по-разному в каждом конкретном случае, выбор пусть каждый делает сам, но вот насчет "не защищает" — не надо.
grumbler66rus
06.04.2017 12:19В моей практике более 90% спама отсеивается на уровне установления соединения в проверках «качества» клиента SMTP. В итоге до проверки RBL дело просто не доходит: в моих конфигурациях проверку по RBL проводит spamassassin.
Ложноположительных случаев за несколько лет не припомню
Я писал о таких случаях. Прочитайте комментарии, описанная ситуация имела повторения. В комментариях есть пример грамотного использования RBL, если другие проверки настроить лень:Мой greysmtpd использует эти RBL-списки, но не для блокирования почты, а только для активирования грейлистинга. Таким образом и спама отсекается львиная доля (80-90%), и в то же время доставка нормальных писем гарантировано работает ...
icCE
06.04.2017 13:48>Из-за этих его недостатков я выбрал Cyrus-IMAP. Он чуть сложнее управляется, зато даёт широчайшие возможности, в том числе элементарно даётся доступ одного сотрудника к почте другого в том же домене. Например, сотрудник, подменяющий заболевшего коллегу, видит его почту и отвечает на письма от своего имени.
Мне кажется, такого человек просто не должен хотеть делать.
Минимум, некие публичные папки или пересылка новой почты.
Ну а Cyrus надо будет попробовать 3 версию что там и как. Да и кстати mbox — это один из форматов, который dovecot умеет использовать.grumbler66rus
06.04.2017 16:30Мне кажется, такого человек просто не должен хотеть делать.
Минимум, некие публичные папки или пересылка новой почты.
То, что вам кажется и производственная необходимость противоречат друг другу.
Сложившаяся практика такова: руководитель организации или подразделения принимает решение, что имярек замещает отсутствующего и, чтобы сотруднику не нужно было выяснять у клиента всю историю вопроса, ему нужно просматривать всю историю переписки. Заметьте, речь о служебной переписке, тайна которой регулируется в понятиях коммерческой тайны.
Там, где на сервере почты работает Dovecot, пользователю приходится настраивать ещё одну учётную запись почты, а при использовании POP3 сотрудник бегает между компьютерами. Если же на сервере Cyrus, достаточно выполнить две команды.icCE
06.04.2017 23:20Да все это мне знакомо прекрасно.
Сейчас уже деталей не скажу, но подключали в режим RO ящик человеку.
Dovecot все же имеет прекрасный ACL
fishca
Ушел поднимать почтовый сервер.