Установка своего почтового сервера, как правило, не вызывает особых трудностей. В Сети доступно большое количество готовых инструкций. Буквально одна команда, и 25-й порт уже готов к работе. Весело становится, когда отправленные письма начинают возвращаться, а получатели жаловаться, что сообщения не доходят. Здесь уже хочешь не хочешь, но придется искать причины и вникать в технологии.
Кто отправляет письмаСегодня возможность привязать свой домен к сервису предлагают многие веб-службы. Особо популярно размещение почты на Gmail или Яндексе. Все сообщения будут идти через предоставленный ими SMTP-сервер, проверенный поставщик услуг сам сформирует все необходимые заголовки и подписи, которые позволят пройти через любой спам-фильтр. Но такой вариант не всегда возможен. Например, организация имеет большое количество пользователей, нужны особые настройки для почты, недоступные в облачных сервисах. Или используется свой сервер с порталом, CMS или интернет-магазин, с которых нужно отправлять сообщения.
По умолчанию все PHP-приложения используют для отправки почты функцию mail(), которая, в свою очередь, отправляет их через локальный SMTP-сервер, описанный в php.ini.
Код:
[mail function]
sendmail_path = /usr/sbin/sendmail -t -iИли в виртуальном хосте:
Код:
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f [email protected]"И хотя там в 100% случаев написан sendmail, на самом деле это может быть симлинк, а почту отсылает Postfix или Exim. Чтобы отправить почту из приложения, можно выбрать один из трех вариантов:
- Сам движок иногда позволяет указать внешний SMTP-сервер (в дефолтных настройках или через плагин, в WordPress это WP Mail SMTP или Easy WP SMTP). Достаточно просто указать данные аккаунта, и все проблемы решены.
- Использование программы-прокладки, которая эмулирует работу локального SMTP-сервера и отправляет сообщения через почтовый аккаунт на стороннем сервере. Здесь очень популярна SSMTP.
- Использование своего почтового сервера. Придется, конечно, его настроить, зато больше возможностей конфигурации.
Как не попасть в спам
Борьба со спамом — это головная боль всех администраторов почты. Причем в последнее время актуальна как раз обратная сторона медали: спам-фильтры буквально зверствуют. Поэтому спам в приходящей почте практически отсутствует, но вот нормальные сообщения постоянно куда-то пропадают, клиенты и руководство нервничают, и приходится дополнительно убеждаться, что сообщение дошло до адресата. И после установки SMTP-сервера с большой вероятностью придется еще повозиться, чтобы сообщения вообще хоть куда-то доходили. В частности, чтобы оценить настройки, следует посмотреть, доставляются ли письма в ящики основных почтовых систем Gmail, Яндекс, Mail.Ru. Обычно на этом этапе появляются первые сложности, и приходится решать все проблемы персонально.
Почтовые сервисы используют многоуровневую систему фильтрации спама, причем настолько серьезную и засекреченную, что о принципах не знает даже их собственная техподдержка. И у каждого сервиса свои приоритеты. Хотя обычно некая подсказка о причине недоставки содержится в ответном письме сервиса. Также в анализе причин помогает сервис , достаточно отправить письмо на указанный там адрес и затем после анализа получить результат и перечень проблем. Некоторые из них можно проверить и решить, еще не настраивая SMTP-сервер.
Mail-tester.com — хорошее подспорье в поиске проблем
Борьба со спамом породила множество технологий. Самая старая из них — blacklist, в который заносятся все IP и домены, занимавшиеся рассылкой спама, сюда же могут попасть открытые релеи, прокси и Dialup-адреса, используемые для удаленного доступа (то есть они теоретически не должны рассылать почту). Организованы такие blacklist по-разному. Популярностью пользуются DNSBL (DNS blacklist) — черные списки в формате DNS, которые легко опрашивать. На сегодня доступно множество баз, не все они популярны и используются. Проблема в том, что списка для конкретного почтового сервиса нет, сколько и какие они опрашивают — это тайна.
Доменные имена, как и IP-адреса, сегодня могут быть «бэушными». Есть вероятность, что до тебя ими пользовался сервис рассылки сообщений или хост, размещенный на нем, был взломан и рассылал спам. Соответственно, они вполне могут попасть в какой-то из DNSBL и быть проблемой. Mail.Ru отбрасывал письма с одного IP именно из-за того, что тот находился в одном из таких полузабытых списков, попав туда в 2010 году. Причем Mail.Ru даже не утруждался проверять правильность SPF и DKIM. Дело сдвинулось, лишь когда IP убрали из блек-листа.
Проверить IP или домен можно самостоятельно, отослав DNS-запрос к выбранному DNSBL-серверу при помощи утилиты dig:
Код:
$ host -tA xakep.ru.ex.dnsbl.org
Host xakep.ru.ex.dnsbl.org not found: 3(NXDOMAIN)Но удобнее пользоваться онлайн-сервисами, проверяющими сразу в нескольких базах. IP можно проверить в (59 баз) или (72 базы), домен, кроме того, — в (107 баз), или . Если вдруг домен или IP окажется в списке, лучше сразу написать в поддержку и убрать свой адрес.
Правильная DNS
При получении сообщения удаленный SMTP-сервер анализирует прежде всего его заголовок. Почтовая программа отправляет только From, To, Date, Subject и X-Mailer. Они в общем понятны и просто указывают, от кого и куда слать. Остальной заголовок формируется как SMTP-сервером, так и приложением, его отправляющим. Это, кстати, тоже нужно учитывать, потому что письма, отправляемые через Telnet, могут уходить, а с Roundcube — нет, просто потому, что у них разный заголовок. Roundcube, например, подставляет свой HELO/EHLO на основании переменной server_name или localhost, если она не определена. Поэтому иногда нужно просто задать его явно:
Код:
$rcmail_config['smtp_helo_host'] = 'example.org';
При передаче письмо будет проходить минимум через два SMTP-сервера, каждый из которых тоже добавляет что-то от себя в заголовок. В первую очередь каждый сервер добавляет свой Received: from. Читать их лучше снизу вверх. Самое нижнее сообщение — это сервер отправителя, самый верхний — сервер получателя. Хотя на самом деле серверов может быть больше, особенно это актуально при работе с крупными провайдерами услуг, которые, приняв письмо, перебрасывают его дальше, или при использовании на пути SMTP-прокси. Для анализа пути сообщения можно использовать сервис от , который покажет в понятной форме все SMTP-серверы, время прохождения и тесты SPF, DKIM и DMARC (о них дальше).
Путь письма
Код:
Received: from server.example.org [1.2.3.4] (helo=server.example.org)
by st15.provider.com with esmtps (Exim 4.80.1) (envelope-from
<[email protected]>)Дальше он производит обратное разрешение имени по IP через обратный DNS-запрос c помощью PTR-записи. То есть он узнает, сервер с каким именем должен быть по адресу, с которого пришло сообщение. Такое поведение было заложено в RFC 2505 от февраля 1999 года Anti-Spam Recommendations for SMTP MTAs. И хотя давно признано, что обратные зоны не являются достаточным условием для однозначного опознавания отправителя и часто приводят к ошибкам и задержкам, они все же поддерживаются. Поэтому они должны совпасть, иначе сообщение как минимум получит минус в рейтинге, а в худшем случае будет отброшено.
В нашем примере за IP 1.2.3.4 должен быть закреплен server.example.org. DNS-запись выглядит так:
Код:
1.2.3.4.in-addr.arpa. IN PTR server.example.org
Код:
$ dig -x 1.2.3.4Особо хочется обратить внимание, что VDS обычно имеет два IPv4 и v6. Поэтому все сказанное касается обеих версий, так как письмо к одному серверу может идти по IPv4 и доставляться, а другой предпочитает использовать IPv6, и письмо может не доходить до получателя. При этом очень много провайдеров, предоставляя IPv6, абсолютно не утруждают себя настройкой PTR-записи, и ее проверка возвращает ошибку. Но Google, например, предпочитает IPv6 и сразу отбрасывает письмо, если PTR не совпадает с именем сервера. В ответном сообщении сервиса это выглядит так:
Код:
Our system has detected that this message does
550-5.7.1 not meet IPv6 sending guidelines regarding PTR records and
550-5.7.1 authentication.
Код:
inet_protocols = ipv4После чего перезапустить сервис.
Код:
$ sudo service postfix restartВ Exim в /etc/exim/exim.conf
Код:
disable_ipv6 = true
Не забываем, что SMTP-сервер обычно использует IPv4 и IPv6
Код:
Received: from smtp26.emlone.com (smtp26.emlone.com [146.0.246.220])То есть пишем провайдеру, чтобы поменял PTR на example.com, меняем hostname и проверяем, что сервер отвечает правильным HELO/EHLO. В Postfix за это ответственен параметр myorigin, указывающий имя домена, которое используется в почте, отправляемой с этой машины. По умолчанию myorigin = $myhostname, указывающее на имя хоста. Поэтому
Код:
myhostname = example.orgИногда используется значение $mydomain, которое по умолчанию содержит доменную часть полного имени машины.
Exim в HELO/EHLO использует значение переменной primary_hostname, которая по умолчанию совпадает с именем хоста. Но можно задать его вручную:
Код:
primary_hostname = example.orgИ здесь есть один нюанс, о котором нужно знать. Например, домен example.org прикреплен к Gmail, и вся работа с почтой ведется с этих аккаунтов. C VDS менеджеры на свой @example.org ящик должны получать только сообщения о заказе. Если настроить в SMTP-сервер EHLO example.org, то Google решит, что над ним явно издеваются, ведь домен у него даже не будет дальше проверять, просто отбросит сообщение.
Но если на одном VDS несколько доменов, то такая схема уже будет проблематичной. В принципе, в RFC нет явного запрета на несколько PTR-записей для одного IP, но есть уже устаревшая IETF, в которой расписана эта проблема и совет не делать этого в первую очередь из-за возможных ошибок. Очевидно, его и придерживаются, во всяком случае, провайдеры не хотят добавлять еще PTR-записи. В такой ситуации нужно или оставить техническое имя сервера, или (лучше) выбрать один из используемых доменов как основной и настроить PTR и hostname под него.
Разбираемся с SPF
Изменить действующие технологии отправки почты, зародившиеся в восьмидесятых годах прошлого века, в глобальном масштабе уже невозможно. Это потребовало бы колоссальных затрат как времени, так и денег. Поэтому проблемы стали решать при помощи дополнений. Начало разработок Sender Policy Framework (SPF) датировано июнем 2003 года, в основе стоял Менг Венг Вонг (Meng Weng Wong) — основатель компании POBOX. Технология SPFv1 определена в RFC 4408 «Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1», опубликованном в апреле 2006 года, в 2014 году вышла новая версия — RFC 7208. Хотя крупные компании вроде Google, AOL, Amazon, eBay, W3C объявили о ее внедрении еще в 2004-м. Суть SPF проста: это нечто вроде персонального белого списка. Администратор почтового домена с помощью специальной TXT- или SPF-записи (опционально) в DNS-зоне перечисляет разрешенные адреса, с которых может отправляться почта. Сервер, получивший сообщение из этого домена, сверяет IP-адрес с SPF-записью. Если адрес указан в списке разрешенных, то считается, что проверка пройдена, и в сообщении появится новый заголовок Received-SPF: pass.
Несмотря на то что для SPF придуман отдельный тип записи, он так и остался опциональным
(при наличии поля его лучше тоже создать, хуже не будет), TXT обязательна.
Код:
example.org TXT "v=spf1 a mx ip4:1.2.3.4 ~all"Если домен может отправлять почту с нескольких адресов, все их прописываем здесь или указываем в MX-записи. Если VDS имеет IPv6-адрес, обязательно прописываем его здесь в ipv6:. Расшифруем:
- v=spf1 — используемая версия SPF;
- a — прием писем от узла с IP-адресом, указанным в A-записи домена;
- mx — подключает адреса, указанные в MX-записях;
- all — что делать с серверами, не перечисленными в SPF. Причем все указанное после all проверяться не будет, оно должно стоять последним.
- None — означает, что в этом домене нет опубликованных SPF-записей, поэтому определить разрешения невозможно;
- Neutral (?) — владелец домена явно указал, что он не хочет устанавливать разрешения, обрабатывается аналогично None и служит больше для информационных целей;
- Pass (+) — прошедшему проверку разрешено отсылать сообщения. Установлен по умолчанию;
- Fail (-) — клиент не уполномочен отсылать почту из этого домена, и принимающая сторона вправе пометить такое сообщение или отвергнуть. Например, v=spf1 -all указывает, что домен вообще не отправляет почту;
- SoftFail (~) — отправитель не имеет права посылать сообщение, но принимающая сторона должна не отвергать сообщение, а провести дальнейшую проверку.
попадающие под правила, следует однозначно отвергать.
Проверить SPF-запись можно при помощи онлайн-сервисов ,
или утилиты spfquery.
Код:
$ apt install spfquery
$ spfquery -ip=1.2.3.4 [email protected] -helo=example.orgВ 2004 году в MS предложили схожую с SPF технологию, названную Sender ID и использующую DNS-записи spf2.0/pra, или spf2.0/mfrom, или spf2.0/mfrom,pra. Проверяется MAIL FROM, а не адрес возврата. Технология в настоящее время не получила широкого распространения, и MS рекомендует при отсутствии явных записей spf2.0 рассматривать v=spf1 как эквивалент spf2.0/mfrom,pra и использовать его при анализе. Вот, собственно, и все, что нужно о ней знать.
В принципе, если выполнить все рекомендации, можно уже смело отправлять письма, застревать они не должны. Но некоторые сервисы требуют обязательного подписывания сообщений.
Проверяем SPF
В основу DKIM (DomainKeys Identified Mail) легли две разработки — технология DomainKeys от Yahoo и система Internet Identified Mail от Cisco. Новый проект был подан на утверждение в качестве стандарта IETF в 2005 году. Принцип DKIM очень прост. Каждое сообщение снабжается цифровой подписью, которая удостоверяет отправителя и гарантирует, что подписанная часть не изменялась. Сам процесс напоминает работу любой системы с открытым ключом. Владелец домена создает пару ключей — открытый и приватный. Приватный используется на SMTP-сервере для подписи сообщения, которая передается в заголовке DKIM-Signature. Домен указывается в поле d=, список подписанных заголовков перечисляется в ключе h:
Код:
h=From:Subject:Reply-To:List-Unsubscribe:To:Message-Id:Date:MIME-
Version:Content-Type; [email protected];Открытый ключ добавляется в TXT-поле DNS-записи и при поступлении письма запрашивается получателем, который проверяет, действительно ли подпись была сгенерирована для домена, указанного в адресе отправителя. При положительном результате в сообщении появляется подзаголовок Authentication-Results: dkim=pass.
Если принимающая сторона не умеет проверять подпись, то на прохождении сообщения это никак не сказывается. Также нужно отметить, что правильный DKIM обычно не служит для антиспам-систем указанием на дальнейшее прохождение проверок. Но по опыту его наличие обычно поднимает его рейтинг насколько, что он редко застревает в фильтрах. Некоторые сервисы вроде postmaster.mail.ru требуют обязательного наличия подписанных DKIM-сообщений в привязанном домене, иначе статистика показываться не будет.
DKIM подписывают сообщения основные почтовые сервисы, и если привязать домен к Яндексу или Google, выполнив все инструкции, то больше ничего делать не нужно. Яндекс подключает DKIM обычно не сразу, а через день-два.
Настроим Postfix, чтобы он подписывал сообщения. Будем считать, что он установлен и сконфигурирован. Далее нам понадобится пакет .
Код:
$ sudo apt install opendkim opendkim-toolsДемон будет работать с правами opendkim
pendkim. Генерируем ключи для селектора mail.
Код:
$ sudo mkdir -p /etc/mail/example.org
$ cd /etc/mail/example.org
$ sudo opendkim-genkey -s mail -d example.orgВ текущем каталоге появятся два файла: mail.private — закрытый ключ и mail.txt — открытый. Добавляем в DNS-запись типа TXT из mail.txt.
Код:
mail._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS....ViwIDAQAB"Настройки OpenDKIM в Ubuntu находятся в файле /etc/opendkim.conf. Их, в принципе, может быть много, и могут использоваться дополнительные файлы, так как один демон часто обслуживает несколько доменов. В /usr/share/doc/opendkim/examples есть пример. Но в простом случае достаточно изменить несколько параметров под свои условия.
Код:
Domain example.org
KeyFile /etc/mail/example.org/mail.private
Selector mail
# По умолчанию подпись только проверяется, нужно изменить на sv (signer, verifier)
Mode svПосле установки демон opendkim слушает сокет /var/run/opendkim/opendkim.sock, но при необходимости можно указать
сетевой порт и интерфейс. После правки файла перезапускаем демон:
Код:
$ sudo service opendkim restartДобавляем в /etc/postfix/main.cf данные сокета:
Код:
milter_default_action = accept
milter_protocol = 2
smtpd_milters = /var/run/opendkim/opendkim.sock
non_smtpd_milters = /var/run/opendkim/opendkim.sock
$ sudo service postfix restartКоротко это все настройки.
Проверить DKIM можно с помощью утилиты opendkim-testkey:
Код:
$ opendkim-testkey -d example.org -s mail -vvv
Настройки в /etc/opendkim.conf
Код:
_dmarc.example.org TXT "v=DMARC1; p=none; rua=mailto:[email protected]"Доступны три варианта политик:
- none — без рекомендаций, регистрировать сообщения, не прошедшие проверку (отчет отсылается по адресу, указанному в rua);
- quarantine — помечать как спам;
- reject — отклонить сообщение.
Если письмо не доставляется
Бывает, что все требования выполнены, а сообщения почему-то не доставляются, и приходит даже глупый ответ сервера. Здесь без обращения в саппорт проблему уже не решить.
Способ обращения в службу поддержки у разных сервисов отличается, найти их
на сайте не всегда просто.
В Яндекс нужно заполнить форму в конце , выбрав причину обращения. В Mail.Ru есть специальный ящик [email protected]. Но лучше
отослать сообщение через веб-форму при , если письмо .
У Google нет поддержки бесплатных продуктов, в том числе и почты Gmail. Но те, кто занимается рассылками, могут отправить запрос через .
Может, повезет и тебе ответят. Там же есть ссылки на документацию.
У Рамблера формы нет, проблемы нужно отсылать на [email protected].
Заключение
Если проделать все описанное, то о проблемах с доставкой почты можно забыть.
