Sendmail path postfix php

Учимся настраивать свою почту, не наступая на чужие грабли: Postfix + msmtp + сайт

Привет, меня зовут Никита, я backend-разработчик в компании ИНТЕРВОЛГА. Работаю в компании уже 3 года, и за этот срок достаточно часто мне приходилось возиться с установкой и конфигурированием собственного почтового сервера для разных задач (см. далее) клиентов.

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

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

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

Я не видел в Сети и на Хабре цельной инструкции такого рода — и решил написать свою.

Статья не претендует на то, чтобы рассказать про всё сразу и максимально подробно (сомневаюсь, что это реализуемо). Наоборот, я стремился описать сложные и комплексные вещи простым языком. Слишком обширные темы, уже давно разобранные сообществом, я опускал. Главной целью было дать новичку, который закопается в дебрях “почтовых интриг”, указатель, в какую сторону копать при возникновении типовых вопросов и проблем. Надеюсь, что эта статья окажется полезной и найдет своего читателя. Приступим!

Читайте также:  Java parse web pages

Зачем ставить свой почтовик?

Настройка почты

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

По данным Statista.com, в 2022 отправляется более 320 млрд писем каждый день, и это число стабильно растет.

Статистика рассылки писем по данным Statista 2022

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

борьба со спамом

Яндекс, предоставляющий возможность использовать свои почтовые сервисы, с 2021 года стал блокировать отправку писем с подменой отправителя (если вдруг не знали, то да, можно отправить письмо с одного ящика, а отображаться у получателей будет другой). Номинально это было правильное и полезное для защиты пользователей решение, но некоторые CMS используют данную возможность. Например, 1С-Битрикс. Он умеет работать с кастомным почтовым сервером, но маленьким и средним интернет-магазинам при запуске было лень решать вопросы его настройки, и поэтому часть из них выбирали сторонний почтовик от Яндекса. И как только Яндекс перекрыл рубильник подмены заголовков, почта банально перестала отправляться. Клиентам Яндекс.Почты с сайтами на Битриксе пришлось исправлять это в экстренном режиме, с чем я сам неоднократно сталкивался.

При размещении почтового клиента на выделенном виртуальном сервере, администраторам, как правило, нужно учесть, что большинство провайдеров перекрывают 25 порт в целях безопасности. Это порт, который по умолчанию использует большинство почтовых клиентов для отправки писем. Таким страдают Яндекс в облачных серверах, Amazon и остальные провайдеры, но они позволяют запросить открытие порта. Selectel же, например, заявил, что будет блокировать порт перманентно (пока, правда, этого не произошло). Это добавит еще больше геморроя администраторам при решении этой проблемы.

Правильный выбор и настройка ПО может помочь в решении и профилактике проблем из примеров.

Как работает отправка писем?

принцип отправки писем в почтовых сервисах

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

Рассмотрим следующий простейший пример:

  1. У пользователя Боба есть почта на Yandex и друг Фил, у которого почта на Mail.ru.
  2. Боб захотел пообщаться с Филом по почте, он со своего компьютера с помощью почтового клиента Outlook отправляет сообщение.
  3. Outlook знает, что письмо нужно передать в почтовый сервер Yandex, передает его, а сервер Yandex принимает его.
  4. Сервер Yandex по домену адреса ящика Фила “phil@mail.ru” понимает, что письмо нужно отправить на сервер Mail.ru, и пересылает письмо на сервер Mail.ru.
  5. Сервер Mail.ru принимает письмо Боба, сохраняет его к себе в папку “Входящие” на почту Фила и ждет.
  6. Фил заходит в Outlook на своем компьютере, и Outlook проверяет, есть ли на сервере Mail.ru, к которому он подключен, новые письма.
  7. Сервер Mail.ru понимает, что Outlook Фила пытается получить новые письма, и отправляет ему запрошенные сообщения, а Outlook их получает и показывает Филу.

Этот пример можно представить в виде следующей схемы:

схема отправки и получения писем Яндекс и МайлРу через Outlook

Все элементы этой цепочки: Outlook Боба, сервер Yandex, сервер Mail.ru и Outlook Фила – участники обмена почтовым сообщением, которых называют агентами.

Все агенты классифицируются на:

  • Mail User Agent (MUA) — пользовательский почтовый агент, получает письма и отправляет их. Как правило такие агенты именуются почтовыми клиентами.
  • Mail Delivery Agent (MDA) — агент доставки письма, дает доступ к письму для MUA получателя.
  • Mail Transfer Agent (MTA) — агент передачи письма, принимает письма и отправляет их на другие MTA или MDA.

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

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

Представим, что теперь Фил из примера решил отправить ответное письмо Бобу: в таком случае функциональные классы серверов Yandex и Mail.ru поменяются местами, т.к. теперь Mail.ru будет пересылать письмо Боба, а сервер Yandex будет принимать письмо и складывать его во “Входящие”. В этом и заключается изменчивость принадлежности агентов к функциональным классам.

смена мест функциональных классов серверов Yandex и Mail.ru

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

Как, например, сервера Yandex и Mail.ru умеют и пересылать письма, и хранить входящие, и обрабатывать запросы клиентов на получение новых писем, но всё это в разные моменты времени. Когда нужно переслать, сервер выполняет функции MTA, когда сохранить входящее или отдать клиенту новое — MDA.

Yandex и Mail.ru умеют так только потому, что разработчики озаботились настройкой серверной инфраструктуры и софта и потратили на это много денег и времени. Чем больше требуется функций почты, тем затратнее будет настройка. Большинству владельцев почты не нужны ни личные “Yandex” и “Mail.ru”, ни лишние затраты, но нужны отдельные возможности почты.

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

Конфигурирование сервера Postfix

Рассмотрим выполнение базовой технической задачи для живого проекта — рассылка рекламных сообщений (не спама) с сайта интернет-магазина. Для ее решения нет необходимости в приеме писем, только в отправке и пересылке — соответственно, нам нужны функции MUA (только для отправки) и MTA.

Наименее затратным решением будет использование связки из:

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

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

почтовый сервер Postfix спешит на помощь

  1. Установка.

Установить Postfix на сервер можно любым доступным способом. Для удобства здесь и далее будем предполагать, что на сервере стоит CentOS 7, и все команды выполняются из-под пользователя root.

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

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

  • myhostname – хост почтового сервера,
  • mydomain – домен почтового сервера, как правило задается как myhostname без первой компоненты,
  • mydestination – адрес для получения писем,
  • myorigin – адрес, который будет указан как отправитель при передаче письма,
  • inet_interfaces – сетевые интерфейсы, по которым может проходить почта,
  • inet_protocols – протокол поиска MTA получателя.

Параметры myhostname, mydomain используются в других параметрах как переменные, их задавать не обязательно, но желательно — если изменится хост или домен, не придется переназначать другие параметры.

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

Параметр inet_interfaces необходимо настроить для ограничения возможных клиентов сервера. Если почтовый сервер и клиент располагаются на одной машине, то достаточно указать localhost, иначе – тот домен, с которого будут приходить инструкции от клиента.

Параметр inet_protocols, как правило, задают в ipv4, игнорируя ipv6 ввиду его ненужности.

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

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

Большинство почтовиков при получении писем проверяют их Anti-Spam софтом, который в первую очередь оценивает наличие и корректность DNS-записей. При отсутствии или некорректной настройке записей почтовый сервер получателя может со временем добавить ваш ящик в черный список. Такого при рассылке рекламных сообщений лучше избежать. Для решения поставленной задачи требуется четыре таких записи, каждая из которых настраивается в доменной панели.

MX-запись.

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

Для решения нашей задачи эта запись не нужна – не собираемся принимать письма. Поэтому без нее почта будет работать, но большинство почтовых AntiSpam-сервисов требует её наличия. Отсутствие MX-записи не воспринимается ими как критичный признак спама. Письма будут приходить получателям, но нет гарантии, что через время из-за отсутствия MX-записи наш почтовый сервер не поместят в черный список. Поэтому желательно эту запись добавить.

Источник

Оцените статью