Aliasy, przekierowania i catch-all: przydatne, ale z ryzykiem

Moduł 3: Zarządzanie skrzynką pocztową · Czas czytania: 11 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili wybrać między skrzynką pocztową, aliasem, przekierowaniem a catch-all, a także wyjaśnić, dlaczego przekierowywanie na adres zewnętrzny oraz catch-all mogą zaszkodzić dostarczalności Państwa poczty.

Kluczowe pojęcia: skrzynka pocztowa, alias, forwarder (przekierowanie), przekierowanie wewnętrzne i zewnętrzne, SPF przestaje działać przy przekierowaniu, SRS (Sender Rewriting Scheme), DKIM przy przekierowaniu, ARC (RFC 8617), catch-all, atak słownikowy, backscatter, wysyłanie w imieniu innego adresu

Cztery sposoby, aby adres zadziałał

Jeśli chcą Państwo, aby adres offerte@example.com działał, mają Państwo cztery możliwości:

W niektórych panelach alias technicznie jest tym samym co przekierowanie na adres na tym samym serwerze. Różnica, która ma znaczenie, jest taka: czy poczta zostaje na tym samym serwerze, czy wychodzi na zewnątrz?

Przekierowanie w obrębie własnej domeny: bez problemu

Jeśli przekierują Państwo offerte@example.com na info@example.com, a oba adresy znajdują się na tym samym serwerze, serwer po prostu dostarcza pocztę do skrzynki info@. Nic nie trafia do internetu, nic nie jest ponownie sprawdzane. Jest to bezpieczne i niezawodne.

Przekierowanie na zewnątrz: gdzie pojawia się problem

Sytuacja zmienia się, gdy przekierowują Państwo pocztę na adres u innego dostawcy, na przykład prywatny adres w Gmail lub Outlook.com. Wówczas Państwa serwer wysyła wiadomość ponownie, tym razem do Gmail. A Gmail sprawdza tę wiadomość tak, jakby pochodziła z Państwa serwera.

Załóżmy, że klant@example.net wysyła wiadomość na adres info@example.com. Państwa serwer przekierowuje ją do Gmail. Co widzi Gmail?

• Nadawca (From): klant@example.net.
• Nadawca koperty (envelope sender): nadal klant@example.net, chyba że Państwa serwer go przepisze.
• Serwer wysyłający: Państwa serwer, na przykład 192.0.2.25.

Gmail sprawdza rekord SPF domeny example.net. Oczywiście nie ma tam Państwa serwera. SPF kończy się niepowodzeniem (fail). Jeśli domena example.net ma politykę DMARC p=reject i wiadomość nie ma ważnego podpisu DKIM, Gmail odrzuci tę wiadomość. Państwa serwer otrzyma zwrotkę (bounce), która trafia do... pierwotnego nadawcy, który teraz dostaje komunikat o błędzie z Państwa serwera.

Istnieją trzy mechanizmy, które to łagodzą:

1. DKIM przeważnie przetrwa

Podpis DKIM (lekcja 4.3) znajduje się w samej wiadomości. Jeśli Państwa serwer przekaże wiadomość bez zmian, podpis domeny example.net nadal będzie poprawny. DMARC wówczas zalicza test na podstawie DKIM, mimo że SPF zawiódł. Dlatego DKIM jest tak ważny: to jedyny mechanizm, który przetrwa przekierowanie.

Problem pojawia się, gdy serwer przekierowujący zmienia wiadomość: dodaje tekst na dole ("przekierowano przez..."), modyfikuje temat (dopisując [SPAM]) albo zmienia formatowanie. Wtedy podpis przestaje się zgadzać.

2. SRS przepisuje nadawcę koperty

Dzięki SRS (Sender Rewriting Scheme) serwer przekierowujący zmienia nadawcę koperty na adres we własnej domenie, na przykład:

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

Teraz Gmail sprawdza rekord SPF domeny example.com, w którym Państwa serwer rzeczywiście się znajduje. SPF zostaje zaliczone. Jeśli pojawi się zwrotka, Państwa serwer może odtworzyć pierwotny adres i wysłać zwrotkę do prawdziwego nadawcy.

Uwaga: SRS rozwiązuje problem SPF, ale nie DMARC. Dopasowanie (uwierzytelnianie, lekcja 4.4) porównuje domenę nadawcy koperty z adresem From. Teraz mamy example.com wobec example.net: brak dopasowania. DMARC nadal musi więc zostać zaliczone na podstawie DKIM.

3. ARC: oświadczenie pośrednika

ARC (Authenticated Received Chain, RFC 8617, eksperymentalny) pozwala pośrednikowi zapisać, co zaobserwował: "gdy ta wiadomość do mnie dotarła, SPF, DKIM i DMARC zostały zaliczone". Serwer przekierowujący podpisuje to oświadczenie. Odbiorca końcowy może zdecydować się zaufać temu oświadczeniu, jeśli ufa pośrednikowi. Więksi odbiorcy, tacy jak Gmail i Microsoft, korzystają z ARC, ale nie można na to liczyć: to przywilej, a nie gwarancja.

A co ze spamem?

Jest jeszcze jeden problem, i często jest on największy. Państwa filtr antyspamowy nie zatrzymuje wszystkiego. Cały spam, który przez niego przejdzie, Państwa serwer teraz przekazuje dalej do Gmail. Dla Gmail wygląda to tak, jakby to Państwa serwer wysyłał spam. Reputacja Państwa serwera (a przy hostingu współdzielonym: reputacja wszystkich klientów na tym serwerze) na tym cierpi. Gmail zacznie wtedy częściej kierować także Państwa prawdziwą pocztę do spamu.

Co jest lepszym rozwiązaniem?

Chcą Państwo czytać pocztę firmową w aplikacji Gmail lub Outlook? Proszę dodać skrzynkę jako konto IMAP (moduł 2). Aplikacja pobiera pocztę bezpośrednio z Państwa serwera. Nic nie jest przekierowywane, nic nie zawodzi i żaden spam nie trafia na zewnątrz. Jeśli jednak przekierowanie jest konieczne, proszę ustawić rygorystyczny filtr antyspamowy przed przekierowaniem.

Catch-all: dlaczego niemal nigdy

Funkcja catch-all przechwytuje całą pocztę na adresy, które nie istnieją. Literówka, taka jak inof@example.com, wówczas i tak dotrze. Brzmi to wygodnie, ale:

• Spam. Spamerzy wysyłają masowo wiadomości na zmyślone adresy w istniejących domenach (a.jansen@, sales2@, xkq7@). Nazywa się to atakiem słownikowym. Bez catch-all Państwa serwer od razu odrzuca wszystkie takie wiadomości. Z catch-all wszystko trafia do skrzynki, często setki dziennie.
• Brak komunikatu o błędzie. Osoba, która pomyli się w adresie, nie otrzyma zwrotki i pomyśli, że jej wiadomość dotarła. Bez catch-all od razu wie, że adres jest nieprawidłowy.
• Przekierowanie pogarsza sytuację. Catch-all przekierowujący do Gmail wysyła cały ten spam do Gmail.
• Backscatter. Serwer, który najpierw przyjmuje wszystko, a dopiero później odkrywa, że dany adres nie istnieje, wysyła zwrotkę na (sfałszowany) adres nadawcy. Nazywa się to backscatter: komunikaty o błędach trafiające do niewinnych osób, co może być powodem umieszczenia na liście blokującej.

Chcą Państwo obsłużyć kilka dodatkowych adresów, na przykład częstą literówkę lub stary adres? Proszę utworzyć dla nich osobne aliasy lub przekierowania. Używają Państwo osobnego adresu dla każdej strony lub sklepu internetowego (webshop-x@), aby sprawdzić, kto odsprzedaje Państwa adres? Proszę utworzyć taki adres jako alias w momencie, w którym zaczynają go Państwo używać.

Wysyłanie z aliasu

Alias może również pełnić funkcję nadawcy. Chcą Państwo na przykład odpowiadać jako offerte@example.com, będąc zalogowanym jako info@. Jest to możliwe, ale:

• Wiele serwerów pocztowych sprawdza obecnie, który adres nadawcy jest powiązany z którym loginem. Mogą Państwo wtedy wysyłać wyłącznie z własnego adresu oraz aliasów lub przekierowań, które wskazują na Państwa skrzynkę. Dowolny inny adres zostanie odrzucony ("account can not send emails from ..."). Chroni to przed nadużyciami.
• W programie pocztowym dodają Państwo alias jako dodatkową tożsamość (Thunderbird: Zarządzaj tożsamościami; Apple Mail: dodatkowe adresy przy koncie, oddzielone przecinkami; Outlook: wyświetlenie pola Od i wpisanie adresu).
• SPF, DKIM i DMARC działają normalnie, o ile alias znajduje się w tej samej domenie i wysyłają Państwo pocztę przez własny serwer.

W praktyce: jak to wygląda w panelu

W DirectAdmin przekierowania tworzą Państwo w sekcji Zarządzanie pocztą E-mail, Przekierowania. Catch-all znajduje się w Funkcje zaawansowane, Usługa Catch-All E-mail; zalecanym ustawieniem jest tam wyłączenie catch-all (poczta na nieistniejące adresy zostaje odrzucona). Jeśli mają Państwo tylko nazwę domeny bez pakietu, przekierowania znajdują się w Moje WebOké, w sekcji Moje domeny, Przekierowania. Inne panele (cPanel, Plesk, Microsoft 365, Google Workspace) mają podobne funkcje, czasem pod nazwami takimi jak "aliasy", "przekierowania" czy "grupy".

Podsumowanie

• Alias lub przekierowanie w obrębie tego samego serwera jest bezpieczne.
• Przekierowanie na zewnątrz powoduje niepowodzenie SPF. SRS naprawia SPF, ale nie dopasowanie DMARC; tylko nienaruszony podpis DKIM ratuje wiadomość, a ARC może pomóc.
• Przekierowany spam szkodzi reputacji Państwa serwera. Lepiej czytać pocztę zewnętrzną przez IMAP w aplikacji.
• Catch-all przyciąga spam, ukrywa literówki i może powodować backscatter. Proszę korzystać z osobnych aliasów.
• Wysyłanie z aliasu jest możliwe, w granicach zasad Państwa serwera.

Quiz

Zadanie

Zadanie O3.3: Inwentaryzacja adresów. Proszę sporządzić listę wszystkich adresów w Państwa domenie: skrzynek pocztowych, aliasów, przekierowań oraz informacji, czy włączony jest catch-all. Przy każdym przekierowaniu proszę zaznaczyć, czy pozostaje ono w obrębie własnej domeny, czy kieruje na zewnątrz (Gmail, Outlook.com, inna firma). Następnie proszę odpowiedzieć: które przekierowanie na zewnątrz można zastąpić kontem IMAP w aplikacji, i czy jest włączony catch-all, który można wyłączyć? Proszę uzupełnić listę kontrolną.

Dalsza lektura

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to w podobny sposób.

• Instrukcja DirectAdmin 7.5: Przekierowania: przekazywanie poczty na inny adres
• Instrukcja DirectAdmin 7.6: Catch-All E-mail: poczta wysyłana na nieistniejące adresy
• Przekierowywanie wiadomości e-mail na inny adres (forwardery, catch-all odradzamy)
• Wysyłanie poczty z kilku aliasów, błąd: Account xxx can not send emails from
• Podręcznik WebOké 5.9: Przekierowania e-mail i domen
• Bezpłatny kurs DNS 4.3: SPF: kto może wysyłać wiadomości w imieniu Państwa domeny?
• RFC 8617 (ARC), RFC 7208 załącznik D (SPF i pośrednicy, tacy jak serwery przekierowujące)