Plus-адресация против уникальных алиасов: почему +tag вычисляют и вырезают одной строкой
Совет «используй [email protected], чтобы ловить того, кто слил адрес» держится на трёх ложных допущениях. Базовый адрес виден прямо в строке, тег снимается одним sed-выражением, а до момента утечки он почти не доживает. Разбираем механику на уровне MTA, показываем, как реально найти источник утечки по заголовкам, и даём схему миграции на уникальные несводимые алиасы.
EvilMail Team4 августа 2026 г.11 мин чтения
Проблема: +tag выдаёт вас, а не защищает
Классическая сцена. На ящик прилетает спам, в поле To: стоит [email protected]. «Ага, значит слил Spotify» — вы довольны, схема работает. Но она держится на трёх допущениях, и все три неверны.
Первое: в самом адресе [email protected] открытым текстом лежит ваш базовый ящик [email protected]. Тег не прячет личность — он её публично подтверждает и рядом дописывает, где именно вы регистрировались. Второе: часть после + снимается одним регулярным выражением, и это делают не хакеры, а рядовые сервисы очистки баз. Третье, и самое неприятное: до момента утечки тег обычно не доживает. Базу перепродают несколько раз, и на каждом мёрже адреса нормализуют для дедупликации. Ваш +spotify исчезает задолго до того, как письмо дойдёт до вас.
Здесь новички путают две принципиально разные задачи:
Атрибуция утечки — понять, кто именно слил или продал адрес.
Несвязываемость — сделать так, чтобы слитый адрес нельзя было привязать к вам и к вашим остальным аккаунтам.
Plus-адресация решает первую задачу наполовину, а вторую — никак. Разберём почему на уровне MTA, а потом покажем, что делать вместо этого.
Как это работает на уровне MTA: RFC 5233 и recipient_delimiter
Механика называется subaddressing и описана в RFC 5233 («Sieve Email Filtering: Subaddress Extension»). Локальная часть адреса — всё, что до @ — делится разделителем на две части: user и detail. Маршрутизация идёт только по части `user`, а detail (ваш тег) существует лишь для того, чтобы вы могли на него фильтровать входящую почту.
Разделитель настраивается на стороне сервера. В Postfix за это отвечает один параметр:
bash
# проверить текущее значение
postconf recipient_delimiter
# main.cf — самый распространённый вариант
recipient_delimiter = +
# можно включить сразу несколько символов
recipient_delimiter = +-
Важный нюанс: у «ванильного» Postfix recipient_delimiter по умолчанию пуст, но практически все готовые почтовые сборки ставят +. А многие включают ещё и -, то есть alice-spotify@ у них тоже спокойно доставится. Если вы полагались на то, что дефис — «безопасный» символ, это не так.
Dovecot должен знать тот же разделитель, иначе LMTP не найдёт мейлбокс:
# dovecot conf.d/15-lda.conf (и для LMTP)
recipient_delimiter = +
Рассинхрон между Postfix и Dovecot даёт классическую ошибку 5.1.1 <user> User unknown — письмо с тегом отбивается, потому что один демон срезал detail, а второй искал ящик вместе с ним.
Кто поддерживает plus-теги из коробки: Gmail, Outlook / Microsoft 365, Fastmail, Proton Mail, iCloud, частично Yahoo. Отдельная ловушка — Gmail dot-blindness: точки в локальной части игнорируются, поэтому [email protected], [email protected] и [email protected] — один и тот же ящик. Это ещё один способ невольно связать между собой адреса, которые вы считали разными. При этом Gmail поддерживает +, но не поддерживает - как разделитель.
Главное: тег — это не часть идентификатора мейлбокса. Сервер и так знает, что почта для alice. Тег — метаданные для вашего удобства, и ровно поэтому его так легко выбросить.
Почему +tag вырезается одной строкой
Любой скрипт очистки базы приводит local+anything@domain к local@domain. Вот всё, что для этого нужно:
bash
# sed
sed -E 's/\+[^@]*@/@/' emails.txt
python
# Python
import re
re.sub(r'\+[^@]*(?=@)', '', addr)
# regex общего вида
^([^+@]+)\+[^@]*(@.*)$ → $1$2
Это не «инструмент злоумышленника». Это стандартный шаг нормализации в email-validation API, в list-hygiene тулзах и у брокеров данных. Цель прозаична — дедупликация. Когда две базы сливают в одну, [email protected] и [email protected] должны схлопнуться в одну запись [email protected], иначе один человек посчитается как два лида и биллинг за рассылку раздуется. Продавцу базы плевать на вашу атрибуцию — ему важно не платить дважды за один контакт.
Следствие жёсткое: как только адрес попал в перепроданную базу, тег с вероятностью, близкой к единице, потерян. И тогда все ваши alice+X@ схлопываются в один alice@, который теперь связан со всеми сервисами разом. Вы старались разделить идентичности — а нормализация собрала их обратно в один узел.
Есть и более ранняя точка отказа. Многие формы регистрации режут + на клиенте или на сервере как «подозрительный символ». То есть тег иногда не доживает даже до попадания в базу — сервис просто отказывается принимать адрес с плюсом либо молча выкидывает всё после него.
Уникальные алиасы: что реально несвязываемо
Критерий один: алиас должен быть неугадываемым и несводимым к базовому адресу нормализацией. Ни один sed, ни одна регулярка не должны из него восстановить ваш «настоящий» ящик или другой ваш алиас. Решения по нарастанию силы:
**Catch-all *@mydomain.tld → один ящик.** Максимально гибко: любой выдуманный на лету адрес доставится. В Postfix это делается через virtual_alias_maps, где пустая левая часть ловит всё:
Минус серьёзный: домен становится спам-магнитом. Directory harvest attack перебирает a@, admin@, info@, и catch-all принимает всё подряд; добавьте сюда backscatter от отбитых писем. Голый catch-all — плохая идея; лучше whitelist из известных алиасов и явное отклонение остального.
Subdomain addressing (стиль Fastmail):[email protected]. Гибко и при этом управляемо через MX на поддомене, но структура адреса всё ещё читаема человеком.
Именованные алиасы со случайным суффиксом:netflix-7g2q@mydomain. Суффикс делает адрес неугадываемым, а netflix- оставлен для вашего удобства. Важно, чтобы разделителем тут был не активный recipient_delimiter, иначе сервер снова срежет хвост.
Masked-email провайдеры: SimpleLogin, addy.io (бывший AnonAddy), Apple Hide My Email, Fastmail Masked Email. Они генерят непрозрачные адреса вида [email protected] — в них нет связи с вашей личностью, и нормализовать нечего.
Именно поэтому уникальные алиасы решают задачу несвязываемости, которую plus не решает в принципе: «ключом» служит весь адрес целиком, а его нельзя усечь, не сломав доставку. Для одноразовых регистраций, где даже отдельный алиас на своём домене избыточен, есть temp-адреса — тот же evilmail.pro даёт разовый ящик, чтобы ваш основной домен вообще не касался сомнительных форм.
Как найти источник утечки правильно
Раз тег не доживает до утечки, атрибуцию делаем иначе: уникальный алиас на каждый сервис плюс чтение служебных заголовков. Каждое входящее письмо несёт след доставки, который показывает, на какой алиас оно реально пришло — независимо от того, что подставлено в видимый To:.
Видимый To: можно подставить любой — спамер часто шлёт на undisclosed-recipients или на чужой адрес, а вас добавляет в конверт (envelope) скрытно. Envelope-заголовки в этом смысле не врут: они пишутся вашим же MTA в момент приёма. Если письмо пришло на netflix-7g2q@mydomain, а этот алиас вы отдавали только Netflix, — вопрос об источнике закрыт.
В отличие от +tag, здесь атрибуция построена на неусекаемом ключе. Заведите простую таблицу «алиас → сервис» (хоть в менеджере паролей), и любая утечка мгновенно указывает виновника.
Чеклист: миграция с +tag на алиасы
Проверьте свой MTA.postconf recipient_delimiter и конфиг Dovecot: понять, какие разделители включены. Если стоит +-, то и - у вас режется — учитывайте это при выборе схемы алиасов.
Уберите +tag с важных аккаунтов. Банк, госуслуги, основная почта — там нормализация особенно вероятна, а цена связывания идентичностей максимальна.
Заведите домен или masked-email провайдера. На каждый сервис — свой уникальный неугадываемый алиас (сервис-<случайный_суффикс>@ или непрозрачный k3f9x2@).
Ведите таблицу «алиас → сервис». Достаточно поля в менеджере паролей. Без неё атрибуция не работает.
При утечке грепайте envelope-заголовки, а не видимый To:: Delivered-To, X-Original-To, Envelope-To.
Одноразовые регистрации — на temp-адрес. Чтобы базовый ящик и основной домен вообще не касались ненадёжных форм.
Не рассчитывайте на выживание +tag после перепродажи базы. Гарантированное число нормализаций, которое переживает тег, — ноль.
Итог. Plus-адресация — удобный локальный фильтр входящей почты, и в этом качестве она хороша. Но как инструмент приватности она работает против вас: показывает базовый адрес, снимается одной строкой и не доживает до утечки. Несвязываемость даёт только адрес, который нельзя усечь, не сломав доставку. Одно sed-выражение схлопывает N ваших plus-адресов в одну идентичность за миллисекунды — уникальный алиас оно не трогает вовсе.
