Przekierowanie to najbardziej niewinne ustawienie, jakie zna skrzynka: poczta przychodzi na adres A i automatycznie idzie dalej na adres B. Od czasu upowszechnienia DMARC właśnie to ustawienie regularnie zabija wiadomości, które bezpośrednią drogą dotarłyby bez kłopotu. Powodem nie jest samo przekierowanie, tylko to, co mechanizmy weryfikacji faktycznie sprawdzają.
Co technicznie dzieje się przy przekierowaniu
Przekierowanie to ani kopia, ani przekazanie w locie. Serwer przekierowujący przyjmuje wiadomość w całości i wysyła ją na nowo — z własnego adresu IP, ze swojej sieci. Dla odbiorcy na końcu łańcucha to przekierowujący jest serwerem nadawczym. Z pierwotnego połączenia nie zostaje nic poza dodatkowym wierszem Received: w nagłówku.
Tym samym znika warunek, na którym SPF opiera się w całości.
SPF nie przeżywa przekierowania
SPF pyta: czy ten adres IP może wysyłać w imieniu tej domeny? Odbiorca widzi jako nadawcę adres IP przekierowującego, ale w kopercie nadal stoi domena pierwotnego nadawcy. Adresu IP przekierowującego rzecz jasna nie ma we wpisie SPF cudzej domeny — nie ma powodu, żeby był. Wynik: fail.
To nie jest błąd konfiguracji. To nieunikniona konsekwencja tego, że SPF sprawdza połączenie, a nie wiadomość. Każde przekierowanie łamie SPF, bez wyjątku.
DKIM przeżywa — dopóki nikt nie tknie treści
DKIM działa inaczej. Pierwotny nadawca liczy podpis kryptograficzny na treści wiadomości i wybranych nagłówkach, po czym dołącza go. Ten podpis podróżuje razem z wiadomością. To, czy szła przez serwer pośredni, nie ma znaczenia — weryfikowana jest zawartość, nie droga.
Dlatego zwykły przypadek przechodzi mimo złamanego SPF: DKIM przechodzi, DKIM jest dopasowany, a DMARC wymaga tylko, żeby jedna z dwóch dróg przeszła i była dopasowana. Jak działa to porównanie, opisano osobno.
Gdzie podpis jednak pęka
Zastrzeżenie „dopóki nikt nie tknie treści" nie jest teoretyczne. Kilka rozpowszechnionych rozwiązań tyka ją regularnie:
- Listy dyskusyjne doklejają stopkę z informacją o wypisaniu i wstawiają przed tematem znacznik w rodzaju
[wewn]. Jedno i drugie mieści się w obszarze objętym podpisem. Podpis jest potem nieważny. - Skanery antywirusowe i filtry załączników zastępują załączniki tekstem informacyjnym albo doklejają adnotację o skanowaniu.
- Centralne stopki prawne, dodawane przez bramkę do każdej wychodzącej wiadomości, dotykają tak samo poczty przekierowanej.
- Zmiana kodowania. Serwer przepisujący wiadomość z
8bitnaquoted-printablezmienia treść na poziomie bajtów, choć czytelnik nic z tego nie widzi.
Gdy złamany jest również DKIM, dla DMARC nie zostaje żadna droga. Wiadomość zostaje odrzucona albo trafia do spamu — i słusznie, bo z punktu widzenia odbiorcy przyszła z nieuprawnionego źródła i została po drodze zmieniona.
SRS: naprawa, która przesuwa problem
Przekierowujący radzą sobie mechanizmem Sender Rewriting Scheme. Przekierowujący przepisuje adres w kopercie na siebie: z anna@firma.pl robi się coś w rodzaju SRS0=abc=xy=firma.pl=anna@uczelnia.example. SPF sprawdza wtedy uczelnia.example, adres IP się zgadza i wynik znów brzmi pass.
Tyle że DMARC nic na tym nie zyskuje. Sprawdzona domena to teraz uczelnia.example, która zgadza się z polem From: na firma.pl jeszcze mniej niż wcześniej. SRS naprawia ścieżkę zwrotek — mają się zbierać u przekierowującego, nie u pierwotnego nadawcy — ale nie dopasowanie. Także z SRS wynik dźwiga wyłącznie DKIM.
Co robi ARC
Tu wchodzi Authenticated Received Chain. Pomysł jest prosty: skoro przekierowujący i tak przeprowadził już weryfikację, zanim zmienił wiadomość, niech przekaże ten wynik dalej w poświadczonej formie.
Każdy serwer pośredni obsługujący ARC dokłada trzy nagłówki:
| Nagłówek | Zawartość |
|---|---|
ARC-Authentication-Results | Wynik, jaki ten serwer zobaczył przy odbiorze |
ARC-Message-Signature | Podpis na wiadomości w stanie, w jakim tu dotarła |
ARC-Seal | Podpis na dotychczasowym łańcuchu, żeby nie dało się go przepisać wstecz |
Odbiorca na końcu widzi wtedy: SPF i DKIM u mnie nie przechodzą, ale łańcuch zaświadcza, że oba przeszły u pierwszego odbiorcy, a sam łańcuch jest nienaruszony.
Rozstrzygające ograniczenie
ARC niczego nie dowodzi. Przenosi twierdzenie — a czy to twierdzenie jest coś warte, zależy w całości od tego, czy odbiorca wierzy serwerowi, który je podpisał. Dowolny serwer może zbudować łańcuch ARC głoszący, że wszystko przeszło.
ARC nie jest więc czymś, co się włącza i co potem działa. Duzi dostawcy biorą pod uwagę łańcuchy ARC od nadawców, których znają i których przez dłuższy czas ocenili jako wiarygodnych. Dla świeżo postawionego przekierowującego bez historii łańcuch ARC początkowo niewiele zmienia. To nie słabość mechanizmu, tylko jego konstrukcja: ARC jest adnotacją o zaufaniu, nie dowodem.
Co z tego wynika w praktyce
Jeśli korzystasz z przekierowania: licz się z tym, że poczta od nadawców z p=reject ginie po drodze. Czystszą drogą jest pozwolić skrzynce docelowej samodzielnie pobierać wiadomości — importem POP3 lub IMAP zamiast przekierowaniem. Wtedy nie ma drugiej wysyłki i nie ma czego łamać.
Jeśli prowadzisz listę: ustaw From: na adres listy, a pierwotny adres wstaw w Reply-To:. Takie rozwiązanie wybrały duże systemy list. Wygląda nieelegancko, ale jako jedyne działa pewnie, gdy lista zmienia treść.
Jeśli wysyłasz: zadbaj o dopasowany DKIM, zanim zaostrzysz politykę. Nadawca opierający się wyłącznie na SPF traci przy każdym przekierowaniu swoich wiadomości jedyną podstawę, na której DMARC mógłby jeszcze przejść.