Пришло время перенести почту со старого почтового сервера (Postfix + Courier-Imap + SASL2 + MySQL + ClamAV) на новый сервер Zimbra Collaboration Suite. Причем сделать это нужно максимально незаметно для пользователей.

Поскольку на нашем сервере порядка 300 активных ящиков все сразу перенести невозможно, поэтому делать придётся постепенно.

Идея такая: создали ящик на новом сервере - перенастроили пользователю почтовый клиент (при этом названия ящика должно сохраниться) - перешли к следующему.

Вот что мы имеем:

• mail.example.com - существующий почтовый сервер с ip:62.220.58.71, обслуживаемый зону example.com
• zcs.example.com - новый почтовый сервер на zimbra с ip:62.220.58.72, обслуживаемый зону example.com

К сожалению, в бесплатной версии Zimbra Collaboration Suite не существует встроенного механизма бекапа. Приходится доделывать самому. Поскольку установка сервера не представляет особой сложности, главное, что нужно архивировать это учетные записи пользователей и содержимое почтовых ящиков.

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

Для создания учетной записи из командной сроки в Zimbra используется следующая команда:

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

Серые списки (англ. Greylisting) - способ автоматической блокировки спама, основанный на том, что если почтовый сервер получателя отказывается принять письмо и сообщает о «временной ошибке», сервер отправителя обязан позже повторить попытку. Спамерское программное обеспечение в таких случаях, обычно, не пытается этого делать. (с) Wikipedia.

В Zimbra управление серыми списками возможно через плагин Pilicyd. Как установить плагин с web-интерфейсом можно прочитать в статье Установка плагина Policyd с web-интерфейсом в Zimbra.

После установки плагина доступ к управлению можно получить по ссылке http://mail.example.org:7780/webui/index.php.

Для начала заполним группы internal_ips и internal_domains, которые создаются после установки (Policies - Groups). Добавьте локальные подсети и домены, которые обслуживает ваш почтовый сервер соответственно.

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

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

При помощи модуля Policyd Quotas, можно настроить ограничение по количеству сообщений за определенное время, например, сделать так чтобы за 1 час пользователи могли посылать не более 100 сообщений.

Таким образом, если пароли пользователей будет украдены они смогут послать не больше 100 писем в час и ваш ip-адрес не попадет в черный список (по крайней мере, не так быстро ☺). Кроме того, вы сможете понять, кто из пользователей вдруг начал отправлять такое большое количество писем.

После того как вы установили Policyd, доступ к web-интерфесу доступен по адресу http://mail.example.com:7780/webui/index.php.

После того как установили Policyd пришло время заняться его настройкой, в данной статье речь пойдет о запрете доступа на основании списков доступа (Access Control).

По умолчанию создаются 2 группы (Policies\Groups) в которые предлагается заносить внутренние домены (internal_domains) и внутренние ip-адреса (internal_ips).

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

• Default - в данную политики попадают все;
• Default Outbound - исходящая почта, применяется к письмам, источник которых внутренний (%internal_ips, %internal_domains), а назначение внешнее (!%internal_domains);
• Default Inbound - входящая почта, источник не внутренний (!%internal_ips, !%internal_domains), назначение внутренние домены (%internal_domains);
• Default Internal - внутренняя почта, источник и назначение - внутренние домены.

Для просмотра логов доставки писем в ZImbra существует (начиная с версии 7.1.1) утилита командной строки zmmsgtrace.

Синтаксис:

Zimbra Collaboration Suite почтовый сервер, который использует Postfix в качестве движка для MTA. Поэтому в нем существует возможность установки плагина Policyd, который включает в себя несколько модулей:

• Access Control - ограничение приема/пересылки писем по спискам доступа (списки могут быть различными - на основе названия домена, учетной записи пользователя, почтового адреса, ip-адреса или подсети);
• HELO/EHLO Checks - организация белых и черных списков;
• SPF Checks - поведение сервера, если сервер-отправитель не прошел проверку SPF-записи;
• Greylisting - организация серых списков;
• Quotas - при помощи данного модуля можно ограничить количество принятых/отправленных сообщений в единицу времени;
• Accounting - при помощи данного модуля можно также ограничивать количество отправленных сообщений и количество отправленных килобайт.

Управление настройками Policyd в Zimbra можно осуществлять через web-интерфейс, к сожалению, он на английском, зато довольно простой и понятный.

Если при попытке отправить сообщение на почтовые сервера Gmail вы вдруг получили ответ:

Скорее всего, это означает что у вас не настроены DKIM, SFP и DMARC. Все больше крупных почтовых серверов (mail.ru, Яндекс) требуют наличие данных записей.

• DomainKeys Identified Mail (DKIM) - используется для защиты от спуфинга при помощи добавления цифровой подписи в заголовки исходящих сообщений.
• Sender Policy Framework (SPF) - это расширение для протокола отправки электронной почты через SMTP, благодаря которому можно проверить, не подделан ли домен отправителя.
• Domain-based Message Authentication, Reporting and Conformance (DMARC) - это техническая спецификация, предусматривающая механизмы для обмена информацией между отправителем и получателем о качестве фильтрации спама и фишинговых атаках.

Настроим каждую из этих систем.

Поскольку Zimbra создает само-подписанный сертификат, что бы браузеры не ругались на неправильную подпись выгрузим сертификат, для этого нас сервере из-под пользователя root выполняем команду:

Теперь его нужно добавить к доверенным корневым центрам сертификации, как это сделать в windows можно прочитать на сайте Microsoft

Узнать дату окончания действия сертификатов можно командой (все команды выполнять под пользователем zimbra):

Создадим новый корневой и новый само-подписанный сертификат

Разворачиваем сертификаты и перезапускаем сервер:

По информации сайта wiki.zimbra.com после новой установки ZCS пытается выделить 30% системной памяти для Java heap (параметр mailboxd_java_heap_size для ZCS7 и выше, или mailboxd_java_heap_memory_percent для ZCS6 и ранее), и 25% памяти для innodb buffer pool. Пожалуйста, убедитесь, что данные значение не слишком высоки для вашей системы.

При объёме системной памяти:

• меньше 8GB, установите размер Java heap в 20%, и для mysql innodb buffer pool 20%
• 8GB, установите размер Java heap в 30%, а для mysql innodb buffer pool 25%
• 16GB, установите размер Java heap в 25%, а для mysql innodb buffer pool 30%
• 32GB, установите размер Java heap в 20%, а для mysql innodb buffer pool 35%