Настройка почтового сервера postfix [айти бубен]

Автоматическая замена темы писем в postfix

Переходим к замене темы письма. Для этого добавляем в конфиг postfix /etc/postfix/main.cf следующий параметр.

Создаем файл rewrite_subject следующего содержания:

Это регулярное выражение, которое меняет заголовок письма, начинающийся с Subject. Оно добавляет в начало темы имя сервера в скобках — (prox-centos7). Вы можете добавлять что-то свое. Для тех, кто вообще не разбирается в регулярках, поясню, что в данном случае $1 это исходное содержание темы.

Перезапускаем postfix и проверяем, отправив через консоль письмо.

Проверяем ящик и видим там письмо.

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

Включение Plaintext аутентификации в Dovecot

По причинам безопасности, сервер Dovecot IMAP/POP, по умолчанию, не позволяет аутентификацию простым текстом — plaintext (например, использовать незашифрованные пароли). И это правильно и очень хорошо! Но по некоторым причинам, иногда необходимо задействовать аутентификацию plaintext в Dovecot, для этого используется следующая настройка.

# vim /etc/dovecot/conf.d/10-auth.conf

disable_plaintext_auth = no

# service dovecot restart

Это только некоторые вещи, которые делают администраторы почтовых серверов. Возможно ещё более глубокая настройка Postfix и Dovecot чтобы соответствовать нуждам всех заинтересованных сторон.

Используем Relayhost

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

Файл изменяется так, чтобы он указывал relayhost:

# vim /etc/postfix/main.cf 
relayhost = mail.providermx.com

## in case of IP address ##
##  disables DNS lookups ##
relayhost = 
# service postfix restart

Выбор сервера отправки в зависимости от адреса получателя

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

[email protected] user1
[email protected] user2

Если у вас использует разные ящики для отправки, то можете настроить правило для всего домена сразу:

*@site1.ru user1
*@site2.ru user2

Дальше вам нужно выяснить, как выглядит полностью адрес домена для локальной доставки почты. Это имя задается в параметре mydomain в конфиге postfix main.cf. Допустим, там указано имя сервера — websrv.site.ru. Это не принципиально, в нашем случае там можно написать все, что угодно, но лучше использовать полное доменное имя (fqdn) самого веб сервера, которое указано в DNS записи типа А.

Теперь создаем файл transport_map, в котором пишем следующее:

websrv.site.ru local

Мы явно указываем, что всю почту для домена websrv.site.ru отправлять локально. Не забываем построить индексированный файл:

# postmap /etc/postfix/transport_map

Отправляемся в конфиг main.cf и добавляем туда параметр:

transport_maps = hash:/etc/postfix/transport_map

Перезапускаем postfix и проверяем работу. При отправке почтового сообщения от имени пользователя [email protected] там должно быть примерно следующее:

websrv postfix/smtpd: CC8F0602E205: client=localhost
websrv postfix/cleanup: CC8F0602E205: message-id=<[email protected]>
websrv postfix/qmgr: CC8F0602E205: from=<[email protected]>, size=874, nrcpt=2 (queue active)
websrv postfix/smtpd: disconnect from localhost ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
websrv postfix/local: CC8F0602E205: to=<[email protected]>, relay=local, delay=0.07, delays=0.06/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
websrv postfix/smtp: CC8F0602E205: to=<[email protected]>, relay=smtp.yandex.ru:465, delay=0.93, delays=0.06/0.01/0.23/0.63, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on myt6-9bdf92ffd111.qloud-c.yandex.net as 1608951012-xOUj8gBhbE-oCJSqvIX)
websrv postfix/qmgr: CC8F0602E205: removed

[email protected]	адрес, с которого сайт ведет отправку почты
[email protected]	итоговый локальный адрес, куда идет пересылка почты
[email protected]	внешний почтовый адрес, куда идет отправление через внешний smtp
smtp.yandex.ru	адрес внешнего smtp сервера

Получили в итоге то, что хотели. Внешняя почта отправляется через внешний smtp адрес, указанный в relayhost, а копии сообщений падают в локальный ящик, который находится в файле /var/mail/user1. Конкретно мне это нужно было для отладки, чтобы понять, что именно отправляет сайт.

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

sender_bcc_maps:

*@site1.ru [email protected] 
*@site2.ru [email protected]

transport_map:

backupmail.ru relay::25

В данном случае backupmail.ru это отдельный почтовый домен и почтовый сервер для него для сбора всей вашей почты. Это не обязательно может быть собственноручно настроенный почтовый сервер. Можете использовать ящик в какой-то готовой службе почты. Но имейте ввиду, если это будет какой-то бесплатный сервис, то он вас быстро заблокирует, если будете слать слишком много почты на этот ящик.

ClamAV

Для работы через ClamSMTPdmain.cf

content_filter = scan:127.0.0.1:10025
receive_override_options = no_address_mappings

1 2	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
2
3
4
5
6
7
8
9
10
11
12
13

# 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

Замена адреса отправителя в postfix

Начнем с подмены отправителя, чтобы можно было сразу тестировать отправку. Для этого добавляем в конфиг postfix /etc/postfix/main.cf следующий параметр.

smtp_generic_maps = hash:/etc/postfix/generic

Там же у меня есть такие параметры:

myhostname = prox-centos7
mydomain = prox-centos7.loc
mydestination = $myhostname

Файл generic у вас уже должен быть. Если нет, то создайте его. Далее добавляем в него одну строку.

[email protected] [email protected]

[email protected]	Локальный пользователь сервера.
[email protected]	Пользователь сервера yandex. В данном случае домен serveradmin.ru привязан к почте яндекса.

Перезапускаем postfix и проверяем отправку.

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

Главный конфигурационный файл Dovecot

Основные настройки Dovecot хранит в файле конфигурации (или, реже ).

Сразу делаем копию конфигурационного файла:

cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.bak

Примечение: путь к файлу может быть /etc/dovecot.conf, проверьте сначала, где у вас в системе этот файл.

Рабочий конфигурационный файл Dovecot 2.0.9 (для 2.3.11 все подходит, может, где-то и есть мелочи, но я не заметил):

# Не использую специализированные файлы из поставки Dovecot из папки /etc/dovecot/conf.d/.
# Основная причина: сравнительно небольшой размер всего конфига (все перед глазами, нет необходимости раскидывать по отдельным файлам).
#!include conf.d/*.conf

# Нет необходимости явно указывать imaps и pop3s - Dovecot 2.* по-умолчанию их включает.
protocols = imap pop3
listen = *

# Завершать все дочерние процессы, если завершен мастер-процесс
shutdown_clients = yes

# Владелец почтовых папок (также см. конфиг Postfix):
mail_uid = vmail
mail_gid = vmail

# Только наш пользователь с uid и gid 5000 (vmail) может быть использован.
first_valid_uid = 5000
last_valid_uid = 5000

# Лог-файлы. Подробнее: http://wiki2.dovecot.org/Logging
log_path = /var/log/dovecot.log
# Отладка. Если все настроено, отключаем (no)
# http://maint.unona.ru/doc/dovecot2.shtml
mail_debug = no 
auth_verbose = no
auth_debug = no
auth_debug_passwords = no

# SSL
# http://wiki2.dovecot.org/SSL/DovecotConfiguration
ssl = required
ssl_cert = </etc/pki/dovecot/certs/server.crt
ssl_key = </etc/pki/dovecot/private/server.key

ssl_protocols = TLSv1.1 TLSv1.2 TLSv1.3 !SSLv2 !SSLv3
ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL

# Запрет аутентификации открытым текстом. yes - запретить, no - разрешить.
disable_plaintext_auth = yes

# Список разрешенных символов в имене пользователя.
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

# Расположение и формат файлов почты (%d - домен, %n - имя пользователя).
mail_location = maildir:/var/vmail/%d/%n

# Если при аутентификации не указан домен, то добавить этот (в данном примере - пустой)
auth_default_realm =

# Доступные варианты аутентификации (PLAIN, DIGEST-MD5, CRAM-MD5...).
# Для того, чтобы иметь меньше головной боли ставьте PLAIN
auth_mechanisms = PLAIN

# Приветственное сообщение
login_greeting = POP3/IMAP server ready.

# Одно из самых важных мест - предоставление сокетов для аутентификации пользователей.
# Если настроено неверно - ничего работать не будет!
service auth {
    # http://maint.unona.ru/doc/dovecot2.shtml
    # Указывает, что данный сокет будет использовать SMTP сервер для аутентификации.
    # Указывается пользователь, группа и права доступа к сокету. В данном случае это postfix
    # ("mail_owner = postfix" в файле /etc/postfix/main.cf).
    unix_listener /var/spool/postfix/private/auth {
        user = postfix
        group = postfix
        mode = 0660
    }
    unix_listener auth-master {
        user = vmail
        group = vmail
        mode = 0660
    }
    unix_listener auth-userdb {
        user = vmail
        group = vmail
        mode = 0660
    }
}

# Запрос параметров виртуальных почтовых пользователей
# (логин, пароль, домен, активный/неактивный и др.)
userdb {
    args = /etc/dovecot/dovecot-mysql.conf
    driver = sql
}
passdb {
    args = /etc/dovecot/dovecot-mysql.conf
    driver = sql
}

# Plugins

protocol imap {
    imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
    mail_plugins = autocreate
}
protocol pop3 {
    pop3_client_workarounds = outlook-no-nuls oe-ns-eoh
    pop3_uidl_format = %08Xu%08Xv
}
protocol lda {
    # Куда будут перенаправлены недоставленные письма
    postmaster_address = postmaster@localhost
    auth_socket_path = /var/run/dovecot/auth-master
}


plugin {
    auth_socket_path = /var/run/dovecot/auth-master

    # Plugin: autocreate. Создаем и подписываемся на папки IMAP.
    autocreate = INBOX
    autocreate2 = Sent
    autocreate3 = Trash
    autocreate4 = Drafts
    autocreate5 = Junk
    autosubscribe = INBOX
    autosubscribe2 = Sent
    autosubscribe3 = Trash
    autosubscribe4 = Drafts
    autosubscribe5 = Junk

    # Plugin: квоты. Пока отключим.
    # http://wiki2.dovecot.org/Quota/Configuration
    #quota = maildir:User quota
    #quota_rule = *:storage=1GB
    #quota_rule2 = Trash:storage=+10%% # 10% of 1GB = 100MB
    #quota_rule3 = Junk:storage=+10%% # 10% of 1GB = 100MB
    #quota_rule4 = Drafts:storage=+10%% # 10% of 1GB = 100MB
}

Ограничения, которые воздействуют на всю 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 <[email protected]>»).
Запрет использования адресов, которые не заключены в угловые скобки <> (пример: «MAIL FROM: [email protected]»).
Отклонение писем с несуществующим адресом отправителя. Эта форма фильтрации «на входе» может помочь в борьбе с «червями» и спамерами, но может вызвать проблемы при работе с «доморощенными» почтовыми клиентами, которые отсылают письма с несуществующим адресом отправителя. По этой причине данной ограничение отключено по умолчанию (» = no»).
Отклонение писем с несуществующим адресом получателя. Эта форма фильтрации «на входе» помогает содержать почтовую очередь свободной от сообщений MAILER-DAEMON, которые не могут быть доставлены. Это ограничение включено по умолчанию (» = yes»).

Включение возможности использовать незашифрованный пароль в Dovecot

По соображениям безопасности сервер Dovecot IMAP/POP по умолчанию не допускает аутентификацию открытым текстом (т.е. использовать незашифрованный пароль). Но если по некоторым причинам, кому-то потребуется включить аутентификацию открытым текстом в Dovecot, то нужно использовать следующие настройки.

# vim /etc/dovecot/conf.d/10-auth.conf 
disable_plaintext_auth = no
# service dovecot restart

Это некоторые из тех настроек, которыми часто пользуются администраторы почтовых серверов. В пакетах Postfix и Dovecot есть еще много других настроек, которыми можно пользоваться в случае необходимости.

Надеюсь, это руководство будет полезным.

Настраиваем Postfix

$ yum -y install postfix cyrus-sasl-plain

/etc/postfix/canonical

# Слева - регулярное выражение, применяемое к отправителю
# Справа - отправитель, которого нужно поставить
/.+/ [email protected]

/etc/postfix/generic

# Слева - локальный пользователь

# Справа - отправитель, которого нужно поставить
root@localhost [email protected]
bitrix@localhost [email protected]

/etc/postfix/mailpasswd

# :SMTP_PORT SMTP_USER:SMTP_PASSWORD
 [email protected]:SecretPassword*

* в этом примере мы создаем учетную запись для аутентификации на Яндексе. При отправке писем от [email protected] необходимо авторизоваться на сервере Яндекса от этой же учетной записи с паролем SecretPassword/etc/postfix/sender_relay

# Слева - отправитель, справа - релей
[email protected] *

*в этом примере мы все сообщения, отправляемые от домена example.com переправляем через сервер smtp.yandex.ru.

Настройка значений From и Reply-To

From: Иван Петров <[email protected]>
To: Фёдор Сидоров <[email protected]>

# Добавить в Reply-To значение, использованное в From
/^From: (.*)/ PREPEND Reply-To: $1
# Перезаписать From на значение по-умолчанию
/^From: (.*)/ REPLACE From: [email protected]
# Удалить добавление технического адреса в ответном письме
/^(Reply-To:.*)/ IGNORE

/etc/postfix/main.cf

header_checks = regexp:/etc/postfix/header_checks

/etc/postfix/main.cf

# Отключаем ipv6, потому что он толком не работает
inet_protocols = ipv4

# Указываем все письма отсылать через этот релей
relayhost = 

# Включение аутентификации на стороне клиента
$ smtp_sasl_auth_enable = yes
# Указывает на файл, в котором хранится база связок логин/пароль
$ smtp_sasl_password_maps = hash:/etc/postfix/mailpasswd

# Опции SASL. noanonymous указывает на запрет анонимной аутентификации
$ smtp_sasl_security_options = noanonymous
# Задает плагин SASL для аутентификации
$ smtp_sasl_type = cyrus
# Перечисляет механизмы проверки пользователя и пароля
$ smtp_sasl_mechanism_filter = login

# Включает зависящую от отправителя аутентификацию, отключает кэширование SMTP-соединения
$ smtp_sender_dependent_authentication = yes
# Указание на список адресов и почтовых серверов, через которые нужно отправлять письма на эти адреса
sender_dependent_relayhost_maps = hash:/etc/postfix/sender_relay
# Добавляет для домена указание через какой аккаунт отправлять почту
sender_canonical_maps = hash:/etc/postfix/canonical

# Добавляет отправку почты админу на внешний ящик
smtp_generic_maps = hash:/etc/postfix/generic
# Указывает, использовать ли TLS для SMTP
smtp_use_tls = yes

Mar  5 19:48:28 MegaRoss-207-Krasnodar postfix/smtp: connect to smtp.gmail.com:587: Network is unreachable

Mar  5 19:48:28 MegaRoss-207-Krasnodar postfix/smtp: 919BB1A3E6E: to=<[email protected]>, relay=none, delay=0.44, delays=0.02/0/0.43/0, dsn=4.4.1, status=deferred (connect to smtp.gmail.com:587: Network is unreachable)

# Удаляем работу через msmtp
; sendmail_path = msmtp -t -i
# Добавляем работу через postfix
sendmail_path = /usr/sbin/sendmail -t -i -f [email protected]

$ postmap /etc/postfix/generic
$ postmap /etc/postfix/canonical
$ postmap /etc/postfix/mailpasswd
$ postmap /etc/postfix/sender_relay

$ systemctl enable postfix
$ systemctl start postfix

Отправка тестового письма

$ echo "Test message" | mail -s "Test subject" [email protected]

“status=sent”

$ tail /var/log/maillog
Mar  6 10:33:43 MegaRoss-207-Krasnodar postfix/pickup: 24FD91A3E6F: uid=0 from=<root>
Mar  6 10:33:43 MegaRoss-207-Krasnodar postfix/cleanup: 24FD91A3E6F: message-id=<[email protected]>
Mar  6 10:33:43 MegaRoss-207-Krasnodar postfix/qmgr: 24FD91A3E6F: from=<[email protected]>, size=478, nrcpt=1 (queue active)
Mar  6 10:33:44 MegaRoss-207-Krasnodar postfix/smtp: 24FD91A3E6F: to=<[email protected]>, relay=smtp.yandex.ru:25, delay=1.3, delays=0.03/0.01/0.33/0.89, dsn=2.0.0, <strong>status=sent</strong> (250 2.0.0 Ok: queued on smtp2o.mail.yandex.net as 1551857624-LUq73TrSs8-XhiW0rUr)
Mar  6 10:33:44 MegaRoss-207-Krasnodar postfix/qmgr: 24FD91A3E6F: removed

Установка Postfix в docker-контейнере

Запустим контейнер с Postfix-ом и открытым 25 портом в который будет ходить наше приложение для отправки почты.
Предлагаю воспользоваться уже собранным образом вот из этого репозитория — https://github.com/MarvAmBass/docker-versatile-postfix

Создадим на хост машине папки для DKIM, почтовой очерди и логов. Потом эти папки подмонтируем в контейнер:

DKIM приватный ключ (публичный в TXT записи), который генерировали выше положим сюда (имя обязательно такое):

Запускаем контейнер:

По умолчанию в этом образе включен TLS, я его отключил в переменной POSTFIX_RAW_CONFIG_SMTPD_USE_TLS, потому что ходить в этот Postfix будут соседние контейнеры на этом же хосте. При необходимости можно опубликовать 25 порт контейнера на интерфейс локальной сети (но не в интернет!), чтобы приложение с соседних хостов могло посылать почту.

Теперь можно отправлять почту с хост машины, или прилинковывать к этому контейнеру соседние, чтобы они тоже получали доступ в 25 порт.

Проверить работоспособность можно маленькой утилиткой mail-checker http://github.com/fote/mail-checker. Она отправляет тестовое письмо на указанный адрес через только что поднятый MTA:

Или по старинке через nc / telnet:

Если все было настроено правильно, то письмо не должно попасть в спам, а если заглянуть в свойства, там будет примерно следующее:

Автоматическая замена темы писем в postfix

Переходим к замене темы письма. Для этого добавляем в конфиг postfix /etc/postfix/main.cf следующий параметр.

header_checks = pcre:/etc/postfix/rewrite_subject

Создаем файл rewrite_subject следующего содержания:

/^Subject: (.*)$/ REPLACE Subject: (prox-centos7) $1

Перезапускаем postfix и проверяем, отправив через консоль письмо.

# df -h | mail -s "Disk usage" [email protected]

Проверяем ящик и видим там письмо.

DKIM

Механизм подписи всех писем цифровой подписьмю и проверки валидности подписи приемником. В общем виде работает так:

Генерируем пару приватный/публичный ключ
Кладем публичный ключ в TXT запись домена
Приватный ключ отдаем почтовому серверу postfix (ниже описано как настроить), и настраиваем чтобы он подписывал все письма этим ключом
Когда почтовый сервер получает письмо, он проверяет что подписано оно ключом из TXT записи домена

Настроим.
Создаем пару ключей:

Добавляем TXT запись

Здесь:
— — версия DKIM, всегда DKIM1
— — селектор в самом домене. Может быть произвольным. Нужен чтобы на один домен можно было повесить несколько ключей. Запоминаем его — он понадобится при настройке Postfix
— — тип ключа; обычно — rsa
— — указывает на то, что письма не отправляются с субдоменов этого домена
— — публичная часть ключа, которую генерировали выше

По домену через другой SMTP

Открываем на редактирование конфигурационный файл postfix:

vi /etc/postfix/main.cf

Редактируем или дописываем:

transport_maps = hash:/etc/postfix/transport_map

Теперь нужно открыть на редактирование файл транспорта:

vi /etc/postfix/transport_map

И добавить:

dmosk.ru smtp::25
[email protected] smtp::25

* где dmosk.ru — домен, для отправки на который используется другой сервер пересылки, а 10.10.10.10 — IP-адрес другого сервера SMTP. [email protected] и mail.mailsystem.ru — конкретный адрес электронной почты и сервер для его пересылки.

После создаем карту:

postmap /etc/postfix/transport_map

И перезапускаем postfix:

systemctl restart postfix

SPF-запись

Это TXT-запись в DNS зоне домена в которой указываются адреса серверов с которых происходит отпарвка почты у данного домена. Когда почтовый сервер приемника получает письмо с адресом отправителя он идет в DNS и проверяет SPF запись у домена example.com. Пример такой записи:

В данном примере:

— версия SPF
— разрешить прием писем с адреса указанного в A записи example.com
— разрешить прием писем с адреса указанного в MX записи example.com
— разрешить прием писем из сети 1.1.1.0/24; разрешить прием писем с адреса 2.2.2.2
— то же самое что ip4, но для IPv6
— отбросить письмо, пришедшее не от указанных адресов. Можно вместо -all указать ~all, что значит — письмо не отбрасывать, но проверить остальными способами.

Все поля опциональные, не обязательно указывать все. Здесь есть более подробное описание синтаксиса SPF-записи: http://www.openspf.org/SPF_Record_Syntax

Блокирование конкретных адресов или доменов

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

# vim /etc/postfix/access 
[email protected]   550             address blocked
wxyz.com        550             domain blocked
# postmap access 
# vim /etc/postfix/main.cf 
smtpd_recipient_restrictions = hash:/etc/postfix/access, permit_mynetworks, permit_sasl_authenticated,reject_unauth_destination
# service postfix restart

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

SSL

Пример настройки работы по порту 587, с использованием сертификатов Let’s Encrypt:/etc/postfix/main.cf

smtpd_tls_cert_file=/etc/letsencrypt/live/domain.ru/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/domain.ru/privkey.pem

smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_local_domain =
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes

smtp_tls_security_level = may
smtpd_tls_security_level = may
smtp_tls_note_starttls_offer = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

smtpd_tls_cert_file=etcletsencryptlivedomain.rufullchain.pem

smtpd_tls_key_file=etcletsencryptlivedomain.ruprivkey.pem

smtpd_use_tls=yes

smtpd_tls_session_cache_database=btree${data_directory}smtpd_scache

smtp_tls_session_cache_database=btree${data_directory}smtp_scache

smtpd_sasl_type=dovecot

smtpd_sasl_path=privateauth

smtpd_sasl_local_domain=

smtpd_sasl_security_options=noanonymous

broken_sasl_auth_clients=yes

smtpd_sasl_auth_enable=yes

smtp_tls_security_level=may

smtpd_tls_security_level=may

smtp_tls_note_starttls_offer=yes

smtpd_tls_loglevel=1

smtpd_tls_received_header=yes

Замена адреса отправителя в postfix

Там же у меня есть такие параметры:

Файл generic у вас уже должен быть. Если нет, то создайте его. Далее добавляем в него одну строку.

[email protected]	Локальный пользователь сервера.
[email protected]	Пользователь сервера yandex. В данном случае домен serveradmin.ru привязан к почте яндекса.

Перезапускаем postfix и проверяем отправку.

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

DMARC

DMARC — это тоже TXT запись в которой указывается политика для принимающего сервера, что делать с письмами не прошедшими проверку SPF и DKIM. Вот пример DMARC записи:

Здесь:

— версия DMARC. Всегда DMARC1
— что делать с письмами не прошедшими проверку. Может быть none — ничего не делать, только слать отчет, quarantine — добавлять письмо в спам, reject — отклонять письмо.
— политика отправки отчетов; 0 — отправлять отчет только если письмо не прошло и DKIM и SPF; 1 — если не прошло или DKIM или SPF; s — не прошло SPF; d — не прошло DKIM
— адрес на который будут слаться отчеты от почтовых серверов в случае обнаружения, не прошедших проверку, писем

Отложенная обработка списков управления доступом к 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 адреса клиента вкупе с полным незнанием того, чья почта была заблокирована.
Смешивание необходимо для реализации комплексных политик «белых списков». Например, чтобы отклонить локальные адреса отправителей в сообщениях от нелокальных клиентов, вам необходимо воспользоваться информацией о клиенте и адресе отправителя в одном и том же списке управления доступом. Без данной возможности многие подобные ограничения для отдельных пользователей невозможно описать.

Все исходящие через другой почтовый сервер

По умолчанию, postfix пытается отправить все сообщения напрямую. В данном подразделе мы настроим сервер SMTP, через который будут отправляться все сообщения.

Открываем конфигурационный файл mail.cf:

vi /etc/postfix/main.cf

Находим и редактируем relayhost:

relayhost =

* в данном примере мы будем отправлять все сообщения через smtp.mailsystem.com, подключившись к нему по порту 25. Также можно было указать IP-адрес.

Или если хост пересылки работает по другому порту:

relayhost = :26

* в данном примере отправка идет через хост, который слушает запросы smtp на порту 26.

Перезапускаем postfix, чтобы настройки применились:

systemctl restart postfix

Заключение

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

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

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

Онлайн курс Infrastructure as a code

Если у вас есть желание научиться автоматизировать свою работу, избавить себя и команду от рутины, рекомендую пройти онлайн курс Infrastructure as a code. в OTUS. Обучение длится 4 месяца.

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .

Заключение

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

Если вас интересует настройка полноценного почтового сервера postfix, то у меня есть очень подробная статья на эту тему.

Буду рад полезным замечаниям и дополнениям. Ваши комментарии иногда делают меня умнее

Онлайн курс Infrastructure as a code

Что даст вам этот курс:

Познакомитесь с Terraform.
Изучите систему управления конфигурацией Ansible.
Познакомитесь с другими системами управления конфигурацией — Chef, Puppet, SaltStack.
Узнаете, чем отличается изменяемая инфраструктура от неизменяемой, а также научитесь выбирать и управлять ей.
В заключительном модуле изучите инструменты CI/CD: это GitLab и Jenkins

Смотрите подробнее программу по .