Алиаси, пренасочване и catch-all: полезни, но с рискове

Модул 3: Управление на Вашата пощенска кутия · Време за четене: 11 минути

Учебна цел: След този урок ще можете да избирате между mailbox, алиас, пренасочване и catch-all, и да обясните защо пренасочването към външен адрес и catch-all могат да навредят на доставянето на Вашата поща.

Основни понятия: mailbox, алиас, forwarder (пренасочване), вътрешно и външно пренасочване, SPF се проваля при пренасочване, SRS (Sender Rewriting Scheme), DKIM при пренасочване, ARC (RFC 8617), catch-all, речникова атака (dictionary attack), backscatter, изпращане от името на друг адрес

Четири начина да накарате даден адрес да работи

Ако искате адресът offerte@example.com да работи, имате четири възможности:

В някои контролни панели алиасът технически е същото като forwarder към адрес на същия сървър. Разликата, която има значение, е следната: остава ли пощата на същия сървър, или излиза навън?

Пренасочване в рамките на собствения Ви домейн: без проблем

Ако пренасочите offerte@example.com към info@example.com, и двата адреса са на един и същи сървър, сървърът просто доставя пощата в mailbox на info@. Нищо не преминава през интернет, нищо не се проверява отново. Това е сигурно и надеждно.

Пренасочване навън: къде възниква проблемът

Нещата се променят, когато пренасочвате към адрес при друга компания, например личен адрес в Gmail или Outlook.com. Тогава Вашият сървър изпраща пощата отново, този път към Gmail. А Gmail проверява пощата така, сякаш идва от Вашия сървър.

Да предположим, че klant@example.net изпраща писмо до info@example.com. Вашият сървър го пренасочва към Gmail. Какво вижда Gmail?

• Подател (From): klant@example.net.
• Envelope подател: все още klant@example.net, освен ако Вашият сървър не го пренапише.
• Изпращащ сървър: Вашият сървър, например 192.0.2.25.

Gmail проверява SPF записа на example.net. Там, разбира се, не е включен Вашият сървър. SPF се проваля. Ако example.net има DMARC политика p=reject, и в писмото няма валиден DKIM подпис, Gmail отхвърля писмото. Вашият сървър получава обратно bounce съобщение, което отива при... първоначалния подател, който сега получава съобщение за грешка от Вашия сървър.

Съществуват три механизма, които смекчават това:

1. DKIM обикновено оцелява

DKIM подписът (урок 4.3) е част от самото писмо. Ако Вашият сървър пренасочи писмото непроменено, подписът на example.net остава валиден. Тогава DMARC преминава на база DKIM, дори SPF да се провали. Затова DKIM е толкова важен: той е единственото нещо, което оцелява при пренасочване.

Но възниква проблем, ако пренасочващият сървър промени писмото: добавя текст в края ("препратено от..."), променя темата (добавя [SPAM] отпред) или преобразува форматирането. Тогава подписът вече не е валиден.

2. SRS пренаписва envelope подателя

С SRS (Sender Rewriting Scheme) пренасочващият сървър променя envelope подателя на адрес от собствения си домейн, например:

SRS0=HHH=TT=example.net=klant@example.com

Сега Gmail проверява SPF записа на example.com, а там Вашият сървър е включен. SPF преминава успешно. Ако получи bounce съобщение, Вашият сървър може да преобразува адреса обратно и да изпрати bounce съобщението до истинския подател.

Внимание: SRS решава проблема със SPF, но не и с DMARC. Подравняването (alignment, урок 4.4) сравнява домейна на envelope подателя с адреса From. Сега това е example.com срещу example.net: няма подравняване. Следователно DMARC все пак трябва да премине на база DKIM.

3. ARC: декларация от посредника

ARC (Authenticated Received Chain, RFC 8617, експериментален) позволява на посредник да запише какво е видял: "когато това писмо пристигна при мен, SPF, DKIM и DMARC преминаха успешно". Пренасочващият сървър подписва тази декларация. Крайният получател може да реши да се довери на тази декларация, ако се доверява на посредника. Големи доставчици като Gmail и Microsoft използват ARC, но не можете да разчитате на него: това е услуга, не право.

А спамът?

Съществува още един проблем, който често е най-голям. Вашият спам филтър не спира всичко. Целият спам, който премине през него, Вашият сървър сега пренасочва към Gmail. За Gmail изглежда сякаш Вашият сървър изпраща спам. Това вреди на репутацията на Вашия сървър (а при споделен хостинг: на репутацията на всички клиенти на този сървър). След това Gmail започва да поставя и истинската Ви поща по-бързо в спам.

Кое е по-добре?

Искате ли да четете служебната си поща в приложението на Gmail или Outlook? Добавете mailbox като IMAP акаунт (модул 2). Приложението извлича пощата директно от Вашия сървър. Нищо не се пренасочва, нищо не се проваля и навън не отива спам. Ако все пак трябва да пренасочвате, настройте спам филтъра строго преди пренасочването.

Catch-all: защо почти никога

Функцията catch-all улавя цялата поща до несъществуващи адреси. Правописна грешка като inof@example.com тогава все пак пристига. Това звучи полезно, но:

• Спам. Спамерите изпращат масово поща до измислени адреси на съществуващи домейни (a.jansen@, sales2@, xkq7@). Това се нарича речникова атака (dictionary attack). Без catch-all Вашият сървър отхвърля всичко това веднага. С catch-all всичко пристига, често стотици писма дневно.
• Няма повече съобщение за грешка. Който сгреши адреса Ви, не получава bounce и мисли, че писмото му е пристигнало. Без catch-all той веднага разбира, че адресът е грешен.
• Пренасочването влошава нещата. Catch-all, който пренасочва към Gmail, изпраща целия този спам към Gmail.
• Backscatter. Сървър, който първо приема всичко и едва по-късно установява, че адресът не съществува, изпраща bounce съобщение до (фалшифицирания) подател. Това се нарича backscatter: съобщения за грешка до невинни хора, и причина да попаднете в blocklist.

Искате да обхванете няколко допълнителни адреса, като често срещана правописна грешка или стар адрес? Създайте отделни алиаси или forwarders за тях. Използвате ли отделен адрес за всеки уебсайт или онлайн магазин (webshop-x@), за да видите кой препродава адреса Ви? Създайте този адрес като алиас в момента, в който го използвате.

Изпращане от алиас

Алиас може да бъде и подател. Например искате да отговаряте като offerte@example.com, докато сте влезли като info@. Това е възможно, но:

• Много пощенски сървъри днес проверяват кой адрес на подател съответства на кое влизане в системата. Тогава можете да изпращате само от собствения си адрес и от алиасите или forwarders, които сочат към Вашата mailbox. Произволен друг адрес се отхвърля ("account can not send emails from ..."). Това защитава срещу злоупотреба.
• В пощенската си програма добавяте алиаса като допълнителна идентичност (Thunderbird: Управление на самоличности (Manage Identities); Apple Mail: допълнителни адреси при акаунта, разделени със запетаи; Outlook: показване на полето От (From) и въвеждане на адреса.
• SPF, DKIM и DMARC работят нормално, стига алиасът да е на същия домейн и Вие да изпращате през собствения си сървър.

На практика: така изглежда в контролен панел

В DirectAdmin създавате пренасочвания в E-mail Manager, Forwarders. Catch-all се намира в Advanced Features, Catch-All E-mail; там "изключване на catch-all" е препоръчителната настройка (пощата до несъществуващи адреси се отхвърля). Ако имате само домейн без пакет, пренасочванията се намират в Моят WebOké под Моите домейни, Пренасочвания. Другите панели (cPanel, Plesk, Microsoft 365, Google Workspace) имат подобни раздели, понякога под имена като "алиаси", "пренасочване" или "групи".

Обобщение

• Алиас или пренасочване в рамките на един и същи сървър е сигурно.
• Пренасочването навън нарушава SPF. SRS възстановява SPF, но не и подравняването за DMARC; само ненарушен DKIM подпис спасява писмото, а ARC може да помогне.
• Пренасоченият спам вреди на репутацията на Вашия сървър. По-добре четете външна поща през IMAP в приложението.
• Catch-all привлича спам, прикрива правописни грешки и може да причини backscatter. Използвайте отделни алиаси.
• Изпращането от алиас е възможно, в рамките на правилата на Вашия сървър.

Тест

Задача

Задача O3.3: Инвентаризация на Вашите адреси. Съставете списък на всички адреси във Вашия домейн: mailbox акаунти, алиаси, пренасочвания и дали е включен catch-all. Отбележете при всяко пренасочване дали остава в рамките на собствения Ви домейн, или излиза навън (Gmail, Outlook.com, друга компания). След това отговорете: кое външно пренасочване можете да замените с IMAP акаунт в приложението, и има ли включен catch-all, който може да се изключи? Попълнете контролния списък.

Прочетете още

Стъпките в тези статии важат за контролните панели на WebOké; при други доставчици работи по подобен начин.

• Ръководство за DirectAdmin 7.5: Forwarders: пренасочване на поща към друг адрес
• Ръководство за DirectAdmin 7.6: Catch-All E-mail: поща до несъществуващи адреси
• Пренасочване на имейл към друг адрес (forwarders, catch-all не се препоръчва)
• Изпращане от няколко псевдонима, грешка: Account xxx can not send emails from
• Ръководство на WebOké 5.9: Пренасочвания на поща и домейни
• Безплатен курс по DNS 4.3: SPF: кой може да изпраща имейли от името на Вашия домейн?
• RFC 8617 (ARC), RFC 7208 приложение D (SPF и посредници като пренасочващи сървъри)