Rozpowszechnione wyobrażenie o obronie przed spamem wygląda tak: wiadomość przychodzi, filtr ją czyta, waży temat i tekst i decyduje między skrzynką odbiorczą a spamem. To istnieje i jest krokiem ostatnim. Zdecydowanie większa część niechcianego ruchu zostaje odrzucona, zanim przesłany zostanie choćby jeden wiersz treści.
Powód jest prozaiczny: czytanie tekstu kosztuje czas procesora, sprawdzenie adresu IP prawie nic. Serwer, który przyjmuje każde połączenie do końca, żeby dopiero potem je ocenić, sam robi z siebie cel.
Rozmowa, zanim dojdzie do treści
SMTP to wymiana zdań o ustalonej kolejności. Każdy krok jest okazją do zakończenia połączenia — a większość połączeń kończy się długo przed ostatnim.
Krok 1: sam adres
Zanim cokolwiek zostanie powiedziane, wiadomo, skąd przychodzi połączenie. To wystarcza do trzech decyzji:
- Listy blokujące. Jedno zapytanie DNS, odpowiedź w milisekundach. Jeśli adres IP figuruje na liście, którą operator uznaje za twardą, tu się kończy.
- Tempo połączeń. Ile połączeń przyszło z tej sieci w ostatniej minucie? Kto otwiera zbyt wiele zbyt szybko, zostaje przyduszony albo odrzucony.
- Rodzaj sieci. Zakresy IP znane jako sieci dostępowe dla klientów indywidualnych bywają odrzucane dla poczty przychodzącej z zasady. Nie stoi za tym uprzedzenie, tylko obserwacja, że dostarczają stamtąd bezpośrednio prawie wyłącznie zainfekowane komputery.
Krok 2: kto odzywa się za wcześnie
Serwer wysyła wiersz powitalny zaczynający się od 220. Dopiero potem kolej na klienta. Część serwerów celowo opóźnia ten wiersz o kilka sekund i sprawdza, czy klient mimo to zaczyna nadawać.
Poprawnie zachowujący się serwer pocztowy czeka. Proste programy wysyłkowe, jakie działają na przejętych komputerach, oszczędzają sobie czekania, bo w tym czasie mogłyby doręczać gdzie indziej. Kto odzywa się przed powitaniem, sam się w ten sposób ujawnił.
Krok 3: EHLO i rozwiązywanie wsteczne
Poleceniem EHLO klient podaje swoją nazwę. Sprawdzane są trzy rzeczy:
- Czy nazwa jest w ogóle pełną nazwą domenową?
EHLO localhostalbo goły adres IP rzuca się w oczy natychmiast. - Czy dla adresu IP istnieje wpis PTR? Czyli: czy adres IP rozwiązuje się wstecz do nazwy? Brak wpisu jest u wielu odbiorców powodem odrzucenia.
- Czy rozwiązywanie zgadza się w obie strony? Nazwa z PTR musi rozwiązywać się wprzód znów na ten sam adres IP. Nazywa się to forward-confirmed reverse DNS i jest jedynym z tych sprawdzeń, którego nie da się po prostu zadeklarować: PTR ustawia operator sieci, wpis A właściciel domeny. Kontrolować obie rzeczy znaczy faktycznie do obu należeć.
Jeśli klient dodatkowo twierdzi, że jest serwerem odbierającym — EHLO mail.firma.pl wobec mail.firma.pl — sprawa jest jednoznaczna. Serwer nie dzwoni sam do siebie.
Kroki 4 i 5: adresy
Przy MAIL FROM przeprowadzane jest sprawdzenie SPF — potrzebuje adresu IP i domeny z koperty, a jedno i drugie już jest. Dodatkowo sprawdza się, czy domena nadawcy w ogóle istnieje i może odbierać pocztę. Domena bez wpisu MX i bez A nie przyjmie odpowiedzi, a więc jako nadawca jest bezużyteczna.
Przy RCPT TO rozstrzyga się, czy odbiorca istnieje. Tu leży różnica między odmową a późniejszym komunikatem o niedoręczeniu: serwer odpowiadający teraz 550 odmawia — komunikat wytwarza nadawca. Serwer, który najpierw przyjmuje, a później zauważa, że adresu nie ma, musi sam wysłać komunikat, często pod podrobiony adres.
Tu działa również greylisting: tymczasowa odmowa z kodem 4xx, wymagająca drugiej próby po kilku minutach. Dlaczego pierwsza wiadomość przychodzi przez to czasem wyraźnie później, opisano osobno. Liczy się także liczbę odrzuconych odbiorców na połączenie: kto próbuje dziesięciu nieistniejących adresów pod rząd, przerabia listę.
Co zdradza treść błędu
Ponieważ każdy etap ma własny błąd, tekst odmowy mówi dość dokładnie, na czym stanęło:
| Komunikat, w istocie | Etap, który zawiódł |
|---|---|
| Client host rejected / blocked using … | 1 — adres IP jest na liście |
| Improper use of SMTP command pipelining | 2 — odezwał się za wcześnie |
| Helo command rejected: need fully-qualified hostname | 3 — nazwa w EHLO się nie nadaje |
| cannot find your reverse hostname | 3 — brak PTR albo się nie zgadza |
| Sender address rejected: Domain not found | 4 — domena nadawcy nie istnieje |
| Recipient address rejected: User unknown | 5 — takiego adresu nie ma |
| Greylisted, try again in … | 5 — tymczasowo, to nie błąd |
Rozróżnienie między 4xx a 5xx waży przy tym więcej niż sam tekst: 4xx znaczy „jeszcze raz później", 5xx znaczy „nigdy więcej". Nadawca, który po 5xx dalej doręcza, staje się podejrzany; ten, który nie powtarza po 4xx, nie jest prawdziwym serwerem pocztowym.
Co z tego wynika dla własnej wysyłki
Lista jest krótka i niemal nudna — właśnie dlatego bywa pomijana:
- Zadbaj o wpis PTR i o to, żeby rozwiązywał się wprzód. Wpisuje go operator sieci, nie Ty. Przy własnej wysyłce to najczęstsza przyczyna odmów bez rozpatrzenia.
- Ustaw
EHLOna tę samą nazwę, na którą wskazuje PTR. Nie na nazwę maszyny i nie na domenę z wiadomości. - Nie doręczaj bezpośrednio z sieci dostępowej dla klientów indywidualnych. Serwer stoi w mieszkaniu albo za zwykłym łączem? Wtedy wysyłaj przez przekaźnik.
- Utrzymuj listy odbiorców w czystości. Nieistniejące adresy wychodzą już w kroku 5, na długo przed oceną jakiejkolwiek treści.
Treść wiadomości decyduje o jej doręczeniu dopiero wtedy, gdy wszystko wcześniej się zgadza. Warto szukać błędu w tej kolejności, w jakiej sprawdza serwer.