MiniSMTP: self-hosted SMTP-relay с HTTP API в Docker

Какую проблему решает MiniSMTP

Подтверждение регистрации, восстановление пароля, счёт, чек или системное уведомление обычно отправляют через SendGrid, Mailgun, Postmark, Amazon SES и похожие сервисы. Для большого продукта это удобный путь, но у небольших и закрытых систем появляются дополнительные ограничения.

MiniSMTP занимает место между этими вариантами: сохраняет контроль self-hosted-решения, но прячет рутинную SMTP-интеграцию за небольшим API.

Что находится внутри

Основой служит docker-mailserver — готовый стек Postfix, Dovecot и DKIM. MiniSMTP добавляет конфигурацию Docker Compose, HTTP API с Bearer-токеном и практический сценарий публикации через Nginx и Let's Encrypt.

1. Backend формирует письмо

   Приложение передаёт получателя, тему и текст в обычном JSON-запросе.

2. Nginx принимает HTTPS

   Reverse proxy завершает TLS и передаёт запрос локальному API.

3. API проверяет токен

   Запрос без корректного Authorization: Bearer не попадает в почтовый контур.

4. SMTP-relay отправляет письмо

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

Для вызывающего приложения весь маршрут выглядит как один стабильный HTTP-контракт. Ему не нужен SDK почтового провайдера и не приходится хранить SMTP-логику в каждом проекте.

Отправка письма одним запросом

curl -X POST https://mail.example.com/send \
  -H "Authorization: Bearer API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "client@example.net",
    "subject": "Подтверждение регистрации",
    "text": "Спасибо! Ваш аккаунт создан."
  }'

Такой интерфейс одинаково просто вызвать из Laravel, Symfony, Node.js, Python, Go или небольшого shell-скрипта. При смене языка приложения почтовая инфраструктура остаётся прежней.

Развёртывание — это только половина задачи

Работающий контейнер ещё не означает, что письма будут попадать во «Входящие». Поэтому документация MiniSMTP охватывает не только docker compose up, но и базовую доставляемость.

Главная сложность собственного SMTP — не отправить письмо, а доказать принимающим серверам, что отправителю можно доверять.

Безопасная схема публикации

HTTP API не должен быть доступен напрямую из интернета: иначе токен и endpoint становятся единственным барьером для злоупотреблений. Базовая схема оставляет сервис на loopback-интерфейсе и публикует только reverse proxy.

Интернет
   │ HTTPS :443
   ▼
Nginx + Let's Encrypt
   │ localhost
   ▼
MiniSMTP API : внутренний порт
   │ SMTP
   ▼
docker-mailserver → сервер получателя

• длинный случайный API-токен хранится в секретах приложения, а не в репозитории;
• наружу открываются только действительно необходимые порты;
• логи и лимиты запросов контролируются на уровне Nginx и приложения;
• доступ к VPS, DNS и резервным копиям рассматривается как часть почтовой безопасности.

Кому подходит такой relay

Где проходит граница решения

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

В минимальной версии нет очереди с повторными попытками, автоматической обработки bounce/complaint и unsubscribe-комплаенса для маркетинговых сообщений. Если эти функции обязательны, их нужно добавить вокруг relay или выбрать специализированного провайдера.

Что получилось в итоге

MiniSMTP превращает сложную, но типовую инфраструктурную задачу в воспроизводимую конфигурацию. Приложение отправляет JSON по HTTPS, API проверяет токен, а почтовый стек отвечает за SMTP и DKIM. Команда при этом сохраняет контроль над сервером, доменом и данными.

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