Опасное использование smtpd_recipient_restrictions
Теперь читатель может спросить, зачем нужны списки ограничений client, helo или sender, если их обработка откладывается до команды RCPT TO или ETRN. Некоторые люди рекомендуют помещать ВСЕ ограничения в список . К сожалению, это может привести к слишком доверчивому поведению SMTP сервера Postfix. Как это возможно?
Цель списка — это управление тем, как Postfix отвечает на команду RCPT TO. Если список ограничения выдает результат REJECT или DEFER, то адрес получателя отклоняется, что и требуется. Если результат — PERMIT, то адрес получателя принимается. И здесь следует ждать сюрпризов.
Вот пример, который иллюстрирует вышеуказанную ситуацию:
1 /etc/postfix/main.cf: 2 = 3 4 hash:/etc/postfix/helo_access 5 6 7 8 /etc/postfix/helo_access: 9 localhost.localdomain PERMIT
В 5-ой строке отклоняется почта от всех клиентов, которые не указывают правильное имя хоста в команде HELO. В строках 4-ой и 9-ой сделано исключение для некоторого клиента, который представляется, как «HELO localhost.localdomain».
Проблема этой конфигурации в том, что список выдает результат PERMIT для ЛЮБОГО хоста, который анонсирует себя, как «localhost.localdomain». В результате, Postfix становится открытым релэем (open relay) для всех таких машин.
Чтобы избежать подобных недоразумений со списком , вам следует помещать ограничения, не связанные с адресом получателя (non-recipient restrictions), ПОСЛЕ ограничения , а не до него. В примере выше ограничение для HELO должно быть размещено ПОСЛЕ , или, еще лучше, поместить ограничение HELO в список , где оно не вызовет проблем.
Настройка аутентификации на Postfix
Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.
а) если используем Ubuntu / Debian:
apt-get update
apt-get install postfix dovecot-imapd dovecot-pop3d
б) если используем CentOS / Red Hat:
yum install postfix dovecot
После установки пакетов, разрешаем автозапуск dovecot и postfix:
systemctl enable postfix dovecot
Открываем на редактирование конфигурационный файл нашего MTA Postfix:
vi /etc/postfix/main.cf
Добавляем строки (или меняем значения):
smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
* где:
- smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
- smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
- smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
-
smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
- permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
- permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
- reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.
Проверяем корректность настройки:
postconf > /dev/null
Если команда не вернула ошибок, перезапускаем Postfix:
systemctl restart postfix
Переходим к настройке dovecot — открываем файл:
vi /etc/dovecot/conf.d/10-master.conf
… и приводим опцию service auth к следующему виду:
service auth {
…
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
…
}
* если соответствующей секции unix_listener нет, то ее нужно создать
Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth
Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):
vi /etc/dovecot/conf.d/10-ssl.conf
![Настройка почтового сервера postfix [айти бубен]](https://tehnikaarenda.ru/wp-content/uploads/c/a/6/ca68b5087a2c42a07ac9bf6fd9b1d654.jpeg)
Проверяем, чтобы значение ssl не было required:
ssl = yes
* нас устроит оба варианта — yes или no.
Настройки аутентификации приводим к следующему виду:
vi /etc/dovecot/conf.d/10-auth.conf
auth_mechanisms = plain login
* данные механизмы позволяют передачу данных в открытом виде.
В этом же файле проверяем, что снят комментарий со следующей строки:
!include auth-system.conf.ext
Проверяем корректность настройки dovecot:
doveconf > /dev/null
Если команда ничего не вернула, перезапускаем сервис:
systemctl restart dovecot
В качестве логина и пароля можно использовать любую системную учетную запись. Создадим ее для теста:
useradd smtptest
passwd smtptest
Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:
Пробуем отправить письмо. Отправка должна потребовать ввода логина и пароль — используем аутентификационные данные для записи, созданной выше.
Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.
Настройка
В данной статье мы не будем рассматривать установку Postfix, так как данный сервер легко устанавливается под большинство дистрибутивов, и вы можете найти большое количество статей, посвященных данному действию.
/etc/postfix/main.cf
Как должно быть понятно из названия, это основной конфигурационный файл Postfix.
Совет: Команда ниже покажет вам все конфигурационные директивы, значения которых отличаются от дефолтных:
postconf -n
Так как на шлюзе требуется только пересылка почты, отключаем локальную доставку сообщений (Замечание: пустое значение конфигурациооной директивы означает её отключение):
mydestination = local_recipient_maps = local_transport = error:local mail delivery is disabled
Установите директиву myorigin в значение домена, на который пересылается почта:
myorigin = example.com
Директива mynetworks = определите сети, которым разрешено выполнять пересылку через данный сервер. Обычно сюда включают только внутреннюю локальную сеть, или вообще только IP внутреннего почтового сервера:
mynetworks = 127.0.0.0/8, 172.16.42.0/24
Данная секция предотвращает прием сообщений для адресов вида username@subdomain.example.com to match. Мы явно определим домены, для которых необходимо принимать почту в директиве relay_domains ниже.
parent_domain_matches_subdomains = debug_peer_list, smtpd_access_maps
relay_domains = в данной директиве определяем домены, для которых необходимо принимать почту.
relay_domains = example1.com, example2.com, subdomain.example.com
smtpd_recipient_restrictions = контролируем действия сервера после команды RCPT TO.
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
transport_maps = указываем связь между доменами и SMTP серверами, на которые будет пересылаться почта.
transport_maps = hash:/etc/postfix/transport
relay_recipient_maps = указатель на файл, который будет содержать спискок адресов электронной почты, для которых Postfix будет принимать сообщения.
relay_recipient_maps = hash:/etc/postfix/relay_recipients
show_user_unknown_table_name = в установленном значении no возвращает сообщение «User unknown» если адрес электронной почты не найден. Используется в связке с relay_recipient_maps.
show_user_unknown_table_name = no
Хотя локальная доставка почты отлючена, почтовый шлюз должен принимать почты для адресов postmaster и abuse. Для этого определите виртуальные алиасы.
virtual_alias_maps = hash:/etc/postfix/virtual
/etc/postfix/master.cf
Данный файл определяет определяет обслуживаемые Postfix службы. Для полного отключения локальной доставки, отредактируйте данный файл и вставьте символ # в начале следующей строки:
#local unix - n n - - local
/etc/postfix/virtual
В случае типичной настройки Postfix файл /etc/aliases используется для пересылки почты на другие аккаунты или внешние адреса. Однако, так как локальная доставка отключена, модификация файла etc/aliases не принесет результатат. Поэтому нам нужно использовать файл /etc/postfix/virtual.
postmaster postmaster@example.com abuse abuse@example.com root guru@example.com
Вы также можете использовать данный файл более широко. Вы можете перенаправлять почту на другие адреса, создавать простые списки рассылки или копировать почту другому пользователю и прочее..
virtualuser@example.com actualuser@example1.com distribution@example.com user1@example.com,user2@example.com,user3@example.com ex_user@example2.com forwarding_address@dom.ain user@example.com user@example.com,spy@example.com
/etc/postfix/transport
Данный файл определяет отношения между доменами и серверами, куда должна пересылаться почта для данных доменов.
example1.com smtp:insidesmtp.example.com example2.com smtp:insidesmtp.example.com subdomain.example.com smtp:insidesmtp.example.com
/etc/postfix/relay_recipients
Данный файл содержит полный списко адресов электронно почты, для которых шлюз будет принимать сообщения.
user1@example1.com OK user2@example1.com OK user1@example2.com OK user2@example2.com OK user1@subdomain.example.com OK user2@subdomain.example.com OK
ClamAV
Для работы через ClamSMTPdmain.cf
content_filter = scan:127.0.0.1:10025
receive_override_options = no_address_mappings
|
1 |
content_filter=scan127.0.0.110025 receive_override_options=no_address_mappings |
master.cf
# AV scan filter (used by content_filter)
scan unix — — n — 16 smtp
-o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10026 inet n — n — 16 smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
|
1 |
# AV scan filter (used by content_filter) scan unix—n-16smtp -osmtp_send_xforward_command=yes # For injecting mail back into postfix from the filter 127.0.0.110026inetn-n-16smtpd -ocontent_filter= -oreceive_override_options=no_unknown_recipient_checks,no_header_body_checks -osmtpd_helo_restrictions= -osmtpd_client_restrictions= -osmtpd_sender_restrictions= -osmtpd_recipient_restrictions=permit_mynetworks,reject -omynetworks_style=host -osmtpd_authorized_xforward_hosts=127.0.0.08 |
etcclamsmtpd.conf
OutAddress: 127.0.0.1:10026
| 1 | OutAddress127.0.0.110026 |
Настройка DNS
Смотрим содержимое файла txt, который был сформирован при генерировании сертификата для домена:
cat /etc/opendkim/dmosk.ru/relay.txt
* где dmosk.ru — домен, для которого производилась настройка.
И используя данное содержимое, в панели управления нашим DNS создаем TXT-запись следующего формата:
relay._domainkey IN TXT «v=DKIM1; k=rsa; p=MIGfMA0GCSqG…rhyaj8OcbwIDAQAB»
* где relay — название нашего селектора MIGfMA0GCSqG…rhyaj8OcbwIDAQAB — сокращенная запись открытого ключа (она длиннее).
Дополнительные необязательные записи
_domainkey IN TXT «o=~; r=postmaster@dmosk.ru»
* где o=~ означает, что не все сообщения подписываются для домена (o=- — говорит, что все письма используют DKIM).
_adsp._domainkey IN TXT «dkim=all»
* all запрещает принимать письма от домена без цифровой подписи. Другие варианты: discardable — блокировать сообщения на стороне получателя, unknown — по умолчанию (такую запись создавать не обязательно).
Пример
Пример для вставки в файл
main.cf
disable_vrfy_command = yes
show_user_unknown_table_name = no
smtpd_helo_required = yes
smtpd_helo_restrictions=
check_helo_access hash:/etc/postfix/helo_restrictions
permit_mynetworks,
permit_sasl_authenticated,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname
smtpd_sender_restrictions=
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_unlisted_sender,
permit_mynetworks,
permit_sasl_authenticated
smtpd_recipient_restrictions=
check_sender_access hash:/etc/postfix/sender_access
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unlisted_recipient,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
reject_invalid_hostname
smtpd_data_restrictions=
reject_unauth_pipelining,
reject_multi_recipient_bounce
smtpd_etrn_restrictions=
permit_mynetworks,
permit_sasl_authenticated,
reject
message_size_limit = 51200000
|
1 |
disable_vrfy_command=yes show_user_unknown_table_name=no smtpd_helo_required=yes smtpd_helo_restrictions= check_helo_access hashetcpostfixhelo_restrictions permit_mynetworks, permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_hostname, reject_invalid_helo_hostname,
reject_unknown_helo_hostname smtpd_sender_restrictions= reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unlisted_sender, permit_mynetworks,
permit_sasl_authenticated smtpd_recipient_restrictions= check_sender_access hashetcpostfixsender_access reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
reject_invalid_hostname smtpd_data_restrictions= reject_unauth_pipelining,
reject_multi_recipient_bounce smtpd_etrn_restrictions= permit_mynetworks, permit_sasl_authenticated, reject message_size_limit=51200000 |
Таблицы:/etc/postfix/helo_restrictions
80.84.114.82 OK
mail.aqmh.ru OK
aqmh.ru OK
aqmhdc.aqmh.com OK
mailpn.ru REJECT
stmails.ru REJECT
5.63.152.144 REJECT
|
1 |
80.84.114.82OK mail.aqmh.ru OK aqmh.ru OK aqmhdc.aqmh.com OK mailpn.ru REJECT stmails.ru REJECT 5.63.152.144REJECT |
/etc/postfix/sender_access
80.84.114.82 OK
mail.aqmh.ru OK
aqmh.ru OK
aqmhdc.aqmh.com OK
mailpn.ru REJECT
stmails.ru REJECT
5.63.152.144 REJECT
@mailpn.ru REJECT
|
1 |
80.84.114.82OK mail.aqmh.ru OK aqmh.ru OK aqmhdc.aqmh.com OK mailpn.ru REJECT stmails.ru REJECT 5.63.152.144REJECT @mailpn.ru REJECT |
Скрипт для компиляции таблиц:/etc/postfix/!update_db.sh
<em>#!/bin/bash</em>
postmap helo_restrictions sender_access transport
|
1 |
<em>#!/bin/bash</em> postmap helo_restrictions sender_access transport |
Зачем нужен postfix на web сервере
Расскажу для начала, зачем вообще в данном случае нужен postfix. Почему не отправлять почту напрямую с сайта через smtp с авторизаций на удаленном сервере. Сейчас все современные движки это поддерживают. Причин тут может быть много. Вот основные из них:
- У postfix хорошее логирование. Если вы отправляете через него, у вас будет вся аналитика по отправке. Вы можете проверить статус доставки каждого письма. Если вам нужны логи, то их ведение нужно будет реализовывать либо в самом движке сайта, либо их должен поддерживать удаленный smtp сервер. Но, к примеру, если с сайта письмо ушло, а на удаленный smtp не попало по какой-то причине, у вас не останется информации об этом событии, если сам сайт не ведет логов.
- Postfix может быть гибко настроен на отправку почты. Можно выбирать, как будет отправляться почта для каждого исходящего домена, для разного домена или даже адреса получателя. Можно на ходу подменять адрес отправителя или изменять тему письма. И все это делается достаточно просто. Реализовывать тот же функционал через движок сайта значительно труднее.
- Вы можете всю отправленную почту пересылать куда-то на отдельный ящик для различных нужд — аналитика, контроль и т.д. Это тоже гибко настраивается. Для каждого сайта может быть свой почтовый ящик для сбора. Их может быть несколько, для каждого адреса отправителя свой дублирующий ящик и т.д. В общем, это все тоже очень гибко настраивается.
- Так как есть подробное логирование отправки, легко настроить мониторинг postfix и получить аналитику и контроль отправленных сообщений. Если кто-то сломает ваш сайт и начнет рассылать через него спам, вы это сразу заметите. К примеру, я настраивал почтовый сервер для одной нишевой соц. сети. Когда кто-то начал массово спамить через личные сообщения, это сразу стало видно на мониторинге почты, так как количество отправленных сообщений через почтовый сервер резко возросло. На каждое личное сообщение отправлялось уведомление по почте.
Это несколько примеров, которые сходу пришли в голову. В целом, никакого уникального функционала postfix не представляет, но все описанное выше очень легко и быстро реализовывается штатными средствами почтового сервера. Просто бери и настраивай, как тебе надо. Нет нужды это реализовывать самому в самом движке. Накодить весь этот функционал трудозатратно.
Настройка OpenDKIM и Postfix
OpenDKIM
Переносим старый конфигурационный файл opendkim и создаем новый.
FreeBSD:
mv /usr/local/etc/mail/opendkim.conf /usr/local/etc/mail/backup.opendkim.conf
ee /usr/local/etc/mail/opendkim.conf
Linux:
mv /etc/opendkim.conf /etc/backup.opendkim.conf
vi /etc/opendkim.conf
И приводим его к следующему виду:
AutoRestart Yes
AutoRestartRate 10/1h
Umask 002
Syslog yes
SyslogSuccess Yes
LogWhy Yes
Canonicalization relaxed/simple
ExternalIgnoreList refile:/etc/opendkim/TrustedHosts
InternalHosts refile:/etc/opendkim/TrustedHosts
KeyTable refile:/etc/opendkim/KeyTable
SigningTable refile:/etc/opendkim/SigningTable
Mode sv
PidFile /var/run/opendkim/opendkim.pid
SignatureAlgorithm rsa-sha256
UserID opendkim:opendkim
Socket inet:12301@localhost
* все параметры можно оставить, как в данном примере, за исключением Socket — можно указать любой другой порт, вместо 12301.
Создаем каталог /etc/opendkim (например, в Debian он не создается автоматически):
mkdir /etc/opendkim
Создаем файл доверенных узлов. В него пока войдут имя локального хоста (localhost) и его IP-адрес, которые будут приняты, как доверенные и подписаны:
vi /etc/opendkim/TrustedHosts
И вносим следующее:
127.0.0.1
localhost
* в данный файл мы заносим все IP-адреса и сети почтовых серверов, которые могут использовать наш сервер как почтовый релей. Таким образом, если в вашей системе используется подобная конфигурация, в файл TrustedHosts мы должны добавить адреса данных почтовых серверов.
Создаем остальные конфигурационные файлы (если их нет):
touch /etc/opendkim/{KeyTable,SigningTable}
Открываем файл /etc/default/opendkim:
vi /etc/default/opendkim
… его либо не должно быть, либо он должен быть пустой, либо проверяем строку с настройкой SOCKET и приводим ее к виду:
SOCKET=inet:12301@localhost
Запускаем службу opendkim.
На FreeBSD:
Сначала добавляем демона в rc.conf:
echo ‘milteropendkim_enable=»YES»‘ >> /etc/rc.conf
echo ‘milteropendkim_uid=»opendkim»‘ >> /etc/rc.conf
* первая команда разрешает запуск демона, вторая — принудительно заставляет его запускаться от пользователя opendkim.
И запускаем его:
service milter-opendkim start
На Linux:
а) CentOS:
systemctl enable opendkim —now
* для старый систем это будут команды chkconfig opendkim on и service opendkim start.
б) Ubuntu / Debian:
systemctl enable opendkim
systemctl restart opendkim
Postfix
Открываем конфигурационный файл.
FreeBSD:
ee /usr/local/etc/postfix/main.cf
Linux:
vi /etc/postfix/main.cf
Добавляем или редактируем:
milter_protocol = 2
milter_default_action = accept
smtpd_milters = inet:localhost:12301
non_smtpd_milters = inet:localhost:12301
* если smtpd_milters и non_smtpd_milters присутствуют в конфигурационном файле, то приведенные в данном примере значения нужно дописать к имеющимся.
** 12301 — порт работы opendkim, который был задан в opendkim.conf.
![Настройка почтового сервера postfix [айти бубен]](https://tehnikaarenda.ru/wp-content/uploads/6/b/c/6bcc36449d4f701ee882460e0af38572.jpeg)
Перезапускаем Postfix:
systemctl restart postfix
или:
service postfix restart
Отложенная обработка списков управления доступом к SMTP
Ранние версии Postfix выполняли действия, предусмотренные списками ограничений доступа к SMTP, настолько рано, насколько это возможно. Список ограничения клиентов (client restriction list) проверялся перед тем, как Postfix отсылал приветствие «220 $…» SMTP клиенту. Список обрабатывался перед тем, как Postfix отвечал на команду HELO (EHLO). Список обрабатывался перед ответом на команду MAIL FROM. И так далее. Эта практика оказалась весьма сложной в применении.
Текущие версии Postfix откладывают обработку списков ограничения для клиентов, отправителей и HELO до получения команды RCPT TO или ETRN. Это поведение контролируется параметром . Списки ограничений обрабатываются в правильном порядке (client, helo, etrn) или (client, helo, sender, recipient, data, end-of-data). Когда список ограничений (например, client) выдает результат REJECT или DEFER, обработка последующих списков (пример: helo, sender, и т.д.) не выполняется.
В то время как был добавлен параметр , в Postfix также была введена поддержка смешанных списков ограничений, которые комбинируют информацию о клиенте, отправителе, получателе и информацию команд helo, etrn.
Преимущества отложенной обработки списков ограничений и смешанных списков:
-
Некоторые SMTP клиенты не ожидают негативных ответов на ранних этапах SMTP сессии. Когда плохие новости откладываются до ответа на RCPT TO, клиент уходит, что и требуется, а не висит до разрыва соединения по таймауту, или, хуже того, входит в бесконечный цикл соединение-отказ-соединение.
-
Postfix может регистрировать больше полезной информации. Например, когда Postfix отклоняет имя или адрес клиента и ждет команды RCPT TO, он получает информацию о адресе отправителя и получателя. Это полезнее, чем регистрация имени хоста и IP адреса клиента вкупе с полным незнанием того, чья почта была заблокирована.
-
Смешивание необходимо для реализации комплексных политик «белых списков». Например, чтобы отклонить локальные адреса отправителей в сообщениях от нелокальных клиентов, вам необходимо воспользоваться информацией о клиенте и адресе отправителя в одном и том же списке управления доступом. Без данной возможности многие подобные ограничения для отдельных пользователей невозможно описать.
Ограничения, которые воздействуют на всю SMTP почту
Помимо ограничений, которые могут быть настроены для отдельных клиентов или пользователей, в Postfix реализованы несколько ограничений, которые воздействуют на всю SMTP почту.
-
Встроенные ограничения по содержимому (проверки заголовка) и (проверки содержимого письма), которые описаны в документе BUILTIN_FILTER_README. Эти проверки производятся во время приема почты, до помещения письма в очередь входящих сообщений ().
-
Внешняя (посредством сторонних программ) проверка содержимого до помещения в очередь, которая описана в документе SMTPD_PROXY_README . Эта проверка выполняется во время приема почты, до помещения письма в очередь входящих сообщений ().
-
Требование к клиентам отсылать команду HELO или EHLO перед использованием команды MAIL FROM или ETRN. Это может вызвать проблемы при работе с «доморощенными» почтовыми клиентами. По этой причине ограничение отключено по умолчанию (» = no»).
-
Запрет некорректного синтаксиса в командах MAIL FROM или RCPT TO. Это может вызвать проблемы при работе с «доморощенными» или древними почтовыми клиентами. По этой причине требование отключено по умолчанию (» = no»).
-
Запрет использования синтаксиса адресов RFC 822 (пример: «MAIL FROM: the dude <dude@example.com>»).
-
Запрет использования адресов, которые не заключены в угловые скобки <> (пример: «MAIL FROM: dude@example.com»).
-
Отклонение писем с несуществующим адресом отправителя. Эта форма фильтрации «на входе» может помочь в борьбе с «червями» и спамерами, но может вызвать проблемы при работе с «доморощенными» почтовыми клиентами, которые отсылают письма с несуществующим адресом отправителя. По этой причине данной ограничение отключено по умолчанию (» = no»).
-
Отклонение писем с несуществующим адресом получателя. Эта форма фильтрации «на входе» помогает содержать почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены. Это ограничение включено по умолчанию (» = yes»).
Решение проблем
Большинство трудностей решается чтением логов. Для opendkim они будут попадать в общий log-файл почты. Включить его непрерывный просмотр можно следующей командой.
а) для Red Hat / CentOS / FreeBSD:
tail -f /var/log/maillog
б) для Debian / Ubuntu:
tail -f /var/log/mail.log
Также, очень часто, проблемы возникают из-за неправильной настройки прав на ключи. Нужно иметь ввиду, что некоторые системы, из соображений безопасности, выдают ошибку, если на файлы выданы слишком широкие права на чтение. То есть, если разрешить читать файлы всем (chmod 644), система будет возвращать ошибку. Если в логах видим «error loading key», скорее всего, проблема с правами. Внимательно выполните повторно рекомендации 2-о пункта данной инструкции.
Еще одно часто появляющееся сообщение — «opendkim no signing table match for». Оно говорит, что для домена, от которого отправляется почта, нет соответствий в файле SigningTable. Либо была допущена опечатка, либо, на самом деле, для домена отправки не нужно использовать DKIM.
Заключение
Для того, чтобы любые работы на prod сервере прошли успешно, я всегда соблюдаю несколько правил:
- Никогда не тороплюсь. Если реально нет необходимости спешить, я всегда довожу до руководства, что спешка не нужна. Она вредит и мешает все сделать хорошо. Пусть лучше я спокойно неделю или две подготовлюсь, все обдумаю, проверю и перенесу без проблем, нежели я буду спешить для соблюдения бессмысленных сроков.
- Тщательно все проверяю и перепроверяю. Делаю все максимально незаметно. Если простой ожидается маленький, не шлю никому никаких уведомлений. Если вы предупредите, что будут работы с почтовым сервером, на следующие дни обязательно кто-то нажалуется, что после переноса все сломалось. Это мешает снимать реальные обратные связи. Когда никто не знает о переносе, отзывы будут только на реальные проблемы, а не надуманные.
- У меня всегда есть запасной план на случай, если что-то пойдет не так. Всегда под рукой актуальные бэкапы и подменные системы. Я точно знаю, что буду делать, если новый сервер не будет введен в эксплуатацию.
Этого достаточно, чтобы успешно проводить любые работы на серверах. Главное, все запланировать заранее, чтобы не было спешки. А как вы планируете масштабные обновления или переносы prod серверов?
Онлайн курс Infrastructure as a code
Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.
Что даст вам этот курс:
- Познакомитесь с Terraform.
- Изучите систему управления конфигурацией Ansible.
- Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
- Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
- В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins
Смотрите подробнее программу по .
