Аліаси проти переадресації в моделі загроз: як зробити витік реального ящика структурно неможливим
Аліас із локальною доставкою тримає вашу канонічну адресу всередині периметра, а класична переадресація тече одразу трьома каналами: SRS-конверт, DSN-відмови й транзитні Received. Розбираємо кожну точку витоку й закриваємо її конфігом Postfix та Dovecot.
EvilMail Team21 липня 2026 р.12 хв читання
Ви завели собі акуратну систему: shop@ для магазинів, bank@ для банку, forum@ для форумів. Усі три вказують на один справжній ящик — умовно [email protected]. Виглядає як приватність. Насправді атакуючому досить одного: змусити ваш сервер згенерувати відмову або відповідь. У ту ж секунду в Return-Path, Delivered-To або тілі DSN спливає канонічна адреса, і вся конструкція з красивих псевдонімів розсипається — сервіси корелюються між собою, а деанонімізація зводиться до читання заголовків.
Питання «аліас чи переадресація» зазвичай ставлять як вибір зручності. Це неправильна рамка. Правильна: чий конверт іде далі по дроту, і в якій точці шляху вперше з'являється рядок із вашою реальною адресою. Аліас із локальною доставкою й переписуванням вихідного конверта — це герметична модель. Класична переадресація на зовнішній ящик тече одразу трьома незалежними каналами, і кожен із них поодинці здатний видати mailbox. Нижче — не «як налаштувати аліас», а як зробити витік структурно неможливим.
Модель загроз: що саме витікає й через кого
Аліаси vs переадресація: захист реальної адреси на рівні SMTP | evilmail.pro — EvilMail Blog
Перелічимо конкретні вектори, кожен із яких — окремий рядок у реальному листі:
Відповідь на лист розкриває From: та Return-Path: справжнього ящика, якщо ви відповідаєте напряму з провайдера.
DSN-відмова містить Original-Recipient та Final-Recipient — тобто і аліас, і кінцевий mailbox поруч.
Транзитні `Received:` при переадресації показують внутрішній хоп: hostname вашого сервера й envelope-rcpt.
`Message-ID` із доменом справжнього провайдера прив'язує лист до конкретного постачальника.
Автовідповідач (vacation) відповідає з канонічної адреси, навіть якщо вхідний лист прийшов на аліас.
Catch-all відкриває enumeration і таймінг-кореляцію між сервісами.
Тепер три рівні супротивника, під яких ми проєктуємо. Маркетолог просто хоче звести ваші акаунти в один профіль — йому досить одного збігу адрес. Спамер із bounce-зондуванням навмисно шле лист на переповнений ящик, щоб зловити NDR і прочитати реальну адресу. Цілеспрямований деанон комбінує все вище: форджить лист, ловить відповідь, читає ланцюжок хопів.
Аліас ≠ переадресація на рівні SMTP
Механіка різниться на одному вирішальному кроці. Аліас — це локальний віртуальний адрес: virtual_alias_maps мапить shop@ на mailbox, який фізично лежить на вашому ж сервері. RCPT TO завершується локальною доставкою, другого конверта не існує. Переадресація використовує ту саму мапу, але значенням стоїть зовнішня адреса — і Postfix відкриває новий вихідний SMTP-хоп до чужого MX.
Різниця в один рядок мапи, наслідки — протилежні. У першому випадку адреса нікуди не їде: доставка завершилась усередині вашого периметра. У другому народжується другий конверт, і саме він несе вашу канонічну адресу через SPF, відмови й Received. Ось де тече.
Чому переадресація тече: SPF, SRS і вирівнювання DMARC
Щойно ваш сервер переслав лист, він став відправником від чужого імені. Приймаючий MX перевіряє SPF домену-джерела — а вашого IP там немає. SPF падає, лист летить у спам або відкидається. Класичне лікування — SRS (Sender Rewriting Scheme) через postsrsd: ви переписуєте MAIL FROM у формат, де відправником стає ваш домен.
# формат SRS-конверта
[email protected]
# hash ts ← оригінальні домен і user видно ВІДКРИТО
Ключовий нюанс, який зазвичай замовчують: HHH — це хеш тільки для tamper-захисту, а не шифрування, а TT — це timestamp у base32. Оригінальний домен і user вписані в конверт відкритим текстом. SRS рятує доставку, але додає ще один рядок, де видно, звідки прийшов лист.
DKIM тим часом переживає форвард — якщо тіло й підписані заголовки не мінялись, підпис лишається валідним. Тому DMARC-вирівнювання при переадресації тримається виключно на DKIM alignment, бо SPF alignment зламано за визначенням. Ставте на своєму домені жорсткий DMARC, щоб чужі не могли форджити ваші аліаси:
Найковарніший канал не потребує від вас жодної помилки конфігурації — тільки факту, що другий хоп існує. Коли переадресований лист відскакує від фінального ящика (переповнення, неіснуючий адресат), bounce приходить на вашу SRS-адресу, і в тілі DSN лежить пряма вказівка на реальний mailbox:
Атакуючий робить це навмисно: шле лист на ваш shop@, знаючи (або домагаючись), що фінальний ящик відхилить його, і читає NDR. Final-Recipient віддає канонічну адресу без жодного зусилля. Контрзаходи на форвардері — disable_vrfy_command = yes, обрізання чи маскування DSN-тіла через body_checks, VERP для власного bounce-трекінгу. Але головний висновок інший: локальний аліас цього класу атак не має взагалі. Немає другого хопа — немає кому відскакувати, немає DSN, немає Final-Recipient.
Заголовки, що видають ящик, і як їх стерти
Навіть без відмови вхідний лист, доставлений через форвард, тягне за собою шлейф. Postfix додає Delivered-To: і X-Original-To: — обидва містять справжній envelope-rcpt. Received: показує internal hostname і адресу доставки. Плюс Return-Path:, домен у Message-ID та Authentication-Results:. Виріжте зайве на межі:
Застереження, яке відрізняє інженера від скрипт-кідді: агресивне різання `Received:` на вхідних листах ламає ARC і трасування. Робіть це виключно на межі — для листів, що йдуть назад відправнику (ваші відповіді), через smtp_header_checks на submission-релеї, а не для вхідного потоку.
Відповідь без розкриття: send-as і переписування конверта
Половина людей забуває, що приватність убиває не вхідний лист, а ваша відповідь. Ви отримали на shop@, натиснули «Відповісти» — і полетіли вже з реального ящика провайдера. Уся попередня герметизація змита. Локальний аліас дозволяє двобічну герметичність: отримав як shop@, відповів як shop@. Схема на submission:
# main.cf
sender_canonical_maps = regexp:/etc/postfix/sender_canonical
sender_canonical_classes = envelope_sender, header_sender
# на релеї — переписати будь-який витік канонічної адреси у вихідних:
# smtp_generic_maps = hash:/etc/postfix/generic
sender_canonical_classes = envelope_sender, header_sender перекриває обидва місця, де канонічна адреса могла б просочитись — і конверт, і заголовок From:. Для автовідповідей використовуйте Dovecot Sieve redirect, який зберігає envelope, і ніколиvacation:
vacation небезпечний тим, що відповідає з канонічної адреси ящика, який фізично обробляє пошту, — тобто робить рівно те, від чого ви ховаєтесь. Переадресація двобічної герметичності не дає в принципі: відповідь завжди йде з реального ящика в чужого провайдера.
Практична архітектура під evilmail
Рекомендована модель — власний домен плюс per-service аліаси. Не plus-addressing: user+shop@ тривіально зрізається будь-яким скрейпером регуляркою s/\+[^@]*//, і для моделі загроз це нульова приватність — не вважайте його аліасом узагалі. Catch-all (@evilmail.pro → mailbox) зручний, але відкриває enumeration і таймінг-кореляцію: вмикайте лише за усвідомленого ризику. Коли аліас скомпрометовано спамом, ви відключаєте один рядок мапи замість зміни головної адреси.
Гранична форма правильної моделі — тимчасовий ящик evilmail.pro. Одноразова адреса це аліас із TTL, за яким реального mailbox не існує взагалі. Витікати структурно нічому: немає канонічної адреси, яку могли б розкрити ні DSN, ні Received, ні ваша відповідь. Там, де вам потрібно лише прийняти код підтвердження чи разовий лист, це найгерметичніший варіант із можливих.
Чекліст герметизації
Локальна доставка замість форварду скрізь, де можливо — немає другого конверта, немає трьох каналів витоку.
postsrsd — тільки якщо форвард неминучий, і пам'ятайте, що SRS показує orig-domain відкрито.
header_checks на X-Original-To та Delivered-To; різання Received — лише для вихідних відповідей.
sender_canonical_maps + smtp_generic_maps на submission, класи envelope_sender, header_sender.
DSN-фільтр і disable_vrfy_command = yes на форвардері.
Заборонити vacation з канонічної адреси; для автовідповідей — Sieve redirect.
Окремий аліас на кожен сервіс, ніякого plus-addressing як «приватності».
Моніторити bounce на SRS-адреси — сплеск NDR означає активне зондування.
DMARC `p=reject; adkim=s; aspf=s` на вашому домені, щоб чужі не форджили ваші аліаси.
Для разових реєстрацій — тимчасовий ящик, де реального mailbox немає за визначенням.
Різниця між аліасом і переадресацією зводиться до одного питання: народжується другий конверт чи ні. Якщо ні — вашу справжню адресу нема звідки дістати. Якщо так — ви весь час латаєте три канали, і достатньо одного недогляду, щоб Final-Recipient віддав усе.
