Ошибки smtp-сервера и способы их решения

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

Настройка Hostname сервера

Посмотреть, как называется сервер можно такой командой:

# hostname

Если название отличается от необходимого или не установлено, тогда записать hostname для сервера:

# echo «server» > /etc/hostname
# hostname -F /etc/hostname

Обратите внимание, что hostname сервера не равно домену сервера! Если полный домен сервера: «server.example.com», то hostname сервера — это «server»

Настройка PTR (Reverse DNS)

В настройках домена прописываются A-записи, которые связывают домен с IP-адресом(ами) сервера. Reverse DNS — это обратное действие, которое связывает IP-адрес с доменом.

Сервер-отправитель письма указывает в параметре HELO (EHLO) свой домен, например server.example.com, а сервер получателя делает специальный whois-запрос, чтобы проверить, какой домен записан для IP сервера отправителя. Если домен, указанный для IP и в заголовке HELO (EHLO) не совпадают, то с большой долей вероятности письмо будет или отклонено, или перемещено в папку Спам.

Прописать Reverse DNS может только владелец IP-адреса, который назначен серверу — это скорее всего хостинг, где размещен сервер или VPS. Если сервис расположен в квартире/офисе, то по вопросу указания PTR стоит обратиться к интернет-провайдеру.

Не нужно путать владельца IP-адреса и регистратора для доменов — это, обычно, разные компании. Но если вы разместили свой сервер и зарегистрировали домен у одного и того же провайдера, то тогда по вопросу изменения Reverse DNS следует обращаться к одной и той же компании.

Проверить домен, присвоенный PTR, можно утилитой командной строки dig: $ dig -x 5.6.7.8 или используя различные онлайн-сервисы.

Настройка DNS доменного имени почтового сервера

В панели управления регистратора домена example.com поддомен для сервера (server) конфигирируется, обычно, в разделе «Настройка DNS»:

server.example.com A 5.6.7.8
server.example.com MX 10 server.example.com
server.example.com TXT v=spf1 +a +mx -all

В третьей строке указывается SPF-запись для поддомена. SPF используется почтовым сервером-получателем для проверки: разрешено ли владельцем домена отправка писем с IP, с которого пришло в действительности письмо? Параметры SPF «+a +mx -all» указывают, что письма могут отправлять только те IP, которые прописаны в A и MX записях домена, а со всех остальных IP принимать почту запрещено.

Проверка влияния настроек PTR и DNS на отправляемые e-mail

После изменения настроек DNS необходимо подождать какое-то время, для того, чтобы они обновились на всех DNS серверах. Иногда это может затянуться до одних суток.

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

Добавить шифрование в Postfix для отправляемых писем — весьма просто, инструкция расположена ниже.

Пользователи не получают почту

Первым делом смотрим, что написано в журнале /var/log/maillog о приёме и обработке письма (ориентируемся на адреса отправителя и получателя).

Если отправитель точно не спамер то, возможно, неправильно настроена обратная зона на его почтовом сервере. Проверить можно так:

# host alpicom.ch
alpicom.ch has address 194.38.160.10
# host 194.38.160.10
10.160.38.194.in-addr.arpa domain name pointer neobolian.deckpoint.ch.

Это пример неправильной настройки, а вот как должно быть:

# host mail.ru
mail.ru has address 94.100.191.246
mail.ru has address 94.100.191.247
mail.ru has address 94.100.191.248
mail.ru has address 94.100.191.249
mail.ru has address 94.100.191.250
mail.ru has address 94.100.191.201
mail.ru has address 94.100.191.202
mail.ru has address 94.100.191.203
mail.ru has address 94.100.191.204
mail.ru has address 94.100.191.205
mail.ru has address 94.100.191.206
mail.ru has address 94.100.191.207
mail.ru has address 94.100.191.208
mail.ru has address 94.100.191.209
mail.ru has address 94.100.191.210
mail.ru has address 94.100.191.241
mail.ru has address 94.100.191.242
mail.ru has address 94.100.191.243
mail.ru has address 94.100.191.244
mail.ru has address 94.100.191.245
mail.ru mail is handled by 10 mxs.mail.ru.

# host 94.100.191.242
242.191.100.94.in-addr.arpa domain name pointer mail.ru.

Если для фильтрации спама стоит spamassassin, то адреса и домены можно включить в белый список в файле /etc/mail/spamassassin/local.cf:

whitelist_from postmaster@domain1.ru
whitelist_from *@domain2.ru

Так же можно в самом Postfix в файле /etc/postfix/main.cf добавить ip адрес домена в список mynetworks — но это уже крайний случай, когда всё остальное уже опробовано, так как в этом списке должны быть перечислены только наши сети. Этот список применяется в нескольких случаях и в частности он определяет какие сети/адреса могут использовать наш сервер для пересылки (relay) писем.

Если в журнале находим ошибку «450 Server configuration problem», то проверяем настройки в файле main.cf. Одна из возможных причин: не запущен какой-нибудь необходимый демон.

У меня эта ошибка появилась после перезагрузки сервера. Оказалось, что postgrey автоматически не запускался при старте системы, а Postfix направлял ему запрос на разрешение принятия письма.

Вообще узнать значение ошибки можно в мануале:

# man smtpd

Управление пересылкой (relay), блокировка спам-а(junk mail), политики для отдельных пользователей (per-user policies)

В далеком прошлом Интернет представлял из себя дружественную среду. Почтовые сервера без ограничений пересылали почту от кого угодно кому угодно. Сегодня спамеры создают проблемы для серверов, которые пересылают почту от произвольных клиентов (т.н. open relay сервера), так как в последствии эти сервера могут быть добавлены в антиспамерские черные списки (anti-spammer blacklists).

По умолчанию, Postfix использует умеренно строгий подход к пересылке почты. Postfix пересылает почту только от клиентов из дружественных сетей (trusted networks) или для доменов, пересылка почты которым разрешена явно. Для ознакомления с поведением Postfix по умолчанию читайте описание параметра , а также документацию, на которую ссылается указанное описание.

Большинство возможностей по управлению доступом к SMTP серверу Postfix направлены на борьбу со спамом.

С ориентацией на протокол. Некоторые средства управления доступом к серверу SMTP блокируют почту от клиентов, которые нестрого придерживаются протокола SMTP. Таким образом, блокируются плохо реализованные и/или плохо настроенные спамерские программы, равно как и почтовые черви, которые пользуются собственной нестандартной реализацией SMTP клиента. Средства контроля, ориентированные на протокол, теряют эффективность со временем, так как спамеры и авторы вирусов учатся читать документы RFC.
Ориентированные на черные списки. Некоторые средства управления доступом к SMTP серверу опрашивают черные списки (blacklists), в которых хранится информация о «плохих» сайтах таких, как открытые релэи (open mail relays), открытые WEB-прокси сервера, скомпрометированные домашние компьютеры, которые удаленно управляемы криминалитетом. Эффективность черных списков зависит от их полноты и актуальности (современости) информации (up to date).
Ориентация на повышение требований. Некоторые средства управления доступом к SMTP серверу позволяют поднять планку требований для клиента, либо заставляя клиента выполнять больше работы (greylisting, серые списки), либо проводя дополнительные проверки (SPF и проверку адресов отправителя/получателя). Серые списки и политики SPF реализованы вне Postfix и являются темой документа SMTPD_POLICY_README. Проверка адресов отправителя/получателя описана в документе ADDRESS_VERIFICATION_README.

К сожалению, все средства борьбы со спамом могут ошибаться, отвергая легитимные письма. Это может быть серьезной проблемой для сервера, обрабатывающего почту для большого количества пользователей. Для одних пользователей неприемлемо получение хоть одного письма спама, в то время как для других одно ошибочно отвергнутое легитимное сообщение может обернуться трагедией. Так как нет определенной политики, которая бы удовлитворяла пожеланиям всех без исключения пользователей, Postfix поддерживает разные ограничения по доступу к SMTP серверу для разных пользователей. Эта возможность описана в документе RESTRICTION_CLASS_README.

Этап 3. Настройка Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, с помощью командной консоли Exchange

Чтобы настроить Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, выполните следующую команду:

Примечание. Чтобы параметры SMTP не отображались в Outlook в Интернете, измените значение на .

Как убедиться, что все получилось?

Чтобы убедиться, что вы настроили Outlook в Интернете на отображение параметров SMTP для клиентов SMTP, прошедших проверку подлинности, выполните следующие действия:

Откройте почтовый ящик в Outlook в Интернете и выберите Параметры > Параметры.
Нажмите Почта > Учетные записи > POP и IMAP и убедитесь, что отображаются правильные параметры SMTP.

Примечание. Если настроенные параметры SMTP отображаются не так, как ожидалось в Outlook в Интернете, запустите команды и перезапустите службы IIS (IIS).

Delayed evaluation of SMTP access restriction lists

Current Postfix versions postpone the evaluation of client,
helo and sender restriction lists until the RCPT TO or ETRN command.
This behavior is controlled by the parameter.
Restriction lists are still evaluated in the proper order of (client,
helo, etrn) or (client, helo, sender, relay, recipient, data, or
end-of-data) restrictions.
When a restriction list (example: client) evaluates to REJECT or
DEFER the restriction lists that follow (example: helo, sender, etc.)
are skipped.

Around the time that was introduced, Postfix
was also changed to support mixed restriction lists that combine
information about the client, helo, sender and recipient or etrn
command.

Benefits of delayed restriction evaluation, and of restriction
mixing:

Some SMTP clients do not expect a negative reply early in
the SMTP session. When the bad news is postponed until the RCPT TO
reply, the client goes away as it is supposed to, instead of hanging
around until a timeout happens, or worse, going into an endless
connect-reject-connect loop.
Mixing is needed for complex allowlisting policies. For
example, in order to reject local sender addresses in mail from
non-local clients, you need to be able to mix restrictions on client
information with restrictions on sender information in the same
restriction list. Without this ability, many per-user access
restrictions would be impossible to express.

Без шифрования

Устанавливаем dovecot.

а) если используем CentOS / Red Hat:

yum install dovecot

б) если используем Ubuntu / Debian:

apt-get install dovecot-imapd dovecot-pop3d

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

vi /etc/postfix/main.cf

И добавляем:

smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

* где smtpd_sasl_path — путь до плагина аутентификации по механизму SASL; smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL; smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации; smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке.

Открываем настройки аутентификации в 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 нет, то ее нужно создать.

Отключаем требование ssl для аутентификации:

vi /etc/dovecot/conf.d/10-ssl.conf

ssl = no

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Перезапускаем сервис Postfix:

systemctl restart postfix

Запускаем Dovecot:

systemctl enable dovecot

systemctl start dovecot

Готово. В качестве логина и пароля необходимо использовать системную учетную запись.

Тестирование правил доступа к SMTP

В Postfix имеются несколько возможностей, которые помогают тестировать правила доступа к SMTP:

Это средство заменяет действия SMTP сервера REJECT на DEFER (попытаться позже). Это позволяет оставлять сообщения в очереди, которые в противном случае были бы возвращены отправителю. Укажите » = yes» в файле main.cf, чтобы предотвратить постоянное отклонение почты SMTP сервером Postfix. С этой целью Postfix заменит все коды ответов 5xx на 4xx.
Эта возможность позволяет заменить действия SMTP сервира REJRCT на замечания (warnings). Вместо отклонения команды клиента Postfix регистрирует, что он собирался отвергнуть. Укажите «» в списке ограничений доступа к SMTP перед тем ограничением, которое вы хотите протестировать без реального отклонения почты.
XCLIENT

Благодаря этой возможности (Postfix 2.1 и последующие версии) авторизованные SMTP клиенты могут имитировать другие системы, таким образом вы можете проводить ралистичные тесты правил доступа к SMTP серверу Postfix. Примеры использования XCLIENT для тестирования правил доступа содержатся в документе XCLIENT_README.

Авторизуйтесь для добавления комментариев!

Шаг 1. Настройка FQDN в соединителене «Клиентский фронтенд»

Вы можете пропустить этот этап, если нужно оставить полное доменное имя сервера по умолчанию (например, mailbox01.contoso.com). Вы также можете указать полное доменное имя, лучше соответствующее вашему соглашению об именовании для Интернета или нужному сертификату TLS.

Если вы изменили полное доменное имя и хотите, чтобы клиенты POP3 или IMAP4 использовали этот соединитель для отправки электронной почты, то новому FQDN должна соответствовать запись на внутреннем DNS-сервере.

Независимо от полного доменного имени, если вы хотите, чтобы внешние клиенты POP3 или IMAP4 использовали этот соединитель для отправки электронной почты, то полному доменному имени должна соответствовать запись на общедоступном DNS-сервере, а TCP-порт (587) должен быть разрешен в брандмауэре на сервере Exchange Server.

Чтобы настроить полное доменное имя для клиентов SMTP, прошедших проверку подлинности, используйте следующий синтаксис:

В этом примере настраивается полное доменное имя mail.contoso.com.

Как проверить, что шаг выполнен?

Чтобы убедиться, что вы успешно выполнили FQDN в соединителене «Client Frontend» Receive, используйте любой из <Server name> следующих процедур:

EAC, перейдите к соединитетелям получения потока почты выберите > > Frontend <Server name> клиента, нажмите кнопку Изменить (изменить значок. ) Scoping и проверить значение в поле > FQDN.
В командной консоли Exchange выполните следующую команду:

6 ответов

TLS просто разрешает шифрование в сеансе smtp и не влияет непосредственно на то, разрешено ли Postfix передавать сообщение.

Сообщение об отказе в передаче происходит, потому что правила smtpd_recipient_restrictions не были сопоставлены. Одно из этих условий должно быть выполнено, чтобы сообщение прошло:

Чтобы объяснить эти правила:

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

Это приведет к тому, что postfix будет искать в /etc /postfix /filters_domains правила, основанные на адресе получателя. (Судя по имени файла в имени файла, возможно, это просто блокировка определенных доменов … Проверьте, не указан ли gmail.com?)

Это позволит хостам по IP-адресу соответствовать диапазонам IP, указанным в $ mynetworks. В отправленном main.cf, $ mynetworks был установлен в 127.0.0.1, поэтому он будет передавать только сообщения электронной почты, созданные самим сервером.

На основе этой конфигурации почтовому клиенту необходимо будет использовать аутентификацию SMTP, прежде чем разрешить ретрансляцию сообщений. Я не уверен, какую базу данных использует SASL. Это указано в /usr/lib/sasl2/smtpd.conf Предположительно, он также использует ту же базу данных, что и ваши виртуальные почтовые ящики, поэтому вы должны иметь возможность включить аутентификацию SMTP в своем почтовом клиенте и быть настроены.

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

Это исправит отправку только из вашей локальной сети. Для отправки электронной почты из-за пределов вашей локальной сети вам необходимо получить аутентификацию TLS.

Я думаю, вы пропустили домен domain.com в mydestination, потому что по умолчанию , поэтому вы можете добавить конфигурацию строки:

или:

Не забудьте перезапустить постфиксный сервер ( постфикс перезагрузки) каждый раз при редактировании файла conffix conf.

У меня была такая же проблема в Outlook (с поддержкой dovecote и postfix), и я потратил два дня на поиск решения и настройку моих конфигурационных файлов. Все, что мне нужно было сделать, это проверить «Сервер требует проверки подлинности» на вкладке «Исходящие» в настройках почты в Outlook, и мои сообщения теперь отправляются в gmail. См. Подробную инструкцию о том, как найти настройки здесь http://support.bluetie.com/node/440 .

Эта проблема исказила меня некоторое время. Я пытался подключиться с server1.domain.com на server2.domain.com.

Вот как я это исправил —

Вам также необходимо убедиться, что вы правильно установили /etc /hosts и /etc /hostname и убедитесь, что после сетевых изменений вы выполните следующее:

и после изменения конфигурации постфикса следующие

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

Ограничения, которые воздействуют на всю 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»).

Подготовка

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

Проверка существующей конфигурации Postfix

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

postconf 1> /dev/null

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

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

Создание резервной копии конфигурации Postfix

Перед внесением изменений в настройки системы рекомендуется сделать резервную копию настроек. Создадим копию каталога .

tar czf /root/postfix-$(date "+%F").tar.gz /etc/postfix

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

postconf > /root/postconf-$(date "+%F")

Версия Postfix

Проверить версию Postfix можно следующей командой:

postconf mail_version | awk -F" = " '{print $2}'

Или воспользуйтесь менеджером пакетов. Пользователи Debian и Ubuntu могут использовать команду .

dpkg -l postfix

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

Выбор почтового сервера

Из огромного множества рассмотрим 3 самых массовых почтовых сервера: Sendmail, Exim и Postfix.

Согласно на июнь 2020 г. самым популярным в мире является Exim (466853 — 57%), за ним следует Postfix (289401 — 35%), а вот некогда самый массово используемый Sendmail уже практически не используется (30640 — 4%).

Еще в 2007 году Sendmail был установлен на большинстве серверов, но утрата позиций связана, в первую очередь, с часто возникающими проблемами с безопасностью. Exim — мощный почтовый агент, большинство функционала которого не будет использоваться для поставленной задачи. Postfix — самый безопасный и простой в настройке полноценный MTA, он и был выбран для отправки писем с сервера.

Restrictions that apply to all SMTP mail

Besides the restrictions that can be made configurable per
client or per user as described in the next section, Postfix
implements a few restrictions that apply to all SMTP mail.

The built-in and content
restrictions, as described in the BUILTIN_FILTER_README document.
This happens while Postfix receives mail, before it is stored in
the .
The external before-queue content restrictions, as described
in the SMTPD_PROXY_README document. This happens while Postfix
receives mail, before it is stored in the .
Disallowing illegal syntax in MAIL FROM or RCPT TO commands.
This may cause problems with home-grown applications that send
mail, and with ancient PC mail clients. For this reason, the
requirement is disabled by default (» =
no»).
- Disallowing RFC 822 address syntax (example: «MAIL FROM: the
  dude <dude@example.com>»).
- Disallowing addresses that are not enclosed with <>
  (example: «MAIL FROM: dude@example.com»).
Rejecting mail from a non-existent sender address. This form
of egress filtering helps to slow down worms and other malware, but
may cause problems with home-grown software that sends out mail
software with an unreplyable address. For this reason the requirement
is disabled by default (» = no»).

Шаг 4 — Переадресация системной почты

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

Файл содержит список альтернативных имен получателей электронных писем. Откройте его для редактирования:

По умолчанию он выглядит так:

/etc/aliases

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

Добавьте в конец файла следующую строку:

/etc/aliases

Для вступления изменений в силу выполните следующую команду:

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

Протестируйте отправку электронных писем пользователю с помощью следующей команды:

Письмо должно прийти на указанный вами почтовый ящик. Если его там нет, проверьте папку «Нежелательная почта».

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

Шаг 3 — Тестирование сервера SMTP

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

Выполните следующую команду для отправки тестового письма:

Проверьте почтовый ящик, на адрес которого вы отправили сообщение. Вы должны увидеть это сообщение в папке «Входящие». Если его там нет, проверьте папку «Нежелательная почта». Сейчас все электронные письма отправляются без шифрования, и поэтому провайдеры могут посчитать их спамом. Шифрование мы настроим немного позднее, на шаге 5.

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

С этой конфигурацией адрес в поле «» в отправляемых тестовых письмах будет иметь вид , где — имя пользователя сервера, от лица которого вы запустили команду.

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

Настройка Postfix

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

vi /etc/postfix/main.cf

Добавим следующие строки:

relayhost =
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/private/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_sasl_type = cyrus
smtp_sasl_mechanism_filter = login
smtp_sender_dependent_authentication = yes
sender_dependent_relayhost_maps = hash:/etc/postfix/private/sender_relay
smtp_tls_CAfile = /etc/postfix/ca.pem
smtp_use_tls = yes

* где:

relayhost — сервер, через который нужно отправлять почту. Мы будем использовать отдельные правила, поэтому оставляем данный параметр с пустым значением.
smtp_sasl_auth_enable — включение аутентификации на стороне клиента.
smtp_sasl_password_maps — указывает на файл, в котором хранится база связок логин/пароль.
smtp_sasl_security_options — опции SASL. noanonymous указывает на запрет анонимной аутентификации.
smtp_sasl_type — задает плагин SASL для аутентификации.
smtp_sasl_mechanism_filter — перечисляет механизмы проверки пользователя и пароля.
smtp_sender_dependent_authentication — включает зависящую от отправителя аутентификацию, отключает кэширование SMTP-соединения.
sender_dependent_relayhost_maps — указание на список адресов и почтовых серверов, через которые нужно отправлять письма на эти адреса.
smtp_tls_CAfile — файл с сертификатом Яндекса.
smtp_use_tls — указывает, использовать ли TLS для SMTP.

Создаем каталог для конфигов:

mkdir /etc/postfix/private

Создаем файл с правилами пересылки сообщений:

vi /etc/postfix/private/sender_relay

@yandex.ru smtp.yandex.ru

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

Создаем файл с настройкой привязки логинов и паролей:

vi /etc/postfix/private/sasl_passwd

root@yandex.ru root@yandex.ru:password1
info@yandex.ru info@yandex.ru:password2

* в данном примере мы создаем 2 учетные записи для аутентификации на яндексе. При отправке писем от root@yandex.ru необходимо авторизоваться на сервере яндекса от этой же учетной записи с паролем password1. Соответственно, при отправке письма от info@yandex.ru — с паролем password2.

Создаем карты для данных файлов:

postmap /etc/postfix/private/{sasl_passwd,sender_relay}

Получаем сертификат от Яндекса, для этого выполняем запрос:

openssl s_client -starttls smtp -crlf -connect smtp.yandex.ru:25

… на экран будет выведена различная информация — нам нужна вся, что заключена между ——BEGIN CERTIFICATE—— и ——END CERTIFICATE——. Копируем ее и создаем файл сертификата:

vi /etc/postfix/ca.pem

——BEGIN CERTIFICATE——
MIIGazCCBVOgAwIBAgIQcUU9mJXW4OUs5Gf0JfLtsjANBgkqhkiG9w0BAQsFADBf
…
nRG0DfdqYIuPGApFORYe
——END CERTIFICATE——

Перезапускаем Postfix:

systemctl restart postfix

Обратите внимание на 2 момента:
1) так как яндекс может обслуживать почту для любых доменов, не обязательно должен использоваться домен yandex.ru.
2) отправка сообщения должна идти строго от того пользователя, под которым идет авторизация на yandex. В противном случае, подключение не пройдет проверку и завершится ошибкой

Проверка

Для проверки можно использовать консольную команду mail.

Если используем Red Hat / CentOS

yum install mailx

После отправляем письмо

echo «Test text» | mail -s «Test title» -r root@yandex.ru master@dmosk.ru

* в данном примере мы отправляем письмо от почты root@yandex.ru на ящик master@dmosk.ru.

Если используем Ubuntu / Debian

apt-get install mailutils

После можно отправлять письмо:

echo «Test text» | mail -s «Test title» master@dmosk.ru -aFrom:info@yandex.ru

* в данном примере мы отправляем письмо от ящика info@yandex.ru на почту master@dmosk.ru.

Результат

В итоге на отправляемый ящик электронной почты должно прийти письмо от нашего адреса с доменом yandex.ru. Если посмотреть в заголовки, оно должно было быть отправлено через серверы Яндекса: