Версии софта принципиального значения не имеют. Важно, что почтовая база хранится в формате maildir, все письма на сервере. Основная проблема переноса таких серверов — очень долгая синхронизация почтовой базы сообщений, состоящей из десятков и сотен тысяч мелких файлов. Если у вас обычные sata диски, просто взять и перенести почтовый сервер на новое место с минимальным простоем не получится. Надо что-то придумывать.

Я придумал такую схему переноса:

1. Подготовка системы на новом месте.
2. Копирование основной почтовой базы на новое место.
3. Остановка старого сервера, заливка изменений в базе на новый сервер.
4. Запуск нового почтового сервера как основного.

Я всегда настраиваю сервера так, что системный диск небольшого размера — 30-50 гб. Все данные, будь то почтовая база, файловый сервер, база данных, сайты и т.д. находятся на отдельном диске. Главное, не экономить сильно и не делать системные диски очень маленькими, как однажды сделал я, сэкономив место на дорогих ssd дисках. Потом пришлось на ходу расширять системный раздел. Оптимально на моей практике это не меньше 30 гб. Если меньше, то приходится ужиматься с логами, кэшами и т.д. Не очень удобно. Все, что больше 30 уже не проблема. Если надо больше места, подключаются отдельные диски и символьными ссылками расширяются проблемные места.

С таким подходом удобно бэкапить виртуальные машины. Я на уровне гипервизоров делаю бэкап только системных дисков. Для данных использую другие способы, например rsync. Иногда и то, и другое. Бэкапить только гипервизором огромные диски по несколько ТБ данных не удобно. А в некоторых случаях практически невозможно, так как нет возможности сделать инкрементный бэкап. Например, в proxmox мне не известен способ централизованного управления и создания инкрементных бэкапов. Для других гипервизоров какие-то решения есть.

Подготовка нового сервера

В данном случае не имеет принципиального значения, переносите вы старый сервер на новое место, или готовите новый обновленный почтовый сервер. Основная проблема все равно с переносом базы, ее и надо отдельно решать. Если просто переносите старый сервер, то перенесите на новое место системный диск. Если это другой гипервизор, то убедитесь, что система нормально стартует в новом гипервизоре. Обновите утилиты интеграции, убедитесь, что определены сетевые карты, корректы записи в fstab. В общем, проверьте все, чтобы система стабильно работала.

Тут важно не торопиться и все проверить тщательно. У меня была ситуация, когда после переноса почтового сервера с одного гипервизора на другой, на сервере стало очень сильно убегать вперед время. Буквально на 1-2 минуты в час. Я это сразу не заметил, не обратил внимание. А когда запустил в работу новый сервер, увидел, что к концу рабочего дня время убежало уже на 15 минут. Синхронизация тут не спасала, так как dovecot, замечая большие изменения во времени после синхронизации, просто аварийно завершал работу. Для него это типовое поведение в таком случае.

Было очень неприятно словить такую ошибку на рабочем сервере. Потом в итоге разобрался, в чем дело. Изменил настройки grub для данной виртуалки, связанные с прерываниями процессора, и время перестало убегать. Но это потребовало тестов и перезагрузок уже на рабочем сервере, что было неудобно. Лучше бы я все отладил с самого начала, благо время было. Я все это к тому, что не торопитесь с переносом. После того, как поднимите систему на новом железе, оставьте ее поработать некоторое время, убедитесь, что все в порядке.

Как я уже сказал, не важно, переносите вы текущий сервер или настраиваете новый. Если новый — то так же настройте все, отладьте, проверьте. Дальше назначьте какие-то ip адреса новому серверу, чтобы был сетевой доступ к старому. Если переносите старый сервер, не забудьте на новом месте сменить MAC и IP адрес у сетевого интерфейса. Бывало, что я забывал сменить MAC. Начинались непонятные сетевые проблемы с обрывами соединений. Не сразу догадался, в чем было дело.

Когда все готово, оба сервера работают и видны в сети, можно переходить к переносу почтовой базы.

Перенос почтовой базы

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

Для этого на новом сервере подключите и смонтируйте новый диск, где будете хранить почту. Дальше без остановки старого сервера выполните синхронизацию каталогов с базой. Я обычно использую rsync для этого. Вот простой пример команды, которую запускаю с нового сервера.

# /usr/bin/rsync -av root@10.1.4.22:/data/mail /data

Здесь мы просто копируем почтовый архив со старого сервера 10.1.4.22 из директории /data/mail на новый сервер в эту же директорию. Не ошибитесь со слешами в конце путей. Я иногда путаюсь, после запуска сразу останавливаю процесс и проверяю, что все копируется именно оттуда и именно туда, куда надо. Чтобы команда точно отработала даже при обрыве ssh соединения, запускаю ее в screen.Копирование почтовой базы лучше запустить в самое наименее нагруженное время, хотя и не обязательно. Важно не пересечься с временем планового бэкапа. Бывает, запланируешь перенос на ночь, запускаешь копирование, а оно совпадает с плановым бэкапом. В итоге оба задания жутко тормозят. При этом еще и сам сервер работает медленно.

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

После того, как скопировали основную часть почтового архива, переходим к переключению на новый сервер.

Переключение на новый сервер

Самый важный и ответственный этап переноса почтового сервера. Здесь нужно еще раз хорошенько все проверить, убедиться, что все работает нормально. Непосредственно перед переключением на новый сервер, можно еще раз накатить изменения почтовой базы без остановки старого. Это позволит максимально уменьшить время простоя. Когда все готово, останавливаем службы dovecot и postfix почтового сервера. После этого сразу же запускаем синхронизацию каталогов между старым и новым сервером. Мы накатываем все изменения почтовой базы, делая ее полностью актуальной в новом сервере. Для этого надо добавить ключ —delete к rsync.

# /usr/bin/rsync --delete -av root@10.1.4.22:/data/mail /data

Важно не перепутать источник с приемником. Сначала идет старый сервер, потом новый. Перед запуском хорошенько проверяйте команды. Один раз я угробил новый сервер, ошибившись в команде и удалив с корня системы некоторые каталоги. Просто слешом ошибся на источнике, когда копировал в корень приемника. Это было не страшно, так как повредил новый сервер. Пришлось отложить перенос и восстановить его.

Ждёте окончания синхронизации. Она должна быть не долгой, так как перед остановкой почтового сервера вы и так накатили все изменения. Обычно несколько минут занимает процесс финального копирования. Когда он закончен, выключаете старый сервер, убираете его из автозагрузки гипервизора. На новом сервере меняете IP на адреса старого сервера и перезагружаете его. Можно и не перезагружать, но я для проверки всегда перезагружаю. Можно не менять IP адрес, если у вас все завязано на dns имена, отредактируйте dns запись. Но я обычно все же меняю ip, так надежнее. Обязательно найдется какое-нибудь старое оборудование, типа сканера, где адрес указан в виде ip адреса и т.д. Эти лишние проблемы потом не нужны. Лучше все сделать максимально незаметно и надежно.

После запуска нового сервера, убедитесь, что все службы работают, почта ходит, мониторинг не показывает проблем. Если все прошло гладко и по плану, то время простоя будет несколько минут. В ночное время этого могут и не заметить.

Бывает, что не все идет гладко. У меня были ситуации, когда после перехода уже на новый сервер, начинались проблемы, которые предусмотреть заранее было нельзя. Новое хранилище начинало тормозить или возникали еще какие-то проблемы. Например, с блокировками на nfs. Вы это не проверили заранее. С работой dovecot на nfs есть свои нюансы. Если вы понимаете, что оставить в работе новый сервер нельзя и надо откатываться, то нужно опять синхронизировать почтовую базу, если для вас важна та корреспонденция, которая была доставлена в то время, как поработал новый сервер. Для этого останавливаете почтовые службы на новом сервере, меняете на нем ip, запускаете старый и выполняете синхронизацию в обратном порядке — с нового на старый. Не ошибитесь в параметрах rsync! После этого оставляете старый сервер в работе, а с новым спокойно разбираетесь и готовите его еще раз к переносу.

Вот, в принципе, и все по переносу почтового сервера из моей практики. Я их переносил штук 10 за все время админства. Можно сказать руку набил.

Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:

1. Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
2. Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
3. У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.

Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки.

Сообщение Перенос почтового сервера postfix появились сначала на Clip-Clap.

Сподвигло меня к разбору этой ситуации огромное количество спама примерно следующего содержания:

I greet you!

I have bad news for you.
06/28/2018 - on this day I hacked your operating system and got full access to your account eme@eme.ru
On that day your account (eme@eme.ru) password was: gyhbtj5pq6b

It is useless to change the password, my malware intercepts it every time.

How it was:
In the software of the router to which you were connected that day, there was a vulnerability.
I first hacked this router and placed my malicious code on it.
When you entered in the Internet, my trojan was installed on the operating system of your device.

After that, I made a full dump of your disk (I have all your address book, history of viewing sites, all files, phone numbers and addresses of all your contacts).

A month ago, I wanted to lock your device and ask for a small amount of money to unlock.
But I looked at the sites that you regularly visit, and came to the big delight of your favorite resources.
I'm talking about sites for adults.

I want to say - you are a big pervert. You have unbridled fantasy!

After that, an idea came to my mind.
I made a screenshot of the intimate website where you have fun (you know what it is about, right?).
After that, I took off your joys (using the camera of your device). It turned out beautifully, do not hesitate.

I am strongly belive that you would not like to show these pictures to your relatives, friends or colleagues.
I think $971 is a very small amount for my silence.
Besides, I spent a lot of time on you!

I accept money only in Bitcoins.
My BTC wallet: 15ZHnf1MPn6ybb8yUeAoCQ1AJtiKhg3NrP

You do not know how to replenish a Bitcoin wallet?
In any search engine write "how to send money to btc wallet".
It's easier than send money to a credit card!

For payment you have a little more than two days (exactly 50 hours).
Do not worry, the timer will start at the moment when you open this letter. Yes, yes .. it has already started!

After payment, my virus and dirty photos with you self-destruct automatically.
Narrative, if I do not receive the specified amount from you, then your device will be blocked, and all your contacts will receive a photos with your "joys".

I want you to be prudent.
- Do not try to find and destroy my virus! (All your data is already uploaded to a remote server)
- Do not try to contact me (this is not feasible, I sent you an email from your account)
- Various security services will not help you; formatting a disk or destroying a device will not help either, since your data is already on a remote server.

P.S. I guarantee you that I will not disturb you again after payment, as you are not my single victim.
 This is a hacker code of honor.

From now on, I advise you to use good antiviruses and update them regularly (several times a day)!

Don't be mad at me, everyone has their own work.
Farewell.

Смысл письма в том, что человек якобы взломал ваш компьютер и следил за вами. Наследил там чего-то важного по посещаемым сайтам и через веб камеру и теперь грозится это обнародовать. Расчет на то, как я понял, что человек по порнографическим сайтам лазил. Для убедительности, в письме приложен пароль, взятый из какой-то публичной базы данных слитых учеток. Сейчас таких баз полно. Пароли могут быть реальными!!! Один человек сказал, что знает этот свой пароль, но только он не от почты, а использовался на сайте booking.com.

В письме используется поддельный адрес From, для того, чтобы письмо выглядело якобы отправленное с вашей учетки, что должно подтверждать реальность угроз. В общем, подход системный получился. Конечно, все это подделка и развод. Я решил сберечь нервы пользователей и каким-то образом оградить людей от подобных писем. С помощью postfix это сделать очень просто. Базовые методы борьбы со спамом я уже подробно расписывал в отдельном разделе в статье по настройке postfix. Но текущая ситуация там не учитывается. Сейчас исправим это.

Для начала давайте проверим, реально ли на ваш почтовый сервер отправить письмо с поддельным полем From. Для этого подключимся к нему по Telnet и попробуем вручную выполнить отправку.

Список команд, которые я вводил:

telnet mx.eme.ru 25
helo yandex.ru
mail from:<zva@eme.ru>
rcpt to:<zva@eme.ru>
data
Test
.
quit

Я использовал поддельные данные в поле helo, представившись yandex.ru и дальше отправил тестовое письмо. Сервер его принял и успешно доставил в ящик. Вот исходный текст этого письма.

Обратите внимание, что используется антиспам Kaspersky Security 8.0 for Linux Mail Server. Но у него настроен белый список на адреса исходного домена. Получается, что антивирус так же проверяет поле From, которое подделано, и не защищает пользователей от таких писем.

Для того, чтобы запретить отправку писем с левых почтовых серверов, которые ставят в поле From наш домен, необходимо добавить еще одну проверку в раздел smtpd_sender_restrictions следующим образом:

smtpd_sender_restrictions =	permit_mynetworks,
				permit_sasl_authenticated,
				reject_authenticated_sender_login_mismatch,
				reject_unknown_sender_domain,
				reject_non_fqdn_sender,
				reject_unlisted_sender,
				reject_unauth_destination,
				check_sender_access hash:/etc/postfix/sender_access

К существующим ограничениям я добавил еще одно в самый конец. Создадим указанный файл sender_access со следующим содержимым.

# mcedit /etc/postfix/sender_access
eme.ru REJECT You are not eme.ru
# postmap /etc/postfix/sender_access

Всем, кто захочет отправить нам письмо с доменом нашего сервера, мы будем выдавать ошибку и отвечать, что вы это не мы Перечитываем конфигурацию postfix:

# postfix reload

Теперь попробуем еще раз через telnet отправить письмо с полем From из нашего домена.

Сервер выдал ошибку 554. В логе почтового сервера будет следующая строка:

Nov  7 17:59:45 ememail postfix/smtpd[17430]: NOQUEUE: reject: RCPT from broadband: 554 5.7.1 <zva@eme.ru>: Sender address rejected: You are not eme.ru; from=<zva@eme.ru> to=<zva@eme.ru> proto=SMTP helo=yandex.ru

Все, больше ни один отправитель не сможет использовать в поле From наш домен. Вообще странно, что изначально это возможно. Протокол smtp давно пора как-то изменить, чтобы раз и навсегда защитить его от спама. На него нагородили уже столько костылей, но ничего не помогает.

Сообщение Запрет писем с поддельным полем From или спам от себя к себе в postfix появились сначала на Clip-Clap.

Введение

Данная статья будет актуальна для тех, кто сам выполнил установку и настройку postfix или воспользовался готовой сборкой на базе iredmail. Это что касается материалов моего сайта. А в целом все описанное ниже будет актуально для любого почтового сервера, который хранит почту в формате maildir.

Скажу пару слов, почему именно maildir. Лично я этот формат использую за его удобство. В нем каждое письмо это отдельный файл, который можно посмотреть любым текстовым редактором. Эти файлы удобно бэкапить, анализировать содержимое, сортировать по каким-то признакам. В общем, с ними можно работать как с обычными текстовыми файлами. На основе этих плюсов и выполняется вся дальнейшая работа в статье. Из минусов вижу только один — огромное количество мелких файлов создают большую нагрузку на дисковую подсистему.

Приведу для наглядности пример, который позволит оценить нагрузку на диски. Для синхронизации с помощью rsync почтовой базы объемом примерно 1 терабайт, расположенной на raid10 обычных 3.5 sata дисков, на одиночный такой же диск для бэкапа, уходит где-то пару часов в основном на сравнение файлов между источником и приемником. Само копирование файлов проходит быстро, но чтобы сравнить изменения за день, приходится выполнять длительную операцию. При этом в целом работа пользователей (~30-40 человек) с этой базой вполне комфортна, каких-то тормозов не наблюдается.

То есть по сути, для такого количества пользователей, сервером может быть обычный десктопный компьютер с 2-4 обычными sata дисками. Хватит производительности любого процессора и примерно 2-4 гигабайта оперативной памяти. Отдельный вопрос, конечно, к надежности обычного системника. Я сервера на них не рекомендую собирать, но при большом желании можно.Приведенные далее скрипты для очистки почтовой базы писались в разное время на разных серверах. Иногда может показаться, что все сделано нелогично или как-то сложно. Громоздкие конструкции часто возникали там, где появлялись проблемы с пробелами или спецсимволами в именах папок на русском языке, которые при переводе в UTF-7 (кодировка названия imap папок в dovecot) превращаются в весьма неудобные для обработки строки. Дальше будет понятно, что я имею ввиду.

Перейдем теперь к конкретным примерам.

Простое удаление старых писем из ящика

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

/usr/bin/find /data/mail/virtual/zabbix@mailsrv.ru/Maildir/*/ -type f -mtime +30 -exec rm {} \;

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

/usr/bin/find /data/mail/virtual/zabbix@mailsrv.ru/Maildir/*/ -type f -mtime +30 >> /root/dellist.txt

После этого смотрите файл /root/dellist.txt и проверяйте, что собираетесь удалить. После того, как проверили, не обязательно заново выполнять поиск по базе и лишний раз нагружать диски. Можно удалить все указанные в dellist.txt письма следующим скриптом.

#!/bin/bash

cat /root/dellist.txt | while read i ; do 
rm -f "$i" 
done

Сам процесс поиска по почтовой базе postfix не такой длительный, как поиск и удаление. На сильно нагруженных базах я рекомендую выполнять удаление, когда сервер нагружен меньше всего, а поиск в любое время. Конечно, искать тоже лучше в нерабочее время, но мне не нравится работать ночью, поэтому все, что можно, я делаю днем, а на ночь оставляю по возможности минимум работы.

Массовая очистка корзин в почтовой базе postfix

Рассмотрим более сложный пример. Нам нужно автоматически очистить все корзины пользователей от писем, старше 30-ти дней. Я рекомендую всегда настраивать такую очистку. Дело в том, что если сервер сильно нагружен, то он не всегда корректно удаляет содержимое корзины. Например, пользователь отправил в корзину очень много писем (десятки тысяч), нажал «очистить корзину» и закрыл почтовый imap клиент. Есть вероятность, что реально письма не удалятся, а так и будут висеть в корзине. Imap сервер dovecot не удаляет мгновенно письма, а ставит их в очередь и потихоньку удаляет. Иногда этот процесс прерывается и удаление не происходит. Можно попытаться это сделать снова и рано или поздно они таки удалятся.

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

Сложность с очисткой корзин в том, что названий папок для удаленной почты может быть много. Каждый почтовый клиент создает какую-то свою папку, имя которой может не совпадать с уже существующими. Сейчас могут использоваться одновременно 3 вида почтовых клиентов: web, десктопная или мобильная программа. Каждая из них создает свой набор папок. Ко всему прочему, русские имена imap папок хранятся в кодировке UTF-7, что осложняет работу скриптов. Необходимо экранировать спецсимволы и пробелы.

Вот мой список возможных названий папок для удаленной почты.

Я обычно выполняю поиск по такому набору папок. Если у вас есть дополнение этого списка, прошу поделиться. А вот скрипт для автоматической очистки корзин с указанными именами папок.

#!/bin/bash

# текущая дата в формате Год-месяц-день
data=`date +"%Y-%m-%d"`
# формируем список почтовых ящиков для поиска
mailbox=`ls -l /data/mail/virtual | grep vmail | awk '{print $9}'`

for box1 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box1/Maildir/'.&BCMENAQwBDsENQQ9BD0ESwQ1-'/*/ -type f -mtime +30 | while read a ; do
	ls "$a" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

for box2 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box2/Maildir/'.Deleted Messages'/*/ -type f -mtime +30 | while read b ; do
	ls "$b" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

for box3 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box3/Maildir/.Trash/*/ -type f -mtime +30 | while read c ; do
	ls "$c" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

for box4 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box4/Maildir/'.&BCMENAQwBDsENQQ9BD0ESwQ1- &BE0EOwQ1BDwENQQ9BEIESw-'/*/ -type f -mtime +30 | while read d ; do
	ls "$d" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

for box5 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box5/Maildir/'.&BBoEPgRABDcEOAQ9BDA-'/*/ -type f -mtime +30 | while read e ; do
	ls "$e" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

for box6 in $mailbox
    do
	/usr/bin/find /data/mail/virtual/$box6/Maildir/'.Deleted Items'/*/ -type f -mtime +30 | while read f ; do
	ls "$f" >> /root/mailclean/trashclean-log/$data.txt
	done
    done

cat /root/mailclean/trashclean-log/$data.txt | while read i ; do
    rm -f "$i"
    done

Конечно, тут для компактности можно было сделать еще один вложенный цикл и перебирать имена папок. Я не стал этого делать для наглядности. К тому же список небольшой, можно оставить так. Некоторые комментарии к скрипту.

Конструкция

mailbox=`ls -l /data/mail/virtual | grep vmail | awk '{print $9}'`

формирует список ящиков для очистки. В данном случае берутся все существующие ящики. vmail тут владелец директорий с ящиками. Получить список актуальных ящиков можно разными способами. Я сделал это вот так. Вы можете вручную составить список ящиков в текстовом файле в формате один ящик в каждой новой строке и работать по своему списку. Примерно вот так:

mailbox=/root/mailclean/mailboxlist.txt

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

Аналогичным образом можно очистить папки со спамом. Вот мой список для таких папок.

Более подробно вопрос автоматического удаления спама рассмотрим отдельно.

Удаление писем на основе содержимого письма

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

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

#!/bin/bash

# формируем список ящиков для очистки
mailbox=`ls -l /data/mail/virtual | grep vmail | awk '{print $9}'`
# дата в формате Год-месяц-день_час-минута-секунда
data_full=`date +"%Y-%m-%d_%H-%M-%S"`
# дата в формате Год-месяц-день
data=`date +"%Y-%m-%d"`
# директория для хранения копий удаленных писем
copydir=/backup/mailclean
# адрес лог файла с информацией о времени работы скрипта
logfile=/backup/mailclean/log.txt

echo "============`date +"%Y-%m-%d"`============" >> $logfile
echo "`date +"%H-%M-%S"` Start mail clean" >> $logfile

for box in $mailbox
    do
    # создаем директории с именами ящиков и текущей даты для копий удаленных писем
    mkdir -p $copydir/$box/mail/$data
    # формируем список всех писем в ящике
    /usr/bin/find /data/mail/virtual/$box/Maildir -type f -name "*mailsrv*" -mtime +30 -daystart | while read a ; do
    # ищем в содержимом письма адрес получателя zabbix@mailsrv.ru и записываем имена таких писем в индивидуальный файл для каждого ящика
        grep -E -R -l -I "*for <zabbix@mailsrv.ru>;*" "$a" >> $copydir/$box/copy-$data_full.txt
        done
    # пишем название ящика в общий лог файл
    echo "=========$box=========" >> $copydir/$data_full-all.txt
    # записываем в общий лог файл все удаленные письма каждого ящика за конкретную дату очистки	
    cat $copydir/$box/copy-$data_full.txt >> $copydir/$data_full-all.txt
    # формируем список писем ящика на удаление	
    cat $copydir/$box/copy-$data_full.txt | while read i ; do
    # копируем письмо из реального ящика в папку архива (рекомендую использовать во время отладки)
        cp -p "$i" $copydir/$box/mail/$data
    # перемещаем письмо из реального ящика в архив (использовать после отладки)
    #   mv "$i" $copydir/$box/mail/$data
        done
    done
# записываем время завершения работы скрипта
echo "`date +"%H-%M-%S"` End mail clean" >> $logfile
echo "==================================" >> $logfile

Поясню основные моменты. В строке с поиском писем по всему ящику есть маска:

/usr/bin/find /data/mail/virtual/$box/Maildir -type f -name "*mailsrv*" -mtime +30 -daystart | while read a ; do

В данном случае mailsrv это часть имени сервера. В формате maildir в именах файлов писем всегда присутствует имя сервера. Эта маска позволяет найти только файлы почты, отбросив остальные служебные файлы, которые могут там быть. А они там точно будут, например, индексы dovecot, правила sieve и др. Не забудьте поменять эту маску на свою в соответствии с именем сервера.

Строка для поиска получателя письма *for <zabbix@mailsrv.ru>;* именно в таком видевзята из служебных заголовков. Даже если письма различными фильтрами будут перемещаться в другие ящики, первоначальный получатель писем все равно будет зафиксирован этой строкой.Предупреждаю, что не нужно слепо использовать этот и другие скрипты. Они приведены в основном для того, чтобы показать принципы и идеи, которые я использую. Эти скрипты нужно внимательно посмотреть, понять, что происходит в каждой строке, и изменить под свои нужды. В готовом виде вряд ли вам нужен будет именно такой скрипт. Тут все очень индивидуально и требует осознания всех выполняемых действий.

Если вам нужно автоматом удалить в почтовом архиве все спам письма, которые ваша антиспам система помечает как спам, то можете взять служебный заголовок, который ставит эта система и использовать его. Например, Касперский антиспам вот так помечает все спамовые письма:

X-KLMS-AntiSpam-Status: spam

Соответственно я ищу все письма с таким служебным заголовком и что-то с ними делаю. Например, перемещаю в папку spam или удаляю. Но тут нужно быть внимательным и делать все аккуратно. Например, если какое-то письмо фильтр по ошибке пометил спамом, у пользователя не будет никакой возможности его сохранить, если вы будете автоматически удалять эти письма. Тут нужно думать в конкретной ситуации как поступить. На текущий момент я не использую подобные правила для удаления или перемещения почты, только для поиска, чтобы оценить объем спамовой почты. Если он слишком велик и его чистка позволит высвободить значительные объемы дискового пространства, то я начинаю что-то делать с ящиками пользователей. Чаще всего напрягать админов на местах, чтобы они стимулировали пользователей к самостоятельной ручной очистке спама. Если же спама не много, то я просто ничего не делаю.

Фильтрация писем на основе темы письма

Рассмотрим более сложный вариант предыдущего скрипта. Там мы фильтровали письма на основе содержимого служебных заголовков. Но если мы захотим отфильтровать почту по теме письма, то сходу у нас ничего не получится. С темой письма возникают сложности из-за того, что она закодирована в base64, если в ней используются русский язык. Вот простой пример. У нас есть письмо с темой «Как дела?». Используем base64 декодер и смотрим, как будет выглядеть тема сообщения в исходнике письма.

Как дела? - 0JrQsNC6INC00LXQu9CwPw==

А вот, что вы увидите в заголовке письма со всеми служебными добавлениями:

Subject: =?UTF-8?B?0JrQsNC6INC00LXQu9CwPw==?=

Вам нужно будет отбросить сначала кодировку =?UTF-8?, потом не знаю, что означающие символы B?, затем в конце еще вот это ?=. Так вы получаете искомую фразу. Теперь представьте, что кто-то ответит на это письмо. Тема сообщения станет Re: Как дела?. В base64 эта фраза будет выглядеть совершенно по-иному:

Re: Как дела?UmU6INCa0LDQuiDQtNC10LvQsD8=

И вот как в реальном заголовке:

Subject: =?UTF-8?B?UmU6INCa0LDQuiDQtNC10LvQsD8=?=

Сложность добавляет еще то, что разные почтовые клиенты используют разную кодировку в теме письма. Мне встречались как UTF-8, так и WIN-1251. То есть для того, чтобы нормально раскодировать и читать тему сообщения, вам нужно сделать обработку на декодирование, на отбрасывание служебных символов. Еще в процессе тестирования я заметил, что если вы используете не весь текст темы, а только ее часть, то закодированная строка поиска может немного не совпадать с той, что будет в теме письма. Изменения могут возникнуть из-за заглавных/строчных букв, пробелов, запятых и т.д. В общем, я не осилил эту тему, так как надо очень плотно погрузиться в предмет и написать много различных проверок и условий. У меня просто не хватило терпения все сделать красиво, чтобы скрипт работал надежно.

Поступил я в итоге по-другому, более просто и топорно, зато надежно. Допустим, вам нужно, чтобы какая-то переписка не хранилась на сервере дольше определенного времени. Это может быть конфиденциальная информация. Например, вы сканируете документы с отправкой на почту и вам нужно, чтобы сканы там не хранились бесконечно долго. Настраиваете на МФУ шаблон темы сообщения, добавляя в начало такую строку — !del. Затем переводите его в base64, добавляя еще фразы с Re: и Fwd: на случай, если эти письма могут куда-то пересылаться или писаться ответы. Конечно, сканеру вряд ли кто-то будет отвечать, но, возможно, для вашей темы сообщения это будет актуально.

Дальше берете скрипт из предыдущего примера и меняете там строку поиска на новую:

grep -E -R -l -I "Subject:.*IWRlb.*|Subject:.*RndkOiAhZGVs.*|Subject:.*UmU6ICFkZWw.*" "$a" >> $copydir/$box/copy-$data_full.txt

Эта строка найдет во всех письмах, сформированных в список предыдущей командой, темы сообщения !del, Re: !del, Fwd: !del и скопирует пути и имена файлов в список. Потом вы можете на свое усмотрение работать с этим списком.

Еще несколько примеров работы с почтовой базой

Этот пример будет актуален, если вы используете почтовые ящики, куда копируется абсолютно вся переписка вашего сервера. Допустим, у вас есть ящик out@mailsrv.ru, куда сохраняется вся уходящая корреспонденция. Если на сервере идет активная переписка, то писем в ящике будет много и искать с помощью какого-то imap клиента будет неудобно, так как он может либо тормозить на большом списке писем, либо вообще отваливаться по таймауту и поиск или сортировка будут невозможны с его помощью. Тогда на помощь придут простые скрипты в консоли сервера. Найдем в этом ящике все письма, отправленные в период между первым и седьмым сентября 2017 года и скопируем их в отдельный ящик.

find /data/mail/virtual/out@mailsrv.ru/Maildir/*/ -newerBt '2017-09-01 00:00' -and -not -newerBt '2017-09-07 00:00' -and -type f | cpio -pdmv /data/mail/virtual/user@mailsrv.ru/Maildir/new

По сути тут просто использовались ключи к команде find. У нее их так много, что я для всех прикладных задач всегда храню готовые конструкции, чтобы заново не вспоминать все ключи и возможности.

Еще полезно бывает посмотреть размер почтовых ящиков. Некоторые пользователи имеют в разы больший объем ящика, чем все остальные. Есть любители хранить в почте презентации, пересылать разбитые на части архивы и т.д. Иногда приходится вручную проверять размеры ящиков, чтобы отдать команду на очистку заполненных сверх меры. Сделать это можно простой командой в директории с ящиками:

# du --max-depth=1 | sort -n -r

Команда выведет размеры всех ящиков и отсортирует их по мере увеличения объема, но при этом объем покажет в байтах, что не очень удобно. Можно вывести директории по алфавиту, но с размером в привычных мегабайтах или гигабайтах, но уже без сортировки.

# du -h --max-depth=1

Еще удобнее отправить сразу вывод в текстовый файл с датой в имени файла, чтобы потом было удобно сравнить с тем, что получилось после чистки почтовой базы.

# du -h --max-depth=1 >> "dirsize_`date +"%Y-%m-%d_%H:%M"`.txt"

Тут можно придумать много всяких способов отсортировать данные для более удобного восприятия, или потом автоматически сравнить размеры ящиков. Я не занимался этим.

Заключение

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

Сообщение Очистка и обслуживание почтовой базы postfix появились сначала на Clip-Clap.

Потребности в почте у среднего бизнеса

Начнем с того, что я подразумеваю под средним бизнесом. Я не знаю точную классификацию и нигде не смотрел, не проверял. Мне интуитивно кажется, что это от 10-15 пользователей до 200-300. Я же буду рассматривать сегмент до 100 пользователей, так как почти все время работаю исключительно в этой нише. Проблемы и потребности более крупных компаний мне достоверно неизвестны. Хотя не уверен, что что-то будет принципиально отличаться от 100 человек, думаю подходы будут те же самые, только железо мощнее. Проблемы распределение нагрузок и кластеризации тут скорее всего еще не будут стоять.

Есть у нас небольшая компания на несколько десятков человек. Нам нужен почтовый сервер. Несмотря на то, что технологии давно шагнули вперед, предоставив массу всевозможных средств коммуникации, электронная почта все равно плотно стоит на своих позициях и не собирается их пока уступать. При этом в таком небольшом коллективе, больших требований к почтовому серверу не предъявляют. Чаще всего достаточно, чтобы почта просто работала, без особых функциональных изысков. Будет достаточно либо почтового клиента и протокола imap, либо web интерфейса. Хорошо, если будет возможность настроить автоответ, делать общие папки, единую адресную книгу, но и без этого можно прожить.

Среди всех возможных вариантов почтового сервиса, я выделяю 3 принципиально разных подхода к реализации необходимого функционала:

1. Сервисы на основе бесплатных почтовых служб гугла, яндекса или мейл.
2. Свой почтовый сервер на основе бесплатного ПО.
3. Exchange сервер от Microsoft.

Разберем каждый из них поподробнее.

Бесплатная почта от google, yandex и mail.ru

Сразу сделаю пару замечаний. Я не уверен, что у гугла сейчас можно зарегистрировать бесплатно корпоративную почту. Все, кто зарегистрировались раньше, пользуются бесплатно, а для новых пользователей теперь доступны только платные подписки. Но это не принципиально и не относится напрямую к теме статьи. Если гугл и стал полностью платным для бизнеса, то просто исключим его из нашего списка. Yandex и Mail.ru пока еще точно бесплатные. Сам я администрировал почтовые домены в google apps и в Яндексе. С biz.mail.ru не работал, только знаю, что там реализовано что-то похожее. Мне как-то сама компания не нравится еще со старых времен. Хотя сейчас они вроде как повернулись лицом к пользователям, но Амиго до сих пор жив здоров, так что повернулись еще не совсем.

Рассмотрим плюсы данных почтовых сервисов.

1. Самое главное преимущество — полноценная почта готова сразу после регистрации. Затрат на покупку железа и настройку нет никаких. Достаточно более ли менее продвинутого пользователя, который по инструкциям на сайте сможет подключить домен и создать почтовые ящики. И почтой уже можно пользоваться.
2. Легко администрировать и управлять пользователями, веб сервис предоставляет все необходимые оснастки для этого. Они удобны и интуитивно (хотя и не всегда) понятны.
3. Удобный и привычный web интерфейс. Все работает быстро, из любого места, где есть интернет и браузер. Есть хорошее мобильное приложение.
4. Широкий функционал, готовый сразу после создания ящика. Различные фильтры, сборщики почты, неплохой антиспам (у гугла) и многое другое.

Вроде все, ничего не пропустил. Казалось бы, плюсы очевидны и существенны. Но прежде чем делать выводы, рассмотрим минусы.

1. Вы не управляете этой почтой. Она принадлежит не вам, находится не на ваших серверах. Вы не знаете, что с ней происходит. Если у вас есть очень деликатная и приватная переписка, то возникают подозрения и сомнения насчет использования популярных почтовых служб. Это может показаться паранойей, но этот вопрос реально заботит пользователей и владельцев бизнеса, и его не стоит сбрасывать со счетов.
2. Вы не застрахованы от сбоев в системе и никак не можете их предотвратить. А сбои хоть и не часто, но бывают. Так как сервисы бесплатные, никто ничего вам гарантировать не будет. И если случится какой-то форс мажор и данные пропадут, вам просто скажут извините. Если у вас самих не очень надежная ИТ структура, вероятность технических проблем на вашем личном сервере возможно будет выше. Но вы этим можете управлять и теоретически сможете построить систему с удовлетворяющим вас уровнем надежности.
3. Неочевидны способы бэкапа и восстановления почтовых ящиков в таких сервисах. Бывают ситуации, когда из почтового ящика удаляют все письма. Допустим, сохранить их можно различными способами, просто скачав, а как потом обратно в ящик вернуть, сохранив все даты оригинальными?
4. Нет возможности анализировать непонятные ситуации. Например, вы отправляете письмо, а оно не приходит к адресату. Что делать? В случае с облачной почтой вы ничего не сделаете, так как у вас нет никаких инструментов для разбора ситуации. Попробуете просто отправить письмо из другого ящика. Бывает к вам не приходит письмо, и вы никак не можете понять, почему его нет. А дело может быть банально в неправильно настроенном фильтре. Это обычная ситуация, когда фильтров много, плюс если еще какие-то пересылки настроены. Без доступа к логам сервера бывает трудно разобраться в ситуации. А если есть лог почтового сервера, то сразу становится понятно, почему письмо не отправляется, или что с ним стало после получения. Можно наверняка узнать, получил ли удаленный сервер ваше письмо или нет.
5. Нет простых способов ограничить доступ к почтовым ящикам, например, только из локальной сети офиса. Почтовые ящики публичных сервисов доступны всегда через интернет. Есть возможность решить эту проблему в google apps через авторизацию в сторонних сервисах. В яндексе и мейле я не встречал возможности реализовать такой функционал.
6. Нужно еще понимать, что бесплатный сыр известно где бывает. До конца не ясно, как почтовые сервисы используют полученную от пользователей информацию. Хорошо, если только для показа им релевантной рекламы. Думаю, что не только для этого.

Когда я только начинал работать примерно 10 лет назад, вопроса какую почту использовать в организации, не стояло. Все ставили свои почтовые серверы и админили их. Бесплатные почтовые сервисы не предоставляли на тот момент для бизнеса никаких инструментов для управления почтой. Когда такие инструменты стали появляться, я думал, что скоро свои почтовые серверы никому не будут нужны, так как в них отпадет смысл. А все мои мучения (не люблю с ними работать) с почтовыми серверами станут бессмысленными.

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

Самым большим минусом мне видится отсутствие полноценных почтовых логов и хорошей схемы бэкапа. Разбирать проблемы неудобно без логов. Быстро и просто восстановить удаленное письмо в прежнее место не получится, хотя для опенсорсных почтовых серверов это простое дело.

Почтовый сервер на базе бесплатного ПО

Рассмотрим преимущества и недостатки собственного почтового сервера на базе бесплатного программного обеспечения. В принципе, сюда можно отнести и некоторые платные, например Kerio Mail Server, который тоже частенько используют. Думаю, его можно сюда же отнести, так как функционал он обеспечивает схожий. Я рассматриваю все почтовые сервера в совокупности, не выделяя отдельных представителей. Хотя в линуксе, кроме postfix и exim, лично я не встречал ничего в продакшене. Сам всегда использую postfix, так как привык к нему и знаю его неплохо. Рассмотрим внимательно плюсы таких серверов.

1. Вы полностью контролируете всю информацию, которая приходит по почте и хранится на вашем сервере. Вы можете ограничивать по своему усмотрению доступ к почте различными техническими средствами. Можете централизованно настраивать правила удаления, к примеру, приватной информации в письмах, по различным признакам, которые сами можете установить.
2. Уровень доступности почтового сервиса зависит только от вас. При должном подходе, вы можете обеспечить устраивающую вас надежность работы системы.
3. Гибкая система бэкапа. Средств для ее организации масса, в том числе бесплатных. Все зависит только от ваших потребностей, навыка и возможностей. Вы можете хранить различные срезы по датам, по ящикам, доменам, организовать любую подходящую схему.
4. Практически ничем не ограниченный функционал. В разумных пределах, конечно Вы можете создавать почтовые ящики с возможностью только локальной переписки, можете централизованно управлять приемом и отправкой почты, вести свои белые и черные списки. Можете настраивать различные ограничения по ящикам и доменам. Можете без проблем централизованно управлять дублированием почты нужных ящиков, делать всевозможные пересылки и много другое.
5. Все средства мониторинга работы сервера в ваших руках. Вы сможете разобраться с любой непонятной ситуацией, имея на руках логи почтового сервера. Эта служба хорошо логируется. У меня практически никогда не возникало проблем, когда не было понятно, куда пропало письмо. Чаще всего находятся следы и можно однозначно сказать, что стало с письмом.

Дальше пройдемся по минусам, которых не очень много, но они существенны.

1. Необходимо покупать или арендовать оборудование для организации своего почтового сервера. В случае с сервером на линукс, требования к производительности будут не большие. Мне обычно хватает виртуалки на 4 ядра и 4 гб оперативной памяти. Гораздо важнее дисковая подсистема. Тут чем быстрее диски, тем лучше. Не стоит забывать про бэкап. Для него тоже нужны ресурсы железа.
2. Настройка полноценного, многофункционального почтового сервера требует как минимум средних знаний в системном администрировании linux. То есть просто админ-эникей тут не подойдет. Нужен специалист с опытом. У него должна быть приличная зарплата. Если такого админа нет в штате, я рекомендую нанять кого-нибудь на разовую работу по настройке. Чаще всего после настройки, особой работы по поддержке сервера не требуется, если не будете менять функционал. Достаточно просто следить за свободным местом на дисках и управлять ящиками через web панель.
3. Удобство работы через web интерфейс будет ниже, чем в бесплатных почтовых службах. Как ни крути, но тот же gmail реализован очень удобно. Быстрый поиск, фильтры, сортировки, метки и т.д. Это реально удобно. Я очень привык и не могу пользоваться чем-то другим.

Такие минусы своего почтового сервиса видятся мне. Самый существенный для меня это последний. Сам привык работать с почтой через web. Почтовыми клиентами не люблю пользоваться, хотя приходится. Web интерфейсы к бесплатным почтовым серверам по удобству и быстродействию сильно не дотягивают до gmail или яндекс, сравнивать бессмысленно. И тем не менее, считаю, что для среднестатистической организации это наиболее оптимальный вариант. Пример настройки такого бесплатного почтового сервера — postfix + dovecot + postfixadmin + roundcube.

Плюсы и минусы Microsoft Exchange Server

У меня нет большого опыта администрирования exchange. Я его когда-то давно тестировал, когда решал, с какими почтовыми серверами буду работать. Устанавливал, изучал функционал. Потом один раз настроил почтовый сервер для организации. Они хотели именно exchange. Проблем не возникло, быстро настроил по многочисленным гайдам в интернете. Порог входа в настройщики почтового сервера exchange очень низкий. С базовым функционалом может справиться даже эникей.

Для средних организаций реально полезным и трудно заменимым функционалом считаю общие календари. И конечно же удобство интеграции с AD, если она есть. А чаще всего AD есть, так как я не представляю себе администрирование сети больше чем на 20-30 человек без Active Directory. Считаю, что тут бессмысленно экономить и надо покупать Microsoft Server.

Рассмотрим теперь плюсы и минусы Microsoft Exchange Server. Предупреждаю на всякий случай еще раз. Рассказываю только свое видение, опыта работы с сервером мало, поэтому хотел бы сам в комментариях получить замечания по нему, чтобы иметь более адекватную оценку этой системы. Плюсы Exchange:

1. Большой функционал при относительной простоте настройки. Развернуть сервер с базовым функционалом по силе любому админу. Причем этот базовый функционал может быть больше, чем у какой-нибудь сборке под линуксом.
2. Интеграция с Active Directory. Вы создаете новую учетную запись пользователя и почтовый ящик ему сразу же готов. Не нужно никаких специальных настроек, если у пользователя Microsoft Outlook. Подключение к серверу настраивается в несколько кликов мышкой.
3. Удобные средства администрирования в виде готовых оснасток Windows Server. Тут все традиционно для решений от Microsoft.

Минусы Exchange Server такие же характерные, как и плюсы, для большинства продуктов от Microsoft:

1. Цена, цена и еще раз цена. Microsoft Exchange Server стоит дорого. Нужно считать и прикидывать, будет ли оправдано его приобретать. Для использования всего заложенного функционала, необходимо будет на каждое рабочее место купить редакцию Microsoft Office c аутлуком в комплекте. Это еще дополнительные расходы.
2. Для хорошей производительности требуется значительно более мощное железо, по сравнению с серверами на линуксе. А для поддержки больших почтовых ящиков, например на 50 гигабайт, понадобится очень мощное железо. Хотя такие ящики для того же dovecot не представляют особых проблем. В exchange вы скорее всего будете использовать квоты для ограничения максимального размера почтового ящика.
3. Для бэкапа скорее всего придется так же приобретать приличной мощности железо и платный софт. Тут я только предполагаю, реально я не знаю, что нужно для удобного бэкапа exchange. Знаю платный софт от популярных вендоров. Возможно есть что-то бесплатное.

Вывод по Exchange Server у меня таков — он почти во всем хорошо, кроме цены. Если бы он был бесплатен, я скорее всего пользовался бы именно им. По вполне объективным причинам, это невозможно. Хороший и удобный софт сам по себе не появляется. Его нужно создать, а на это потратить средства, которые захочется вернуть с прибылью.

На сегодняшний день, с учетом стоимости Microsoft Exchange Server и Microsoft Office, я не использую эти продукты Microsoft. Мало кто согласен выложить необходимую сумму для почтового сервера. Мне бы хотелось посмотреть на Exchange поближе в реальных условиях хотя бы человек на 60-80, чтобы оценить более объективно этот сервер. Но пока такой возможности не представилось.

Заключение

Подведу итог своим рассуждениям о почтовом сервере для небольшой среднестатистической организации. Хотя вывод, думаю, уже и так понятен. Сам я предпочитаю второй описанный мной вариант — почтовый сервер на базе бесплатного ПО на linux. Но другие два варианта я бы не стал сбрасывать со счетов. Бесплатная почта от публичных сервисов будет однозначна удобна для совсем небольшого коллектива — на 10-15 человек. Городить свой сервер для такой численности нет никакого смысла.

Exchange Server я бы порекомендовал использовать, если есть и не жалко потратить средства на его приобретение. Продукт однозначно удобный, функциональный и простой в настройке и администрировании. Говоря простой, нужно понимать, что это условно. Конфигурации могут быть и очень сложными, но в данном случае я рассматриваю начальный уровень.

Сообщение Выбор почтового сервера для среднего бизнеса — свой или облачный появились сначала на Clip-Clap.

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

Настроить почтовый сервер не самая простая задача. Лично мне не нравится с ними возиться из-за большого количества всевозможных настроек и элементов, которые нужно между собой связать. Чуть позже я детально разберу все самое основное, что требуется для полноценного почтового сервера. Недавно мне на глаза попалась готовая сборка для почтового сервера под названием iRedMail. Я решил на нее внимательно посмотреть, потестировать. В ее основе традиционный smtp сервер — postfix. Она мне понравилась, я решил, что ей вполне можно пользоваться. Дальше расскажу о ней поподробнее.Если вы хотите полностью самостоятельно настроить свой почтовый сервер, то воспользуйтесь моей отдельной статьей на эту тему — настройка почтового сервера postfix + dovecot. В ней реализован примерно такой же функционал, что и в данной статье, но без iredmail. Все установлено и настроено руками самостоятельно.

Что такое iRedMail

Расскажу своими словами что такое iRedMail и как ей пользоваться. Это набор скриптов для автоматической установки и базовой настройки всех компонентов, необходимых для полноценной работы почтового сервера. Вот список основных программ, которые будут установлены вместе с iRedMail:

1. Postfix — сердце почтовой системы, вокруг которого настраивается все остальное.
2. Dovecot — imap сервер для доступа к почтовым ящикам пользователей.
3. Web сервер — apache+ php + mysql для вспомогательных функций.
4. Roundcube и SOGo — веб интерфейсы для доступа к почте. Пользоваться можно любым, что больше понравится.
5. Awstats — статистика работы почтового сервера.
6. Amavisd — модуль связи почтовой системы и дополнительных обработчиков почты (антиспам, антивирус и т.д.)
7. SpamAssassin — бесплатный антиспам для почты.
8. ClamAV — бесплатный антивирус.
9. Greylist — эффективная система борьбы со спамом.

Это основные элементы. В сборке еще много вспомогательных системных настроек и утилит, которые упрощают настройку сервера. Например, в iRedMail включены:

• готовые правила для iptables
• fail2ban для защиты сервера от брутфорса
• logwatch для наблюдения за логами сервера
• наборы cron скриптов для обслуживания и бэкапа сервера
• модуль iRedAPD для удобного управления функционалом почтового сервера
• готовые ssl сертификаты и dkim ключ.

Чем же мне понравился iRedMail?

1. Во-первых, в нем есть все, что нужно для почтового сервера. Очень грамотно и четко подобраны все элементы.
2. Во-вторых, в нем нет никаких импровизаций и свистелок. Весь софт стандартный, все конфиги стандартные. Их легко читать и править. По сути, iRedMail это скрипт по автоматической установке и настройке стандартного софта. После установки вы можете по своему усмотрению донастроить или изменить все, что вам покажется необходимым. Именно этим я и займусь в своей статье.
3. В-третьих, выполняются полезные системные настройки сервера, избавляющие вас от рутинных операций, которые пришлось бы делать вручную.
4. В-четвертых, в комплекте идет написанный на питоне модуль iRedAPD для управления всем установленным хозяйством. Это полезно тем, кто не очень понимает, как работает весь тот комплекс, который будет установлен. С помощью этого модуля можно очень быстро и просто, к примеру, отключить антивирус или антиспам, если он вам не нужен. При этом вам не надо будет разбираться во внутренней работе этих модулей.

Теперь ложка дегтя. В бесплатной версии iRedMail нет почти никаких настроек. Через веб интерфейс вы сможете только добавить нового пользователя почты и все. Если нужно что-то большее, то выкручивайтесь как умеете. В данной конфигурации почтового сервера все управление происходит через базу данных mysql. Вы можете вручную через phpmyadmin сделать все, что угодно. Платная версия iRedMail предлагает всего лишь навсего удобную панель управления всеми настройками, которая избавит вас от необходимости лазить в базу напрямую.

Сначала я решил, что меня устроит вариант правки базы данных через phpmyadmin. Но когда я попробовал, я понял, что это неудобно. Такой сервер после меня не сможет никто обслуживать. Да и самому руками забивать поля в базе данных было неудобно. Выход из сложившейся ситуации есть. Я расскажу, как получить бесплатно часть возможностей платной версии, не покупая ее. Да, придется немного потрудиться, но это не сложно, я все расскажу.

Как я уже сказал, бесплатная версия веб панели позволяет только создать пользователя. Для нормальной работы с пользователями не хватает создания алиасов и перенаправления почты из одного ящика в другой. Данный функционал реализован в бесплатной панели управления postfix — postfixadmin. Ее мы и прикрутим к iRedMail. Она не без проблем, но все же устанавливается и нормально работает вместе с веб панелью iRedMail, используя одну базу данных mysql, не мешая друг другу.

Управлять модулями сборки мы будем в iRedAPD в консоли сервера с помощью его конфигурационных файлов. Разработчики любезно оставили весь рабочий функционал, никак его не ограничив. Платная версия представляет только удобное управление. Это позволит нам получить весь имеющийся функционал бесплатно.

Вкратце описал что такое iRedMail. Подозреваю, что тем, кто никогда не настраивал почтовые сервера многое не понятно. Но ничего не поделать. Простых путей в освоении работы почты нет, придется разбираться. А для тех, кто понимает о чем идет речь, стало понятно, что такое iRedMail и как его можно использовать. Мне было полезно просто заглянуть в некоторые конфиги, чтобы посмотреть, как реализуется та или иная возможность.

Требования для почтового сервера

Начнем потихоньку подготовку к настройке нашего почтового сервера. Первым делом нужно подготовить DNS записи. Это очень важно. Без правильной наcтройки dns записей нормально работать сервер не будет. Вернее, работать то он будет, но ваша почта может улетать в спам у принимающей стороны. Я буду рассказывать все на конкретном примере. У меня есть домен zeroxzed.ru. Его почта уже привязана к другому почтовому серверу, я не хочу его менять. Для написания этой статьи, я сделал поддомен m.zeroxzed.ru. Для демонстрации работы нет никакой разницы, используется домен второго уровня или третьего, как в моем случае. В этом поддомене будет находиться мой почтовый сервер srv.m.zeroxzed.ru. Это имя физического сервера, на котором будет работать почта. Почтовые ящики у меня будут вида user1@m.zeroxzed.ru. Внешний ip адрес на котором будет работать сервер — 188.45.19.125.

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

Подробнее о типах DNS записей читайте на википедии. В случае с доменом первого уровня, например site.ru и именем почтового сервера srv.site.ru, вам нужны будут только 2 записи:

Но это не все. К сожалению, одних DNS записей не достаточно. Для вашего внешнего IP адреса должна быть прописана обратная зона — PTR. В обратной зоне ip-адресу ставится в соответствие доменное имя. То есть вашему IP адресу должно соответствовать доменное имя srv.site.ru. Настройками обратной зоны в подавляющем большинстве случаев вы не можете управлять. Для ее изменения нужно обратиться к вашему провайдеру, который выделил вам внешний IP и сказать ему, что вы хотите настроить почтовый сервер и вам необходимо прописать обратную зону с именем srv.site.ru на внешний IP адрес. Это обычная просьба, и тех поддержка без проблем сделает то, что вы просите, если они предоставляют такую услугу. Чаще всего провайдеры, работающие с юридическими лицами, такую услугу предоставляют. Домовые провайдеры для физиков нет.

Проверить обратную зону для домена можно в консоли сервера с помощью команды host. Вот пример для моего внешнего IP. Я не стал просить провайдера прописывать обратную зону для тестового сервера, она не правильная. Привожу просто для примера:

# host 188.45.19.125
125.19.45.188.in-addr.arpa domain name pointer host-188-45-19-125.beirel.ru.

Это пример не настроенной обратной зоны. Возьмем для примера какой-нибудь сайт, у которого правильно настроены все DNS записи и обратная зона. Например это будет raiffeisen.ru. Смотрим его записи.

Здесь все четко — есть MX запись с именем почтового сервера, есть IP адрес этого сервера и обратная зона. Все это однозначно соответствует друг другу. Иногда люди путают, называют, к примеру, сервер mail.site.ru, а обратную зону делают просто site.ru или srv.site.ru. Вроде все правильно, домен один и тот же, но соответствие не полное. Чтобы все было правильно, должно быть полное соответствие всех записей — A, MX, PTR. Очень много спам фильтров используют эти записи для проверки домена отправителя на полное соответствие всех записей.

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

После того, как закончите с DNS и PTR можно приступать к настройке самого сервера.

Установка iRedMail

Я буду настраивать почтовый сервер на CentOS 7. Если у вас еще не готов сервер, то рекомендую мои материалы — установка и базовая настройка CentOS. Каких-то особых требований к установке нет. Для системы достаточно раздела 20-30 гигабайт. Для почтовой базы рекомендую отдельный раздел с достаточным свободным местом. Начать можно хотя бы с 200 гигабайт. Но это не обязательно, для теста можете все сделать на одном разделе. Потом, если появится необходимость, просто перенесете всю базу в другое место с помощью символьной ссылки. Когда все будет готово, приступайте к установке iRedMail.Если не будете смотреть мою статью по базовой настройке, то не забудьте отключить SELinux, без этого iRedMail нормально работать не будет. Это обязательное требование, указанное на сайте разработчика. Так же не рекомендую отключать firewalld, если не хотите настраивать iptables вручную, iredmail автоматически настраивает iptables.Второй важный момент. Перед началом установки почтового сервера, убедитесь, что указали корректный hostname для своего сервера, равный DNS записи, которую сделали ранее. Если забыли это сделать во время установки, то смотрите в моей статье про сетевые настройки centos как изменить hostname.

Установка неплохо описана на самом сайте продукта. Можете подсматривать туда, если что-то будет непонятно. Идем на страницу загрузки и копируем ссылку для загрузки.

Скачиваем скрипт установки iRedMail и распаковывем.

# cd /root && wget https://bitbucket.org/zhb/iredmail/downloads/iRedMail-0.9.5-1.tar.bz2
# tar xjf iRedMail-*

Переходим в каталог и запускаем установку:

# cd iRedMail-* && bash iRedMail.sh

Первым вопросом будет каталог для хранения почтовой базы. Можете оставить по-умолчанию /var/vmail, либо выбрать свой. Потом нужно выбрать веб сервер — nginx или apache. Я рекомендую выбрать apache, так проще будет установить и настроить phpmyadmin и postfixadmin. Но если вам непременно нужен nginx, то можно выбрать и его, никаких проблем с ним не будет, если умеете настраивать. В качестве базы данных я выбираю mariadb.

Затем нужно будет указать имя почтового домена. Обращаю внимание, что это не имя сервера, а именно домена для почты. В моем случае это m.zeroxzed.ru. Если у вас домен второго уровня, то это будет site.ru. Дальше нужно указать пароль от административной учетной записи — postmaster@m.zeroxzed.ru. На последнем этапе выбираем необходимые компоненты. Я рекомендую выбрать все, потом ненужное можно отключить.

Еще раз проверяете настройки и если все в порядке, то начинается установка.

В конце установки будет задан вопрос, хотим ли мы применить предлагаемые правила Firewalld. Соглашаемся.

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

Перезагружаем сервер, чтобы все службы корректно запустились. Идем в свой почтовый ящик пользователя postmaster в roundcube webmail или SOGo groupware и читаем созданные автоматически письма. Заодно посмотрите, какой вам интерфейс больше нравится и чем будете пользоваться. Мне лично roundcube нравится больше.

В первом письме вся техническая информация по установленным компонентам, в том числе необходимые пароли. Это письмо обязательно сохраните и никому не показывайте. Копия этой информации есть в файле /root/iRedMail-0.9.5-1/iRedMail.tips. Эта информация нам понадобится в дальнейшем.

На текущий момент почтовый сервер полностью готов и работоспособен. Вы можете зайти в панель администрирования по адресу https://имя_сервера/iredadmin/ и создать нового пользователя. Добавим пользователя user1.

Если поле Mailbox Quota оставить пустым, то размер ящика будет неограниченным. Теперь можно зайти этим пользователем в webmail и отправить кому-нибудь письмо. Я для примера отправлю письмо на ящик zeroxzed@gmail.com. Вот как будет выглядеть лог /var/log/maillog во время корректной доставки письма.

Я сразу ввожу вас в курс дела, чтобы вы понимали, как работает почта, куда смотреть если что-то не так. Во время администрирования почтового сервера частенько придется заглядывать в логи для разбора различных ситуаций. По логу postfix видно, что сервер gmail корректно принял сообщение без каких-либо предупреждений. Письмо дошло до адресата. Теперь ответим с ящика zeroxzed@gmail.com и посмотрим на лог.

Все в порядке, письмо доставлено пользователю user1. На текущий момент почтовый сервер postfix на CentOS полностью работоспособен и готов обслуживать пользователей. Если вам достаточно текущего функционала, то можно дальше не читать и пользоваться тем, что есть. Но я советую все же почитать. Сейчас не хватает нескольких очень популярных настроек.

Обзор возможностей почтового сервера

Посмотрим, что в данный момент умеет наш почтовый сервер на centos со сборкой iredmail, чтобы мы понимали, на что можно рассчитывать и чего ждать от сервера.

Graylist

Сразу расскажу о настроенной и активированной функции Greylist, которая вызовет у неподготовленного администратора массу вопросов. Технология называется серый список, подробно о ней можно почитать на википедии. Расскажу своими словами без технической информации как это работает и в чем могут быть проблемы. Когда вам кто-то первый раз отправляет письмо, почтовый сервер его сразу не принимает, а говорит удаленному серверу, подожди, попробуй еще раз через несколько минут. Удаленный сервер понимает эту просьбу и через несколько минут отправляет письмо еще раз. И только после этого наш сервер принимает письмо и добавляет адрес сервера отправителя в белый список на 30 дней, чтобы больше не делать такую проверку и принимать письма сразу.

Этот механизм очень хорошо отсеивает спам, так как спамеры чаще всего не делают повторных попыток отправить письмо. Не все, конечно, но некоторая часть точно. По моему опыту могу сказать, что большая часть спама отсеивается технологией graylist. Но есть несколько серьезных минусов, из-за которых лично я предпочитаю серые списки не использовать.

1. Не все серверы корректно отрабатывают просьбу на повторную доставку письма. Кто-то может через 5 минут повторно отправить письмо, а кто-то через час. При этом пользователь сидит и ждет свое письмо. Это очень неудобно, особенно если менеджер разговаривает по телефону и пытается обменяться тестовыми письмами с новым клиентом. Да, задержка будет только в первый раз, но все равно это неудобно. Даже 5 минут иногда раздражает ждать.
2. Сейчас распространены облачные технологии и многие пользователи используют облачные почтовые системы. У таких систем много почтовых серверов, и отправка производится каждый раз с разного. Домен может быть один и тот же, но полное имя сервера будет другое. Технология graylist запоминает точное имя сервера и ждет, что повторное письмо придет с этого же сервера. Но может получиться так, что первое письмо придет с сервера srv1.pochtamail.ru, а повторное с srv2.pochtamail.ru. В итоге повторное письмо тоже попадет в серый список и наш сервер будет ждать повторное письмо уже от второго сервера. А следующее письмо может прийти с третьего сервера и так далее. В общем, письмо можно ждать сутки и более, пока не придет пара писем с одного и того же сервера. Всех таких клиентов можно добавлять в белый список по имени домена и для них серый список вообще не будет работать, но это ручной труд и заранее не узнаешь с кем будут проблемы. Добавлять начинаешь уже тогда, когда пользователи жалуются на то, что письмо не доходит.

Возможно вторую проблему как-то можно решить, изменив механизм работы graylist, но по умолчанию он работает именно так, как я описал. Дальше я расскажу, как включать и отключать серые списки.

Переадресация почты

Наш почтовый сервер способен переадресовывать почтовые сообщения. Например, у вас есть пользователи user1 и user2. Можно сделать так, что при отправке письма пользователю user1, копия этого письма будет отправлена user2. То есть письмо получат оба пользователя. Пользователь user1 может не знать, что его почта копируется куда-то еще.

Мы можем создать алиасы и направлять с них почту в несколько почтовых ящиков. Например, можно сделать алиас sale@site.ru. При отправке письма на этот адрес, письмо отправляется пользователям user1 и user2.

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

Весь этот функционал невозможно включить через бесплатную панель администрирования. Нужно либо покупать платную, либо руками делать настройки в mysql базе. Ниже я расскажу, как это делать удобно.

Антивирус clamav

В сборку iredmail включен бесплатный антивирус clamav. Лично я не вижу в нем никакого смысла. По почте вирусы давно уже не рассылают, а если рассылают, то ссылки на них. Лишнюю нагрузку на систему в виде антивируса считаю ненужной. Если у вас другое мнение, поделитесь и аргументируйте. Расскажу позже, как отключить антивирус.

Антиспам SpamAssassin

Модуль SpamAssassin — самое популярное бесплатное средство для борьбы со спамом. По идее, он не плохо работает, но требует некоторого внимания к себе, так как работает по оценочному признаку и иногда может делать ложные срабатывания. Нужна некоторая калибровка на месте для эффективной работы. Мне всегда было лень этим заниматься. Не рекламы ради, а для информации скажу, что самым эффективными и недорогим средством для борьбы со спамом я считаю Касперский антиспам. Чаще всего я использую его. Он реально хорошо режет спам и не дает ложных срабатываний. Удобное решение из серии поставил и забыл, только раз в год ключи продлевай. Предлагаю на местах посмотреть на SpamAssasin и решить, нужен он вам или нет. Отключить при случае не проблема.

Общая адресная книга

Удобный функционал, но я пока не разбирался подробно как это работает. Подозреваю, что если использовать в качестве базы данных не mysql, а ldap, то можно без проблем подключить глобальную адресную книгу через ldap в любом почтовом клиенте, где это реализовано. В случае mysql работает по-умолчанию адресная книга по всем пользователям домена в веб интерфейсе SOGo. Там можно искать пользователей по домену в соответствующем разделе.

В roundcube такого функционала я не нашел. Так что этот вопрос открытый. Функция удобная и нужная, возможно позже я отдельно рассмотрю этот момент. Я всегда использую в качестве адресной книги ldap каталог Active Directory, если в организации настроен домен. Это удобно. Все пользователи там заведены, достаточно просто указать им email и подключать адресную книгу в почтовых клиентах.

Whitelist и Blacklist

В iRedMail есть возможность использовать белые и черные списки отправителей и получателей почты. Управлять этими функциями без платной панели управления неудобно. Необходимо все выполнять в консоли сервера. Но по моему опыту такие возможности нужны не очень часто, поэтому можно иногда залезть на сервер и заблокировать кого-нибудь. Я расскажу как это сделать. Например, вы можете какому-то конкретному пользователю запретить отправку писем, не трогая его аккаунт. Иногда это бывает полезно.

Throttle — лимиты

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

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

Включение и отключение модулей почты

Разберемся с тем, как нам включать или отключать ненужные модули. В комплекте iRedMail есть написанный на питоне модуль iRedAPD. У него есть конфигурационный файл, который управляет основными возможностями почтового сервера. Идем в консоль сервера. В папке /opt/iredapd файл settings.py с основными настройками. Я рекомендую отключить все те модули, которыми вы не будете пользоваться. Это упростит конфигурацию системы, уменьшит нагрузку, сделает проще разбор логов. В конфигурационном файле есть параметр plugins.

plugins = ["reject_null_sender", "reject_sender_login_mismatch", "greylisting", "throttle", "amavisd_wblist", "sql_alias_access_policy"]

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

# service iredapd restart

Я не разбирался с работой лимитов на отправку и получение почты. Точнее я не смотрел, как ими управлять без платной панели. В связи с этим, данный модуль можно тоже отключить. Он называется throttle. Остальное можно оставить.

Теперь разберемся, как отключить SpamAssassin и ClamaV, если вы не будете ими пользоваться. Они оба завязаны на модуль Amavisd, отключаются в его настройках. Открываем его конфиг

# mcedit /etc/amavisd/amavisd.conf

Находим там строки:

# @bypass_virus_checks_maps = (1); # controls running of anti-virus code
# @bypass_spam_checks_maps = (1); # controls running of anti-spam code

И убираем комментирование с них (удаляем # в начале строки). После этого перезапускаем amavisd.

# systemctl restart amavisd

Антиспам и антивирус отключили. Обращаю внимание, что отключать антиспам не обязательно. Он вполне нормально работает, рекомендую его потестировать и посмотреть результат. Я просто показываю возможности системы, но не призываю делать именно так, как я показываю.

Теперь можно поотправлять тестовые письма и убедиться, что отключенные модули не работают. Я не буду приводить логи, чтобы не загромождать статью, она и так очень большая получается. Отмечу только, что после отключения антиспама в логах не будут видны баллы, которые система назначает каждому письму. А после отключения антивируса больше не будет соответствующих служебных заголовков в письмах. После отключения greylist письма от любого сервера будут сразу же доставляться получателям.

Разобрали управление основными функциями нашей почтовой системы. Теперь давайте расширим ее функционал.

Установка postfixadmin

Я предлагаю установить панель управления почтового сервера postfix — postfixadmin. Ее принципиальная особенность от того, что предлагает бесплатная версия iRedMail — возможность создавать алиасы и настраивать переадресацию. У нас уже есть настроенный веб сервер apache с php, но его текущая конфигурация не позволяет нормально использовать postfixadmin, нужно разрешить несколько заблокированных опций. Для этого открываем файл настроек php — /etc/php.ini, находим там параметр disable_functions и убираем из него несколько значений: proc_open, proc_close, php_uname, escapeshellarg. Их быть в указанной строке не должно. После этого перезапускаем apache.

# apachectl restart

Перед тем, как поставить postfixadmin, установим phpmyadmin для работы с базой данных mysql. Нам это пригодится в будущем. Подробно вопрос установки phpmyadmin я рассматривал в отдельной статье, если что-то не получается, посмотрите там. Сейчас просто ставим без пояснений и дополнительных настроек.

# yum install phpmyadmin

Открываем файл /etc/httpd/conf.d/phpMyAdmin.conf и разрешаем подключаться с вашего ip адреса, редактируя одну строку.

# mcedit /etc/httpd/conf.d/phpMyAdmin.conf

Require ip ваш_ip_адрес

Перезапускаем apache для применения настроек. Зайти в phpmyadmin можно по адресу http://имя_вашего_сервера/phpmyadmin Пароль пользователя root от mysql есть в первом письме в ящике postmaster.

Теперь у нас все готово для установки postfixadmin. Скачиваем его и распаковывем.

# cd /root && wget https://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin-3.0/postfixadmin-3.0.tar.gz
# tar -xvzf postfixadmin-*

Переносим папку postfixadmin в директорию веб сервера и делаем владельцем пользователя apache.

# mv /root/postfixadmin-3.0 /var/www/postfixadmin
# chown -R apache. /var/www/postfixadmin

Создаем конфигурационный файл httpd для postfixadmin.

# mcedit /etc/httpd/conf.d/postfixadmin.conf

Alias /postfixadmin /var/www/postfixadmin
<Directory /usr/share/phpMyAdmin/>
 AddDefaultCharset UTF-8
  <IfModule mod_authz_core.c>
   <RequireAny>
    Require ip ваш_ip_с_которого_заходите_на_сервер
   </RequireAny>
  </IfModule>
</Directory>

Перезапускаем httpd.

# apachectl restart

Теперь надо отредактировать конфигурационный файл postfixadmin — /var/www/postfixadmin/config.inc.php.

# mcedit /var/www/postfixadmin/config.inc.php

Изменяем значения указанных строк, остальное на свое усмотрение. Там неплохо описаны все параметры.

$CONF['configured'] = true;
$CONF['default_language'] = 'ru';
$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'root';
$CONF['database_password'] = 'hRm3StSuY0WSpk0kkl9OX1Xjv8';
$CONF['database_name'] = 'vmail';
$CONF['encrypt'] = 'dovecot:SSHA';
$CONF['dovecotpw'] = "/usr/bin/doveadm pw";

Пароль пользователя mysql root ищите в первом письме в ящике postmaster. Теперь заходим по адресу http://имя_вашего_сервера/postfixadmin/setup.php и запускаем установку. Если все в порядке, то у вас начнется обновление базы данных, которое завершится ошибкой:

DEBUG INFORMATION:
Invalid query: Duplicate key name 'domain'

Check your error_log for the failed query.

Инсталлятор хочет установить индексы в таблице, но они там уже есть. Нам надо их удалить, чтобы корректно завершить установку. Для этого идем в phpmyadmin, открываем базу vmail и выполняем в ней запрос.

DROP INDEX domain on mailbox;
DROP INDEX domain on alias;

После этого обновляем страницу http://имя_вашего_сервера/postfixadmin/setup.php, установка должна завершиться без ошибок. В конце вас попросят ввести пароль для завершения настройки postfixadmin. Его нужно запомнить, он пригодится дальше при создании учетной записи администратора.

У вас сгенерируется строка:

$CONF['setup_password'] = 'cf1b85fba4ee3ffcc9efd8d098e335:ef221c19697ef4208b52d61ab75b0586560b9b';

Ее нужно изменить в /var/www/postfixadmin/config.inc.php, записав новое значение. Теперь используя ранее придуманный пароль вам нужно добавить учетную запись администратора postfixadmin. Я рекомендую использовать для этого уже существующую учетную запись postmaster. Хотя это не обязательно. Вы можете в web панели iredmail сделать нового пользователя и воспользоваться этой учетной записью. Заходим в postfixadmin по адресу http://имя_вашего_сервера/postfixadmin

Все, установка и настройка postfixadmin завершена. Теперь покажу, что мы в итоге получили. Во-первых, тут вы можете создавать новых пользователей и управлять существующими. Создадим новый алиас test@m.zeroxzed.ru и направим всю почту, отправленную на этот адрес в почтовый ящик user1@m.zeroxzed.ru. Для этого идем в раздел Обзор -> Создать алиас и создаем его.

Почтовый ящик user1 должен существовать. Теперь отправим письмо на адрес test@m.zeroxzed.ru и посмотрим лог.

Письмо было доставлено в почтовый ящик user1. Здесь я заметил одну неприятную особенность. В логе нигде не отражено, что изначально письмо было отправлено на адрес test@m.zeroxzed.ru, указан только конечный получатель. Это неудобно, когда нужно будет разбирать какую-нибудь ситуацию по логам. Я сейчас не смог вспомнить, от чего зависит такое поведение, но когда я руками все настраиваю, потом в логах вижу сообщение о том, что изначально письмо было отправлено на test, а потом уже доставлено в user1. С этим надо будет разобраться отдельно. Буду рад подсказке по этому поводу, чтобы самому не искать.

Теперь сделаем так, чтобы копия всех писем, отправленных user1 падала в ящик к user2. Для этого открываем список всех пользователей домена, выбираем нужного пользователя и жмем Алиас.

В поле Кому вводим ящик user2@m.zeroxzed.ru. Отправляем снова письмо на user1 и смотрим лог.

Видно, что письмо было доставлено обоим пользователям.

Через postfixadmin вы можете добавлять новых администраторов для управления доменом, новые виртуальные домены, создавать пользователей и алиасы. В принципе, web интерфейс бесплатной версии iredmail вам больше не нужен. Его функционал беднее. Postfixadmin полностью его заменяет. Остальные возможности postfixadmin посмотрите сами, расписывать не хочется. Статья и так получается очень большой, а разбивать на части не хочется, чтобы не нарушать целостную картину.

Тонкая настройка почтового сервера

В завершении хочу затронуть несколько полезных моментов в настройке почтового сервера на базе postfix, которые не были рассказаны в других разделах.

Максимальный размер письма

Важным параметром является максимально разрешенный размер письма. В бесплатной версии для его изменения нужно отредактировать конфигурацию postfix. Сделать это не трудно. За размер письма отвечает параметр в файле /etc/postfix/main.cf — message_size_limit = 15728640. Размер указан в байтах. Значение по-умолчанию 15 мегабайт. Мне кажется удобнее будет установить его в 20 мегабайт. Слишком большое значение не ставьте, пользователи забьют свои почтовые ящики огромными вложениями и это осложнит администрирование сервера. После изменения параметра необходимо перечитать конфигурацию postfix.

# postfix reload
postfix/postfix-script: refreshing the Postfix mail system

Запрет на отправку писем конкретного пользователя

Иногда бывают ситуации, когда нужно запретить отправку писем какому-нибудь пользователю. В iRedMail это можно сделать с помощью встроенного средства белых и черных списков. Для его работы должен быть включен модуль amavisd_wblist. Переходим в папку /opt/iredapd/tools/ и используем скрипт wblist_admin.py для добавления запрета отправки писем.

# cd /opt/iredapd/tools/
# python wblist_admin.py – add – blacklist user1@m.zeroxzed.ru

Этой командой мы запретили пользователю user1@m.zeroxzed.ru отправлять письма. При отправке письма он получит сообщение об ошибке, а в логе появится следующая запись.

При этом входящая почта будет нормально работать. Посмотреть весь черный список можно командой:

# python wblist_admin.py – list – blacklist

Удаляем из черного списка командой:

# python wblist_admin.py – delete – blacklist user1@m.zeroxzed.ru

К сожалению, во время тестирования заметил, что черный список на отправку работает только при работе из веб интерфейса. При подключении извне с помощью почтового клиента письма продолжают отправляться. Я потратил некоторое время на тесты и попытку разобраться, но так и не смог понять в чем дело. Для тех, кто разбирается в теме и будет пытаться решить этот вопрос подскажу, что разница между веб интерфейсом и почтовым клиентом в том, что первый способ подключения относится к mynetworks = 127.0.0.1, а удаленное подключение это sasl_authenticated. Во всех restrictions в postfix оба эти способа идут по порядку и должны по идее обрабатываться одинаково, один за другим, но не все так просто, раз существует проблема. White/Blacklist хранятся в mysql в базе amavisd. У меня, к сожалению, нет времени подробно разобраться с этой особенностью.

Этот же функционал можно реализовать стандартными возможностями postfix без сторонних модулей. Я этот делал, когда было нужно. Если получится, то расскажу об этом со временем.

Каталог с почтовыми ящиками

По-умолчанию, вся почта хранится в каталоге /var/vmail/vmail1/m.zeroxzed.ru, а дальше немного странная структура. Например, ящик пользователя user1 будет находиться по адресу /var/vmail/vmail1/m.zeroxzed.ru/u/s/e/user1-2016.11.06.14.08.39, пользователя postmaster — /var/vmail/vmail1/m.zeroxzed.ru/p/o/s/postmaster-2016.11.06.13.22.15. Со слов разработчиков, такая структура позволяет повысить быстродействие системы. Наверно это актуально, когда у вас тысячи ящиков. Мне кажется гораздо удобнее структура, когда все ящики лежат в одной папке с именем домена. Даты создания ящиков лично мне тоже не нужны.

Уточню, что описанная выше проблема актуальна только для ящиков, созданных web панелью iRedMail. Postfixadmin по-умолчанию создает ящики так, как мне нужно — все в папке с именем домена. Так что если вы будете пользоваться только postfixadmin, можно ничего не делать. Но я для порядка изменю настройки iredmail на всякий случай, чтобы не было путаницы.

Чтобы привести структуру новых создаваемых ящиков к привычному виду, отредактируем файл /var/www/iredadmin/libs/default_settings.py. Изменим там два параметра.

# mcedit /var/www/iredadmin/libs/default_settings.py

MAILDIR_HASHED = False
MAILDIR_APPEND_TIMESTAMP = False

Теперь новые почтовые ящики будут располагаться по адресу /var/vmail/vmail1/site.ru, не зависимо от того, где были созданы. Для того, чтобы изменить пути уже созданных ящиков, необходимо отредактировать путь в mysql базе vmail, в таблице mailbox, в столбце maildir.

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

Создание копий всех почтовых сообщений postfix

Воспользуемся штатной возможностью почтового сервера postfix — bcc. С помощью этой настройки мы сможем направить всю входящую и исходящую почту в отдельные почтовые ящики. Создадим их перед этим. В моем случае ящики будут называться:

• all-in@m.zeroxzed.ru для входящей почты
• all-out@m.zeroxzed.ru для исходящей почты

Идем в phpmyadmin, открываем базу vmail и выполняем в ней запрос:

INSERT INTO sender_bcc_domain (domain, bcc_address, active, created) VALUES ('m.zeroxzed.ru', 'all-out@m.zeroxzed.ru', 1, NOW());
INSERT INTO recipient_bcc_domain (domain, bcc_address, active, created) VALUES ('m.zeroxzed.ru', 'all-in@m.zeroxzed.ru', 1, NOW());

Первая строка для сбора всей исходящей почты, вторая для сбора входящей. Не забудьте изменить названия домена и ящиков на свои значения. Если у вас несколько виртуальных доменов, делайте для каждого отдельные ящики. Можно сделать вообще просто — собирать абсолютно всю почту, проходящую через postfix в один ящик. Но это очень неудобно. Будет огромный ящик с тысячами файлов внутри. Там банально даже найти что-то станет проблемой, так как поиск будет выполняться очень долго. Я когда только начинал настраивать почтовые сервера так сделал, но быстро понял ошибку и переделал.Я рекомендую использовать такие ящики для оперативного доступа к почте, чтобы быстро проверить, кому что приходило или уходило, если вдруг возникает вопрос, что пользователь не может найти письмо. Иногда он может либо по ошибке, либо специально, его удалить. Чтобы быстро осуществлять поиск по ящику, там не должно быть много писем. Я рекомендую скриптами регулярно архивировать почту из таких ящиков и складывать в архивы, а в ящике оставлять комфортное для быстрого поиска количество писем. В зависимости от загрузки сервера, это может быть архив за пару недель или пару месяцев.

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

Настройка автоответчика

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

Настраивается автоответ через roundcube. Для этого заходите под своей учетной записью, переходите в раздел настройки и там выбирайте меню Отпуск.

На вкладке дополнительные настройки можно указать адрес для отправки копий.

Сохраняете настройку и проверяете на всякий случай. Все должно работать. Загляните так же в лог и убедитесь, что письмо отправляется теперь помимо адресата, бэкапных ящиков, еще и в ящик заместителя. Хорошая и полезная возможность, рекомендую ее использовать. Напишите небольшую инструкцию для пользователей, пусть сами заходят и настраивают автоответ и переадресацию.

На этом, пожалуй, заканчиваю настройку почтового сервера на centos на базе iredmail и postfix.

Анализ лог файлов postfix с помощью webmin

Для поиска информации в лог файле poistfix удобно использовать плагин webmin для просмотра системных логов. После установки в разделе System -> System logs можно посмотреть системные логи, в том числе maillog. Удобство этого модуля заключается в том, что зная, к примеру, id писmма, можно вывести все строки с этим id. Это очень удобно для анализа различных ситуаций.

Лог файл почтового сервера очень насыщен и там на каждую секунду куча событий. Без удобного фильтра сообщений трудно разбираться в ситуации. Приходится либо в консоли грепать лог файл, либо куда-то его копировать и анализировать в более удобных текстовых редакторах. Я лично привык использовать webmin для этих целей. Мне кажется это удобным. Особенно удобно, когда нужно несколько файлов просматривать одновременно. Я их просто открываю в разных вкладках браузера и анализирую. Главное отключить в настройках модуля поиск по сжатым файлам. Это очень сильно замедляет процесс, но иногда серьезно выручает, когда нужно поискать по всем лог файлам за последнюю неделю. Поиск по сжатым файлам я включаю по необходимости, постоянно его не использую.

Заключение

Подведем итог работы по настройке почтового сервера. Я постарался рассмотреть наиболее полезные и значимые возможности и настройки на основе своего опыта эксплуатации почтовых серверов postfix. Конечно, я не раскрыл всех нюансов. Отдельно надо рассмотреть вопрос бэкапа почтового сервера, а точнее почтовых ящиков пользователей. Там есть свои нюансы и сложности. Связаны они в первую очередь с тем, что каждое письмо это отдельный файл. Офис человек в 100-150 генерирует очень много почтового трафика, который будет состоять из десятков тысяч файлов в месяц. А за 5 лет накопятся терабайтные архивы очень важных писем менеджеров, которые нужно будет где-то хранить и быстро отдавать пользователям. Если случится проблема на сервере, то оперативно восстановить из бэкапа почтовый архив не получится, если у вас не бюджетное аппаратное решение дисковой подсистемы. Тут нужны свои подходы и хитрости. По возможности буду ими делиться.

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

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

Сообщение Настройка почтового сервера iRedMail на CentOS 7 появились сначала на Clip-Clap.