Алиасы против пересылки: что реально скрывает ваш адрес, а что его сдаёт
Плюс-адресация и обычная пересылка дают ложное чувство приватности: Delivered-To, цепочка Received и SRS-конверт всё равно несут ваш настоящий ящик. Разбираем по заголовкам, чем алиас-релей отличается от форварда — и почему уникальный алиас на контакт превращает утечку в улику.
EvilMail Team2 августа 2026 г.9 мин чтения
Отправляем два одинаковых письма: одно на плюс-адрес [email protected], второе на форвард [email protected], который льёт всё в тот же ящик. Забираем оба на конечном сервере и снимаем заголовки:
bash
formail -c -X Delivered-To -X Return-Path -X Received < forwarded.eml
text
Delivered-To: [email protected]
Return-Path: <[email protected]>
Received: from myforward.com (myforward.com [203.0.113.7]) by mx.realdomain.com
Received: from mail.shop.com (mail.shop.com [198.51.100.9]) by myforward.com
Отправитель, который «видел» только
Алиасы vs пересылка почты: приватность адреса по заголовкам — EvilMail Blog
. Но она есть — её вписал конечный MDA, и любой, кто держит форвардер или конечный сервер, читает реальный ящик открытым текстом. Вопрос не в том, «скрыт адрес или нет». Вопрос —
какой слой адреса скрыт, от кого, и что происходит, когда письмо отбивается
.
Три слоя адреса, и кто какой видит
У письма три независимых слоя, и путать их — главная ошибка в разговорах про приватность почты.
Конверт (envelope). Это SMTP-диалог: MAIL FROM и RCPT TO. В доставленном письме след конверта — заголовок Return-Path. Отправитель задаёт MAIL FROM, но RCPT TO знает только принимающая сторона.
Заголовки (header).From, To, Reply-To, Subject, а также служебные Delivered-To, Received, X-Original-To. Это то, что рисует почтовый клиент, и то, что дописывает каждый хоп по пути.
Тело (body). MIME-части, картинки, трекинг-пиксели.
Отправитель видит ровно две вещи: заголовки, которые он сам поставил, и результат своего SMTP-диалога (принято/отбито). Он не видит Delivered-To конечного ящика и не видит цепочку Received после первого хопа. Форвардер видит всё — он физически держит письмо в руках. Конечный MDA дописывает свой Delivered-To с реальным адресом.
Отсюда следствие, которое ломает большинство «приватных» схем: спрятать адрес *от отправителя* и спрятать его *от инфраструктуры* — две разные задачи. Пересылка в лучшем случае решает первую, да и то дыряво. Вторую она не решает вообще: сам смысл форварда в том, что реальный адрес известен и записан в конфиге.
Почему пересылка ломает SPF и переписывает конверт
Обычный форвард пересылает письмо, сохраняя MAIL FROM исходного отправителя. Принимающий сервер берёт IP того, кто прямо сейчас с ним разговаривает — а это IP форвардера — и проверяет его против SPF-записи домена из MAIL FROM. IP форвардера там, естественно, нет. SPF=fail.
Лечится это Sender Rewriting Scheme. Форвардер переписывает конверт так, чтобы MAIL FROM указывал на *его* домен, и тогда SPF снова сходится. На практике это postsrsd, воткнутый в Postfix:
postsrsd слушает два сокета: 10001 переписывает исходящий конверт (forward), 10002 раскодирует обратный при возврате отбойника (reverse). И вот тут приватностный подвох: SRS не шифрует адрес, он его кодирует открытым текстом. Посмотрите, из чего собран новый Return-Path.
Два сегмента подсвечены не просто так: shop.com и noreply — это исходный адрес получателя, разложенный по полочкам. SRS придуман ради доставляемости, а не ради приватности, и обратного не обещает. Timestamp-тег вдобавок задаёт окно валидности обратного пути (у postsrsd по умолчанию около 21 дня) — после него reverse-адрес протухает, и запоздавший NDR просто некуда вернуть.
Заголовки-стукачи: разбор форварднутого письма
Пройдёмся по дампу построчно — это те строки, которые пересылка вписывает мимо вашей воли.
X-Original-To: и X-Forwarded-To: — многие форвардеры прямо кладут сюда оригинального получателя.
Received: from myforward.com (myforward.com [203.0.113.7]) by mx.realdomain.com — верхний хоп: ваш MX принял письмо от форвардера, и его хостнейм торчит в by-строке; хопом ниже видно, как форвардер принял письмо от shop.com. Домен реального ящика читается по цепочке без усилий.
Return-Path: — тот самый SRS-адрес с исходным доменом внутри.
Отдельная беда — отбойники. Когда письмо к реальному ящику не проходит, NDR уходит на SRS-адрес, а в тело сервер по RFC вкладывает оригинальные заголовки — включая To: с реальным получателем. То есть отказ доставки несёт реальный адрес дважды: в конверте и в цитате.
И самая бытовая утечка — «reply-ловушка». Пересылка не трогает From, поэтому в клиенте у получателя стоит настоящий отправитель. Нажали «Ответить» — и ушли напрямую с реального ящика, минуя форвардер целиком. Никакой SRS тут уже не поможет, потому что вы сами вышли из схемы.
Кстати, вот как выглядит «дырявый» форвард на Sieve, который многие считают приватным:
Он добавляет свой Received, не переписывает From, оставляет reply-приватность в руинах и держит копию. Это удобно, но к сокрытию адреса отношения не имеет.
Как устроен настоящий алиас-релей
Релей — SimpleLogin, addy.io, Firefox Relay, self-hosted аналоги и модель, на которой построен evilmail — работает принципиально иначе. Он не пересылает, он терминирует входящее и собирает новое.
Входящее приходит на [email protected]. Релей его принимает, завершает SMTP-транзакцию и генерирует полностью новое сообщение к реальному ящику. В нём:
From: "Магазин (via relay)" <[email protected]> — отправитель закодирован, но реального адреса тут нет;
Reply-To: reply+<hmac-token>@relay.tld — обратный адрес с подписанным токеном.
Вы жмёте «Ответить» — письмо уходит на reply+<hmac>@relay.tld. Релей декодирует токен, находит исходного отправителя и шлёт ему ответ со своего домена и под своей DKIM-подписью. Реальный ящик не появляется ни в одном заголовке, который видит отправитель — ни в From, ни в Return-Path, ни в Received. Разница с Sieve redirect фундаментальная: redirect тащит письмо как есть и клеит хоп, релей — рвёт и пересобирает.
DKIM, DMARC и ARC: что переживает пересылку
Аутентификация ведёт себя на форварде несимметрично.
SPF ломается всегда — по причине из раздела про SRS. Проверяется IP последнего хопа.
DKIM пересылку переживает — подпись считается по канонизированным телу и заголовкам и не зависит от SMTP-пути. Пока форвардер не трогает контент, b= остаётся валидной.
DMARC проходит по alignment. Поскольку DKIM выжил, чистый форвард обычно проходит DMARC через DKIM-alignment, даже когда SPF отвалился.
Ловушка — в модификации тела. Стоит форвардеру приклеить баннер «Переслано», антивирусный футер или переписать ссылки — хеш тела меняется, DKIM b= рушится, а раз SPF и так fail, DMARC уходит в fail целиком, и письмо летит в спам. Ровно поэтому «пересылка с плашкой» так плохо доставляется.
ARC (Authenticated Received Chain) — костыль под эту проблему: форвардер заверяет своими ARC-Seal и ARC-Message-Signature исходные результаты аутентификации, чтобы конечный сервер поверил «здесь SPF/DKIM были валидны до меня». Работает, если конечная сторона ARC доверяет (rspamd и OpenARC умеют). Алиас-релей эту головную боль обходит по построению: он пере-подписывает исходящее своим ключом, и на выходе стоит валидная свежая DKIM-подпись домена релея, а не унаследованная чужая.
Проверить свою раскладку — три dig и один тест-ключ:
Отслеживание отправителя: один алиас на контакт = атрибуция
Главный приватностный аргумент не «спрятаться», а поймать. Заводите уникальный алиас на каждый сервис. Когда [email protected] всплывает в спам-базе или в дампе утечки — вы точно знаете, кто вас слил, отключаете один алиас и не трогаете ящик. Пересылка так не умеет: у вас один-два форварда на всё, и утечка неатрибутируема.
Плюс-адресация это чувство изоляции лишь имитирует. RFC 5233 subaddressing — не механизм приватности, а удобство сортировки. Тег снимается одной регуляркой:
Спам-листы и брокеры чистят плюс-теги автоматически — базовый адрес раскрывается мгновенно. Catch-all не лучше: он громко сообщает, что домен принимает всё, и приглашает энумерацию имён. И отдельный слой — трекинг. Удалённые картинки и пиксели 1x1 сливают факт открытия, ваш IP и User-Agent. Релей может проксировать или резать изображения на своей стороне, разрывая open-tracking и пряча сетевые метаданные, — форвард отдаёт письмо как есть.
Чеклист приватной раскладки
Уникальный алиас на каждый сервис — утечка становится атрибутируемой.
Никогда не считать plus-addressing изоляцией: s/\+[^@]*@/@/ снимает тег за один проход.
Если всё же форвард — включить SRS (postsrsd, сокеты 10001/10002), иначе SPF-fail и спам.
Проверить, что форвардер не модифицирует тело — иначе DKIM рвётся и DMARC падает.
Поднять DMARC до p=quarantine и включить ARC, если письма проходят через промежуточные хопы.
Отключить автозагрузку картинок или проксировать их через релей — убивает open-tracking и утечку IP.
Для одноразовых регистраций — временный ящик вместо постоянного алиаса.
Периодически грепать собственную почту на утечки: formail -X Delivered-To -X Received < msg — смотрите, что реально доходит.
Пересылка прячет адрес от отправителя, да и то ровно до первого Reply или первого отбойника. Алиас-релей делает другое: он терминирует письмо, пере-подписывает исходящее и держит реальный ящик за пределами всех заголовков, которые кто-либо снаружи способен прочитать. А уникальный алиас на контакт превращает будущую утечку из анонимной неприятности в улику с именем виновника.
