Envelope from что это
Как из письма выудить
информацию об отправителе.
Для того чтобы посмотреть, откуда реально пришло письмо нужно в Outlook Express выбрать нужное письмо и нажать Ctrl+F3. В появившемся окне жирным шрифтом выделены заголовки письма. Вот именно они нам и нужны.
Вот что я выудил из спам-письма, которое мне пришло:
Return-Path:
Received: from myleleka.com.ru (myleleka.com.ru [195.45.34.52])
by myleleka.com.ru (8.13.1/8.13.1/sn-branch) with ESMTP id j647T92E083346
for
; Mon, 4 Jul 2005 10:29:10 +0300 (EEST)
(envelope-from wbjemg@nfg.com)
Received: from 68.116.210.168 (68-116-210-168.dhcp.thbd.la.charter.com
[68.116.210.168])
by myleleka.com.ru (8.13.3/8.13.3/ic) with SMTP id j647SXb4004075;
Mon, 4 Jul 2005 10:28:44 +0300 (EEST)
(envelope-from wbjemg@nfg.com)
Message-Id:
From: =?koi8-r?B?+8XT1M/QxdLP1yDhLuku?=
To: umnjurwyhgor
Subject:=?koi8-r?B?/MbGxcvUydfOwdEg0sXLzMHNwSDEzNEg98HTIUUtbWFpbCDSwdPT2czLwSEgz8k=?=
Date: Mon, 4 Jul 2005 11:31:14 +0400
Reply-To: wbjemg@nfg.com
Mime-Version: 1.0
Content-Type: multipart/related; boundary=»—-=_NextPart_000_0036_01ERQLCQ.333NMF25″
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Сначала рассмотрим, что именно эти заголовки обозначают.
Например, строчка «From:=?koi8-r?B?+8XT1M/QxdLP1yDhLuku?=wbjemg@nfg.com» обозначает, что письмо отправлено с почтового адреса wbjemg@nfg.com.
Строчка «To: umnjurwyhgor umnjurwyhgor@myleleka.com.ru» сообщает нам, что это письмо должно было отправиться на адрес umnjurwyhgor@myleleka.com.ru.
А теперь интересная штука. В разделе:
Received: from myleleka.com.ru (myleleka.com.ru [195.45.34.52])
by myleleka.com.ru (8.13.1/8.13.1/sn-branch) with ESMTP id j647T92E083346
for
; Mon, 4 Jul 2005 10:29:10 +0300 (EEST)
(envelope-from wbjemg@nfg.com)
мы видим строчку «for
Это тот адрес, на который пришло письмо. Как видите, адрес, на который было отправлено сообщение, разнится от того, на который оно пришло. Это в большинстве случаев и есть признаком спама.
Но самое главное скрывается в этом разделе:
Received: from 68.116.210.168 (68-116-210-168.dhcp.thbd.la.charter.com
[68.116.210.168])
by myleleka.com.ru (8.13.3/8.13.3/ic) with SMTP id j647SXb4004075;
Mon, 4 Jul 2005 10:28:44 +0300 (EEST)
(envelope-from wbjemg@nfg.com)
Здесь указывается, откуда пришло письмо.
Из строчки «from 68.116.210.168» берем IP адрес компьютера, с которого было отправлено письмо.
Вам необходимо просто ввести имя домена или IP адрес, после чего программа выведет полную информацию о домене из базы данных whois. Но не следует исключать возможность получения фиктивной информации. Так как спамеры прекрасно осведомлены о доменных именах и процедуре whois, они наверняка не укажут реальные данные при регистрации имени домена.
Однако нередко эти сведения бывают достоверными, поэтому важно проверить, действительно ли человек, от которого Вы получили спам, является спамером, и действительно ли тот домен, которым Вы интересуетесь, представляет собой домен спамера.
Следующая часть ответа предоставляет нам информацию о владельце домена, оплачивающего и обеспечивающего его работу.
MASTER, HOST hostmaster@CHARTERCOM.COM
Charter Communications Holding Company
817 Charter Commons
Town and Country, MO 63017
US
636 733 5300 fax: 636 394 9797
А это уже кое-что. Так что дерзайте.
Электронная почта: «From» и «mail from». Памятка веб-разработчикам.
В последние годы стали массово появляться web-сервисы с формами обратной связи. При этом, значительное количество web-разработчиков не задумывается о том, как именно работает электронная почта. В основном, внимание уделяется полям сообщения, и совсем не уделяется параметрам smtp-конверта (envelope), а именно, важному параметру «envelope from» (задаётся командой «mail from» в smtp-сессии). Почтовые сервера в своей работе ориентируются именно на smtp-конверт, а не на поля сообщения «From», «To» и «Cc». Классический почтовый клиент формирует «envelope from» из значения поля «From», скрывая различие от пользователя, а вот при написании своего кода это следует учитывать. Например, рассмотрим вариант с PHP. Функция PHP mail() не умеет формировать «envelope from», по-этому, при её использовании по-умолчанию, «envelope from» формируется почтовым агентом сервера из имени хоста и имени пользователя, из-под которого работает web-сервер. Как правило, это получается несуществующий E-Mail на несуществующем почтовом сервере.
Правила передачи электронной почты подразумевают, что сообщение не должно быть потеряно бесследно. Сообщение либо должно быть доставлено получателю, либо отправителю формируется так называемое bounce-сообщение с уведомлением о недоставке и причинах. Это сообщение формируется с использованием того, что содержится в «envelope from», а, отнюдь, не в «From» самого письма. Если «envelope from» содержит мусор, по которому невозможно доставить сообщение (сервер не отвечает), то это сообщение остаётся в спуле сервера, сформировавшего сообщение, на интервал времени (несколько суток), который предусмотрен в RFC 5321 /1123 (раздел 4.5.4.1. Sending Strategy ). Достаточно большое количество таких сообщений в спуле может привести к проблемам в работе почтового сервера. Несмотря на то, что предпочтительной настройкой почтовых серверов сейчас является принятие решения на этапе SMTP-сессии (когда формирование bounce перекладывается на сервер отправителя), существуют ситуации, когда сообщение приходится сначала принимать, а уже потом проверять возможность доставки. Почтовый сервер может быть защищён от этого проверкой smtp callback (кроме того, это ещё и один из вариантов защиты от спама). В этой ситуации сообщение с веб-формы не будет доставлено получателю, а отправитель ничего не узнает, так как и его собственный сервер не отошлёт уведомление. Вероятно, это сообщение может увидеть администратор web-сервера, но это только в том случае, если он проверяет почту локальных пользователей, чего, как правило, на площадках web-хостинга никто не делает. В случае PHP mail() следует использовать пятый (необязательный) параметр, который передаётся, как есть, в bin/sendmail, где следует задать envelope from способом, который поддерживает ПО сервера. Как правило, это «-f e-mail». При написании кода сайта на других языках следует учитывать написанное аналогичным образом.
Проблему усугубляет то, что недостатком квалифицированных кадров в этой области сейчас страдают даже очень крупные компании.
Попавшийся образец мнения (домены и название хостинг-провайдера изменены):
quicktask@ example.com Данный адрес, отлично работает на почтовых клиентах, mail.ru yandex.ru, Gmail а также с моим доменом example.com если поставить адреса данных провайдеров, ВСЕ РАБОТАЕТ НА УРА, В ТАКИХ КРУПНЫХ КОМПАНИЯХ, КАК ЯНДЕКС ГУГЛ и вы сообщаете что у хостинг провайдера ABCD проблема.
Загадки и мифы SPF
SPF (Sender Policy Framework), полное название можно перевести как «Основы политики отправителя для авторизации использования домена в Email» — протокол, посредством которого домен электронной почты может указать, какие хосты Интернет авторизованы использовать этот домен в командах SMTP HELO и MAIL FROM. Публикация политики SPF не требует никакого дополнительного софта и поэтому чрезвычайно проста: достаточно добавить в зону DNS запись типа TXT, содержащую политику, пример записи есть в конце статьи. Для работы с SPF есть многочисленные мануалы и даже онлайн-конструкторы.
Первая версия стандарта SPF принята более 10 лет назад. За это время были созданы многочисленные реализации, выработаны практики применения и появилась свежая версия стандарта. Но самое удивительное, что почему-то именно SPF, более чем любой другой стандарт, оброс за 10 лет невероятным количеством мифов и заблуждений, которые кочуют из статьи в статью и с завидной регулярностью выскакивают в обсуждениях и ответах на вопросы на форумах. А протокол, казалось бы, такой простой: внедрение занимает всего пару минут. Давайте попробуем вспомнить и разобрать наиболее частые заблуждения.
TL;DR — рекомендации в конце.
1. Заблуждение: SPF защищает мой домен от подделок
На самом деле: SPF никак не защищает видимый пользователю адрес отправителя.
Объяснение: SPF вообще не работает с содержимым письма, которое видит пользователь, в частности с адресом отправителя. SPF авторизует и проверяет адреса на уровне почтового транспорта (SMTP) между двумя MTA (envelope-from, RFC5321.MailFrom aka Return-Path). Эти адреса не видны пользователю и могут отличаться от видимых пользователю адресов из заголовка From письма (RFC5322.From). Таким образом, письмо с поддельным отправителем во From запросто может пройти SPF-авторизацию.
2. Заблуждение: Я внедрю SPF и станет безопасней и меньше спама
На самом деле: скорей всего, изменений в плане безопасности и спама вы не заметите.
Объяснение: SPF изначально альтруистический протокол и сам по себе не дает преимуществ тому, кто публикует SPF-политику. Теоретически, внедрение вами SPF могло бы защитить кого-то другого от поддельных писем с вашего домена. Но на практике даже это не так, потому что результаты SPF редко используются напрямую (об этом ниже). Боле того, даже если бы все домены публиковали SPF, а все получатели запрещали получение писем без SPF-авторизации, это вряд ли привело бы к снижению уровня спама.
SPF не защищает от подделки отправителя или спама напрямую, тем не менее, он активно используется и весьма полезен и в системах спам-фильтрации и для защиты от поддельных писем, т.к. позволяет привязать письмо к определенному домену и его репутации.
3. Заблуждение: SPF отрицательно (положительно) влияет на доставляемость писем
На самом деле: Всё зависит от типа письма и пути, по которому оно доставляется.
Объяснение: SPF сам по себе не влияет на доставляемость писем обычным потоком, и отрицательно влияет при неправильном внедрении или на непрямых потоках писем (indirect flow), когда пользователь получает письма не от того сервера, с которого письмо было отправлено, например на перенаправленные письма. Но системы спам-фильтрации и репутационные классификаторы учитывают наличие SPF, что в целом, на основном потоке писем, дает положительный результат. Если, конечно, вы не рассылаете спам.
4. Заблуждение: SPF авторизует отправителя письма
На самом деле: SPF авторизует почтовый сервер, отправляющий письмо от имени домена.
Объяснение: Во-первых, SPF работает только на уровне доменов, а не для отдельных адресов электронной почты. Во-вторых, даже если вы являетесь легальным пользователем почты определенного домена, SPF не позволяет вам отправить письмо из любого места. Чтобы письмо прошло SPF-валидацию, вы должны отправлять только через авторизованный сервер. В-третьих, если вы авторизовали сервер по SPF (например, разрешили отправку писем от вашего домена через какого-либо ESP или хостинг-провайдера) и он не реализует дополнительных ограничений, то все пользователи данного сервера могут рассылать письма от имени вашего домена. Всё это следует учитывать при внедрении SPF и аутентификации писем в целом.
5. Заблуждение: письма, не прошедшие авторизацию SPF, отсеиваются
На самом деле: SPF-авторизация или ее отсутствие в общем случае не влияет кардинально на доставку писем.
Факт наличия SPF-авторизации важен не столько для доставки письма и принятия решения о том, является ли оно спамом, сколько для подтверждения адреса отправителя и связи с доменом, что позволяет для письма использовать не репутацию IP, а репутацию домена.
На принятие решения о действии над письмом, не прошедшим авторизацию, гораздо больше влияет политика DMARC. Политика DMARC позволяет отбросить (или поместить в карантин) все письма, не прошедшие авторизацию или их процент.
7. Заблуждение: достаточно прописать SPF только для доменов, с которых отправляется почта
На самом деле: необходимо также прописать SPF для доменов, используемых в HELO почтовых серверов, и желательно прописать блокирующую политику для неиспользуемых для отправки почты A-записей и вайлдкарда.
Объяснение: в некоторых случаях, в частности, при доставке NDR (сообщение о невозможности доставки), DSN (сообщение подтверждения доставки) и некоторых автоответах, адрес отправителя в SMTP-конверте (envelope-from) является пустым. В таком случае SPF проверяет имя хоста из команды HELO/EHLO. Необходимо проверить, какое имя используется в данной команде (например, заглянув в конфигурацию сервера или отправив письмо на публичный сервер и посмотрев заголовки) и прописать для него SPF.
Спамерам совершенно не обязательно слать спам с тех же доменов, с которых вы отправляете письма, они могут отправлять от имени любого хоста, имеющего A- или MX-запись. Поэтому, если вы публикуете SPF из альтруистических соображений, то надо добавлять SPF для всех таких записей, и желательно еще wildcard (*) для несуществующих записей.
8. Заблуждение: лучше добавлять в DNS запись специального типа SPF, а не TXT
На самом деле: надо добавлять запись типа TXT.
Объяснение: в текущей версии стандарта SPF (RFC 7208) записи типа SPF являются deprecated и не должны больше использоваться.
9. Заблуждение: чем больше всего (a, mx, ptr, include) я включу в SPF-запись, тем лучше, потому что меньше вероятность ошибиться
10. Заблуждение: TTL для SPF-записи следует сделать поменьше (побольше)
На самом деле: как и для большинства DNS-записей, лучше иметь TTL в диапазоне от 1 часа до 1 суток, заблаговременно снижая его при внедрении или планируемых изменениях и повышая при стабильно работающей политике.
Объяснение: более высокий TTL снижает вероятность ошибок DNS и, как следствие, temperror SPF, но повышает время реакции при необходимости внесения изменений в SPF-запись.
11. Заблуждение: если я не знаю, с каких IP могут уходить мои письма, то лучше опубликовать политику с +all
На самом деле: политика с явным +all или неявным правилом, разрешающим рассылку от имени домена с любых IP-адресов, негативно скажется на доставке почты.
Объяснение: такая политика не несет смысловой нагрузки и часто используется спамерами, чтобы обеспечить SPF-аутентификацию на спам-письмах, рассылаемых через ботнеты. Поэтому домен, публикующий подобную политику, имеет очень большие шансы попасть под блокировку.
12. Заблуждение: SPF бесполезен
На самом деле: SPF необходим.
Объяснение: SPF — это один из механизмов авторизации отправителя в электронной почте и способ идентификации домена в репутационных системах. В настоящее время крупные провайдеры почтовых сервисов постепенно начинают требовать наличие авторизации писем, и на письма, не имеющие авторизации, могут накладываться «штрафные санкции» по их доставке или отображению пользователю. Кроме того, на письма, не прошедшие SPF-авторизации, могут не возвращаться автоответы и отчеты о доставке или невозможности доставки. Причина в том, что эти категории ответов, как правило, идут именно на адрес SMTP-конверта и требуют, чтобы он был авторизован. Поэтому SPF необходим даже в том случае, если все письма авторизованы DKIM. Также SPF совершенно необходим в IPv6-сетях и облачных сервисах: в таких сетях практически невозможно использовать репутацию IP-адреса и письма с адресов, не авторизованных SPF, как правило, не принимаются. Одна из основных задач SPF, определенная в стандарте — как раз использование репутации доменного имени вместо репутации IP.
13. Заблуждение: SPF самодостаточен
На самом деле: необходимы также DKIM и DMARC.
Объяснение: DKIM необходим для прохождения писем через различные пересылки. DMARC необходим для защиты адреса отправителя от подделок. Кроме того, DMARC позволяет получать отчеты о нарушениях политики SPF.
14. Заблуждение: если сервер пересылает письма, необходимо использовать SRS (Sender Rewriting Schema) для сохранения SPF-авторизации.
На самом деле: SRS следует использовать только в том случае, если вы хотите дать перенаправляемым письмам авторизацию (и, как следствие, репутацию) своего домена.
Объяснение: SRS перезаписывает адрес конверта отправителя на адрес из домена перенаправляющего сервера, таким образом, для письма проходит SPF-авторизация с доменом осуществляющим перенаправление. Однако, домен отправителя RFC5322.From у такого письма не будет совпадать с доменом конверта, для которого проходит SPF-авторизация. С точки зрения DMARC такая авторизация не рассматривается как валидная. Кроме того, перенаправляемое письмо получает авторизацию домена, если бывают ситуации в которых перенаправляются спам-письма (например, переправляется общий поток писем в котором даже при наличии хорошей спам-фильтрации присутствует некоторая доля спама) — это негативно затрагивает репутацию перенаправляющего домена и наоборот, распространяет репутацию домена на спам-письма. SRS имеет смысл использовать там, где входящие письма проходят дополнительную авторзацию и спам-фильтрацию, например в списках рассылки с ограничением по отправителям, возможно в сочетании с опцией From rewrite для сохранения DMARC-аутентификации. Во всех остальных случаях, лучше уделить внимание тому, чтобы пересылки сохраняли целостность DKIM-сигнатуры.
15. Заблуждение: spf1 хорошо, spf2.0 — лучше
Объяснение: spf2.0 не существует. Публикация записи spf2.0 может приводить к непредсказуемым результатам. spf2.0 никогда не существовал и не был стандартом, но отсылка на него есть в серии экспериментальных стандартов, самым известным из которых является RFC 4406 (Sender ID). Эта серия стандартов разрабатывалась независимой рабочей группой, параллельно с принятием стандарта spf, что и внесло путаницу. Sender ID, который должен был решить проблему подмены адресов, не стал общепринятым стандартом и от него следует отказаться в пользу DMARC. Даже в том случае, если вы решаете использовать Sender ID и опубликовать spf2.0 запись, она не заменит записи spf1.
Я практически закончил писать эту статью, когда меня перехватила служба поддержки пользователей и настоятельно (с угрозой применения грубой силы) рекомендовала напомнить о следующих нюансах SPF, с которыми им чаще всего приходится сталкиваться при разрешении проблем:
Технические рекомендации к почтовым рассылкам
«Даже если вы получите какое-нибудь письмо, вы не сможете его прочитать»
(Марк Твен)
Мы уже писали о том, как правильно делать рассылки, улучшать их качество и эффективность. Приводили метрики, на основе которых строится репутация отправителя. Рассказывали об интерфейсе Постмастер Mail.Ru, с помощью которого их можно отслеживать. Многие компании, как находящиеся в начале своего развития, так и довольно крупные, пренебрегают этими правилами, в результате чего начинаются проблемы с доставляемостью писем, разбирательства со службой техподдержки и т.п. Но мы надеемся что вы не принадлежите к их числу.
Итак, ваш проект набирает популярность и нравится пользователям, вы собираетесь оставаться с ними на связи. Вы ознакомились с административными требованиями (о которых мы писали ранее) и собираетесь ответственно и без спама организовать рассылку для тех пользователей, которые готовы ее получать. А может быть, вы просто собираетесь настроить корпоративную почту. Поднимаете из дистрибутива почтовый сервер, пишете скрипт, запускаете и… 70% получателей письмо не доставлено, у 15% оно попало в папку «Спам», а остальные не могут прочитать то, что в нем написано. О том, что делать, чтобы этого не случилось, я попробую рассказать в этой статье.
Почему же все может не работать «из коробки» и требуются какие-то дополнительные рекомендации? Электронная почта — один из старейших протоколов интернета, который дожил до наших дней практически без изменений, но оброс огромным количеством сопутствующих стандартов и нигде не задокументированных практик применения. В самих стандартах электронной почты не заложено каких-либо методов аутентификации отправителя или предотвращения нежелательных рассылок и спама. Поэтому любой почтовый сервер выполняет ряд дополнительных проверок, чтобы отсеять нежелательную корреспонденцию (которой может быть более 90%).
Мы собрали список советов, которые помогут пройти эти дополнительные проверки. Многие из рекомендаций, перечисленных ниже, не являются обязательными, но чем больше из них вы выполните, тем выше вероятность, что проблем с доставкой писем возникать не будет.
Рекомендации для администратора почтового сервера:
Начинаем с… IP-адреса. От провайдера, хостера или регистратора вы получили IP-адрес (или целую сеть). Что нужно сделать, чтобы использовать выбранный адрес для почтового сервера, и годится ли он?
1. Убедитесь, что адрес реальный и статический.
Большая часть почтовых серверов ограничивает прием почты с динамических адресов или из сетей с трансляцией адресов. Причина в том, что в таких сетях находятся компьютеры конечных пользователей, которые не выполняют доставку почты. Соответственно, почти вся почта, которая идет из этих сетей, является спамом, отправленным через ботов. Поэтому репутация этих сетей безнадежно испорчена.
2. Проверьте whois-информацию с помощью утилиты whois или онлайновых сервисов (легко находятся поиском). Приведу список того, на что нужно обратить внимание:
2.1 У сети должно быть корректное описание. Если в описании будет информация о том, что она динамическая или предназначена для раздачи конечным индивидуальным пользователям (например, сети ADSL), скорее всего, вы также столкнетесь с множеством проблем при попытке ее использовать.
2.2 Для сети должны быть указаны abuse-контакты для жалоб, и эти контакты должны быть живыми и реагирующими. Иначе сеть (а вместе с ней и ваш IP) имеет большие шансы «влететь» в черные списки при наличии спам-инцидентов с любого из ее хостов.
2.3 Если сеть европейская (регистратор RIPE), статус сети должен быть ASSIGNED, ASSIGNED PA или ASSIGNED PI — это означает, что данная сеть используется. Многие регистраторы забывают пометить сеть как используемую, а некоторые получатели запрещают прием почты из неиспользуемых сетей.
Требуйте от регистратора внести корректную информацию в описание сети, но помните, что многие потенциальные получатели уже «помнят» старую информацию. Поэтому лучше изначально использовать IP-адреса из добросовестно администрируемых сетей с хорошей репутацией.
3. Проверьте и настройте PTR-запись для IP-адреса. PTR-запись должна указывать на реальное имя хоста. Желательно, чтобы
3.1 Это имя не напоминало имя динамического хоста, то есть не содержало слов dynamic, adsl, nat, длинных последовательностей символов или групп цифр. Например, server.example.com – хорошая, годная PTR-запись.
3.2 Если планируется действительно большой объем исходящей почты с нескольких серверов, то желательно давать наименования серверам в соответствии с черновым стандартом «DNS Naming Convention for Outbound Internet Email Servers» и создать предусмотренные этим документом зону и A-запись mxout.
3.3 Имя PTR-записи должно разрешаться обратно в тот же самый IP адрес, то есть A или CNAME запись server.example.com должна существовать и разрешаться в IP адрес сервера из примера.
Если сервер будет поддерживать несколько доменов, нет необходимости делать PTR-записи в каждый домен — вполне достаточно одной записи на любой из доменов. При проверке DNS лучше пользоваться сторонним DNS-сервером, чтобы убедиться, что записи действительно видны снаружи.
Управлением PTR-записями занимается оператор IP-сети, например, интернет- или хостинг-провайдер. Обычно это можно сделать самостоятельно через панель управления хостингом или службу поддержки провайдера.
4. Настройте MX-записи для домена, с которого будет производиться рассылка. Даже в том случае, если вы не планируете принимать какие-либо письма для этого домена. Как минимум вы должны корректно принимать и обрабатывать сообщения о невозможности доставки ваших писем и адрес postmaster@. Использование в адресе отправителя или в SMTP-конверте доменов без MX-записей негативно влияет на доставляемость писем. Некоторые получатели валидируют адреса отправителей из SMTP-конверта, поэтому желательно, чтобы сервер не давал ошибок при отправке письма на такой адрес.
5. Настройте SPF-запись. SPF позволяет указать, каким серверам разрешено отправлять почту от имени домена. SPF настраивается для адреса используемого в envelope-from (SMTP конверте).
6. Настройте DKIM:
6.1 Сгенерируйте ключевую пару DKIM и опубликуйте публичный ключ;
6.2 Не забудьте настроить подпись DKIM для всех исходящих писем (об этом чуть позже).
DKIM позволяет подписывать письма, которые отправляются от имени определенного домена. В настоящее время DKIM — это уже технология must have, она является технической основой для других — FBL, DMARC, а также для таких сервисов, как Постмастер Mail.Ru.
7. Опубликуйте политику DMARC. DMARC указывает, как именно следует использовать SPF и DKIM, и позволяет полностью исключить фишинг от имени домена с помощью публикации ограничивающей политики. А еще он дает возможность получать в виде структурированных отчетов все сведения о попытках нарушения вашей политики.
DMARC еще не принят как официальный стандарт, но уже поддерживается основными игроками на рынке электронной почты – Mail.Ru, Google, Yahoo и Microsoft. Это очень простое к внедрению и при этом крайне эффективное решение.
Вот теперь можно попытаться поднять почтовый сервер.
8. В настройках Mail Transfer Agent (почтового сервера) сконфигурируйте hostname сервера, который передается в команде HELO. Это имя должно совпадать с каноническим именем сервера из PTR-записи (server.example.com). Очень часто по умолчанию в HELO используются имена типа localhost.localdomain, и многие почтовые сервера отказываются принимать почту при таком HELO. Настройте SPF-запись для имени из HELO, это требование RFC 7208 которое позволит доставлять служебные письма с пустым адресом SMTP-конверта.
9. Включите поддержку DKIM в вашем почтовом сервере. В некоторых серверах поддержка встроена, в некоторых может быть реализована с помощью бесплатных программ (например, OpenDKIM), для Microsoft Exchange / IIS SMTP есть недорогие и бесплатные плагины. При настройке не спутайте DKIM (RFC 4871 / RFC 6376) и DomainKey (RFC 4870). DomainKey — устаревший стандарт, который так и не был принят. Делать его поддержку необязательно. DKIM можно узнать по наличию подписи DKIM-Signature в заголовках письма. Для подписи заголовков и тела письма лучше использовать relaxed режим.
10. Настройте ящик postmaster.
11. Избегайте конфигураций, приводящих к несанкционированному релеингу писем, иначе вся работа пойдет насмарку вместе с репутацией сервера.
12. Протестируйте конфигурацию вашего сервера, отправив письма на основные почтовые сервисы через стандартный почтовый клиент, например, Thunderbird. Проверьте заголовки полученных писем. Убедитесь в:
12.1 правильности HELO;
12.2 наличии и прохождении SPF-, DKIM- и DMARC-проверок на серверах, поддерживающих DMARC;
12.3 невозможности несанкционированного релеинга через ваш сервер;
12.4 том, что на postmaster@ и на адреса для отчетов DMARC и FBL доходят письма
12.5 сервером корректно формируются отчеты о невозможности доставки писем.
13. Подпишитесь на FBL (FeedBack Loop). FBL предоставляются многими крупными почтовыми сервисами. Подписка даст вам возможность получать сведения обо всех жалобах на спам на почту с вашего домена.
Теперь можно настраивать рассылки / писать скрипты для отправки писем. Приступаем.
14. Обрабатывайте сообщения о невозможности доставки писем. Помните, что есть два способа получения ошибки: в SMTP-сессии (в таком случае сообщение о невозможности доставки может формировать ваш сервер) или письмом с отчетом о невозможности доставки (NDR) от сервера получателя. Обрабатывать надо оба случая. При этом обязательно следует реагировать и исключать пользователя из рассылок при повторяющихся или постоянных (permanent) ошибках доставки на его адрес. Наличие большого количества невалидных получателей может приводить к снижению репутации и/или срабатыванию грейлистинга.
15. Устанавливайте адрес SMTP MAIL FROM: (envelope sender) – адрес отправителя, который используется на уровне протокола SMTP. Он может не совпадать с адресом отправителя из заголовка письма From:. Для нормальной работы DMARC желательно, чтобы адрес From: и адрес envelope sender были из одного домена. И, разумеется, письмо должно иметь валидную DKIM-подпись для этого домена и проходить проверки SPF. Некорректный адрес отправителя в конверте (envelope) – наиболее частая и серьезна ошибка в рассылках с различных веб-сайтов.
16. Не следует использовать в адресах From: и MAIL FROM адреса публичных почт, поскольку подобные рассылки не пройдут аутентификации SPF/DKIM в рамках DMARC. Используйте адреса вашего собственного домена.
17. В заголовках Content-Type для всех текстовых частей письма указывайте корректные кодировки. Убедитесь, что реальная кодировка текста совпадает с указанной в заголовке. Желательно использовать одну кодировку во всех заголовках и частях письма. В настоящее время рекомендуемой, наиболее широко поддерживаемой кодировкой текста является UTF-8. Если кодировка не указана (или указана неверно), текст может по-разному отображаться различными сервисами и почтовыми программами.
18. Формируйте заголовки From:, Message-ID: и Date: непосредственно в скрипте отправки письма. Убедитесь, что эти заголовки, особенно Date:, формируются в правильном формате. По стандартам эти заголовки формируются вместе с текстом письма. Если они отсутствуют или сформированы некорректно, заголовки может добавить один из транзитных серверов, что может привести к нарушению целостности DKIM-сигнатуры.
19. Убедитесь что во всех служебных и других заголовках, включая тему письма (Subject), имена вложенных файлов (Content-Type и Content-Disposition), символы, отличные от ASCII, в частности кириллица, закодированы в quoted-printable или base64. Согласно стандартам, в заголовках писем не могут встречаться некодированные восьмибитные символы; некоторые серверы не принимают такие письма. Если вы ориентируетесь на зарубежных подписчиков, то желательно чтобы письмо вообще не содержало не кодированных 8-битных символов.
20. Ограничивайте длину строки и используйте корректные терминаторы строк.
20.1 Максимальная допустимая длина строки в электронной почте — 998 8-битных символов. При использовании UTF-8 один отображаемый символ может занимать несколько октетов, поэтому старайтесь делать текст в строках короче или кодируйте текст в base64.
20.2 Корректным терминатором строк в электронной почте является CRLF (символы с кодами 13 и 10). В Unix стандартным терминатором строки является LF. Если используемый скрипт или MTA не заменяет терминаторы строк, это может приводить к проблемам — некорректному отображению письма или отрезанию части текста. Ошибки может вызвать и двойная замена терминаторов. Уточните в документации или протестируйте, следует ли в используемой вами конфигурации производить перекодировку концов строк.
20.3 Терминаторы строк не должны разбивать UTF-8 символы, чтобы не возникала ситуация, в которой терминатор в длинную строку добавляется, например, между двумя октетами одного кириллического символа. Поэтому разбивка текста должна производиться до формирования письма.
Кодирование текстовых частей в base64 увеличивает размер письма примерно на треть, но зато спасает от всех проблем, связанных с терминаторами строк в текстовых частях.
21. Старайтесь придерживаться достаточно простой структуры письма, избегайте глубокого нестирования составных (multipart) частей (то есть включения одной составной части в другую). Если в письме встречается более одной multipart-частей каждого типа (одной multipart/mixed одной multipart/alternative и одной multipart/related), скорее всего, письмо сформировано неоптимально.
22. Корректно проставляйте Content-Disposition каждой части как attachment (вложение, показываемое отдельно от письма) или inline (объект, отображаемый как часть письма, — например, картинка в тексте). Часто случается, что вложенный в письмо документ помечен как inline, хотя предназначен для скачивания пользователем, или логотип в тексте письма помечен как attachment, хотя он не должен быть виден в списке вложенных файлов.
23. Формируйте текстовую (plaintext) часть письма как альтернативную к HTML-части. Не забывайте, что пользователь может читать письмо, например, с сотового телефона. Корректно и красиво преобразовать HTML-содержимое в текст не всегда возможно. Добавив текстовую часть к письму, вы сможете быть уверены, что текст будет показан именно так, как вы этого ожидаете.
24. Протестируйте работу вашего скрипта на тестовых ящиках с разных сервисов электронной почты. Не забудьте скачать оригинал пришедшего в ящик письма и проверить:
24.1 корректность envelope sender;
24.2 прохождение SPF-, DKIM- и DMARC-проверок;
24.3 наличие и соответствие действительности кодировок текста в заголовках Content-Type для всех текстовых частей (включая HTML);
24.4 в HTML-частях – соответствие действительности кодировок, указанных в тегах meta (при их наличии);
24.5 отображение различных символов, включая кириллицу в текстовой, HTML-части и именах файлов (если планируется рассылать файлы);
24.6 наличие правильного Content-Disposition и Content-Transfer-Encoding для каждой части письма (кроме multipart);
24.7 отображение картинок и вложений;
24.8 корректность терминаторов строк;
24.9 корректное разбиение на строки и отображение длинных текстов в HTML и plain text частях;
24.10 Убедитесь, что заголовки From: Date: и Message-ID сформированы именно вашим сервером, подписаны DKIM-подписью и валидны.
Теперь можно переходить к верстке писем. Рекомендации для верстальщика:
25. Будьте проще. Не забывайте, что веб-почты вынуждены фильтровать часть тегов и атрибутов с целью обеспечения безопасности, и все они делают это по-разному. Избегайте использования классов, минимизируйте использование стилей, особенно для позиционирования. Старая добрая верстка на таблицах является наиболее переносимой.
26. Не пытайтесь верстать под веб-интерфейс определенного почтового сервера. Пользователи часто настраивают перенаправление, сборщики почты или читают письма в почтовых программах.
27. Думайте о пользователе. Он может открыть ваше письмо как на огромном ретина-дисплее, так и на старом телефоне на вершине Эвереста, пытаясь ухватить GPRS-соединение. Соответственно, письмо должно грузиться быстро, но выглядеть красиво даже при отключенных картинках.
28. Никаких надписей мелким шрифтом. Они нервируют и заставляют относиться к вам с подозрением. Не стесняйтесь показать пользователю, что вы знаете и уважаете его права и свои обязанности.
29. Выбирайте наиболее подходящий способ внедрения картинок. Есть следующие варианты, каждый со своими плюсами и минусами:
29.1 Внешние картинки: с точки зрения скорости отправки этот вариант – наиболее предпочтительный. Внешние картинки ничего не весят и не усложняют структуру письма. Однако многие приложения и почтовые сервисы требуют от пользователя разрешения на показ таких картинок. Кроме того, сервер, на котором они расположены, должен быть достаточно надежным, чтобы при открытии письма не приводить к «подвисаниям» из-за недоступности картинки. Используйте их, когда наличие картинок является опциональным.
29.2 Inline-картинки. Отправляются вместе с содержимым письма. Усложняют структуру письма и увеличивают его вес, зато могут быть достаточно большими и обычно отображаются по умолчанию.
29.3 Data URI. Содержимое картинки вставляется непосредственно в тег. Не усложняют структуры письма, почти всегда показываются в веб-почтах, иногда даже при отключенных картинках. Как правило, имеют ограничение на размер, годятся для небольших иконок.
29.4 Шрифтовые картинки. Изображения Unicode-символов из стандартных шрифтов или с помощью внедренных кастомных шрифтов. Уникальное свойство — могут масштабироваться вместе с текстом. Практически ничего не весят. Могут отображаться некорректно, в зависимости от версий операционной системы и установленных обновлений, устройства, почтовой программы или сервиса.
30. Во всех URI обязательно указывайте протокол (http://, https:// или mailto:), использование URI без протокола, например «//example.com/» недопустимо и может приводить к подвисанию письма в некоторых почтовых приложениях из-за попыток обратиться в сеть, использование протоколов отличных от перечисленных не рекомендуется, т.к. может быть зарезано фильтрами.
31. Тестируйте отображение каждой новой верстки письма на различных устройствах в разных веб почтах перед отправкой его «живым» пользователям.
Что делать, если, несмотря на соблюдение всех рекомендаций, письма все-таки не доходят до пользователей? Обращайтесь в службы поддержки получателей писем — как правило, подобные проблемы решаются оперативно. О проблемах доставки на адреса, обслуживаемые серверами Mail.Ru, можно писать на abuse@corp.mail.ru. Не забывайте как можно полнее описать проблему – очень помогут сообщения об ошибках, тексты сообщений о невозможности доставки, журналы серверов и прочая техническая информация.
К сожалению, формат статьи не позволяет детально расписать каждую из рекомендаций или дать подробные инструкции по настройке, но если у вас есть технические вопросы – с удовольствием на них отвечу в комментариях.