Co to jest protokół SMTP i jak działa wysyłanie e-maili?

Protokół SMTP to zbiór technicznych reguł komunikacji, który odpowiada za fizyczne przekazywanie wiadomości tekstowych i załączników z serwera nadawcy na serwer odbiorcy w internecie. Wysyłanie e-maili działa na zasadzie sztafety, gdzie twój program pocztowy przekazuje paczkę danych do lokalnego węzła, a ten, odpytując systemy domenowe, znajduje właściwy adres docelowy i pcha komunikat dalej do maszyny końcowej. Bez tego standardu globalna wymiana informacji w sieci w ogóle by nie istniała.

Prawda jest zresztą absolutnie taka, że większość użytkowników traktuje pocztę elektroniczną jak magię. Klikasz przycisk i po sekundzie tekst pojawia się na telefonie odbiorcy na drugim końcu świata. My po stronie administracyjnej widzimy to zupełnie inaczej. Widzimy surowy tekst, żądania autoryzacyjne, nagłówki kryptograficzne i niekończące się logi błędów. SMTP, czyli Simple Mail Transfer Protocol, został zdefiniowany w 1982 roku w dokumencie RFC 821. To technologia stara jak sam komercyjny internet. Mimo to trzyma się mocno. Przez dekady obudowano ją łatkami bezpieczeństwa, by w ogóle przetrwała atak spamerów.

Co to jest protokół SMTP w codziennej praktyce administratora?

Kiedy mówimy o infrastrukturze pocztowej, musimy rozdzielić pojęcia. Masz program na swoim komputerze, na przykład Outlook albo Thunderbird. To jest MUA, czyli Mail User Agent. Ten program jest całkowicie głupi. Nie potrafi sam z siebie dostarczyć wiadomości do serwera w innej firmie. MUA musi połączyć się z maszyną wysyłającą, którą nazywamy MTA. Mail Transfer Agent to oprogramowanie serwerowe typu Postfix, Exim albo Microsoft Exchange. SMTP to język, w którym MUA dogaduje się z MTA. A potem MTA używa tego samego języka, by dogadać się z kolejnym MTA w internecie.

Robiliśmy wdrożenie serwera Postfix dla małego biura rachunkowego na warszawskim Mokotowie. Konfiguracja wydawała się banalna. Zwykła autoryzacja, certyfikaty wygenerowane, porty otwarte. A jednak o trzeciej nad ranem we wtorek system zaczął wypluwać masowe błędy połączeń. Okazało się, że stary firmowy firewall sprzętowy sprzętowy dławił ruch wychodzący, bo ktoś dziesięć lat temu nałożył limit pakietów na sesje tekstowe. Musieliśmy przepisać reguły zapory z palca. To pokazuje brutalną prawdę o sieciach. Czasami najprostszy protokół wysypuje się na fizycznej warstwie u klienta.

Protokół ten działa wyłącznie w oparciu o architekturę klient-serwer. Inicjator otwiera sesję TCP. Maszyna docelowa odpowiada kodem numerycznym. Zawsze jest to sekwencja komend i odpowiedzi. Klient mówi HELO lub EHLO. Serwer odpowiada kodem 250, co oznacza zgodę na dalszą rozmowę. Potem idzie komenda MAIL FROM określająca nadawcę, a następnie RCPT TO definiująca odbiorcę. Na samym końcu wpada komenda DATA. To jest moment, w którym przesyłasz właściwą treść wiadomości. Kropka w pustej linii kończy transmisję. Serwer potwierdza odbiór. Koniec sesji.

Jakie role pełnią demony pocztowe w tle?

Demony pocztowe to procesy działające na serwerach linuksowych lub uniksowych, które nasłuchują żądań. Czekają w nieskończoność na to, aż jakaś maszyna z zewnątrz zapuka do ich drzwi. Kiedyś te demony akceptowały wszystko od każdego. Serwery działały jako tak zwane open relays. Jeśli chciałeś wysłać anonimową groźbę, po prostu podłączałeś się pod niezabezpieczony serwer uniwersytecki w Stanach Zjednoczonych i kazałeś mu przekazać wiadomość dalej. Dzisiaj to jest niemożliwe. Każdy szanujący się demon pocztowy żąda loginu i hasła od własnych użytkowników, a od obcych maszyn wymaga twardych dowodów kryptograficznych.

Wprowadziliśmy u siebie rygorystyczne limity dla demonów nasłuchujących. Domyślny timeout dla połączeń w starych wersjach demona Exim wynosił ledwie kilka minut, co przy obecnym obciążeniu węzłów kończy się zrywaniem sesji w bez mała połowie przypadków przy dużych załącznikach. Zmieniliśmy te zasady na robocie. Podbiliśmy limity czasowe i nagle odsetek niedoręczonych paczek spadł do zera. Czasami poprawa infrastruktury polega na zmianie jednej cyfry w pliku tekstowym ukrytym głęboko w systemie plików.

Jak działa wysyłanie e-maili krok po kroku na poziomie sieci?

Zastanawiacie się zresztą, dlaczego to na produkcji tak wyje na testach po drodze? Sam się nad tym borykałem dzisiaj u siebie we wtorek. Musimy prześledzić dokładną ścieżkę pakietu. Piszesz maila do klienta. Wciskasz enter. Twój telefon nawiązuje połączenie szyfrowane z serwerem twojego dostawcy usług pocztowych. Autoryzujesz się. Przekazujesz paczkę. Twój dostawca przyjmuje zadanie i odkłada wiadomość do kolejki (spool). Od tego momentu to serwer martwi się o dostarczenie danych. Twój telefon może zostać wyłączony.

Serwer nadawcy musi teraz dowiedzieć się, gdzie fizycznie znajduje się serwer odbiorcy. Adresy e-mail mają format [email protected]. System pocztowy wyciąga z tego ciągu znaków samą domenę. Następnie odpytuje globalne serwery DNS o rekordy MX. MX to skrót od Mail Exchange. Rekord ten zawiera jawną informację o tym, jaka maszyna obsługuje pocztę dla danej firmy. DNS zwraca adres IP. Twój serwer nawiązuje połączenie z tym adresem IP. Znowu używa protokółu SMTP. Przekazuje paczkę. Maszyna odbiorcy zapisuje wiadomość na dysku twardym i czeka, aż odbiorca pobierze ją na swój komputer za pomocą zupełnie innej technologii. To proste. Skuteczne. Działa.

Po co nam w ogóle rekordy MX i system DNS?

Bez systemu DNS poczta elektroniczna wymagałaby wpisywania ciągów liczb zamiast przyjaznych nazw. DNS to książka telefoniczna internetu. Rekordy MX mają przypisane priorytety. Duże korporacje mają dwa lub cztery serwery pocztowe odbierające ruch. Jeśli główny serwer o priorytecie 10 ulegnie awarii z powodu braku prądu, maszyna nadawcy automatycznie spróbuje połączyć się z serwerem zapasowym o priorytecie 20. Ta redundancja sprawia, że e-maile rzadko giną bezpowrotnie w eterze.

Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał przed spowolnieniem rynku. Czasami administratorzy błędnie konfigurują rekordy zapasowe. Zapasowa maszyna przyjmuje pocztę, ale nie potrafi jej potem zsynchronizować z główną bazą danych. Wtedy maile wiszą w próżni. Klient dzwoni z pretensjami. A ty musisz ręcznie przepychać pliki tekstowe z jednego serwera na drugi za pomocą narzędzi konsolowych.

Dlaczego numery portów pocztowych wywołują tyle awarii?

Komunikacja w internecie odbywa się przez określone bramki, zwane portami. Każdy protokół ma swój domyślny numer. Historycznie SMTP działał na porcie 25. Został on przydzielony na początku lat osiemdziesiątych. Problem polega na tym, że port 25 służył do wszystkiego. Służył do wysyłania poczty przez użytkowników i do przekazywania poczty między serwerami. Kiedy pojawił się problem spamu, dostawcy internetu domowego zaczęli masowo blokować port 25. Zrobili to, by zawirusowane komputery domowe nie mogły wysyłać milionów reklam bezpośrednio w świat.

Dzisiaj zasada jest prosta i brutalna. Twój program pocztowy powinien używać portu 587. To port przeznaczony wyłącznie do przyjmowania wiadomości od autoryzowanych użytkowników. Wymaga on logowania i zazwyczaj wymusza szyfrowanie TLS. Port 25 zostawiamy wyłącznie dla komunikacji między serwerami w szkielecie internetu. Jeśli spróbujesz skonfigurować Outlooka na porcie 25 w domowej sieci WiFi, twój pakiet po prostu zginie na routerze dostawcy bez żadnego ostrzeżenia.

Co się stało z portem 465?

Historia portu 465 to klasyczny przykład bałaganu w komitetach standaryzacyjnych. W latach dziewięćdziesiątych ktoś wpadł na pomysł stworzenia SMTPS. Chodziło o całkowicie zaszyfrowany wariant protokołu, analogiczny do HTTPS. Przypisano mu port 465. Niedługo potem inna grupa inżynierów stwierdziła, że to głupie. Zamiast tworzyć osobny port, wymyślili komendę STARTTLS, która pozwalała przejść na szyfrowanie w ramach istniejącego połączenia na porcie 25 lub 587. Port 465 oficjalnie wycofano. A potem okazało się, że miliony programów na świecie już go używają. I używają go do dziś. My, jako administratorzy, musimy nasłuchiwać na wszystkich trzech portach jednocześnie. Inaczej ktoś odetnie sobie dostęp do firmy.

W jaki sposób serwery pocztowe weryfikują tożsamość nadawcy?

Główną i fundamentalną wadą SMTP jest brak wbudowanej weryfikacji nadawcy. Mogę połączyć się z serwerem i w komendzie MAIL FROM wpisać adres prezesa twojej firmy. Protokół to przyjmie. Oprogramowanie to przetworzy. W latach dwutysięcznych ten problem doprowadził do załamania zaufania w sieci. Spamerzy podszywali się pod banki, urzędy i korporacje. Prawda jest zresztą absolutnie taka, że połowa tych rzekomo inteligentnych filtrów antyspamowych to jeden wielki syf konfiguracyjny, który musisz naprawiać ręcznie. Branża IT musiała wymyślić nakładki weryfikacyjne opierające się na systemie DNS.

Pierwszym mechanizmem jest SPF, czyli Sender Policy Framework. To zwykły wpis tekstowy w konfiguracji domeny, który publikuje listę adresów IP uprawnionych do wysyłania poczty w imieniu tej domeny. Kiedy serwer odbiorcy przyjmuje połączenie, sprawdza IP nadawcy. Jeśli IP nie pasuje do listy opublikowanej w SPF, serwer odnotowuje naruszenie. Może wiadomość odrzucić, a może tylko dorzucić punkty spamu. To zależy od lokalnej polityki.

Drugim filarem jest DKIM. DomainKeys Identified Mail wprowadza kryptografię asymetryczną bezpośrednio do struktury e-maila. Serwer wysyłający posiada klucz prywatny. Przed wypchnięciem wiadomości w świat, maszyna oblicza sumę kontrolną z nagłówków i treści, a następnie podpisuje ją tym kluczem prywatnym. Podpis ląduje w nagłówku wiadomości. Serwer odbiorcy pobiera klucz publiczny z systemu DNS i weryfikuje matematyczną zgodność podpisu. Jeśli ktokolwiek po drodze zmienił choć jedną literę w załączniku, podpis staje się nieważny. To po prostu matematyka. Nie oszukasz jej.

Dlaczego DMARC wywołuje panikę u marketerów?

SPF i DKIM działały niezależnie, co rodziło luki. Dlatego stworzono DMARC. Domain-based Message Authentication, Reporting, and Conformance to polityka, która mówi serwerowi odbiorcy dokładnie to, co ma zrobić, gdy SPF lub DKIM zawiodą. Możesz ustawić politykę na „none” dla celów testowych, „quarantine”, żeby podejrzane maile trafiały do folderu spam, albo uderzyć twardo w „reject”. Opcja reject sprawia, że serwer po prostu ODRZUCA pakiet. Nie ma dyskusji. Grubo ponad osiemdziesiąt procent firm, które włączają DMARC na twardo bez wcześniejszych audytów, blokuje własną komunikację marketingową. Wystarczy, że dział handlowy użyje zewnętrznego narzędzia do wysyłki newsletterów bez dodania ich adresów IP do wpisu SPF. Katastrofa gotowa.

Czy SMTP odbiera wiadomości od użytkowników?

Tutaj panuje ogromne niezrozumienie wśród ludzi spoza działów technicznych. SMTP służy wyłącznie do wypychania wiadomości. Push. Nie potrafi pobrać e-maili z serwera na twój telefon. Do czytania poczty służą zupełnie inne technologie. Dawniej królował POP3, czyli Post Office Protocol w wersji trzeciej. POP3 łączył się z serwerem, pobierał plik na dysk lokalny i od razu kasował oryginał. Był świetny w czasach, gdy dyski serwerowe miały pojemność liczoną w megabajtach.

Dzisiaj używamy IMAP. Internet Message Access Protocol pozwala na synchronizację folderów w czasie rzeczywistym. Widzisz strukturę katalogów na serwerze. Kiedy czytasz wiadomość na telefonie, oznacza się ona jako przeczytana na komputerze w biurze. IMAP i SMTP działają zawsze w parze. Konfigurując nowego klienta pocztowego, musisz podać dane do serwera wychodzącego dla wysyłki i do serwera przychodzącego dla odbioru. To dwie oddzielne usługi, często działające na dwóch różnych maszynach fizycznych. Środowisko IT dzieli te role dla bezpieczeństwa i rozłożenia obciążenia procesorów.

Jak diagnozować odrzucenia wiadomości i błędy doręczeń?

Z punktu widzenia administratora systemów Linux, wysyłanie e-maili to ciągła walka z odrzuceniami. Kiedy wiadomość nie dociera, serwer nadawcy generuje NDR. Non-Delivery Report to automatyczny komunikat zwrotny. Zawiera on kod błędu wygenerowany przez maszynę docelową. Kody te dzielą się na dwie główne rodziny. Błędy z puli 4xx oznaczają problemy tymczasowe. Przeciążenie serwera, brak miejsca na dysku u odbiorcy, albo tymczasowa blokada antyspamowa. Twój serwer spróbuje wysłać paczkę ponownie za kilkanaście minut. Błędy 5xx to wyrok ostateczny. Adres nie istnieje, domena wygasła, albo twoje IP trafiło na czarną listę RBL. Serwer poddaje się natychmiast i informuje cię o porażce.

Czarne listy RBL to prywatne bazy danych utrzymywane przez organizacje walczące ze spamem. Jeśli z twojego adresu IP nagle wyjdzie dziesięć tysięcy dziwnych wiadomości, automaty trafisz na taką listę. Inne serwery na świecie, widząc twoje IP, odrzucą połączenie już na etapie przywitania TCP. Wyciąganie adresu z listy Spamhaus czy Barracuda to proces upokarzający i bolesny. Wymaga pisania zgłoszeń, udowadniania, że usunąłeś złośliwe oprogramowanie z sieci i proszenia o łaskę. Nikt nie chce tego robić w piątek po południu.

Reputacja domeny to zupełnie inna bajka. Google i Microsoft używają własnych, zamkniętych algorytmów sztucznej inteligencji do oceny ruchu. Chociaż prawdę mówiąc brakuje nam twardych danych za wczoraj, więc wydaje się to tylko jedną z możliwych hipotez na najbliższy kwartał, że analizują zaangażowanie użytkowników. Jeśli wysyłasz maile, a ludzie masowo przenoszą je do kosza bez czytania, twój wskaźnik reputacji spada. Żadne certyfikaty ci nie pomogą. Algorytm uzna cię za spamera i twoje wiadomości wylądują w folderze niechciane u wszystkich klientów korzystających z Gmaila. Zbudowanie dobrej historii domeny zajmuje miesiące. Zniszczenie jej zajmuje jeden błędny skrypt z masową wysyłką w tle.

FAQ – Najczęściej zadawane pytania o infrastrukturę e-mail

• Jakiego portu SMTP powinienem użyć do konfiguracji poczty? Zawsze używaj portu 587 z włączonym szyfrowaniem STARTTLS. Port 25 jest blokowany przez większość dostawców internetu, a port 465 jest technicznie przestarzały, choć nadal działa na starych serwerach.
• Co oznacza błąd 550 w zwrotce pocztowej? Błąd 550 oznacza ostateczne odrzucenie wiadomości. Najczęstszą przyczyną jest błędny adres e-mail odbiorcy, brak konta na serwerze docelowym lub twarda blokada twojego adresu IP przez filtry antyspamowe.
• Czy SMTP i IMAP to to samo? Nie. SMTP służy wyłącznie do wysyłania wiadomości w sieć. IMAP to protokół służący do odbierania i synchronizowania poczty z serwera na twój telefon czy komputer.
• Dlaczego moje maile trafiają do folderu SPAM? Najprawdopodobniej brakuje ci poprawnie skonfigurowanych rekordów SPF, DKIM oraz DMARC w strefie DNS twojej domeny. Innym powodem może być niska reputacja twojego adresu IP na globalnych listach RBL.
• Czym jest rekord MX? Rekord MX (Mail Exchange) to wpis w systemie DNS, który informuje resztę internetu, jaki konkretnie serwer odpowiada za odbieranie poczty dla danej domeny.
• Jak sprawdzić, czy mój serwer pocztowy wysyła dane bezpiecznie? Możesz użyć narzędzi konsolowych takich jak telnet lub openssl s_client, aby ręcznie połączyć się z serwerem i sprawdzić, czy demon pocztowy odpowiada na komendę STARTTLS wymuszając szyfrowanie TLS.

Przejrzyj logi swoich własnych serwerów pocztowych już dzisiaj. Spróbuj wyciągnąć z nich kody błędów z ostatnich dwudziestu czterech godzin i sprawdź, ile wiadomości z twojej firmy zostało odbitych przez braki w rekordach DNS na twardo. Zobaczysz surowe dane, z którymi nie da się dyskutować.

Bibliografia:

1. Naukowa i Akademicka Sieć Komputerowa – https://nask.pl
2. Ministerstwo Cyfryzacji – https://www.gov.pl/web/cyfryzacja
3. Główny Urząd Statystyczny – https://stat.gov.pl
4. Urząd Komunikacji Elektronicznej – https://uke.gov.pl
5. Wydawnictwo Naukowe PWN – https://pwn.pl