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

Задачи решаемые режимом backoff

Автоматически остановить рассылку на Х период

1 — Одна из причин «глубокой» блокировки сервера — рассылка после предупреждения почтовой системой о потенциальном спаме. Публичные почтовые сервера уведомляют smtp ответами: 550 spam redjekt и т.п.
Если не остановить сервер во время получения первых ошибок 550 spam redjekt — доля вероятности полной блокировки «ip, domain» сильно возрастает.
— либо сервер уже определен как спам
— либо с сервера идет подозрительный трафик, или трафик распознанный как спам
Рекомендовано заморозить очередь при первом получении ошибки spam для публичных почтовых систем на Х период — которую может выполнить backoff.

2 — Сервер получателя имеет более жесткие политики фильтрации серверов отправителей, либо Ваша конфигурация не настроена должным образом. Что вызовет отказ от приема сообщения — режим backoff позволит Вам сохранить письма в очереди, заморозив ее. После исправления ошибки Вы сможете отправить письма повторно

Автоматически понизить скорость рассылки на Х период

3 — Слишком большая скорость отправки писем для молодого сервера — может так же быть причиной 550 spam либо давать иной отклик. В этом случае режимом можно автоматически понизить скорость отправки писем.

Автоматически временно заморозить рассылку на Х период с последующим возобновлением

4 — Grey list (грей листинг) в основе которого лежит временный отказ от приема сообщения почтовым сервером и подразумевает повторную доставку в тот же адрес повторно через некоторый интервал, к примеру yandex к не доверенным может выдавать временный отказ с формулировкой Sorry, the service is currently unavailable. Please come back later.

5 — сервер получателя временно не доступен или ящик переполнен — повторно отправить через Х часов. Так же если у Вас используется relay и он временно не доступен — позволит сохранить очередь до починки ретранслятора.

К чему можно применить режим backoff:

— К конкретной очереди рассылки (по получателю)
— К ip адресу (дополнительно можно почитать)

Как работает backoff

— в момент отправки писем сервер получателя отвечает PMTA кодами статусов доставки:
250 ….. OK: …… — принято
550 spam message rejected — отклонено по причине спам
451 4.7.1 Sorry, the service is ………… так отвечает грей листинг Yandex.ru
и т.п.

Ваш PMTA при получении кода ошибки — инициализирует режим backoff, и включает особые, заданные Вами настройки для очереди которая получила ошибку.

PMTA устанавливает (при должной настройке) для нашей очереди режим backoff, применяя к очереди установленные нами настройки для данного режима.
Если Вы не используете «mx свертки» rollup или обьеденения очередей queue-to — режим будет применяться для конкретной очереди обьедененной по домену получателю.
Это позволяет сохранить частоту доставки на другие доменные зоны получателей.

Возможности режима backoff:

— Перевод очереди в другую очередь (vmta)
— сбросить очередь в bounce
— перевести очередь в vmta с другими настройками (сменить домен sender или from, убрать DKIM, и т.п.)
— перевести очередь в vmta с ретрансляцией через другой сервер
— перевести очередь в vmta для удаления, сброса в bounce
— Остановить очередь на Х период с последующим возобновлением рассылки
— Остановить очередь и делать попытки отправки через Х интервал времени, после первой успешной доставки — возобновить отправку
— Понизить скорость рассылки на Х период

Как включить режим backoff

Для подключения режима backoff необходимо:

1. Создать список шаблонов на основе отклика SMTP в <smtp-pattern-list NameList>
   к примеру reply /550 spam message rejected/ mode=backoff, где reply — ответ сервера / 550… ошибка / mode= включить режим backoff (по умолчанию режим может быть отключен mode=normal)
2. Подключить список шаблонов для домена,ов на которые мы будем отправлять письма
   Выборочно к примеру <domain mail.ru> — наш шаблон ошибок будет сопаставляться только с ответами mail.ru на наши письма
   Для Всех получателей <domain *>

Подключать можно как глобально в файле конфигурации так и персонально для конкретного vmta (очереди)
Кол-во <smtp-pattern-list NameList> — не ограничено

Какие задачи решает режим backoff

Основные функции режима: заморозка очереди на Х время, перевод очереди (ретрансляция) в другую очередь, изменения дозировки очереди писем.
Режим перспективно применяется при проблемах:
— Грейлистинг (к Вашим письмам относятся с подозрением, временно отклонено)
— При rejected (к Вашим письмам относятся негативно, отклонено как спам)

Директивы backoff в PMTA

backoff-max-msg-rate
Область: domain
Тип: значение/время (1/h )
Атрибуты: необязательный
Значение по умолчанию: безлимитно
Директива ограничения скорости отправки писем.
В ограничение входит как успешные доставки писем, так и попытки доставки. Когда будет достигнут лимит, в веб-мониторе будет показана следующая ошибка:
“message rate limit reached (based on backoff-max-msg-rate in configuration)”

backoff-retry-after
Область: domain
Тип: временной интервал
Атрибуты: optional
Значение по умолчанию: 10 минут
Устанавливает интервал или интервалы между повторами попыток для домена/virtualMTA, когда они в режиме повтора попыток.

backoff-notify
Область: domain
Тип: e-mail адрес
Атрибуты: необязательный
Значение по умолчанию: «» (no notification sent)
Указывает электронные адреса, на которые будут приходить оповещения о том, что заданный
домен заходит в или выходит из режима отката. Несколько адресов можно указать в виде
списка, разделённого запятыми.

Пример:
<domain *>
backoff-notify two@host.domain,one@host.domain
</domain>

backoff-to-normal-after
Область: domain
Тип: значение время (1h )
Атрибуты: необязательный
Значение по умолчанию: never
Временной интервал, по истечению которого, очередь автоматически возвращается в обычный режим.

Пример:
<domain *>
backoff-to-normal-after 6h
</domain>

backoff-to-normal-after-delivery
Область: domain
Тип: логический
Атрибуты: необязательный
Значение по умолчанию: false (отключено)
Если активна, эта директива возвращает очередь отправки в нормальный режим после успешной доставки.

backoff-upon-all-sources-disabled
Область: domain
Тип: логический
Атрибуты: необязательный
Значение по умолчанию: false (отключено)
Если включено, переключает очередь в режим отката, когда исходные IP-адреса отключаются
либо через командную строку, либо использованием функции <smtp-pattern-list> “disable-source-ip».
!!! Рекомендуется использовать директиву «backoff-to-normal-after» в сочетании с этой директивой, так как PowerMTA не переводит очередь в нормальный режим автоматически при включении IP-адреса.

backoff-reroute-to-virtual-mta
Область: домен
Тип: VirtualMTA name
Атрибуты: необязательный
Значение по умолчанию: none
Указывает, что PMTA должен перенаправлять письма в выбранный VirtualMTA в случае вхождения очереди в режим отката. Например, если письма стоят в очереди для example.com/vmta1 и эта очередь входит в режим отката, а директива backoffreroute-to-virtual-mta имеет значение vmta2, все письма из этой очереди будут перенаправлены в очередь example.com/vmta2. Новые письма будут также перенаправляться, пока очередь не выйдет из режима отката.

Пример:
<virtual-mta vmta1>
<domain *> 
backoff-reroute-to-virtual-mta vmta2 
</domain>
</virtual-mta>

<virtual-mta vmta2>
...
</virtual-mta>

!!! Внимание: При обнаружении цикла, сообщения остаются в последней очереди цикла, а в лог будет записана ошибка.
Перенаправление с одного виртуального MTA на себя автоматически игнорируется, а перенаправление в пул VirtualMTA не поддерживается.

backoff-max-smtp-out
Область: домен
Тип: цифровое значение
Атрибуты: необязательный
Значение по умолчанию: 20
Указывает максимальное количество одновременных подключений для этого домена. 

backoff-max-connect-rate
Область: domain
Тип: {unlimited|0|N/{h|hr|m|min|s|sec} «значение/время (1/h )»
Атрибуты: необязательный
Значение по умолчанию: безлимитно
Указывает максимальное количество подключений, открытых для этого домена в течении определённого периода времени в режиме отката.

Доступно для VIP пользователей

• Консольные команды управления режимами backoff
• Базовые списки шаблонов backoff
• Примеры для чего нужен режим
  backoff при блокировке redjekt
  backoff для грей листинга
  backoff удаляем плохую очередь

Если Вы нашли ошибку или не точности пишите в нашу телеграмм группу my-mails.ru/telegramm

Если на Вашем сервере включена поддержка ipv6 и адреса добавлены, в конфигурацию PMTA добавить можно так:

Для web монитора

smtp-listener [0000::0202:0303:0404:0505:00]:25

Cброс очереди на ip 

<domain test.port25.com>
route [0000::000:000:000:000:00]:25
</domain>

smtp-source-host virtual host

<virtual-mta ipv6-3.m-salecraft.ru>
smtp-source-host 0000::000:000:000:000:00 sub.domain.ru
domain-key mail,domain.ru,/etc/pmta/dkim.pem
max-smtp-out 850
<domain *>
</domain>
</virtual-mta>

Если Вы добавляете ipv6 адреса на сервер без панели:

Включаем поддержку IPv6 в /etc/sysconfig/network добавить

NETWORKING_IPV6=yes

В конфигурационный файл сетевого интерфейса /etc/sysconfig/network-scripts/ifcfg-eth0 добавить

IPV6INIT=yes

IPV6ADDR="0000::000:000:000:000:00/64"
IPV6ADDR_SECONDARIES="0000::000:000:000:000:01/64 0000::000:000:000:000:02/64 0000::000:000:000:000:03/64"
IPV6_DEFAULTGW="2a07:14c0:3000::1"

IPV6ADDR=»Ваш ipv6/маска»
IPV6ADDR_SECONDARIES=»первый_ipv6/маска второй_ipv6/маска третий_ipv6/маска и_так_далее»
IPV6_DEFAULTGW=»шлюз»

Перегружаем сеть

service network restart

Resolv.conf

Добавьте настройки преобразования DNS для ipv6

nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

Проблемы и ошибки:

Если система выдает ошибку:

CRITICAL : [ipv6_test] Kernel is not compiled with IPv6 support
то в файле /etc/modprobe.conf комментируем следующие строки

#alias net-pf-10 off
#alias ipv6 off

также меняем значение с 1 на 0

options ipv6 disable=0

Вы прописали ip адреса но при перегрузке конфигурации pmta выдает ошибку
Error in line 154 of /etc/pmta/virtualhost.txt: specification does not match any valid local IP addresses.
Это означает что в Вашей сети не виден ip адрес проверьте правильность внесение адресов, перезагрузите сеть.

Проверьте подключение с указанного ip в Вашей конфигурации к примеру на yandex.ru

pmta resolve --connect --source=sub.domain.ru,0000::0202:0303:0404:0505:00 yandex.ru

Руководство пользователя PMTA v4.5

Использование запланированной доставки в 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. Кроме того, если очередь находится в режиме повтора, когда сообщения вводятся, доставка сообщения не начнется во время начала окна, а скорее попытка доставки сообщения начнется, когда очередь выйдет из режима повтора.

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

Основной заголовок который обычно требуется удалить — это трансляцию имени основного сервера в Received.

За скрытие источника отправителя в заголовке Recived  в PMTA отвечает значение:

hide-message-source
Область: source
Тип: boolean
Атрибуты: optional
Значение по умолчанию: false

hide-message-source true

Указывает, что PowerMTA должен делать попытки скрыть источник сообщения при доставке
почты от этого источника. Имя и IP-адрес MTA, с которого PowerMTA получил сообщение, не будут добавлены в хэдер Received:. Скрытие источника сообщения может быть полезно, к примеру, в целях безопасности – это поможет избежать раскрытия информации внутренней сети, из которой было отправлено сообщение.

Данное значение исключит из Recived только источника отправки сообщения, при этом в Recived PMTA поставит сервер PMTA.

При этом Вы можете указать значение для каждого пользователя персонально:

<smtp-user user1>
        password passuser
        source {pmta-auth}
</smtp-user>
<source {pmta-auth}>
        ....
         hide-message-source true
        ....
</source>
и
<smtp-user user2>
        password passuser
        source {pmta-auth}
</smtp-user>
<source {pmta-auth}>
        ....
         hide-message-source false
        ....
</source>

Обратите внимание что бы значения hide-message-source в этом случае не были переопределены в глобальных настройках source или domain — в этом случае опция сработает для всех подключений:

<smtp-user domain.ru-vmta>
 password pass
source {domain.ru-vmta-auth}
</smtp-user>
 
<source {domain.ru-vmta-auth}>
 ....
hide-message-source true
 ....
</source>

Удаление заголовка Recived в PowerMTA

За добавление заголовка Recived в PMTA отвечает значение:

add-received-header
Область: source
Тип: boolean
Атрибуты: optional
Значение по умолчанию: true

Указывает, должен ли PowerMTA добавлять в письмо хэдер «Доставлено» (Received header) при получении письма адресатом.

Если при включенной опции hide-message-source PMTA удалит только первоисточник из recived, то данная опция удалит сам заголовок recived

Пример включения опций из заголовков письма Yandex

Заголовок Recived отсутствует

add-received-header false
hide-message-source false

Received: from mxfront7o.mail.yandex.net ([127.0.0.1])
by mxfront7o.mail.yandex.net with LMTP id dpLjaBmF
for <ltdviso@yandex.ru>; Sun, 6 Jan 2019 09:35:13 +0300
Received: from mos-ttprint.ru (mos-ttprint.ru [95.46.8.26])
by mxfront7o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id X1LVJCtZEC-ZC2iFGP8;
Sun, 06 Jan 2019 09:35:12 +0300
Return-Path: buonce@mos-ttprint.ru
X-Yandex-Front: mxfront7o.mail.yandex.net
X-Yandex-TimeMark: 1546756512
Authentication-Results: mxfront7o.mail.yandex.net; spf=pass (mxfront7o.mail.yandex.net: domain of mos-ttprint.ru designates 95.46.8.26 as permitted sender, rule=[mx]) smtp.mail=buonce@mos-ttprint.ru; dkim=pass header.i=info@mos-ttprint.ru
X-Yandex-Spam: 1
X-Yandex-Fwd: ODEzNDAyMDMyNTU2NjQ0MzI0MSwyMzY3NDE3NzM0MDg2NTc3NTIz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=key1; d=mos-ttprint.ru;
h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
i=info@mos-ttprint.ru;
bh=VP5NeIM/hVPaMpGaarJRXYZmRZoehNCEK+WUMNNhb9w=;
b=BW1+xYQ+8FKaKHOnibeISNxj9ieGNgfyincjHkX1ewXEw2T5n3az+8I8GTsfF5t/2jUr9Idhz3Af
PZbWM1hB4zEoTQyECrge8pqT/+D7I5xVVPDz3K+a6NXcsLQtsYjg69K0LeUA8Kg16HNgoBdLb/9T
Y9Wmd4vUKAmcXnU0PMN0h4bwqx0AFEWLPvCeHxZFIagAoomMmqiWqTf+xJq1fNRuk2QQ9yfpYdgR
YqNi+B7Xj8Z6BByKibLQfzJCbWL+1ycHlQM9M6Qq/Al0Eiz2mEnFzs04BMS3TnV2S9aX0oao+2m9
BvruCwqmH7QdnMy+hFKq+NP+jRqVa8EieJM3qQ==

Заголовок Recived полностью отсутствует

Message-ID: <f606c2a87756b1639a574b3869096fda@mos-ttprint.ru>
Date: Sun, 06 Jan 2019 06:35:11 +0000
Subject: Please validate this server.
From: mymails1 <info@mos-ttprint.ru>
Reply-To: mymails1 <info@mos-ttprint.ru>
To: ltdviso@yandex.ru
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=»_=_swift_v4_1546756511_6fc1c0d4933249f81fac0b2d0b8e7cbe_=_»
X-Sender: buonce@mos-ttprint.ru
X-Receiver: ltdviso@yandex.ru
X-Mw-Mailer: SwiftMailer — 5.4.x
X-Yandex-Forward: d5da2b2e27d00b08c1de9e1f685d0eda

в Recived стерт первоисточник

add-received-header true
hide-message-source true

Received: from mxfront8o.mail.yandex.net ([127.0.0.1])
by mxfront8o.mail.yandex.net with LMTP id QH6TlyMp
for <ltdviso@yandex.ru>; Sun, 6 Jan 2019 09:37:36 +0300
Received: from mos-ttprint.ru (mos-ttprint.ru [95.46.8.26])
by mxfront8o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id OFH4MipGxL-bZqepPw4;
Sun, 06 Jan 2019 09:37:35 +0300
Return-Path: buonce@mos-ttprint.ru
X-Yandex-Front: mxfront8o.mail.yandex.net
X-Yandex-TimeMark: 1546756655
Authentication-Results: mxfront8o.mail.yandex.net; spf=pass (mxfront8o.mail.yandex.net: domain of mos-ttprint.ru designates 95.46.8.26 as permitted sender, rule=[mx]) smtp.mail=buonce@mos-ttprint.ru; dkim=pass header.i=info@mos-ttprint.ru
X-Yandex-Spam: 1
X-Yandex-Fwd: ODEzNDAyMDMyNTU2NjQ0MzI0MSwyMzY3NDE3NzM0MDg2NTc3NTIz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=key1; d=mos-ttprint.ru;
h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
i=info@mos-ttprint.ru;
bh=vJxxiGaMidKpNtoLMY8TEy9QoXTxIfsDsAvonXIZJgw=;
b=nvywFSgtpgdo7J6kr6TWmy5JK8ww3An81WV0xXA5lHCo37Wt/vXJQ/QgQEzaaBygcR7rUBUx3V66
OKBe4RIykedlhAFOaZzDzNZShOTV95sWLWD58BOg7lGi46csOTZ5AYCEdIbBqmAOo57iwQEUuQBp
3S79+iu1HzB+2SHAlC56NcMtOgLwfWPsF2aWa7uRGjhxHof8uTntv7w3GAIwtEZNVVM9O0yK2A05
RUBc611wjUnMDHxOYOucydMbs/Ix1KB+lk+UhQz61N0a8V7HL1v5xwK7OjZ7WtxU039c9hD0WWq4
d/Ej2Bfm6RrQAFj89lK9nK3VV+hX/Coy+4dFNw==

Received: by mos-ttprint.ru for <ltdviso@yandex.ru>; Sun, 6 Jan 2019 01:37:35 -0500 (envelope-from <buonce@mos-ttprint.ru>)

Заголовок Recived присутствует, в заголовке стерт первоисточник, и добавлен только сервер PMTA

Message-ID: <a30e41739a3edc8e64ce1d13b969e097@mos-ttprint.ru>
Date: Sun, 06 Jan 2019 06:37:35 +0000
Subject: Please validate this server.
From: mymails1 <info@mos-ttprint.ru>
Reply-To: mymails1 <info@mos-ttprint.ru>
To: ltdviso@yandex.ru
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=»_=_swift_v4_1546756655_73cbb1f3a1f187d14e859eee51b603de_=_»
X-Sender: buonce@mos-ttprint.ru
X-Receiver: ltdviso@yandex.ru
X-Mw-Mailer: SwiftMailer — 5.4.x
X-Yandex-Forward: d5da2b2e27d00b08c1de9e1f685d0eda

Recived без изменения

add-received-header true
hide-message-source false

Received: from mxfront4j.mail.yandex.net ([127.0.0.1])
by mxfront4j.mail.yandex.net with LMTP id l5kTbfg8
for <ltdviso@yandex.ru>; Sun, 6 Jan 2019 09:40:21 +0300
Received: from mos-ttprint.ru (mos-ttprint.ru [95.46.8.26])
by mxfront4j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 6mr7kmaGMD-eKOqDOU1;
Sun, 06 Jan 2019 09:40:20 +0300
Return-Path: buonce@mos-ttprint.ru
X-Yandex-Front: mxfront4j.mail.yandex.net
X-Yandex-TimeMark: 1546756820
Authentication-Results: mxfront4j.mail.yandex.net; spf=pass (mxfront4j.mail.yandex.net: domain of mos-ttprint.ru designates 95.46.8.26 as permitted sender, rule=[mx]) smtp.mail=buonce@mos-ttprint.ru; dkim=pass header.i=info@mos-ttprint.ru
X-Yandex-Personal-Spam: ODIzNDcyNjU3Cg==
X-Yandex-Spam: 1
X-Yandex-Fwd: ODEzNDAyMDMyNTU2NjQ0MzI0MSwyMzY3NDE3NzM0MDg2NTc3NTIz
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=key1; d=mos-ttprint.ru;
h=Message-ID:Date:Subject:From:Reply-To:To:MIME-Version:Content-Type;
i=info@mos-ttprint.ru;
bh=wbXsQnZf5lppr1CNQIQHgE2X0ByEWg7wcC8jBB/JMmw=;
b=IhF05rtbZ9NPicVahLurcTzP8jEQdsCREuOTFkObQNBQuNFLMwhOaikcoADtWLgdaA3j9SBKWXHW
muV5+sSxC20AhQKhDdx062K6E4wJ0gKtWw0X8R5YNY+Dd5xKY5f+Vay/NxCG8LO1yccTrlFri1Y0
s87EiU2Osy6Vg9CCKm3Hn0eexBZshH/uAcz3yt1S94WDmLDYbg1jgamu6YH78JccNy5VBJmhCVZ3
nczug74uydP07ApUBAIkiBmynRl8zyJ5A2ttTptN+lxCn7LMuFT04Unp6OJJN1ILRCMxB3TYaR+7
SxkHGsFZOmWIPlaW05fEZNZC2ETX7nSLn2yj+w==

Received: from trb2mails.ru (185.117.152.185) by mos-ttprint.ru for <ltdviso@yandex.ru>; Sun, 6 Jan 2019 01:40:20 -0500 (envelope-from <buonce@mos-ttprint.ru>)

Заголовок Recived присутствует, в заголовке указан первоисточник, и сервер PMTA

Message-ID: <5a95de5e931813d65858f34e767d6352@mos-ttprint.ru>
Date: Sun, 06 Jan 2019 06:40:20 +0000
Subject: Please validate this server.
From: mymails1 <info@mos-ttprint.ru>
Reply-To: mymails1 <info@mos-ttprint.ru>
To: ltdviso@yandex.ru
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=»_=_swift_v4_1546756820_475c6869d7cd67bfd97ec0eea179f59d_=_»
X-Sender: buonce@mos-ttprint.ru
X-Receiver: ltdviso@yandex.ru
X-Mw-Mailer: SwiftMailer — 5.4.x
X-Yandex-Forward: d5da2b2e27d00b08c1de9e1f685d0eda

Удаляем любой заголовок письма

remove-header
Область: source, domain
Тип: string
Атрибуты: optional
Значение по умолчанию:

Указывает хэдер, который PowerMTA должен будет удалить из входящего или исходящего сообщения. В директиву можно прописать список хэдеров, разделенных запятыми, если необходимо удалить более одного хэдера. Хэдер удаляется при доставке письма, а не при постановке сообщения в очередь. Директива может использоваться в source или domain, но не обязательна к прописыванию в обоих.

Чтобы указать, что ни один хэдер не должен быть удален, используйте пустые кавычки (“”) (необходимо только при изменении унаследованной настройки).

Пример удаления заголовка X-Mw-Mailer:

пример части сформированных заголовков yandex:

X-Sender: buonce@mos-ttprint.ru
X-Receiver: ltdviso@yandex.ru
X-Mw-Mailer: SwiftMailer — 5.4.x
X-Yandex-Forward: d5da2b2e27d00b08c1de9e1f685d0eda

<smtp-user user>
        password passuser
        source {pmta-auth}
</smtp-user>

<source {pmta-auth}>
        ....
        remove-header X-Mw-Mailer
process-x-job false
</source>

после добавления remove-header X-Mw-Mailer, в заголовках письма видим:

X-Sender: buonce@mos-ttprint.ru
X-Receiver: ltdviso@yandex.ru
X-Yandex-Forward: d5da2b2e27d00b08c1de9e1f685d0eda

Для удаления двух заголовков укажите их через запятую:

        ....
        remove-header X-Mw-Mailer,X-Sender
        ....

Если Вы захотите поиграть с подстановкой X-Mailer от разных программ в своем esp — небольшой список заголовков

Добавление заголовка в PMTA

За добавления заголовков с файла отвечает атрибут:

include-headers-from
Область: virtual mta, global
Тип: file name
Атрибуты: optional
Значение по умолчанию: none
Задает имя файла, содержащего хэдеры в формате RFC2822 для вставки во все сообщения,
доставляемые из VirtualMTA. Хэдеры добавляются сразу после хэдера Received, добавленного PowerMTA. При использовании директивы в области global, все VirtualMTA унаследуют настройки. Если для VirtualMTA уже имеется прописанная директива, будут использоваться оба параметра. Эта директива является перезагружаемой.

К примеру у нас удален Received первоисточника письма, но мы хотим показать Received с другим значением:

В VMTA добавим атрибут со значением загрузки файла где у нас будет опубликован заголовок include-headers-from /etc/pmta/haders.txt

<virtual-mta trast-vmta> 
auto-cold-virtual-mta 00.00.0.000 domain.ru
domain-key key1,domain.ru,/etc/pmta/key1.domain.ru.pem
max-smtp-out 850
include-headers-from /etc/pmta/haders.txt
<domain *>
</domain>
smtp-source-host 00.00.0.000 domain.ru.xyz
</virtual-mta>

в include-headers-from /etc/pmta/haders.txt пропишите нужный заголовок, к примеру мы в примере сделали Received: from admin by mail.its-krd.xyz with local (Exim 4.91)

Файл haders.txt поместите в свою папку pmta

Старайтесь не делать подмен заголовков, мы сторонники легетимной конфигурации

• Селектор ключа, который определяет какой ключ среди прочих ключей домена следует
  использовать;
• Имя домена DNS для ключа;
• Имя файла, содержащего ключ

Например

<virtual-mta domainkey>
 host-name port25.com
 ...
 domain-key test, port25.com, c:\pmta\k1.example.org.pem
</virtual-mta>

или

domain-key test, port25.com, c:\pmta\k1.example.org.pem

Можно указывать несколько записей domain-key. PowerMTA последовательно перебирает
ключи и выбирает первый ключ, домен которого соответствует личности, от имени которой подписывается электронное письмо. Информацию о этой личности PowerMTA извлекает из адреса
в хэдере Sender или, если таковой хэдер отсутствует, можно указать эту информацию директивой dkim-identity.

В директиве domain-key также можно указать подстановочный знак «*». В этом случае
PowerMTA будет считать его подходящим для любого домена личности. Это полезно, когда
один и тот же открытый ключ вводится в DNS под несколькими доменными именами.

Чтобы настроить подпись DKIM для домена:

1. Укажите домен, в котором будет зарегистрирован ключ. Это должен быть либо сам домен DKIM-личности, либо его родительский домен. В приведенных ниже примерах мы предположим, что это example.org.
2. Решите, что будет использоваться в качестве селектора. Селектор – это уникальный идентификатор ключа в пределах домена, указанного в шаге 1. Мы будем использовать k1 в приведенных ниже примерах.
3. Создайте свой закрытый ключ, используя утилиту pmtakeytool или мастер ключей от Port25 по адресу (если вы будете использовать мастер ключей, пропустите шаг 8):
   https://www.port25.com/support/domainkeysdkim-wizard/pmtakeytool newdk k1 example.org 2048
4. Эта процедура создаст 2048-битный закрытый ключ в файле k1.example.org.pem и соответствующий открытый ключ в формате BIND k1.example.org.dns.
5. Переместите PEM-файл в каталог c:\pmta\ на Windows или в каталог /etc/pmta на Unix; проверьте разрешения на доступ к файлу (в идеале, доступ должен быть предоставлен только PowerMTA).
6. Добавьте текстовую запись из файла k1.example.org.dns к вашей конфигурации DNS.
   Возможно, придётся подогнать синтаксис для программного обеспечения, которое вы
   используете. Вы можете обратиться к спецификации DKIM (с сайта http://www.dkim.org/)
   для получения более подробных сведений о синтаксисе записи:

K1._domainkey IN TXT ("k=rsa\; p="
"MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxeRmblkAUC0ZwBLltS37"
"ubgOk3bifNP8ubH5wc01mkAskRJcSDnXhxrbNseIBJye2lwVyRSDmkhCo5lreGbt"
"pwdo3kqIEj0k2+ZC2MSNREovoyFXuJHbNDB2VUvlh0ROJMNQx3VuBsYr884K1dsE"
"tzb+9+8JjYwKr6khNu4GeuebT4XdTwcqvtYkqw/MW4H0RxPJ8/w7pUHy1o08W1Hk"
"N/wAQkhcxygJTaehtkApDfY3N5kVk8XAYdzbJaSe/7Uw0ImqFgxy60MrWlUaUyWO"
"uTBwIPQScDgX3yIl1GHgV25DlEKo8sfTNgFJhil1ju3iZ25KoiPeFyWN+7AohF1Y"
"SQIDAQAB")

Добавьте директиву domain-key в файл конфигурации:

<virtual-mta example>
 ...
 domain-key k1, example.org, c:\pmta\k1.example.org.pem
</virtual-mta>

Или, если нужно произвести глобальную настройку

domain-key k1, example.org, c:\pmta\k1.example.org.pem

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

<domain yahoo.com>
 ...
 dkim-sign yes
</domain>

Если директива domain-key настроена для VirtualMTA, а не глобально, настройте
PowerMTA так, чтобы письма, которые необходимо подписывать, отправлялись через
нужный VirtualMTA:

<pattern-list L>
 mail-from /[@\.]example\.com$/ virtual-mta=example
</pattern-list>
<source 10.1.0.0/16> # источники предоставления информации
 pattern-list L
</source>

Добавление параметров DKIM-подписи в хэдер

PowerMTA поддерживает добавление параметров DKIM-подписи в хэдер, которые переопределяют параметры писем. Для этого необходимо активировать -директиву processX-DKIM-Options и добавить хэдер X-DKIM-Options перед предоставлением письма PowerMTA. Хэдер будет использовать синтаксис, схожий с тегами, разделёнными двоеточиями в DKIM-signature и может добавлять сразу несколько параметров:

• s – селектор. Указывает значение тега s= в подписи. В domain-key обязательно должен
  быть указан данный селектор.
• d – домен. Указывает значение тега d= в подписи. В domain-key обязательно должен
  быть указан точный домен или подстановочный шаблон («*»).
• i – личность. Указывает значение тега i=. Если не указан d, то в domain-key должен
  быть указан такой же домен, родительский домен или подстановочный шаблон («*»).
• q – метод запроса. Указывает значение тега q= в подписи.
• key-list – указывает, что ключ домена выбирается из указанного раздела <domainkey-list>

К примеру, со следующей конфигурацией:

domain-key key1, example.com, c:\pmta\key1.example.com.pem
domain-key key2, example.com, c:\pmta\key2.example.com.pem

Для выбора ключа могут быть использованы такие параметры X-DKIM-Options:

X-DKIM-Options: s=key2

Поддержка второй DKIM-подписи

PowerMTA поддерживает возможность добавления второго хэдера DKIM-Signature с параметрами, которые отличаются от параметров первого. Данная опция, например, фактически требуется gmail при использовании их цикла обратной связи. Все директивы dkim-… для второй
подписи начинаются с префикса «second-»:

second-dkim-add-body-limit
second-dkim-add-timestamp
second-dkim-algorithm
second-dkim-body-canon
second-dkim-disallow-adding-headers
second-dkim-expire-after
second-dkim-headers
second-dkim-headers-canon
second-dkim-identity
second-dkim-identity-fallback
second-dkim-sign
second-dkim-query-method

В примере ниже, мы видим, что PowerMTA добавляет и подпись клиента, и ESP-подпись к письмам, отправляемым через VirtualMTA «12345». Подпись клиента основывается на домене
хэдера From (customer.com), а ESP-подпись – на указанном параметре second-dkim-identity
(dkimesp.com). PowerMTA будет добавлять хэдер Feedback-ID, необходимый для gmail, в обе
подписи только для писем на gmail.

<virtual-mta 12345>
 domain-key 2017k1, esp.com, c:\pmta\keys\esp.esp.com.pem
 domain-key 2017-01, customer.com, c:\pmta\keys\2017-01.customer.com.pem
 <domain gmail.com>
 dkim-headers Feedback-ID
 second-dkim-headers Feedback-ID
<domain *>
 dkim-sign yes
 second-dkim-sign yes
 second-dkim-identity @esp.com
 </domain>
</virtual-mta>

Примечание: метод заголовка X-DKIM-Options не поддерживается для второй подписи, но все
равно может использоваться для первой подписи.
PowerMTA все равно доставит сообщение, если из-за атрибутов сообщения и параметров конфигурации нет подходящих подписей, независимо, должна ли применяться одна подпись или
обе.

Возможность DKIM-подписи закрытым ключом, данным в письме.

У PowerMTA есть возможность извлечения закрытого ключа из хэдера в письме и дальнейшего
использования этого ключа для DKIM-подписи писем. Это альтернативное решение для прописывания ключей в файле конфигурации. Чтобы сделать эту функцию активной, используйте
директиву process-x-dkim-key для источников.

Если установлено значение true, PMTA будет извлекать закрытый ключ, указанный в хэдере
X-DKIM-Key, и использовать его для DKIM-подписи писем. По соображениям безопасности, перед передачей письма, этот хэдер будет удален из него. Обратите внимание, что при использовании этой функции вы должны указать селектор (значение «s=») для DKIM-подписи с помощью хэдера X-DKIM-Options, иначе письмо не будет подписано. Обработка хэдера X-DKIMOptions также должна быть включена с помощью директивы process-x-dkim-options для
источника.

Также следует помнить, что содержимое X-DKIM-Key будет занимать несколько строк, поэтому
вам будет нужно ввести хэдер в теле сообщения, как показано в примере ниже:

Date: Mon, 8 Mar 2017 13:29:22 -0500
From: Test User <test@port25.com>
To: test@port25.com
Subject: help!
X-Dkim-Options: s=ball; d=some-esp.com;
X-Dkim-Key: -----BEGIN PRIVATE KEY-----
 MIICdQIBADANBgkqhkiG9w0BAQEFAASCAl8wggJbAgEAAoGBAL2/eGlUEGzYGMoN
 P8fdRRHF8BZ0/7+ani5IkZq5W84WDjSLtx8OryMYJNttOtdcIy3vb5YCsqziZncE
 a8ite5GiYct2SW+Such/KTWWNuJFEpyz7bjWjP46izuoktZ6JWErnmK+IiPCkc8/
 iSVJXZgafio5gBwr0mUi2YDGUX/RAgMBAAECgYBGYCSV1EL/S6ruDbnxNAUxEVv5
 yE0u0HcIrYurekItjoqYPJWfpD+a4ZKR+9JOG/NET0Dwv3Fro9DjJbWgSY/BkSKs
ckypdEh2DECtAaqpZ18Bs7nmaHnsyhaFHaTvT/VKM/WVvBXfh+NlaHoJK05um9MS
 jVwiDkZHVeku6g+Y0QJBAO392X05FziwQYFS5Y6ldfyJfWQzRmGTsz8B1HGeS84N
 wuMtP4zjL/c5nwOkN5SO8inE7xZLy958WQQtZW9BW00CQQDMGxbwuK4HmBLejLZw
 R7g9SH8b/54bWWt+4BmiWjF1Dnbeq/5Co2ZHcXOQ50fopk/OsAsN/F0VZb5578lz
 nsyVAkAyhSieBHiBeCjvowFH/qfFLAqKMrhGDmyGe4T1eXzuCM3OG9TZu4B7Iqg2
 xa1mw9F0PHHkccKdQBhFYr2dmGohAkAJi6bKAUkaT9FqGRibLa9/JjnTnGPPkaIG
 YAKy5hb0C4YhqdeNVEj/RF4MQ9TIG6cV2oPZ1pif3I9I8p7wSlf1AkBznyYhKnML
 OdSR8QUfwVm8o5TtFz+kisDJ7fQc1kCruB5IyLXPnKxugUcetHBVnC4Y7O996N4R
 mkoEKsyfiQhk
 -----END PRIVATE KEY-----
HELP! How do I port25?
Thanks abunch,
.. Test

Для DKIM-подписи письма выше, вам будет нужно добавить следующие директивы в конфигурацию PMTA:

<source 0/0>
 process-x-dkim-key yes
 process-x-dkim-options yes
</source>
<source {pickup}>
 process-x-dkim-key yes
 process-x-dkim-options yes
</source>

Макрос для домена позволяет индивидуально настроить дозировку почтового трафика для каждого принимающего почтового сервера, будь то mail.ru, yandex.ru, gmail.com в отдельности.

# domains that resolve to MAIL.RU
domain-macro mailru mail.ru,bk.ru,inbox.ru,list.ru,mail.ua,mail.kz

<domain $mailru>
  max-smtp-out 1 
  max-msg-per-connection 1 
  max-errors-per-connection 2

  max-msg-rate 1/m

  bounce-upon-no-mx true
  assume-delivery-upon-data-termination-timeout yes
  smtp-421-means-mx-unavailable yes
  smtp-553-means-invalid-mailbox yes
  bounce-upon-5xx-greeting true
  connect-timeout 2m
  smtp-greeting-timeout 5m
  data-send-timeout 5m
  retry-after 3h 
  bounce-after 2d

  smtp-pattern-list blocking-errors
  backoff-max-msg-rate 1/m
  backoff-retry-after 1h,3h,6h,12h 
  backoff-to-normal-after-delivery yes 
  backoff-to-normal-after 1h 

  dk-sign yes
  dkim-sign yes
  deliver-local-dsn false
</domain>

Разбираем опубликованный макрос

domain-macro mailru mail.ru,bk.ru,inbox.ru,list.ru,mail.ua,mail.kz

Область применения: глобальная
Тип: список
Атрибуты: необязательно
По умолчанию: нет

Задаем переменную домена domain-macro mailru и почтовые сервера mail.ru,bk.ru,inbox.ru,list.ru,mail.ua,mail.kz для расширения влияния макроса домена.

Старт секции макроса домена
<domain $mailru>

для макроса mailru домена mail.ru и его почтовых доменов

max-smtp-out

Область применения: домен, virtual-mta
Тип: номер
Атрибуты: необязательно
По умолчанию: 20 для домена, неограниченное для virtual-mta

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

max-msg-per-connection

Область применения: домен
Тип: номер
Атрибуты: необязательно
По умолчанию: 0

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

Значение ноль означает, что нет ограничений.

max-errors-per-connection

макс-ошибка-за соединение
Область применения: домен
Тип: номер
Атрибуты: необязательно
По умолчанию: не ограничено

Директива указывает после какого кол-ва ошибок разорвать соединение с сервером. Значение по умолчанию не ограничено, что означает, что PowerMTA не будет разорвать соединение из-за ошибок на уровне получателей.

max-msg-rate

максимальная  скорость передачи
Область применения: домен
Тип: {unlimited|0|N/{h|hr|m|min|s|sec}
Атрибуты: необязательно
По умолчанию: не ограничено

Позволяет вводить поминутные, по часовые и посекундные скорости передачи сообщений. Принимает
следующие значения: «unlimited или 0 — без ограничений», «кол-во писем/значение времени»

bounce-upon-no-mx

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: false

Если задано значение «true» и записи MX для домена не найдены, то все электронные письма сразу поступают в очередь отказов. Обратите внимание, это относится только к случаям, когда выполняется поиск MX, и не включает случаи, когда список хостов указан явно в директива route.

assume-delivery-upon-data-termination-timeout

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: no

Если включено, и время ожидания соединения остается в ожидании ответа на «.» после
DATA или для ответа на последний сегмент BDAT, PowerMTA предполагает, что
доставка прошла успешно. Может привести к дублированию сообщений.

smtp-421-means-mx-unavailable

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: no

Если установлено «yes», PMTA немедленно разорвет соединение при получении
ошибка 421 и предпримет попытку нового подключения к следующей записи MX
перечисленных в DNS. Установка по умолчанию «no» заставит PowerMTA сбросить
подключение, а затем повторно использовать то же соединение для дополнительных получателей

smtp-553-means-invalid-mailbox

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: yes

Указывает PowerMTA, следует ли использовать значение по умолчанию 5.1.1 после ответа 553 RCPT
в ответе не указывается расширенный код состояния

bounce-upon-5xx-greeting

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: true

Указывает, должен ли PowerMTA немедленно отбрасывать все сообщения для домена при получении приветствия 5xx SMTP. Если эта директива установлена в false, PowerMTA будет считать приветствия 5xx временной ошибкой и попытается доставить сообщения на вторичные почтовые сервера MX, а также продолжайте повторную попытку доставки до истечения интервала отказов.

connect-timeout

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 2 м (две минуты)

Задает максимальное количество времени, в течение которого PowerMTA ожидает установки исходящего
SMTP-соединение.

smtp-greeting-timeout

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 5 м (пять минут)

Задает время ожидания начального приветствия SMTP 220 после того, как соединение установленно.

data-send-timeout

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 3 м (три минуты)

Задает максимальное время ожидания PowerMTA для передачи данных. В соответствие с RFC 2821, этот тайм-аут должен составлять не менее трех минут.

retry-after

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 10 минут

Определяет интервал повторной доставки для сообщений, которые не были доставлены при первой попытки.

bounce-after

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 4 дня, 12 часов

Определяет максимальное количество времени, которое PowerMTA будет продолжать пытаться
доставлять сообщения на домен секции. Сообщения старше этого интервала времени будет отклонено, то есть будет отправлен  отчет о не доставке в формате DSN (bounce).

smtp-pattern-list (имя листа) blocking-errors

Директива добавляет шаблон регулярных выражений ошибок в макрос домена. По которым PowerMTA предпринимает определенные действия на основе ответов SMTP полученных от удаленного почтовика. Регулярные выражения задаются в директиве <smtp-pattern-list> Вашей конфигурации с присвоением имени blocking-errors используемого в нашем случае в макросе домена.

backoff-max-msg-rate

Область применения: домен
Тип: номер
Атрибуты: необязательно
По умолчанию: unlimited

Эта директива имеет ту же функцию, что и max-msg-rate, и применяется вместо maxmsg-rate, когда очередь находится в режиме отката. И доставки, и попытки доставки засчитываются в лимит.
следующая ошибка будет отображаться на веб-мониторе, когда ограничение скорости
достигнуто: «message rate limit reached (based on backoff-max-msg-rate in configuration)»

backoff-retry-after 1h,3h,6h,12h

Область применения: домен
Тип: временной интервал
Атрибуты: необязательно
По умолчанию: 1h

Эта директива имеет ту же функцию, что и retry-after, и применяется для повторной попытке, пока очередь находится в режиме отката (bounce).

backoff-to-normal-after-delivery

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: false

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

backoff-to-normal-after

Область применения: домен
Тип: время Nd|h|m|s|
Атрибуты: необязательно
По умолчанию: никогда

Определяет интервал времени, после которого очередь отката (ищгтсу) автоматически возвращается в нормальное состояние.

dk-sign yes
dkim-sign yes

Включает DKIM подпись для домена отправителя

deliver-local-dsn no

Область применения: домен
Тип: логическое значение
Атрибуты: необязательно
По умолчанию: true

Директива указывает PowerMTA, следует ли создавать и отправлять уведомление о доставке (DSN) сообщения. DSN более широко известные как отчеты об отказах, однако существуют также уведомления об отсутствии отказов.
Независимо от того, установлено ли значение «true» или «false», PowerMTA запишет окончательную информацию об отказе в файл учета PowerMTA, когда PowerMTA получает постоянную ошибку / 5xx
с удаленного хоста во время соединения или когда ошибка генерируется PowerMTA. По умолчанию установлено значение true, что указывает PowerMTA на создание отчета и попытки его а также сделать записать в лог файл.
Если установлено значение false, PowerMTA не создает отчет о доставке, он записывает данные отказов в файл учета для последующей обработки. Значение false правильная настройка для систем, которые анализируют только данные файла учета, и не хотите, чтобы какие-либо отчеты о ошибках генерировались и отправлялись на SMTP MAIL

Виртуальные MTA в конфигурации PMTA позволяют разделять трафик на отдельные управляемые почтовые потоки, распределять их по группе ip адресов, балансировать почтовый трафик на smtp и т.п, при одной системной конфигурации или объединять в пул множество ip/smtp для последующего распределения и ротации.

PowerMTA.

Статья — усеченный перевод 8 раздела официальной справки PMTA с дополнениями © My-Mails

Поддержка VirtualMTA / VirtualMTA Support 

VirtualMTA определяются с помощью директивы <virtual-mta>.

Создайте группы <virtual-mta> с желаемыми псевдонимами и присвоением имени хоста и IP-адреса SMTP.

Например: создать VMTA с именем mta1, просто добавьте в файл конфигурации:
в нашей версии 4.5r1 /etc/pmta/virtualhost.txt

<virtual-mta mta1>
 smtp-source-host 1.2.3.4 mta1.port25.com
</virtual-mta>

Обратите внимание, что если вы опустите в определении директиву smtp-source-host, PowerMTA, будет использовать глобальные настройки для этого VMTA.
Рекомендуется указывать директивы имени хоста в каждом определении VirtualMTA.
Убедитесь, в правильности имени хоста: smtp-source-host 2.3.4.5 mta2.port25.com

Если в определении указано более одного адреса smtp-source-host, PowerMTA будет использовать различные исходные IP-адреса в циклическом порядке для соединений:

<virtual-mta mta3>
 smtp-source-host 1.2.3.4 mta4.port25.com
 smtp-source-host 2.3.4.5 mta5.port25.com
 smtp-source-host 3.4.5.6 mta6.port25.com
</virtual-mta>

Пулы VirtualMTA

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

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

Пулы VirtualMTA определяются с помощью новой директивы <virtual-mta-pool>.

Определение пул влечет за собой создание группы <virtual-mta-pool> с желаемым псевдонимом и перечислением VirtualMTA, которые вы хотите объединить в группу.

Например, если вы хотите создать пул VirtualMTA с именем pond, вы должны сначала определить конкретные VirtualMTA, которые будут входить в группу, а затем впоследствии перечислите каждый из них в <virtual-mta-pool pond>:

Определяем VMTA

<virtual-mta mta1>
 smtp-source-host 1.2.3.4 mta1.port25.com
</virtual-mta>
<virtual-mta mta2>
 smtp-source-host 2.3.4.5 mta2.port25.com
</virtual-mta>

Объединяем в пул

<virtual-mta-pool pond>
 virtual-mta mta1
 virtual-mta mta2
</virtual-mta-pool>

Важно: имя virtual-mta-pool на может совпадать с именем virtual-mta

Выбор пула VirtualMTA

PMTA поддерживает различные методы выбора VirtualMTA (или пула) в зависимости от ваших методов соединения:

• API представления:

Путем определения переменной * vmta mailmerge в сообщениях mailmerge;
С помощью setVirtualMta или эквивалентного метода

• Представление каталога раскладки:

Путем определения переменной * vmta mailmerge в сообщениях mailmerge;
Путем сопоставления с образцом на основе MAIL FROM, RCPT TO или заголовка.

• Отправка SMTP:

— Путем определения переменной * vmta mailmerge в сообщениях mailmerge;
— Путем включения в сообщение заголовка X-virtual-MTA
— Совпадением регулярного выражения SMTP MAIL FROM или RCPT TO адреса или заголовок сообщения;
— Путем настройки VirtualMTA по умолчанию для директивы <source>, выбранной IP-адрес и порт на компьютере PowerMTA, к которому вы подключаетесь
— Путем настройки VirtualMTA по умолчанию для директивы <source>, выбранной
IP-адрес источника
— Методы выбора, перечисленные выше, перечислены в порядке приоритета в каждом представлении.
методы.
Использование mailmerge может повлиять на выбор VirtualMTA. При использовании mailmerge
и API или SMTP, x-virtual-mta будет применяться ко всему заданию mailmerge, а не
отдельные получатели (в большинстве случаев с использованием первого определенного x-virtual-mta).
При использовании mailmerge и списков шаблонов, выбор VirtualMTA будет для каждого получателя
при сопоставлении RCPT TO, и будет только для каждого получателя для MAIL FROM
при использовании переменной * from mailmerge. Когда не используется * из или когда используется
Соответствие заголовка, *all * получатели в задании mailmerge будут использовать один и тот же VirtualMTA (в
в большинстве случаев первый подобранный шаблон).

Обратите внимание, что один выбирает пул VirtualMTA, используя тот же точный заголовок, директивы или
вызов функции, но с использованием имени пула вместо имени VirtualMTA.

Выбор VirtualMTA с помощью X-virtual-MTA Заголовок

Чтобы выбрать VirtualMTA с заголовком X-virtual-MTA, вам необходимо:

Добавить к директиве

1. определить VirtualMTA или пул (ы), используя директиву <virtual-mta>;

2. определить конкретный IP-адрес или диапазон IP-адресов для источника сообщений

что оно применимо с использованием расширенной директивы <source>;

3. определить способность PowerMTA обрабатывать заголовок x-virtual-mta через

директива process-x-virtual-mta в директиве <source>, определенной в шаг 2;

process-x-virtual-mta yes # разрешить выбор VirtualMTA

После правильной настройки файла конфигурации вам просто нужно добавить заголовок xvirtual-mta к вашему сообщению, указав псевдоним VirtualMTA, как в

x-virtual-mta: mta1

где mta1 — псевдоним VirtualMTA в файле конфигурации. Обратите внимание, что PowerMTA

проанализирует и удалит заголовок перед окончательной доставкой, поэтому он не будет виден

почтовый шлюз получателя или получателя.

Например, предполагая, что у вас есть следующее определение VirtualMTA в вашем

конфигурационный файл:

<virtual-mta mta1>
 smtp-source-host 1.2.3.4 mta1.port25.com
</virtual-mta>

и вы хотели, чтобы PowerMTA обрабатывал заголовок x-virtual-mta только из почты

исходя из локального IP-адреса 127.0.0.1 для выбора VirtualMTA, вам потребуется

иметь как минимум следующее в вашем конфигурационном файле;

<source 127.0.0.1>
 process-x-virtual-mta yes # разрешить выбор VirtualMTA
 always-allow-relaying yes # разрешить кормление с 127.0.0.1
</source>

При этом любые сообщения, отправленные с локального IP-адреса 127.0.0.1, содержащие
заголовок x-virtual-mta: mta1 будет иметь PowerMTA, используя VirtualMTA mta1 и его
параметры при установлении соединения для доставки этих сообщений. Можно также выбрать
Пул VirtualMTA будет использоваться для сообщений таким же образом.

Выбор VirtualMTA по SMTP MAIL FROM / SMTP RCPT TO

Сайты также могут иметь PowerMTA использовать VirtualMTA или пул VirtualMTA для конкретных

сообщения посредством сопоставления с шаблоном регулярного выражения SMTP MAIL FROM

адрес, SMTP RCPT TO адрес или заголовок, основанный на IP-адресе источника

сообщение.

Чтобы выбрать пул VirtualMTA или VirtualMTA на основе шаблона регулярного выражения

1. определить пулы VirtualMTA или VirtualMTA в файле конфигурации, используя

директива <virtual-mta>;

2. определить псевдоним для списка шаблонов регулярного выражения с помощью <pattern-list>

директива;

3. определить фактический шаблон регулярного выражения, который будет использоваться для сопоставления SMTP MAIL

ОТ, адрес RCPT TO или заголовок, а также последующий VirtualMTA или

Пул VirtualMTA для использования при совпадении через mail-from, rcpt-to и

директивы заголовка. Эти директивы определены в <pattern-list>

определение, созданное на шаге 2;

4. определить конкретный IP-адрес или диапазон IP-адресов для источника сообщений

это применимо в расширенной директиве <source>;

5. определить директиву pattern-list, используя соответствующий псевдоним, определенный на шаге 2

в директиве <source>, определенной на шаге 4. Условное сопоставление с образцом как

определенные в разделе 3.2.16, также могут быть использованы.

Например, если в вашем файле конфигурации есть следующие определения VirtualMTA:

<virtual-mta mta1>
smtp-source-host 1.2.3.4 mta1.port25.com
</virtual-mta>

<virtual-mta mta2>
smtp-source-host 2.3.4.5 mta2.port25.com
</virtual-mta>

и вы хотели, чтобы PowerMTA соответствовал шаблонам «abc» и «xyz» в начале

ПОЧТА ОТ адреса, чтобы выбрать соответствующий VirtualMTA для использования для каждого, вы

в вашем конфигурационном файле должно быть как минимум следующее:

<pattern-list group2>
mail-from /^abc/ virtual-mta=mta1
mail-from /^xyz/ virtual-mta=mta2
</pattern-list>

<source 127.0.0.1>
pattern-list group2 # выбирает список шаблонов для сообщений
always-allow-relaying yes # разрешить кормление с 127.0.0.1
</source>

При этом любые сообщения, отправленные с локального IP-адреса 127.0.0.1, будут иметь

PowerMTA с использованием сопоставления регулярных выражений по адресу MAIL FROM, и если

PowerMTA обнаружил «abc» в начале адреса (например, abc2890u8@bounces.port25.com), VirtualMTA mta1 и его параметры будут использованы

при создании соединений для доставки этих сообщений. Для отправленных сообщений, которые имели

ПОЧТА ОТ, начиная с «xyz», например, xyz-ljwer@bounces.port25.com,

VirtualMTA mta2 и его параметры вместо этого будут использоваться при подключении к

доставить эти сообщения.

Чтобы дополнительно выбрать несколько других VirtualMTA для получателей на yahoo.com, вы можете

добавьте директиву rcpt-to, как показано ниже:

<pattern-list group2>
mail-from /^abc/ virtual-mta=mta1
mail-from /^xyz/ virtual-mta=mta2
rcpt-to /@yahoo.com$/ virtual-mta=mta3
</pattern-list>

В приведенных выше простых примерах вы можете видеть, что PowerMTA может использовать различные соответствия

шаблоны для разных кампаний, клиентов и / или рассылок одновременно, чтобы

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

Допускается использование нескольких директив mail-from, rcpt-to и header.

определение <pattern-list>, и поскольку используется первое совпадение, вы захотите перечислить

скорее всего совпадет первым. В группе <source> допускается только один шаблонный список.

Условное соответствие также допускается. Например, если вы хотите, чтобы все письма

иметь MAIL FROM of X и RCPT TO Y, что допускается по схеме, аналогичной

следующие

<pattern-list patterns>
  mail-from /X/ <pattern-list>
    rcpt-to /Y/ virtual-mta=vmta2
    rcpt-to /Z/ virtual-mta=vmta1
   * virtual-mta=vmta2
  </pattern-list>
</pattern-list>

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

Обратите внимание, что поддерживается простое и расширенное сопоставление с шаблоном регулярного выражения

который основан на Perl-совместимых регулярных выражениях (PCRE).

8.4.3 Выбор VirtualMTA по IP

Адрес / Порт, Получающий Соединения

Для дополнительной гибкости PowerMTA поддерживает возможность выбора VirtualMTA на основе

IP-адрес (и номер порта TCP) на компьютере PowerMTA, к которому вы подключаетесь

при отправке ваших сообщений.

Например, если вы определили 10 VirtualMTA, каждый из которых имеет свой IP-адрес, вы

можно выбрать VirtualMTA для использования для каждого сообщения, просто сделав свой SMTP

подключение к определенному IP-адресу, определенному на вашем компьютере PowerMTA для

конкретный VirtualMTA.

Это достигается с помощью «именованных» тегов <source> в сочетании с директивой smtplistener. Именованные теги <source> позволяют вам указывать директивы, которые переопределяют

те, которые обычно выбираются по IP-адресу источника; они применяются только при условии ссылки в

Директива smtp-listener (и для аутентифицированных пользователей — см. Раздел 10.2.2).

Например, чтобы выбрать VirtualMTA vmta1 по назначенному адресу smtp-source-host

1.2.3.4 и стандартный порт SMTP (25), вы должны настроить:

<virtual-mta vmta1>
smtp-source-host 1.2.3.4 vmta1.yourdomain.com
...
</virtual-mta>

<source vmta1>
default-virtual-mta vmta1
</source>

smtp-listener 1.2.3.4:25 source=vmta1

В файле конфигурации может быть указано несколько записей smtp-слушателя, каждая из которых указав другой IP-адрес и / или порт.

Обратите внимание, что если указаны какие-либо директивы smtp-listener, все слушатели должны быть явно определено: PowerMTA больше не запускает прослушиватель автоматически на основе значения

Директивы smtp-ip и smtp-port. При настройке вашей первой записи smtp-listener,

чтобы сохранить прослушиватель по умолчанию, вы должны добавить еще одну директиву smtp-listener, указав

твой smtp-ip и smtp-порт в нем. Если у вас не настроен smtp-ip, используйте 0.0.0.0

вместо этого, что заставляет PowerMTA связываться со всеми локальными IP-адресами:

smtp-listener 0.0.0.0:25

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

адрес и порт, нужно быть осторожным с тем, что там вводится. Например,

Всегда разрешать ретрансляцию, скорее всего, не следует включать в названном источнике.

Вместо этого следует разрешить пересылку, доступ к расширениям mailmerge и т. Д.

на основе аутентифицированных источников (см. раздел 10.2.2) или IP-адреса источника, как в

пример ниже:

<virtual-mta vmta1>
 smtp-source-host 1.2.3.4 vmta1.yourdomain.com
 ...
</virtual-mta>

smtp-listener 1.2.3.4:25 source=vmta1
smtp-listener 0.0.0.0:26

<source vmta1>
 default-virtual-mta vmta1
</source>

<source 10.0.0.0/8>
 allow-mailmerge yes
 always-allow-relaying yes
</source>

<source 0/0>
 allow-mailmerge no
 always-allow-relaying no
</source>

Выше VirtualMTA vmta1 выбран по умолчанию для любых сообщений, полученных через

1.2.3.4 на машине PowerMTA. Прослушиватель по умолчанию на 0.0.0.0:25 сохраняется

через собственную директиву smtp-listener. Разрешение на ретрансляцию и использование

Расширения mailmerge предоставляются для подключений из <source 10.0.0.0/8>,

подключаются ли они к 1.2.3.4 или нет.

Выбор VirtualMTA по исходному IP Адресу отправителя

1. определите пулы VirtualMTA или VirtualMTA в файле конфигурации, используя

директива <virtual-mta>;

2. определить конкретный IP-адрес или диапазон IP-адресов для источника сообщений

это применимо с использованием расширенной директивы <source>;

3. определить VirtualMTA, который будет использоваться для сообщений через новый default-virtual-mta

директива внутри директивы <source>, определенной на шаге 2.

Например, предполагая, что у вас есть следующее определение VirtualMTA в вашем

конфигурационный файл:

<virtual-mta mta1>
smtp-source-host 1.2.3.4 mta1.port25.com
</virtual-mta>

и вы хотели использовать только почту с локального IP-адреса 127.0.0.1

VirtualMTA по умолчанию для каждого сообщения (без указания x-virtual-mta

заголовок в сообщениях), вы должны иметь как минимум следующее

конфигурационный файл;

<source 127.0.0.1>
default-virtual-mta mta1 # выбирает VirtualMTA / пул по источнику сообщения
always-allow-relaying yes # разрешить кормление с 127.0.0.1
</source>

При этом любые сообщения, отправленные с локального IP-адреса 127.0.0.1, будут иметь

PowerMTA, использующий VirtualMTA mta1 и его параметры при подключении к

доставить эти сообщения. Можно также выбрать пул VirtualMTA, который будет использоваться для сообщений

исходя из определенного IP-адреса, указав вместо этого имя пула VirtualMTA через

директива default-virtual-mta

Вы можете в основном определить столько разных IP-адресов источника или диапазонов IP-адресов для

сообщения в файле конфигурации, как вы хотите, каждый из которых использует разные VirtualMTA

или пул VirtualMTA.

Выбор VirtualMTA по IP-адресу VirtualMTA

Адрес

В дополнение к вышесказанному, VirtualMTA может быть привязан в зависимости от того, какой PowerMTA IP

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

1. IP. Чтобы использовать этот метод выбора, потребуется исходная директива default-virtual-mta.

для использования с настройкой «by-smtp-source-ip» вместо имени VirtualMTA.

При такой настройке для входящего SMTP-подключения PowerMTA будет использовать как

VirtualMTA по умолчанию, чей параметр «smtp-source-host» равен целевому IP

адрес на входящем соединении.

Пример:

<virtual-mta mta1>
smtp-source-host 1.2.3.4 vmta1.port25.com
</virtual-mta>
<source 0/0>
default-virtual-mta by-smtp-source-ip
</source>

В приведенном выше примере подключение к IP-адресу 1.2.3.4 будет автоматически маршрутизировать

сообщение через VirtualMTA «mta1». Также при подключении с внешнего

отправив PowerMTA по почте, PowerMTA ответит именем хоста, настроенным в

VirtualMTA.

8.6 Настройка дополнительных IP-адресов

Прежде чем вы сможете назначить IP-адреса для VirtualMTA, они должны быть распознаны

операционная система. Обычно для каждого сетевого адаптера назначается один IP-адрес (сеть

Интерфейсная карта), также возможно определить дополнительные (псевдоним) IP-адреса к существующему

NIC.

В Windows 2000 вы добавляете псевдоним IP-адреса, открыв Панель управления, затем щелкнув правой кнопкой мыши «Подключение по локальной сети», открыв «Свойства», дважды щелкнув «Интернет».

Протокол », нажимая« Дополнительно »и, наконец, нажимая« Добавить … »в верхней половине« IP

Вкладка «Настройки». Для получения дополнительных IP-адресов, просто нажмите «Добавить …» несколько раз, предоставляя новый

IP-адреса. Изменения должны стать активными, как только вы нажмете «ОК»

закрыть окно свойств подключения по локальной сети.

В Red Hat Linux вы добавляете IP-адрес псевдонима, скопировав / etc / sysconfig / networkscripts / ifcfg-eth0 (подставив соответственно имя интерфейса, если оно не eth0), в

ifcfg-eth0: 1 (в том же каталоге), а затем отредактируйте файл, изменив DEVICE на eth0: 1

и IPADDR на новый IP. Если добавляемый IP-адрес находится не в той же подсети, что и

основной IP-адрес, возможно, вам также потребуется обновить NETMASK. Вы можете просто удалить

поля NETWORK и BROADCAST, если они есть, так как они автоматически вычисляются

система. Для получения дополнительных IP-адресов создайте дополнительные файлы с именем ifcfg-eth0: 2 и т. Д. Чтобы активировать

изменения, либо остановите и перезапустите интерфейс, либо просто перезагрузите систему.

В Solaris вы добавляете псевдоним IP-адреса, создавая файл с именем /etc/hostname.hme0:1

(подставив имя интерфейса, если оно не hme0) и введя нужный IP-адрес в

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

создайте дополнительные файлы с именем hostname.hme0: 2 и т. д. Чтобы активировать изменения, перезагрузитесь

система.

Естественно, любые IP-адреса, которые вы добавляете, должны быть действительными в локальной сети, в которой находится ваша система.

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

использовать.

Настройка конфигурации брандмауэра

Если PowerMTA работает на машине за брандмауэром, после того, как он настроен на использование

разные IP-адреса для каждого VirtualMTA, ваш брандмауэр будет видеть исходящее соединение

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

соответственно.

8.7 Предварительные условия DNS

Многие интернет-провайдеры проверяют имя хоста и IP-адреса источника, используемые во входящем SMTP

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

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

VirtualMTAs.

Изменения в определениях VirtualMTA можно применять с помощью команды pmta reload, не требуют перезагрузки.

max-smtp-msg-rate
область применения: virtual-mta

max-msg-rate
область применения: домен

значения: unlimited | 0 | кол-во / h | hr | m | min | s | sec
Атрибуты: необязательно
По умолчанию: не ограничено

Значения скорости отправки писем можно указывать поминутно / по часовое/ по секундное.

Значения:

• unlimited — безлимитно
• кол-во/h или кол-во/hr (для почасовых часов): 1/h или 1/hr — 1 письмо в час
• кол-во/m или кол-во/min (в минуту): 1/m или 1/min — 1 письмо в минуту
• кол-во/s или кол-во/sec (в секунду): 1/s или 1/sec — 1 письмо в секунду

«max-msg-rate» и «max-msg-per-hour» изменяют одну и ту же внутреннюю настройку и таким образом переопределяют каждый

Другое, когда установлено.

<virtual-mta customer1>
max-smtp-msg-rate 6/sec # 6 писем в секунду
</virtual-mta>

или для принимающего почтового сервера mail.ru 
<domain $mailru>
 max-msg-rate 1/m # 1 письмо в минуту
</domain>

В лимит отправки засчитываются и удачные доставки, и попытки.

Следующая ошибка будет отображаться на веб-мониторе, когда достигнет ограничение скорости:

«message rate limit reached (based on max-smtp-msg-rate in configuration)».

backoff-max-msg-rate
область применения: domain
значение: номер
Атрибуты: необязательно
По умолчанию: не ограничено

к примеру

backoff-max-msg-per-hour="unlimited"
или
backoff-max-msg-per-hour 120

Эта директива имеет ту же функцию, что и max-msg-rate, и применяется для очереди в режиме отката bounce.

Top 10 queues by number of recipients / Топ-10 очередей по количеству получателей

…………..::1001/queues

Установки отображения статистики

Расширенная статистика

ВОПРОС — тукущее исполнение или будущее в очереди показывается !?

Текущие настройки конфигурации данного MTA

Domains

……..:1001/domains

Наблюдаем статистику по доменам получателям, выводится последние 10 по объему отправки писем.

Узнать время на сервере можно проверкой статуса PMTA

show status

Статусы

Skipping rescheduling because a configured rate limit is zero / Пропуск повторной отправки, так как, установленный предел скорости равен нулю.

Message rate limit reached (based on queue’s backoff-max-msg-rate in configuration) — достигнут предел скорости передачи сообщений (в зависимости от частоты отсрочки очереди-max-msg-rate в конфигурации)

4.4.7 (delivery time expired) / Срок поставки истек

All SMTP sources for queue ymail.com/mta195 are now disabled.

message rate limit reached (based on queue’s max-msg-rate in configuration)