Как делать email-рассылки и не косячить
  • Раздел: Полезная информация
У разработчика, который впервые столкнулся с генерированием электронных писем, практически нет шансов написать приложение, которое будет делать это корректно. Около 40 % писем, генерируемых корпоративными приложениями, имеют те или иные нарушения стандартов, и, как следствие, проблемы с доставкой и отображением. На это есть причины: электронная почта технически гораздо сложнее, чем веб, работа почты регулируется несколькими сотнями стандартов и несчетным количеством общепринятых (и не очень) практик, а почтовые клиенты отличаются разнообразием и непредсказуемостью. Тестирование может заметно улучшить ситуацию, но материалов, посвященных тестированию почты, практически нет.

Почта Mail.Ru регулярно взаимодействует со своими пользователями посредством электронных писем. В нашем проекте все компоненты, отвечающие за генерирование писем, и даже единичные рассылки проходят обязательное тестирование. В этой статье мы поделимся своим опытом (и набитыми шишками).

Какие бывают электронные письма

Приложение может генерировать различные виды писем. Их можно классифицировать по нескольким категориям. По способу выбора получателей: триггерные — выборочные — групповые. По назначению: транзакционные — маркетинговые — служебные. К разным типам писем можно предъявлять разные требования и применять разные сценарии тестирования.

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

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

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

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

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

Групповые маркетинговые письма, например, сообщения о сезонных предложениях, акциях и распродажах, часто рассылаются «вручную» и не являются частью вашего приложения, но к ним также можно (и нужно) применять общие принципы тестирования.

Кроме того, могут быть служебные письма, генерируемые для сотрудников, для автоматических или автоматизированных систем CRM, журналирования, аудита или DWH. Такие письма являются триггерными, а это значит, что они также являются частью приложения и должны проходить тестирование.

Кто участвует в процессе тестирования и контроля

  1. QA-инженер — участвует на всех стадиях процесса.
  2. Сетевой инженер — отвечает за конфигурацию сетевой инфраструктуры и инфраструктуры доставки сообщений. Сетевого инженера следует привлекать при планировании тестирования инфраструктуры.
  3. Deliverability-специалист — это человек, следящий за доставляемостью писем, который также участвует в контроле технических и административных параметров всех отправляемых сообщений и следит за ходом процесса рассылки. Он отвечает за то, чтобы отправленные письма дошли до максимально возможного процента пользователей и не попали в спам, а для этого специалист должен обладать определенными знаниями и контактами. При возникновении проблем с доставкой писем именно он должен понять вероятную причину и устранить её: либо устранив технические препятствия; либо что-то поменяв в содержимом писем; либо решив проблему вместе со службой поддержки почтового провайдера, до которого не доходят письма. Такого специалиста (если он есть) также следует привлекать к составлению чеклиста и тестированию инфраструктуры, генерирующего приложения и писем. Однако сам процесс тестирования должен быть под контролем службы QA.
  4. Email-маркетолог — определяет эффективность маркетинговых рассылок. Под его контролем проходят необходимые для маркетинговых рассылок сплит-тестирования на аудитории. Email-маркетолог также контролирует сегментирование пользовательской базы, состав и частоту отправляемых писем, визуальное «представление» письма для пользователя.
Все эти роли не обязательно выполняет отдельно выделенный сотрудник: роль маркетолога может выполнять кто-то из продуктовых менеджеров, а роль deliverability-специалиста — например, сотрудник поддержки или сетевой инженер. А в стартапах с высокой долей вероятности всем этим придется заниматься одному человеку, и им может оказаться специалист по качеству.

Почтовое сообщение и почтовый транспорт

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

Подводная часть айсберга — это сетевая служба, базовым протоколом которой является прикладной протокол SMTP, определяемый RFC 5321. Он отвечает за доставку писем. Для доставки письма формируется так называемый SMTP-конверт, в который включаются адреса отправителя и получателя уровня SMTP. Также за доставку письма отвечают другие сетевые службы, такие как DNS. Основным компонентом сетевой инфраструктуры является Агент Передачи Сообщений (Mail Transfer Agent, или чаще используется аббревиатура MTA). MTA отвечает за работу с очередью доставки сообщений и сам процесс доставки на серверы получателей. Примеры MTA — Postfix, Sendmail, exim, служба Microsoft SMTP.

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

Надводная часть айсберга — это само письмо. Базовая структура письма определяется стандартом RFC 5322. Письмо состоит из служебных заголовков и одной или нескольких частей с данными. В данных может быть текст письма в формате plain text и/или HTML, инлайновые изображения или вложения практически любого типа.

Интерфейс почтовой инфраструктуры и границы тестируемого приложения

У почтовой инфраструктуры, как правило, есть один или несколько интерфейсов, с помощью которых отправляется письмо (попадает в очередь доставки MTA). Например, сервис SMTP Submission, функция mail() в PHP, передача данных во внешнее приложение mail или sendmail, API внутренних или внешних сервисов (к примеру, GetResponse, SendPulse или Amazon SES). Мы будем считать эти интерфейсы частью инфраструктуры. Достаточно часто бывает ситуация, когда приложение A подготавливает данные для письма и список получателей, а затем передает их в приложение B через его API (для маркетинговых массовых рассылок это может производиться вручную через пользовательский интерфейс — UI), а уже приложение B генерирует почтовое сообщение в формате RFC 5322 и каким-либо образом ставит его в очередь доставки MTA. С точки зрения приложения A (и при его тестировании), приложение B будет частью почтовой инфраструктуры. API или UI приложения B будет для приложения A интерфейсом почтовой инфраструктуры. Хотя с точки зрения приложения B ситуация будет иной, и почтовой инфраструктурой для него будут более низкоуровневые сетевые приложения или протоколы.

Определение тестируемых параметров

При тестировании каждого приложения важно выделить все используемые им почтовые инфраструктуры (их может быть несколько), и для каждой инфраструктуры выделить используемые интерфейсы (их тоже может быть несколько для каждой инфраструктуры). Для каждого интерфейса как можно точнее определяется состав и формат передаваемых в него данных, например: текст письма в TEXT/HTML, текст письма в TEXT/PLAIN, тема письма, имя получателя, адрес получателя, имя отправителя, адрес отправителя письма (RFC5321.From), адрес отправителя SMTP-конвера (RFC5322.mailfrom). Далее разрабатывается набор требований для каждого параметра (представления, кодировки, граничные значения и т.д.), определяются методы контроля каждого из параметров (каким способом можно сравнить фактический результат с ожидаемым).

Типичная структура генерирующего приложения

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

Основные элементы приложения, которые необходимо контролировать:

  • код, отвечающий за генерирование заголовков и/или структуры письма, если структура письма генерируется динамически, и/или статический шаблон письма, описывающий его структуру;
  • верстку HTML-части письма (в идеале, это отдельная сущность или часть шаблона/макета письма, но может быть зашита в код приложения);
  • подстановку данных приложения в письмо (или в шаблон письма);
  • интеграцию приложения с инфраструктурой доставки письма, корректность параметров, передаваемых в интерфейс инфраструктуры.

Что и когда тестировать

Хотим мы этого или нет, но айсберг надо тестировать весь. Можно выделить несколько основных компонентов, требующих тестирования:

1. Инфраструктура доставки

Упор в тестировании следует делать на: доставляемость письма; корректность DNS-записей, включая PTR/FCrDNS, MX- и A-записи; параметры SMTP-протокола (HELO, использование TLS); авторизацию письма (SPF/DKIM/DMARC); адреса SMTP-конверта (если они не управляются приложением); корректность обработки входных параметров интерфейса инфраструктуры; отслеживание, учет и обработку не доставленных писем.

Надо тестировать инфраструктуру при начальном внедрении и каждый раз, когда вносятся изменения в саму инфраструктуру (меняется конфигурация MTA, DNS или сети) или интерфейс отправки письма; используется новый домен, сеть или API; существенно меняются характеристики отправляемых писем, такие как их язык, размер или количество. По опыту, инфраструктура имеет склонность меняться без объявления войны, поэтому базовые тесты следует проводить периодически, даже если нет информации о каких-либо изменениях.

К составлению плана и чек-листов тестирования инфраструктуры можно и нужно привлекать сетевого инженера и deliverability-специалиста.

2. Генерирующее приложение

Следует контролировать адреса SMTP-конверта (если они управляются приложением, т.е. передаются в интерфейс — envelope-from, envelope-to), значения служебных заголовков письма (Date, Message-ID, List-Unsubscribe, Auto-Submitted и т.п.), авторизацию письма (DKIM/DMARC), MIME-кодировки (base64, quoted-printable), общую правильность формата письма, например отсутствие не-ASCII символов в заголовках, состав подставляемых данных, корректность срабатывания триггеров, механизмы отписки, механизмы трекинга письма и сбора статистики (postmaster-заголовки, например, Feedback-ID или X-Mailru-Msgtype, а также трекинговые пиксели).

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

3. Структурный и вёрсточный шаблоны письма (могут быть частью генерирующего приложения или разрабатываются отдельно)

Проверяется структура письма (Content-Type, Content-Disposition, вложенность Multipart-частей письма, кодировки текста, строковые параметры), значение целевых и отображаемых заголовков (From, To, Reply-to, Subject), отображение письма в списке писем и при чтении в различных интерфейсах, микроформаты (например, что событие календаря распознается как событие календаря, или авиабилет как авиабилет), брендирование.

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

К составлению чек-листа по тестированию шаблона письма рекомендуется привлечь email-маркетолога и deliverability-специалиста.

Базовые требования при проверке инфраструктуры

IP-адрес, выбранный для почтового сервера, должен быть максимально похож на IP-адрес почтового сервера. Рекомендуется проверить его с помощью утилиты whois. В частности, адрес отправителя не должен принадлежать сети, которая может восприниматься как динамическая; у выбранной сети должны быть действующие контакты, на которые можно отправлять жалобы; сеть обязательно должна быть используемой (иметь статус ASSIGNED в RIPE). IP-адрес должен иметь корректно настроенную PTR-запись. Ее можно настроить самостоятельно через панель управления хостингом, либо с помощью службы поддержки провайдера. PTR-запись должна указывать на реальное имя хоста и при этом быть содержательной, разрешаться обратно в тот же самый IP-адрес (т.н. проверка FCrDNS), не напоминать имя динамического хоста и не включать в себя большую группу цифр или символов. Хороший пример — mailserver.example.com.

У каждого домена, используемого в адресах конверта или заголовках письма, должна быть валидная MX-запись, указывающая на A-запись хоста, который, как минимум, может обрабатывать сообщения о невозможности доставки. Для MX недопустимо напрямую ссылаться на IP-адрес.

Контролируйте прохождение SPF, DKIM, DMARC. SPF позволяет владельцу домена указать в TXT-записи список серверов, имеющих право отправлять email-сообщения с обратными адресами в этом домене. Настраивается она для адреса, используемого в envelope-from (SMTP-конверте), в разделе управления DNS-зонами домена. DKIM обеспечивает проверку авторства сообщения или принадлежности его отправителя определенному домену с помощью технологий цифровой подписи, которая добавляется в само письмо (в его заголовок DKIM-Signature). Обычно DKIM-подпись настраивается на уровне MTA (инфраструктуры). DMARC задает политику проверки приходящей почты в определенном домене и действия над письмами, не проходящими аутентификацию SPF или DKIM. При попытке нарушения этой политики приходит структурированный отчет со сведениями о такой попытке. DMARC, также как и SPF, публикуется в виде TXT-записи в доменной зоне.

Проверьте доставляемость писем до основных почтовых служб — для России Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. В пришедших письмах нужно проконтролировать правильность HELO; наличие и прохождение проверок PTR/FCrDNS, SPF, DKIM и DMARC; валидность заголовков и данных в них, в частности, синхронность часов в датах и правильность временных зон.

Похожие публикации
Ранее вы смотрели