Техническая часть: pmta / vds с 1+ ipv4

Наша конфигурация:

Техническая часть: pmta / vds 1 один ip / vds 2 один ip

Карта: 
vds 1 — основной сервер подключения и ретрансляции трафика mail.ru / yandex.ru / gmail.com
— осуществляем к нему подключение и пересылку всех писем на vds2, принимаем возвращенные письма на публичные почтовые сервера для последующей отправки.
vds 2 — сервер ретрансляции корпоративного трафика
— принимает письма с vds1, распределяет их по mx получателя и возвращает очереди mail.ru / yandex.ru / gmail.com на vds1. Оставшийся трафик рассылается с vds2
— свертка по mx получателя подразумевает все адреса как частные так и корпоративные делегированные на почтовые сервера mail.ru / yandex.ru / gmail.com.

Причина использования карты с возвратом трафика публичных почтовых систем и 2мя vds

1 — при блокировке по abuze причинам vds2 сохранить основной сервер vds1 изолировав его на другой хост аккаунт или дата центр.

2 — для авто «сортировки» и перенаправления трафика мы используем директиву route для домена получателя, «свернуть» по mx в одну очередь «все кроме» — не представляется возможным, при этом использование route глобально для <domain *> переопределяет route для свертки очереди на mx mail.ru / yandex.ru / gmail.com.

Наша конфигурация:

Для корректной работы PMTA потребуется увеличить данное ограничение

Увеличим лимит до системного ограничения в 65535

Добавляем в файл sysctl.conf следующую строку:

fs.file-max = 65535

Добавляем в файл /etc/security/limits.conf следующее:

* soft nproc 65535
* hard nproc 65535
* soft nofile 65535
* hard nofile 65535

Перезагружаем сервер

reboot

Проверяем результат

ulimit -n
и
ulimit -u

Вывод на обе команды видим

65535

Текущий лимит (Soft limit) открытых файлов на процесс для текущего пользователя

ulimit -Sn

Максимальный лимит (Hard limit) открытых файлов на процесс для текущего пользователя

ulimit -Hn

Посчитать кол-во открытых файлов всеми процессами

lsof | wc -l

Посчитать кол-во открытых файлов всеми процессами (по версии ядра линукс)

cat /proc/sys/fs/file-nr

Максимальный лимит открытых файлов для всей системы

cat /proc/sys/fs/file-max

При активной отправке pmta (по шаблону backoff) «замораживает» отправку. При этом копиться значительная очередь писем в vmta, иногда шаблон не достаточно выдерживает время «передышки» изменяет статус очереди и продолжает отправку, что усугубляет показатели сервера и вводит его в частичную или полную блокировку.

Вам так же будет полезно:
— Готовая конфигурация PMTA  (ротация) при блокировке / избавляемся от redjekt 550 spam mail.ru
— Панель автоматического управления серверами по показателям доставки  postmaster.mail.ru

Задача: При срабатывании шаблона (backoff) на одной из очередей, переместить «замороженную» очередь в другую vmta со статусом retry (отправка), при этом новый vmta имеет другую конфигурацию или является релеем.

Реализация:

Мы рассматриваем только принцип перемещения писем из одной очереди PMTA в другую

1. Требуется реализация шаблонов backoff SMTP откликов серверов в Вашей конфигурации.
2. vmta 2 с отличной конфигурацией от основного vmta. Требуется обязательно!!! 

vmta 2 — нам нужен для того что бы при перемещении заблокированной почтовым провайдером очереди, сервер повторно не получил 550…. redjekt…. Иначе вероятна частичная или полная блокировка сервера!!! 

Повторную ошибку Вы вероятнее всего получите в той же конфигурации. Схожий sender / ip / DKIM и т.п.

Нам потребуется директива:  backoff-rerouteto-virtual-mta

Директива указывает, что PowerMTA должен перенаправить сообщения на указанный VirtualMTA, если очередь переходит в режим отката (backoff).

Например, есть очередь писем для mail.ru/vmta1. Если эта очередь переходит в режим отката, а директива backoff-reroute-to-virtual-mta имеет в значении vmta2, все письма будут перенаправлены в очередь mail.ru/vmta2.

Так как письма будут находиться в очереди для vmta2, то к ним будут применяться настройки этого VMTA.

Новые письма, попадающие в первую очередь, будут немедленно перенаправляться на
vmta2, пока очередь vmta1 не выйдет из режима отката (backoff)

Реализованный пример:

<virtual-mta mta1>
 smtp-source-host 1.1.1.1 mta1.domain.com
 <domain *>
 backoff-reroute-to-virtual-mta backoff-mta1
 smtp-pattern-list block-errors
 </domain>
</virtual-mta>

<virtual-mta backoff-mta1>
 smtp-source-host 1.1.1.2 mta2.domain.com
 <domain *>
 retry-after 30m
 bounce-after 1h
 </domain>
</virtual-mta>

Обратите внимание: поскольку письма перенаправляются от одного VirtualMTA к другому, директива backoff-reroute-to-virtual-mta имеет приоритет перед backoff-max-msg-perhour и backoff-retry-after.

Использование запланированной доставки в PowerMTA требует добавления заголовка x-schedule к электронному письму до поступления писем в очередь PowerMTA.

Формат заголовка: x-schedule: <start time — 1>/<end time — 1>, <start time — 2>/<end time -2>
Пример заголовка отложенной передачи для PMTA

x-schedule: 2016-12-29 17:01:00 / 2016-12-29 17:30:00, 2016-12-30 17:01:00 / 2016-12-30 17:30:00

«Окна» доставки

В приведенном выше примере отправка писем будет начата в 17:01 вечера (время сервера PowerMTA) 29 декабря 2016 года.

Попытки отправки прекратятся в 17:30 29 декабря 2016 года.

Попытки отправки возобновятся 30 декабря 2016 года в 17: 30:00, и, если письма не будут доставлены, очередь удалиться 30 декабря 2016 г. в 17:30.

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

После возврата очереди в статус normal повторно расписание не применяется к письмам с заголовком x-schedule. Расписание переопределяет заданное значение bounce-after. Кроме того, если очередь находится в режиме повтора, когда сообщения вводятся, доставка сообщения не начнется во время начала окна, а скорее попытка доставки сообщения начнется, когда очередь выйдет из режима повтора.

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

<domain *> 
    use-starttls yes 
    require-starttls no 
</ domain>

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

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

<acct-file logacct.csv> 
    records d, b 
    record-fields d *, dlvTlsProtocol, dlvTlsCipher 
    record-fields b *, dlvTlsProtocol, dlvTlsCipher 
</acct-file>

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

Исходящий клиентский сертификат

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

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

<domain super-secure-server.com> 
    smtp-client-certificate /path/to/certificate.pem password 
    use-starttls yes 
    require-starttls yes 
</domain>

В приведенном выше примере любые сообщения, отправленные на super-secure-server.com, будут отправляться по зашифрованному каналу с использованием сертификата /path/to/certificate.pem (в большинстве случаев предоставляется администратором удаленного почтового сервера). Если шифрование не удалось, сообщения не будут отправлены.

Входящее шифрование

Запросить зашифрованное соединение от входящих подключений можно сделать в PowerMTA для каждого <source>. Настройка будет выглядеть примерно так:

# 
smtp-listener 1.2.3.4:465 tls=yes 
smtp-server-tls-certificate /etc/pmta/smtp-cert.pem "YourPasswordHere" smtp-server-tls-ciphers "HIGH:MEDIUM:!ADH:@STRENGTH"

<source 0/0>    # matches all 
    allow-starttls yes 
    require-starttls-before-auth yes 
    allow-unencrypted-plain-auth no 
</source> 
#

Создание сертификата /etc/pmta/smtp-cert.pem следует стандартным методам OpenSSL.

Пример содержимого сертификата выглядит следующим образом:

-----BEGIN CERTIFICATE-----
YOUR CERT HERE
-----END CERTIFICATE-----
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,EBA505536010547C

YOUR PRIVATE KEY HERE
-----END RSA PRIVATE KEY----- 

При такой конфигурации весь трафик, подключающийся к 1.2.3.4 через порт 465, будет пытаться использовать шифрование для приема электронной почты в PowerMTA.

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

• <source>
• <virtual-mta mta>
• domain-key
• mail-from

Платформа: Windows

Наша практика опыта работы с ПО:  нет.

Правообладатель: неизвестен

Лицензия: Бесплатный

Скачать файл Configurator PowerMTA

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

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

<virtual-mta 1>
domain-key key1,domain.tld,/etc/pmta/keys/key1.domain.pem
smtp-source-host   192.168.0.1   1.mta.domain.tld
max-smtp-msg-rate 800/h
</virtual-mta>

Создаем внешний файл конфигурации для настраиваемого подключения, в этом примере это client1.txt
Внешние файлы содержат весь домен и лимиты отправки и, конечно же, настройки DKIM.

Ниже приведен пример такого внешнего файла.

<virtual-mta 1>
    max-smtp-out 3
    max-msg-per-connection 100
    max-rcpt-per-message 10
    max-msg-rate 266/m
retry-after 25m    
bounce-after 1440m
max-connect-rate 10/m
max-errors-per-connection 10
backoff-reroute-to-virtual-mta domain.tld
#smtp-pattern-list backoff
backoff-to-normal-after-delivery yes
backoff-reroute-to-virtual-mta domain.tld
backoff-to-normal-after 5m
backoff-max-msg-rate 700/h
backoff-retry-after 15m
#smtp-421-means-mx-unavailable  yes
</domain>
 
domain-key key1,domain.tld,/etc/pmta/keys/key1.domain.tld
<domain *>
   dkim-sign yes 
   dkim-identity @domain.tld
</domain>
</code>

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

include /etc/pmta/client1.txt

Ваша конфигурация будет выглядеть примерно так:

<virtual-mta 1>
domain-key key1,domain.tld,/etc/pmta/keys/key1.domain.tld
smtp-source-host   192.168.0.1   1.domain.tld
max-smtp-msg-rate 800/h
include /etc/pmta/client1.txt
</virtual-mta>

Теперь вы можете настроить различные параметры DKIM. 

Просто создайте еще один .txt документ client2.txt и добавьте его в свой другой vmta в своем конфигурационном файле.

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

client1.txt. — должен иметь права на чтение

Перевод статьи

<domain *>
deliver-local-dsn YES
</domain>

Это гарантирует, возврат писем на адрес электронной почты, который вы указали в Interspire для приема «откатов» bounce.

Теперь  нужно указать обработчику отказов Interspire на обработку писем с темой «Отчет о доставке».
Файл, который нам нужно отредактировать: bounce_rules.php,
находится в каталоге установки Interspire. /admin/resources/

Если вы не добавите это в свой interpsire, bounce_rule.php interpsire просто проигнорирует это электронное письмо и удалит его после запуска обработки отказов.

В области строк 68 вы найдете это значение:

$GLOBALS['BOUNCE_RULES_SUBJECT'] = array(

Чуть ниже мы добавляем:

'Delivery report',

Сохраните файл и протестируйте изменения.

Если Interspire не помечает письмо как отклоненное, и вы активировали режим отладки, и вы получаете что-то вроде этого:

Line 883; Date: Thu, 22 May 2013 10:45:25 +2
Line 884; Processing emailid: 20; listid: 1024
Line 471; the email headers werent returned properly. See if they have a utf-8 byte-order-mark in them.
Line 891; no proper email headers found. Returning ignore

То добавьте в вашу конфигурацию powerMTA:

<domain *>
     ignore-8bitmime true
</domain>

Перевод оригинала статьи