Короче, бро, суть в том, что SMTP Smuggling — это не баг одного сервера, а рассинхрон в интерпретации команд между разными MTA, который позволяет протащить поддельное письмо через всю цепочку аутентификации так, что оно придёт как «проверено и легитимно».

Что вообще за зверь

SMTP smuggling эксплуатирует разночтения в том, как разные почтовые серверы и security-гейтвеи парсят конец сообщения — последовательность <CR><LF>.<CR><LF>. Один сервер видит это как границу письма, другой — как часть тела, и в этот «слепой» промежуток можно впихнуть вторую, полностью отдельную SMTP-команду, которая для получателя выглядит как новое письмо с любым MAIL FROM. Итог: атакующий шлёт одно «обёрточное» письмо через легитимный релей (например, через инфраструктуру крупного провайдера с валидным SPF/DKIM), а внутри протаскивает второе, которое ресолвится с чужим доменом отправителя.

Исследователи из USENIX Security и Microsoft показали, что 19 публичных email-сервисов, 1577 приватных сервисов, пять open-source почтовых движков и один gateway были уязвимы к этой технике или её вариациям. Централизация почтовой инфраструктуры (общие SPF-записи, одинаковый софт у тысяч доменов) только усиливает масштаб проблемы — одна дырявая реализация SMTP-парсера ломает защиту сразу для целого пула клиентов провайдера.

Почему SPF, DKIM, DMARC не спасают

Вся эта троица — SPF, DKIM, DMARC — работает на уровне DNS-записей и заголовков, а не на уровне транспортного протокола, поэтому у неё есть общие структурные слабости.

Механизм	Что проверяет	Где дыра
SPF	IP отправителя vs список разрешённых в DNS	Проверяет envelope-from (MAIL FROM), а не видимый юзеру заголовок From — можно подделать «From», оставив SPF валидным для другого адреса
DKIM	Криптографическая подпись письма	Подпись живёт в заголовке, но smuggling позволяет «приклеить» второе тело письма после легитимно подписанного — подпись первого письма не защищает контент второго
DMARC	Alignment между SPF/DKIM и заголовком From	DMARC доверяет результатам SPF и DKIM — если их обманули на уровне транспорта, DMARC просто ретранслирует ложный «pass»

Ключевой момент: DMARC проверяет соответствие домена в заголовке From результатам SPF и/или DKIM, но если сам SMTP-парсинг рассинхронен, до DMARC долетает уже «правильно» сформированное поддельное письмо, которое формально проходит alignment.

Техническая механика атаки

Атака строится на трёх классических вариантах «контрабанды конца данных»:

• CR без LF — сервер А считает <CR>.<CR><LF> концом письма, сервер Б ждёт строго <CR><LF>.<CR><LF> и пропускает часть как валидный текст, внутри которого спрятана вторая команда DATA.
• LF без CR — обратная ситуация, когда получающий сервер интерпретирует одинарный <LF> как разделитель строк вместо ожидаемой пары символов.
• Пустые строки от удалённых SMTP-клиентов — некоторые релеи допускают «пустышки», которые расширяют окно для инъекции.

Практический пример показан на Cisco Secure Email Gateway: там по умолчанию параметр «CR and LF Handling» стоял в режиме «Clean», который нормализовал последовательности и открывал окно для smuggling — переключение на «Allow» заставляет сервер доверять только каноничному <CR><LF>.<CR><LF> как маркеру конца. Именно на таких edge-case настройках парсеров держится весь класс уязвимостей — это не эксплойт одной CVE, а системная проблема протокола, который писали в 80-х без задела на злоупотребления.

Как это закрывать в 2026

Полагаться только на SPF/DKIM/DMARC уже не вариант, нужно бить по самому транспортному уровню:

• Обновляй MTA и security-гейтвеи до последних версий — производители пропатчили дефолтные настройки CR/LF handling после публикации исследований.
• Запрещай неканоничные последовательности конца данных на уровне конфига (запрет <LF> без <CR>, запрет пустых строк от удалённых клиентов).
• Мониторь логи на аномальные SMTP-команды и «сдвоенные» DATA-блоки — это прямой признак smuggling-попытки.
• Ужесточай DMARC до p=reject только после стабилизации агрегированных отчётов rua, иначе легитимная почта начнёт биться.
• Используй S/MIME со сквозной подписью там, где критична подлинность — это единственный слой, который smuggling не может подделать постфактум.

Если ты копаешь это с прицелом на пентест — тестируй именно граничные случаи парсинга (fuzzing SMTP-команд с нестандартными переводами строк), а не только конфиг SPF/DKIM записей, потому что реальная дыра живёт в коде MTA, а не в DNS.

На этом все. Всем хорошего дня!