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

Краткий ответ

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

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

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

Обзор элементов для современных небольших поставщиков услуг электронной почты

Графическое представление заголовков электронной почты, связанных с безопасностью и репутацией

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

Защита домена от попыток спуфинга и проблем с репутацией

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

Это:

1. Структура политики отправителя(SPF)
2. Ключи домена Идентифицированная почта(DKIM)
3. Отчетность и соответствие аутентификации сообщений на основе домена -(DMARC)

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

• Простое объяснение SPF:

Postfix пропускает исходящую почту через демон SPF, который оценивает, соответствует ли отправитель политике исходящей почты. Принимающий почтовый сервер извлекает запись SPF домена из DNS и сверяет запись с заголовком SPF, который сервер-отправитель помещает в электронное письмо.

Реализация SPF, совместимая с постфиксом

• Простое объяснение DKIM:

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

Реализация DKIM, совместимая с постфиксом

• Простое объяснение DMARC:

Принимающий почтовый сервер извлекает запись политики DMARC из DNS и принимает или отклоняет сообщение или выполняет мягкий отказ сообщения.

Реализация DMARC, совместимая с постфиксом

Считается Передовой практикой безопасности вводить запись политики DMARC «отклонить», даже если ваш домен не отправляет электронные письма.

Пример записей DNS для SPF, DKIM и DMARC

MX  10  mail.domain.tld.

TXT "v=spf1 a:mail.domain.tld -all"

mail._domainkey IN  TXT ( "v=DKIM1; h=sha256; k=rsa; "
  "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0w7N0fWtTndtlR+zOTbHyZOlvFiM73gyjjbHDN1OhhcPCbhRUqTsA7A8uXHGHao6nZ5qejlVtn6NfZwbn7rdhJ0MTjlgTnTsVa8E9rgS6dFo0bEIzeFecDr/4XOF9wpNjhHlnHm4wllkPheFnAWpZQiElZeYDN5Md47W1onwZ3DwcYJNX/3/GtfVZ0PrjisC4P0qeu+Z8jIgZc"
  "MLvBm8gj2pX3V6ntJY9QY09fWSVskvC6BQhi6ESOrqbM63f8ZJ4N/9ixPAMiD6k/lyGCokqc6sMuP6EC7z5McEOBbAVEuNy3idKi1sjwQH8WZHrvlSBlzx1wwmpFC1gqWcdTiEGwIDAQAB" )  ; ----- DKIM key mail for domain

_dmarc  IN TXT v=DMARC1;p=reject;sp=reject;fo=0:d;adkim=s;aspf=s;rua=mailto:webmaster@domain.tld;ruf=mailto:webmaster@domain.tld;

_domainkey IN TXT o=-;

Вы можете заметить, что DNS-запись с именем mail._domainkeyсодержит криптографический открытый ключ.Этот ключ и связанная с ним запись могут быть сгенерированы с помощью программы opendkim-genkey, установленной вместе с пакетом opendkim, установленным на вашем сервере.

Генерация ключей довольно проста:

opendkim-genkey -b 2048 -d yourdomain -h sha256 -s mail

Эта команда создаст закрытый ключ, открытый ключ и правильно отформатированную запись DNS. Закрытый ключ необходимо поместить в каталог, указанный в вашей конфигурации opendkim. В то время как открытый ключ и связанная с ним запись DNS помещаются в файл зоны DNS вашего домена. К сожалению, у некоторых провайдеров DNS есть ограничения на длину записей. Итак, убедитесь, что ваш провайдер DNS может обеспечить длину открытого ключа.

Добавление милтеров SPF и DKIM

СПФ

Выдержка из справочной страницы policyd-spf:

ИНТЕГРАЦИЯ POSTFIX

1. Add the following to /etc/postfix/master.cf:

           policyd-spf  unix  -       n       n       -       0       spawn
               user=policyd-spf argv=/usr/bin/policyd-spf

2. Configure the Postfix policy service in /etc/postfix/main.cf:

           smtpd_recipient_restrictions =
              ...
               reject_unauth_destination
               check_policy_service unix:private/policyd-spf
              ...
           policyd-spf_time_limit = 3600

ДКИМ

Демон opendkimработает на сокете UNIX, который можно настроить либо как стандартный сокет UNIX, либо на служебном порту inetd. В моих установках Debian эта конфигурация находится по адресу /etc/default/opendkim. После запуска opendkimmilter необходимо добавить в конфигурацию postfixв /etc/postfix/main.cf.

Вот пример с рабочего сервера:

# DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891

ДМАРК

Для небольших или личных почтовых серверов DMARC можно просто ограничить записью DNS. Демон проверки DMARC позволяет отклонять входящую почту в соответствии с политикой домена-отправителя, а также отправлять любые запрошенные отчеты обратно в домен-отправитель. Сообщения считаются «хорошо -воспитанными соседями». Однако я обычно не включаю его для небольших или персональных систем, поскольку накладные расходы на настройку довольно высоки.

Однако DNS-запись DMARC очень важна для поддержания репутации домена. Запись используется всеми современными крупными почтовыми провайдерами для приема или отклонения писем, которые кажутся исходящими из вашего домена. Итак, без записи DMARC,вся входящая почта, которая выглядит так, как будто она была отправлена ​​вашим доменом, засчитывается в счет репутации вашего домена. Таким образом, домен, который вообще не ожидает отправки почты, должен опубликовать запись DMARC «отклонение», чтобы избежать проблем с репутацией из-за поддельных сообщений, рассылаемых спамерами.

Подключения TLS для почтовых серверов и клиентов

В вашей информации о конфигурации указано, что вы используете Dovecot и Postfix.

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

Таким образом, подключение Mail User Agent (MUA )обрабатывается промежуточным программным обеспечением, а не фактическим почтовым сервером. В вашем случае это будет Dovecot.

TLS должен быть включен и правильно настроен в Dovecot, чтобы безопасно передавать ваше имя пользователя и пароль от вашего MUA (ex :Evolution, Sylpheed, Mutt и т. д. ).

Для справки см. документацию Dovecot по настройке TLS .

Возможно, но не обязательно, чтобы «сервер -— -сервер» или «промежуточное ПО» для постфиксного соединения были зашифрованы одним и тем же сертификатом TLS. Однако в случае небольшого почтового сервера соединение «промежуточного программного обеспечения» с postfix не обязательно должно быть зашифровано, поскольку оно находится на том же оборудовании.

Получение сертификата LetsEncrypt TLS для вашего почтового сервера и интерфейса MUA (POP3, IMAP и т. д.)

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

1. Остановить службы postfix и dovecot.
2. Остановите веб-сервер, если он запущен.
3. Остановите все работающие службы, которые в настоящее время включены в сертификат.
4. Развернуть сертификат

certbot certonly --expand -d domain.tld,www.domain.tld,mail.domain.tld

Затем добавьте путь к сертификату в конфигурацию main.cf.

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

А также добавьте путь к сертификату в конфигурацию Dovecot в соответствии с документацией Dovecot, указанной выше.

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

Следует отметить, что SMTP-соединение TLS — это соединение, которое ваш сервер устанавливает с другими серверами. В то время как соединение Dovecot TLS, как правило, является тем, к чему кто-то подключается для отправки электронной почты с клиента веб-почты, отличного от -.

Настройка совместимости SMTP-сервера с сервером TLS

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

smtpd_tls_security_level = may

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

Однако сертификат TLS, включенный в Dovecot, должен быть утвержден CA. Самоподписанный сертификат -в Dovecot приведет к предупреждению при использовании большинства MUA, таких как sylpheed, evolutionили thunderbird.

Разумные ограничения SMTP-клиента

По моему опыту, 99% спама можно отклонить с помощью SPF, проверки DKIM и проверки RBL.

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

smtpd_client_restrictions = permit_mynetworks 
                permit_sasl_authenticated
                            check_helo_access hash:/etc/postfix/helo_access
                            check_client_access hash:/etc/postfix/client_checks 
                            reject_unauth_destination
                            check_policy_service unix:private/policy-spf
                            reject_rbl_client cbl.abuseat.org
                            reject_rbl_client pbl.spamhaus.org
                            reject_rbl_client sbl.spamhaus.org
                            reject_rbl_client bl.blocklist.de
                            reject_unknown_client 

Настройка совместимости ограничений клиента SMTPD

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

Однако почти 100 % спама отправляется с почтовых серверов без надлежащих записей обратного домена.

Проверки HELO

Спаммеры часто пытаются подделать HELO, отправив имя вашего домена, IP-адрес или локальный хост. Эти попытки подделки могут быть немедленно отклонены с помощью опции check_helo_access, как показано выше. Текстовая база данных HELO состоит из доменного имени, IP-адреса или диапазона IP-адресов, за которыми следует действие и сообщение для отправки.

Далее следует довольно простая проверка HELO:

# helo access
# check_helo_access hash:/etc/postfix/helo_access

localhost             REJECT Only I am me
127.0.0.1             REJECT Only I am me
example.com           REJECT Only I am me
dns.host.ip.addr      REJECT Only I am me

«example.com» — это ваш домен, а «dns.host.ip.addr» — это IP-адрес вашего сервера, указанный в DNS.

Этот пример базы данных приводит к чему-то подобному из одного моего фактического журнала сервера:

Oct 30 06:32:49 <domain> postfix/smtpd[22915]: NOQUEUE: reject: RCPT from xxx-161-xxx-132.dynamic-ip.xxxx.net[xxx.161.xxx.132]: 554 5.7.1 <xxx.xxx.xxx.xxx>: Helo command rejected: Only I am me; from=<dlh@xxx.xxx.cq.cnt> to=<gogo@xxxx.com.tw> proto=SMTP helo=<xxx.xxx.xxx.xxx>

Потенциальный спамер/спуфер получает сообщение «Только я — это я». Неважно, что это за сообщение, но, по крайней мере, спамер/спуфер знает, что вы знаете.

Обязательно сгенерируйте базу данных postfixс помощью:

postmap helo_access

Добавление исключений к ограничениям через клиент _проверка белого списка

Проверка отдельных клиентов происходит примерно так:

ip.addr.hack.attmpt  REJECT
misconfig.server.but.good  OK

Обязательно сгенерируйте базу данных postfixс помощью:

postmap client_checks

И на этом все. Я получаю около 3 писем со спамом в месяц, сотни спамов отклонены.

Ресурсы

1. Оценщик политик DMARC/SPF
2. Оценщик открытого ключа DKIM
3. Веб-сайт MxToolbox
4. Оценщик безопасности электронной почты