Привет! В нашей команде возникла задача — развернуть почтовый сервер для удобства тестирования. Цель — проверять, как различные сервисы осуществляют рассылку писем клиентам. В этой статье хочу поделиться нашим опытом, каким решением мы воспользовались и почему оно может быть полезно и вам.
Предыстория
Иногда на решение задачи не хватает времени или желания, и на помощь приходит делегирование. Однако с этим нередко возникают проблемы коммуникации. Вроде бы задача простая: развернуть готовое решение, вроде iRedMail, настроить дублирование писем, прописать политики в Postfix или ограничить выход сообщений наружу через iptables. Но на практике всё оказывается сложнее.
Во время проверки конфигурации стало ясно, что устно сформулированная задача была воспринята неоднозначно, и итоговое решение не соответствовало ожиданиям. Параллельно появился проект с похожей задачей, но его реализация оставляла желать лучшего — тестировщикам приходилось вручную выгружать файл, перерабатывать его в подходящий формат и только потом работать с ним. Демонстрация старых конфигураций тоже не добавляла уверенности в успехе — писать подробную инструкцию было откровенно лень.
Как известно, лень — двигатель прогресса. В поиске более удобного решения мы наткнулись на сервис Mailtrap. У него есть как бесплатные, так и платные тарифы, но использовать внешний сервис для даже тестовой рассылки не всегда удобно, особенно если важен постоянный доступ и конфиденциальность.
Требования к решению
Задача: организовать локальный почтовый сервер для целей тестирования.
Желаемый функционал:
Команда должна видеть реальную картину по рассылке
Автоматическая очистка сообщений
Полная изоляция — письма не должны покидать тестовую среду
К дополнительным целям можно отнести:
Простота установки и настройки
Минимизация недопониманий при повторной постановке аналогичных задач
Возможность самостоятельной работы с инструментом со стороны тестировщиков
Результат поиска
Мы начали с Mailhog — он соответствовал большинству требований, но последний его релиз датирован 2020 годом, что вызвало сомнения в поддержке и актуальности. В итоге мы нашли более современный и функциональный инструмент — Mailpit.
Обзор Mailpit
Mailpit — это современный инструмент для перехвата, просмотра и отладки почтовых сообщений, отправляемых приложением. Он выступает как локальный SMTP-сервер и предоставляет удобный веб-интерфейс для работы с письмами. Его ключевые преимущества:
Поддержка локального SMTP с эмуляцией отправки (fake SMTP)
Удобный Web UI с авторизацией (basic auth), поиском и фильтрацией
Система тегирования сообщений и удобный фильтр по ним
Real-time обновление интерфейса и push-уведомления в браузере
REST API для интеграции в автоматические тесты
Интеграция со SpamAssassin
Готовые Docker-образы и поддержка Docker Compose
Поддержка POP3 (по желанию)
SMTP relay, т.е. письма можно пересылать через другой SMTP сервер, включая необязательный список разрешенных получателей (по желанию)
Так выглядит пример docker-compose.yml
services:
mailpit:
image: axllent/mailpit:v1.24.1
container_name: mailpit
restart: unless-stopped
volumes:
- /opt/fakemail-data:/data
ports:
- 8025:8025
- 1025:1025
environment:
MP_MAX_MESSAGES: 5000
MP_DATABASE: /data/mailpit.db
MP_UI_AUTH_FILE: /data/uiauthfile
TZ: Europe/Moscow
MP_SMTP_AUTH_ACCEPT_ANY: 0
MP_SMTP_AUTH_ALLOW_INSECURE: 1
MP_SMTP_AUTH_FILE: /data/smtpauthfile
MP_TAGS_CONFIG: /data/tagfilter
MP_WEBROOT: fakemailПо умолчанию максимальное количество сообщений составляет 500, после этого происходит очистка самых старых писем через регулярные интервалы после достижения этого лимита. По этому если хотите больше 500 писем - задавайте MP_MAX_MESSAGES.
Можно задать логин и пароль как для smtp, так и для web ui через переменные, как через файл, как указано выше (MP_SMTP_AUTH_FILE и MP_UI_AUTH_FILE).
Предусмотрено задание webroot, т.е. когда вам нужно не fakemail.mysite.ru, а mysite.ru/fakemail.
И на что хочу обратить внимание, на тег фильтр, который мы задаем в данном примере через MP_TAGS_CONFIG
filters:
- match: this is a match
tags: Tag 1
- match: addressed:test@example.com
tags: Tag 2
- match: from:from@example.com
tags: Tag 1, Tag 2Мы используем его для фильтрации писем при помощи тегов в Web UI для выявления писем по стендам и т.д.. Как видите, в фильтре можно указать несколько тегов. По конфигурации сервиса более подробно рекомендую заглянуть на страницы документации, с этим инструментом можно эмулировать разные сценарии.
Краткий обзор интерфейса Web UI
Цель этой статьи — не дать подробное описание интерфейса, а лишь поделиться тем, что автору понравилось в первую очередь и что он хотел бы донести до читателя.
Что приятно выделяется, так это кнопка Delete all. С её помощью можно быстро очистить сервер от мусора, особенно если вы придерживаетесь стратегии, когда для каждой среды используется свой Mailpit, а сервис находится на ранней стадии разработки. Эта кнопка будет крайне полезна в таком случае.
Давайте быстро напишем скрипт для отправки обычного текстового сообщения (plain text mail), текст ниже написан на python 3.
import smtplib
from email.mime.text import MIMEText
# Configuration
port = 1025
smtp_server = "127.0.0.1"
login = "der_login"
password = "very_strong_password"
sender_email = "uasyan1@example.com"
receiver_email = "new@example.com"
# Plain text content
text = """\
Hi,
SMTP TEST
"""
message = MIMEText(text, "plain")
message["Subject"] = "Plain text email"
message["From"] = sender_email
message["To"] = receiver_email
with smtplib.SMTP(smtp_server, port) as server:
server.login(login, password)
server.sendmail(sender_email, receiver_email, message.as_string())
print('Sent')
Для обычного plain text сообщения у нас не так много фич. Мы можем посмотреть заголовки, сырое сообщение и у нас есть возможность проверить ссылки. Теги можем добавить свои для дальнейшего рассмотрения этого сообщения командой и уже заданные при помощи заготовленного тег-фильтра.
С HTML сообщением уже появляется и HTML Check (как на скрине) и киллер фича - вы можете увидеть как ваше сообщение откроется на разных устройствах, типа планшет, смартфон. Данные элементы отображены сверху справа, показано на скриншоте ниже.
Далее можем посмотреть на HTML Check
Функция HTML Check в Mailpit позволяет проверить, как ваше HTML-сообщение будет отображаться в различных почтовых клиентах и устройствах. Это особенно полезно, если вы отправляете маркетинговые рассылки или тестируете, как корректно отображаются сложные email-шаблоны.
При использовании этой функции Mailpit анализирует HTML-контент и предоставляет удобный инструмент для просмотра, где можно увидеть, как ваше письмо будет выглядеть на различных устройствах: смартфонах, планшетах, а также на разных операционных системах и почтовых клиентах.
Эта опция позволяет гарантировать, что ваше письмо будет выглядеть так, как задумано, на всех устройствах, что крайне важно для успешных кампаний.
Кроме того, Mailpit предоставляет возможность проверять не только визуальное отображение, но и ссылки внутри сообщения, что помогает избежать возможных ошибок в контенте и ссылках, которые могут нарушить работоспособность письма или его восприятие пользователем.
Итог
Mailpit стал для нас отличным решением задачи локального тестирования email-рассылок. Он прост в развёртывании, удобен для разработчиков и тестировщиков, активно поддерживается и предоставляет весь необходимый функционал для безопасной работы с письмами в изолированной среде.
В результате применения данного решения команде было передано управление конфигурацией группе тестирования. Коллеги получили возможность самостоятельно конфигурировать данный сервис без привлечения третьих лиц и написания тикетов. Фактически мы делегировали управление над данным сервисом нашим коллегам из группы тестирования.
Если вы ищете современный, гибкий и лёгкий в использовании инструмент для тестовой почтовой инфраструктуры — Mailpit точно стоит вашего внимания.
P.S. Я не профессиональный писатель статей, но желание поделиться с сообществом чем-то полезным наконец привело меня к публикации данной статьи. Другие темы, которые я хотел бы осветить, увы, потеряли актуальность, так как инструменты, о которых шла речь, уже не так популярны... Прошу не судить строго. Буду рад обратной связи, чтобы в будущем улучшать свои публикации и создавать более качественный контент.
Спасибо, что уделили время моей статье!