Najwięcej czasu zajęły rzeczy, które wyglądały na poprawne, a były błędne, albo wyglądały na błędne, a były poprawne.
Narzędzie diagnostyczne, które kłamało o rekordzie PTR
Zapytanie o rekord PTR serwera zwróciło zupełnie inną, testową nazwę hosta, co wyglądało na poważną niezgodność z nazwą HELO. Przyczyną był lokalny resolver na stacji diagnostycznej: odpowiadał na zapytania PTR wpisami z pliku hosts komputera. W publicznym DNS rekord był od początku poprawny. Od tej chwili każde sprawdzenie DNS szło bezpośrednio do serwerów autorytatywnych i do publicznego resolvera.
Microsoft twierdził, że adres nie jest zablokowany, a pocztę i tak odrzucał
Tak wyglądał zwrot, który dostał użytkownik; adresy i znacznik czasu są zanonimizowane:
<**************@hotmail.com>: host hotmail-com.olc.protection.outlook.com[x.x.x.x]
said: 550 5.7.1 Unfortunately, messages from [x.x.x.x] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors.
[Name=Protocol Filter Agent][AGT=PFA][MxId=**************] [**************.eurprd04.prod.outlook.com 2026-03-17T08:14:52.316Z **************] (in reply to MAIL FROM command)
Odrzucenia miały kod S3150, a portal samoobsługowy Microsoftu zapewniał, że adres IP nie jest zablokowany. S3150 oznacza blokadę zakresu adresów u dostawcy hostingu, a nie pojedynczego adresu, a portal obsługuje tylko pojedyncze adresy. Wyjściem było zgłoszenie do wsparcia Microsoftu, eskalowane z faktami: SPF, DKIM i DMARC we wszystkich domenach, czyste publiczne czarne listy, niski wolumen, wyłącznie uwierzytelnieni nadawcy. Potwierdzenie zdjęcia blokady przyszło 1 godzinę 18 minut po pierwszej wiadomości do wsparcia. DKIM i DMARC nie usuwają takiej blokady, bo Microsoft odrzuca połączenie, zanim zobaczy wiadomość; kompletne uwierzytelnienie bardzo jednak wzmacnia eskalację.
Serwer mógł zacząć podpisywać przychodzący spam
Przy milterze podpisującym włączonym globalnie, jak radzi większość poradników, poczta przeskanowana przez amavisa przeszłaby przez niego drugi raz w drodze powrotnej do Postfixa. Przychodzący spam z podrobionym nadawcą z jednej z czterech domen dostałby wtedy prawidłowy podpis DKIM tej domeny. Miltery są więc wyłączone na porcie, którym amavis oddaje pocztę, i na publicznym porcie 25.
Jeden znacznik w rekordzie DKIM i TTL
Test klucza kończył się błędem „unknown hash”: znacznik h= w rekordzie DKIM przyjmuje nazwy funkcji skrótu, takie jak sha256, a nie nazwę algorytmu podpisu. Odbiorcy pilnujący specyfikacji odrzuciliby każdy podpis. Rekord poprawiliśmy, zanim domena cokolwiek podpisała, a test klucza stał się warunkiem włączenia podpisywania. Rekord miał TTL równe dobie, więc resolvery mogły trzymać błędną wersję przez 24 godziny; na czas wdrożenia obniżyliśmy TTL do godziny.
Zwroty potrzebują SPF dla własnej nazwy serwera
Komunikat o niedoręczeniu ma pusty adres nadawcy w kopercie, więc SPF sprawdza wtedy nazwę HELO serwera. Bez rekordu SPF dla tej nazwy zwroty nie przeszłyby DMARC po przejściu domeny głównej na reject, a nadawcy z zewnątrz nigdy nie dowiedzieliby się, że ich wiadomość nie doszła. Jeden rekord to załatwił.
