Кто-то пытается заглядывать в почту (image_1) • morikoff.ru

Кто-то пытается заглядывать в почту

⏱ 4 мин. на чтение
от

Представьте: вы отправили важное уведомление. На вашей стороне логи чистые — соединение 220, шифрование STARTTLS успешно, адресат подтверждён. Сервер говорит: «Давай данные». Вы передаёте 4 килобайта текста и… сервер захлопывает дверь перед носом с формулировкой «Сообщение не соответствует нашим требованиям доставки».

Что это было? Оскорбление чувств робота-почтальона? Паранойя спам-фильтра? Или письмо действительно было «не таким»?

Давайте наденем шляпу Шерлока Холмса и пройдём по цепочке улик, оставленных в этом логе mta550.zurumsg.com и mail.abasta.ru. Мы соберём варианты подозрений — от банальной опечатки до хитрых политик панели управления VestaCP.

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

Отправки почты адресату с прочтением третьей стороной / ИИ для morikoff.ru
Отправки почты адресату с прочтением третьей стороной / ИИ для morikoff.ru

Вот лог последнего случая:

2026-04-11 14:51:12
Connection established to 147.45.103.222:25
2026-04-11 14:51:16
220-mail.abasta.ru ESMTP Postcow
220 mail.abasta.ru ESMTP Postcow
2026-04-11 14:51:16
EHLO mta550.zurumsg.com
2026-04-11 14:51:16
250-mail.abasta.ru
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
2026-04-11 14:51:16
STARTTLS
2026-04-11 14:51:16
220 2.0.0 Ready to start TLS
2026-04-11 14:51:16
Connection upgraded with STARTTLS
2026-04-11 14:51:16
EHLO mta550.zurumsg.com
2026-04-11 14:51:16
250-mail.abasta.ru
250-PIPELINING
250-SIZE 104857600
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
2026-04-11 14:51:16
SMTP handshake finished
2026-04-11 14:51:16
MAIL FROM:<notify@morikoff.ru>
2026-04-11 14:51:16
250 2.1.0 Ok
2026-04-11 14:51:16
RCPT TO:<igor@morikoff.ru>
2026-04-11 14:51:16
250 2.1.5 Ok
2026-04-11 14:51:16
DATA
2026-04-11 14:51:16
354 End data with <CR><LF>.<CR><LF>
2026-04-11 14:51:16
<4348 bytes encoded mime message (source size 4345 bytes)>
2026-04-11 14:51:18
554 5.7.1 This message does not meet our delivery requirements

Попробуем проанализировать, фрагмент лога SMTP-сессии (отправка электронной почты). Давайте разберём его пошагово и объясним, что произошло и почему письмо было отклонено.

1. Установка соединения и приветствие

Connection established to 147.45.103.222:25
220-mail.abasta.ru ESMTP Postcow
  • Отправитель (mta550.zurumsg.com) подключился к почтовому серверу получателя mail.abasta.ru по стандартному порту 25.
  • Сервер ответил кодом 220, представившись как Postcow (это почтовый сервер на базе популярной панели управления VestaCP / HestiaCP).

2. EHLO и возможности сервера

EHLO mta550.zurumsg.com
250-mail.abasta.ru
250-STARTTLS
  • Команда EHLO — расширенное приветствие. Сервер в ответе 250 перечислил свои возможности, в частности поддержку шифрования STARTTLS (код 250-STARTTLS).

3. Установка шифрования (TLS)

STARTTLS
220 2.0.0 Ready to start TLS
Connection upgraded with STARTTLS
  • Отправитель запросил переход на зашифрованное соединение.
  • Сервер подтвердил (220). После этого вся дальнейшая передача данных (кому, от кого, текст письма) шла в зашифрованном виде.

4. Повторный EHLO и отправка конверта

EHLO mta550.zurumsg.com
MAIL FROM:<notify@morikoff.ru>
RCPT TO:<igor@morikoff.ru>
DATA
  • После включения шифрования команды EHLO повторяется.
  • MAIL FROM — адрес отправителя (notify@morikoff.ru).
  • RCPT TO — адрес получателя (igor@morikoff.ru). На этом этапе сервер ответил 250 Ok, то есть ящик существует и сервер готов принять данные.
  • DATA — команда начать передачу содержимого письма.

5. Передача данных и ОТКАЗ

354 End data with <CR><LF>.<CR><LF>
<4348 bytes encoded mime message (source size 4345 bytes)>
554 5.7.1 This message does not meet our delivery requirements
  • Сервер ответил 354 — «Давай, присылай письмо».
  • Отправитель передал 4348 байт данных письма.
  • КЛЮЧЕВОЙ МОМЕНТ: Вместо подтверждения приёма (250 OK) сервер разорвал транзакцию с ошибкой 554 5.7.1.

Почему письмо не принято? (554 5.7.1)

Код 5.7.1 означает постоянную ошибку политики доставки (Policy Rejection). Сервер проверил содержимое письма (а не просто факт существования адреса) и счёл его несоответствующим требованиям.

Учитывая, что в логах указан сервер Postcow и домен morikoff.ru, наиболее вероятные причины:

  1. Спам-фильтр на основе содержимого (SpamAssassin / Rspamd): Письмо весит всего 4.3 КБ (это очень мало). Текст в нем мог содержать типичные спам-фразы, сомнительные ссылки или был оценён как фишинг.
  2. Правила для служебного адреса notify@: Администратор сервера abasta.ru (или владелец ящика igor@) мог настроить правило, что письма от notify@morikoff.ru должны быть подписаны определённым образом (DKIM/SPF) или приходить с конкретного IP.
  3. Ошибка кодировки или формата MIME: В логах указано: source size 4345 bytes -> 4348 bytes encoded. Возможно, кодирование прошло некорректно (например, добавлены лишние символы перевода строки, нарушена структура заголовков). Postcow очень чувствителен к правильности структуры письма.

Итог

Сессия завершилась неудачей после отправки данных письма. Отправитель mta550.zurumsg.com не смог доставить это конкретное письмо из-за того, что сервер получателя посчитал его содержимое вредоносным или нарушающим правила почтового домена. Получатель igor@morikoff.ru это письмо не увидит ни во Входящих, ни в Спаме.

Если вы приглядываете за почтовым сервером, типа таких казусов не наблюдаете?

17