Mimo mnogości sposób komunikowania się przez sieć, nadal maile są królami. Nic dziwnego, gdyż jest to poczta elektroniczna, a więc najbliższy elektroniczny odpowiednik tradycyjnych listów, które ciągle są przecież najbardziej odpowiednią pisemną formą przekazywania treści formalnych i nieformalnych na odległość (miłosnych już rzadziej). A skomputeryzowana wersja tego przekazu jest o niebo wygodniejsza, pozwala przetwarzać więcej i szybciej, że o kosztach magazynowania już nie wspomnę. Niekoniecznie zawsze jest to zaleta (spam, spam, spam...), ale nie bez powodu nadal maile służą m.in. do:

• przesyłania linków aktywacyjnych przy rejestracji w serwisie,
• przekazywania informacji o długo generowanych raportach,
• newsletterów,
• potwierdzania zakupów i płatności,
• oficjalnej komunikacji z uczelnią, miejscem pracy itd.,
• ofert zakupowych,
• próśb banku o zaktualizowanie numeru dowodu osobistego, bo oni wiedzą, kiedy mija termin.

I niezależnie od tego, czy nasza aplikacja obsługuje inne formy powiadomień, jak te umieszczane bezpośrednio w oprogramowaniu, push, wyskakujące na pulpicie, SMS-y itd., to i tak na 99% gdzieś znajdzie się potrzeba wysłania starego, poczciwego maila. To oznacza, że trzeba umieć go obsłużyć z poziomu programu i to dla wielu programistów nie jest problem, zwłaszcza, że frameworki (a właściwie biblioteki) znacząco to ułatwiają. Ale czasem tego nie robią, a poza tym niekiedy brakuje wiedzy o tym, co tak naprawdę dzieje się podczas wysyłki elektronicznej wiadomości. Dzisiaj sobie o tym nieco powiemy. Być może wiedza zawarta w tym artykule będzie nieco zbyt szczegółowa do standardowych zastosowań, bo narawdę zarówno klienty pocztowe, jak i biblioteki robią to wszystko w tle, ale lepiej mieć za dużo informacji niż za mało.

Uwaga na boku: jak zauważyliście, używam formy "mail", a nie "e-mail" czy "mejl". W pierwszym przypadku (którego zwolennikiem kiedyś byłem) jakiś czas temu uznałem, że przedrostek "e-" już nie jest potrzebny, gdyż wszyscy wiedzą, o co chodzi i nie ma potrzeby przedłużać pisania tego słowa. Swoją drogą, nadal jestem za pisownią "e-" z łącznikiem i raczej przy tym pozostanę (tak, jak przy e-booku czy e-sporcie - pozdrowienia dla Zbyszka, który teraz na pewno się piekli widząc, że nie piszę "esport"). Natomiast "mejl" wygląda dziwnie, ale jest próbą spolszczenia angielskiego terminu, na którą według językoznawców powinniśmy patrzeć z większą sympatią. I ja patrzę, ale jednak przyznam, że jakoś się nie przekonałem do stosowania.

Jak przebiega wysłanie maila?

Prawdopodobnie wszyscy czytający te słowa potrafią wysłać maila - wchodzą do ulubionego klienta pocztowego (Thunderbird, Outlook, Apple Mail itd.), wybierają wysłanie wiadomości, wpisują treść, tytuł, wybierają nadawcę i klikają "wyślij". Koniec mistrzostw, do widzenia, pora na CS-a. Większości osób ta wiedza całkowicie wystarczy, ale nie programistom - ci bowiem czasem muszą wysłać maila nie w sposób graficzny, tylko poprzez odpowiednie API, bibliotekę lub generalnie programowo. I chociaż w większości wypadków to te narzędzia załatwią za nas sprawę, to jednak warto wiedzieć, jak to działa od środka, także dlatego, że po drodze pojawia się wiele terminów, które przewijają się np. przy konfigurowaniu dostępu.

Przede wszystkim, musi to wszystko obsługiwać jakiś ustandaryzowany protokół internetowy, czyli zestaw reguł (napisałbym "algorytm", ale ChatGPT zaczął gonić mnie z wałkiem, gdy weryfikował informacje w tym tekście...), który odpowiada za określoną operację w świecie Internetu. Przykładem takiego protokołu jest HTTP do obsługi stron internetowych w sieci WWW. W przypadku odbierania maili jest to IMAP lub powoli wycofywany POP3. Natomiast nas bardziej interesuje protokół służący do wysyłki wiadomości - jest to SMTP (Simple Mail Transfer Protocol), który jest z nami od lat 80. XX wieku. Jeśli gdzieś przy okazji konfigurowania poczty elektronicznej musimy podać hosty serwerów poczty przychodzącej lub wychodzącej, to w tym drugim przypadku właśnie chodzi o SMTP - klient pocztowy musi wiedzieć, gdzie ma wysłać wiadomość, na jaki port i w jaki sposób, aby serwer potem pokierował ją dalej. Zupełnie jak to, że po wpisaniu danego adresu w przeglądarce trafimy do serwera o konkretnym adresie IP.

Na nieco większym poziomie szczegółowości wygląda to tak:

1. Użytkownik w kliencie pocztowym wprowadził wszystkie informacje o mailu.
2. Klient Rozpoczyna połączenie z serwerem SMTP, który jest odpowiedzialny za przyjęcie wiadomości od tego użytkownika lub aplikacji i dalszą wysyłkę. Przykładowo, jeśli masz maila w Google'a (domena gmail.com), to łączenie następuje z serwerem smtp.gmail.com. Dzieje się to na określonym porcie - dawniej było to zazwyczaj 25, obecnie częściej jest to 465, ew. 587. Wybór wynika ze sposobu zabezpieczenia:
• 465 obsługuje szyfrowane połączenie TLS od początku i jest to tzw. Implicit TLS. Często określane jako SSL,
• 587 obsługuje szyfrowanie TLS poprzez rozpoczęcie normalnej sesji SMTP i podania po drodze komunikatu STARTTLS,
• a 25 to "jakoś to będzie, po co się martwić", bez uwierzytelnienia i z tego powodu nie powinno się z niego korzystać - obecnie służy tylko do porozumiewania się serwerów pocztowych (konkretnie agentów MTA) ze sobą. Aczkolwiek trzeba przyznać, że też mogą używać STARTTLS do szyfrowania, ale nie bez powodu odradza się port 25 do wysyłania maili przez użytkownika.
3. Serwer SMTP odpowiada kodem 220 i czeka na dalsze instrukcje. Zaczyna się sesja SMTP, w trakcie której będą przesyłane różne komunikaty.
4. Klient przesyła HELO (lub EHLO, jeśli zaraz będziemy chcieli szyfrować i się uwierzytelniać; "E" jest od "Extended"), przedstawiając się serwerowi. Serwer potwierdza to kodem 250.
5. Jeśli klient chce zabezpieczyć komunikację, wysyła komendę STARTTLS - w tym momencie klient i serwer negocjują szyfrowanie, podobnie jak się to dzieje przy łączeniu ze stroną internetową protokołem HTTPS. Co ciekawe, po STARTTLS następuje ponowna wymiana komunikatów EHLO.
6. Teraz następuje zalogowanie się na konto nadawcy. Klient podaje komendę AUTH (np. AUTH LOGIN) oraz login użytkownika i jego hasło. Jeśli się zgadzają, serwer odeśle kod 235. Oprócz AUTH LOGIN może też być AUTH PLAIN (hasło podane jawnie), ale także XOUATH2, o czym jeszcze będziemy mówić.
7. Klient przesyła komunikat MAIL FROM, czyli określa nadawcę, a w odpowiedzi dostaje od serwera kod 250. Po co ten komunikat, skoro już się zalogowaliśmy? Dlatego, że możemy ukryć prawdziwego nadawcę i podać np. adres typu "noreply" do maili, na które nie chcemy odpowiedzi. Użytkownik z kolei widzi to, co potem będzie w nagłówku "From".
8. Klient przesyła odbiorcę komendą RCPT TO, dostając w odpowiedzi od serwera kod 250. Gdy odbiorców jest wielu, to dla każdego następuje powtórzenie komendy RCPT TO, niezależnie od tego, czy to odbiorca jawny, osoba do kopii (CC, DW) czy niejawnej kopii (BCC, UDW). W tym ostatnim przypadku ukrycie odbiorcy następuje w taki sposób, że ostatecznie nie docierają w nagłówkach wiadomości do pozostałych adresatów.
9. Klient zaczyna przesyłać dane za pomocą komunikatu DATA - po nim serwer odpowiada kodem 354 i czeka dalej. Wtedy klient przesyła różne nagłówki, w tym "Date", "From", "To", "Subject", treść oraz załączniki zakodowane za pomocą Base64. Po podaniu danych kończy się wszystko jak w życiu - kropką (aczkolwiek w osobnej linii). Serwer odpowiada wtedy 250 i już zaczyna przesyłać maila dalej, do docelowego serwera SMTP.
10. Klient kończy sesję poprzez komunikat QUIT i po uzyskaniu od serwera kodu 221 rozłącza się z serwerem SMTP.
11. W międzyczasie serwer SMTP kontynuuje przekazywanie maila, jeśli jeszcze tego nie zrobił. To dlatego może nam się wydawać, że klient już wysłał wiadomość, a dopiero po chwili przyjdzie informacja o tym, że jednak mail nie mógł zostać wysłany, gdyż nie można znaleźć odbiorcy lub ten z jakiegoś powodu nie przyjmie maila (np. przez zbyt duży załącznik).

Tak to wygląda pod spodem. Pominąłem tutaj wiele szczegółów, gdyż nie są one istotne dla naszej sprawy. Uprościłem też nazewnictwo - przykładowo, klient pocztowy to coś, co tak naprawdę technicznie określa się jako MUA, a po stronie SMTP jest kolejno MSA, MTA i MDA. Więcej szczegółow można znaleźć np. w tym artykule.

Mimo że punktów jest wiele, to dla programisty ostatecznie najważniejsze jest to, że:

• istnieje serwer SMTP, z którym trzeba się połączyć (ale niekoniecznie bezpośrednio, o czym też później będzie),
• zazwyczaj trzeba się uwierzytelnić (czyli normalnie zalogować), aby wysłać maila,
• różnym sposobom szyfrowania odpowiadają różne porty.

Jakie mamy sposoby uwierzytelnienia się i połączenia?

Wróćmy do punktu z uwierzytelnieniem, gdyż - jak można się domyślać - jest on niezwykle istotny. Zwłaszcza, że taka prosta ścieżka opisana powyżej już jest wygaszana u dużych dostawców w rodzaju Google lub Microsoft.

Mianowicie, przekazywanie loginu i hasła poprzez tzw. Basic Authentication jest już bardzo odradzane ze względów bezpieczeństwa. Nie oznacza to, że nie będzie dostępne w ogóle, gdyż mniejsi dostawcy poczty jeszcze długo nadal będą obsługiwać tę drogę (piszę to w sierpniu 2026 roku). Tym niemniej, warto o tym wiedzieć, gdyż ma to duży wpływ na programistów. Musimy być świadomi, że czymś innym są:

• SMTP - protokół, sposób komunikacji z serwerem pocztowym, działającym pod pewnym portem. Ewentualnie z serwerem prowadzącym do serwera pocztowego.
• Sposób uwierzytelniania - czyli metoda pokazania "to moje konto i ja wysyłam maila". Mowiąc łopatologicznie, sposób logowania do serwera.

Ile mamy kombinacji? Całkiem dużo.

1. SMTP + Basic Authentication - klasyka, którą opisałem w poprzednim rozdziale. Wraz z komendą AUTH podawany jest login i hasło. To właśnie będzie wygaszane u dużych dostawców, aczkolwiek nadal powszechnie funkcjonuje w sieci i przez dekady właśnie tak wysyłało się maile, także z aplikacji WWW.
2. SMTP + OAuth2 (XOAUTH2) - wygląda to tak, jak poprzednio (dane uwierzytelniające wysyłane są do serwera SMTP), ale zamiast hasła podawany jest token, wcześniej uzyskany właśnie poprzez endpoint OAuth2 na drodze osobnego logowania. Oczywiście, dostawca poczty musi umożliwiać uzyskanie takiego tokenu. Ale jeśli to robi, to właśnie ta metoda jest preferowana, jeśli jako programiści obsługujemy wysyłanie z serwera pocztowego np. Microsoftu.
3. Microsoft Graph API/GMail API/inne API + OAuth2 (XOAUTH2) - wcześniej zasugerowałem, że można się łączyć z serwerem SMTP niebezpośrednio. Może być bowiem tak, że dany dostawca udostępnia API, gdzie najpierw uzyskujemy token za pomocą OAuth2, a potem przez dany endpoint w API przekazujemy żądanie wysłania maila. I dopiero to API wewnętrznie komunikuje się z serwerem SMTP. W przypadku Microsoftu usługa Graph API obsługuje nie tylko maila, ale też inne serwisy typu OneDrive czy SharePoint, a sam interfejs jako "pośrednik" do SMTP może ogólnie też umożliwiać dużo więcej, łącznie z odbiorem wiadomości, kolejkowaniem itd.
4. Bezpośrednie wysłanie na port 25 przez endpoint MX - a teraz coś z kompletnie innej beczki i tzw. ścieżka dla hardkorów (z certyfikatami czterema). Nie logujemy się, nie łączymy z SMTP, tylko bezpośrednio odtwarzamy całą wysyłkę poprzez wcześniej opisywane komendy tak, jak byśmy byli serwerem SMTP. Bardzo niewygodne, niskopoziomowe i mówiąc szczerze, często niepotrzebne, o ile nie chcemy tworzyć własnego agenta MTA (Mail Transfer Agent). A MX to jeden z rekordów odczytywanych z serwera DNS.

Istnieją też inne metody, już bardziej zależne od dostawcy poczty, natomiast w 99,9% przypadków będziemy mieli do czynienia z pierwszymi trzema (czwartą opisałem jako ciekawostkę do samodzielnych poszukiwań). Dobra biblioteka do wysyłania poczty np. z aplikacji PHP pozwoli nam po prostu podać wszystkie dane maila i zrobi to za nas, a często też pomoże w zdobyciu tokenu OAuth2, jeśli jest to potrzebne. A jeśli nie, to można go zdobyć za pomocą innych bibliotek lub po prostu samodzielnie obsługując żądania HTTP, które do tego służą.

Czy to oznacza, że na serwerze pocztowym można wyłączyć SMTP? Nie - on nadal jest wykorzystywany do wysyłania maili. Natomiast może istnieć sytuacja, w której rekomendowane będzie ograniczenie logowania się do niego bezpośrednio dla określonych kont. Stąd warto sprawdzić, czy nasza aplikacja wysyłająca wiadomości używa specjalnie przeznaczonego do tego konta pocztowego.

A co jeżeli do wysłania jest wiele maili?

Słuszne pytanie - dobrze znamy systemy, które muszą wysłać naraz tysiące maili, np. w postaci newslettera, informacji o zmianie regulaminu czy z informacją promocyjną. Jeśli mowa byłaby o kilkunastu czy nawet kilkudziesięciu mailach, to sprawa jest dość prosta - wysyła się je po prostu jeden po drugim, gdyż taka ilość nie powinna spowodować niczego złego wobec serwera SMTP. Ale co z setkami, tysiącami czy nawet milionami wiadomości elektronicznych?

Najprostszy sposób to jedna wiadomość e-mail, ale z wieloma odbiorcami, oczywiście, jako ukryte kopie (zapamiętajcie to, bo branża zna zbyt wiele sytuacji, w których wszyscy odbiorcy w niechciany sposób radośnie się dowiedzieli o sobie nawzajem, czym zwrócili na siebie uwagę inspektora UODO). To naturalna droga, często też odtwarzana przy ręcznej wysyłce maila, kiedy wpisujemy wielu adresatów. Natomiast ta metoda ma dwie wady:

• liczba odbiorców zależy od dostawcy poczty i najczęściej jest to 500 adresów,
• nie można spersonalizować maila, co dotyczy także linków.

Z tego powodu na myśl przychodzi inne rozwiązanie - istnieje możliwość otwarcia jednej sesji SMTP i wysłania wielu wiadomości w jej ramach. Wówczas mamy do czynienia z osobnymi wiadomościami (i można jawnie podać odbiorcę), ale serwer traktuje to jako swego rodzaju paczkę (batch, choć w świecie maili często się używa słowa "bulk"). W ten sposób działają popularne biblioteki do wysyłania maili z poziomu aplikacji, aczkolwiek w większości przypadków i tak wykorzystuje się je do wysłania po jednym mailu.

Czasem dostępnych jest wiele serwerów SMTP, najczęściej jako "ratunkowe" na wypadek, gdyby nie działał ten właściwy. Jednak drugą cechą takiej sytuacji jest właśnie bilansowanie wysyłania maili i tym samym osiągnięcie większej przepustowości. Jest to swego rodzaju load balancer do poczty elektronicznej, choć często samemu trzeba decydować o serwerze SMTP, z którego chcemy skorzystać.

Niezależnie od wszystkiego, należy pamiętać o tym, że można rozdzielić utworzenie maila od jego wysłania. W momencie, kiedy aplikacja ma do nadania setki tysięcy maili, to najczęściej, zamiast przekazywać je bezpośrednio do serwera SMTP, umieszcza je w kolejce sterowanej przez tę samą lub inną aplikację. Dopiero ona, okresowo (np. przez mechanizm crona) wysyła je w paczkach liczących określoną liczbę sztuk np. co minutę. W ten sposób działają zewnętrzne usługi do newsletterów, które w dodatku dysponują rozbudowaną infrastrukturą, z wieloma serwerami SMTP, nieskazitelną reputacją utrudniającą zakwalifikowanie wysłanych maili jako spam (do tego jeszcze wrócimy) oraz mechanizmami konfigurowania wiadomości (np. personalizacją). Można też takie oprogramowanie napisać samemu, dedykowane do swojej aplikacji i tutaj ciekawostka - Feedybacky do wysyłki maili korzysta z prostej, napisanej przez nas aplikacji, która właśnie kolejkuje wiadomości.

Należy też pamiętać, że limitowanie wysyłek po stronie nadawcy to jedno, ale także serwery SMTP odbiorców mają swoje limity. Może zaistnieć sytuacja, w której my bez problemu będziemy mogli przesłać 1000 maili, ale jeśli wszystkie są do jednego serwera (np. smtp.gmail.com), to on może odrzucić nadmiarową liczbę przez swoje mechanizmy obronne. Może nas zaklasyfikować jako potencjalnie niebezpiecznego nadawcę rozsyłającego spam.

Ochrona przed zostaniem spamerem

Można tego uniknąć poprzez rozsądne dawkowanie wiadomości e-mail, ale także zadbanie o:

• SPF (Sender Policy Framework) - rekord DNS, gdzie widnieje lista serwerów lub adresów IP uprawnionych do wysłania poczty. Jest to rekord TXT zaczynający się od v=spf1..., gdzie podane są właśnie "autoryzowane" przez nas serwery. Ten rekord jest sprawdzany przez serwer SMTP odbiorcy wiadomości, ale trzeba uważać na sytuacje, w których nasz mail dociera po wielu przekierowaniach.
• DKIM (DomainKeys Identified Mail) - kolejny rekord DNS typu TXT, tym razem z v=DKIM1..., który publikuje klucz publiczny serwera. Z kolei wiadomość jest wysyłana podpisanym kluczem prywatnym z odpowiednim nagłówkiem wskazującym na oryginalną domenę wysyłki wiadomości. Ważne: to nie oznacza, że mail jest szyfrowany - jest tylko podpisany kluczem po to, aby odbiorca mógł to zweryfikować odpytując o klucz publiczny. Dzięki temu wie, że z tej domeny przyszła wiadomość i nikt jej nie zmienił po drodze.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) - sprawdza powiązanie uwierzytelnionej domeny z tą, która jest widoczna w nagłówku "From". Ponownie mamy tutaj do czynienia z rekordem DNS typu TXT (tym razem v=DMARC1...), który może zawierać regułę, jak "none" (sprawdzaj, ale nic nie rób), "quarantine" (traktuj podejrzliwie), "reject" (odrzucaj). Ostatnia opcja jest najlepsza, bo znacząco utrudnia podszycie sie pod nas, ale korzystajmy z niej tylko wówczas, kiedy mamy pewność, przez jakie serwery faktycznie przechodzi nasza wiadomość.
• używanie TLS - czyli stosowanie szyfrowania wiadomości, co oznacza, że nadawca poważnie podchodzi do bezpieczeństwa.
• zapewnienie mechanizmu odsubskrybowania za pomocą jednego kliknięcia - może być weryfikowane przez większych dostawców, ponownie upewniejących się, że jesteśmy "profesjonalni". Ale to nie wszystko - warto zapewnić nagłówki "List-Unsubscribe: link z indywidualnym tokenem" oraz "List-Unsubscribe-Post: List-Unsubscribe=One-Click", co wiele mówi np. Gmailowi przy odbieraniu i wyświetlaniu poczty.
• zapewnienie dobrej reputacji domeny oraz adresu IP, czyli dbanie o historię swojej "działalności" - jeśli nasza poczta "sprawia problemy", wiadomości z niej są często odrzucane lub były skargi na nasze maile, to nasza reputacja będzie słaba, co oznacza większe prawdopodobieństwo trafienia do spamu. Dlatego należy uważać i nie przesadzać z częstotliwością wysyłek mailowych, zadbać o to i aby nikt niepowołany nie korzystał z naszego serwera pocztowego oraz - co tu dużo mówić - nie zaśmiecać skrzynek użytkownikom dziwnymi treściami. To samo dotyczy serwera, jak i domeny.

W przypadku korzystania z zaufanych dostawców serwera SMTP (Google, Microsoft, systemy newsletterowe) ten problem częściowo spada nam z głowy, ale schody zaczynają się przy własnym serwerze lub po prostu mniej popularnym. Mówiąc szczerze, rzadko istnieje potrzeba samodzielnej konfiguracji tego typu rekordów, choć nie jest to niespotykane, dlatego podałem tylko podstawowe informacje, bez dokładnego omówienia - zazwyczaj programiści nie są angażowani w działania tego typu. Trzeba jedynie pamiętać o rozgraniczeniu, że czymś innym jest domena (np. mojawspanialastrona.pl), a czym innym serwer, na którym jest SMTP (np. Microsoft) - zupełnie jak przy aplikacjach webowych.

Specjaliści zalecają również rozdzielenie domen i serwerów dla maili standardowych (np. z linkiem do resetu hasła) oraz do masowych wysyłek (jak np. newsletter). Nie jest to ostateczne remedium, ale pozwoli ograniczyć "straty", gdy w wyniku niezbyt rozważnych działań kombinacji marketingowców i programistów, użytkownicy nie dostaną faktycznie istotnego maila z naszego serwisu.

A czym jest EML?

Wychodzimy na chwilę ze świata serwerów SMTP, zabezpieczeń itd. i przechodzimy na poziom samej wiadomości e-mail. Czasem możemy natknąć się na pliki o rozszerzeniu .eml - jest to ogólnie przyjęty format zapisu pojedynczej wartości e-mail i początkowo został opracowany przez firmę Microsoft, stopniowo stając się standardem w tej materii. Takie pliki można wyeksportować z maili w programie pocztowym (Outlook, Thunderbird itd.), otworzyć je w takim kliencie, zapisać na dysku jako ważny mail, którego nie można zgubić (np. podpiąć jako załącznik w bazie wiedzy), ale także - co ciekawe - otworzyć w przeglądarce internetowej po zmianie rozszerzenia na .mht (to taka sama sztuczka, jak zmiana androidowego rozszerzenia .apk na .zip).

EML to tak naprawę zwykły plik tekstowy o określonej strukturze, który zawiera wszystko, co jest potrzebne do otwarcia danego maila w ładnej, graficznej formie w kliencie pocztowym (łącznie z informacjami o załącznikach). Trzeba jednak przyznać, że nie zawsze "ręczne" czytanie takiej wiadomości jest przyjemnością, gdyż różne fragmenty mogą byc kodowane w nieczytelny dla ludzkiego oka sposób.

Szyfrowanie PGP

Wspomnieliśmy o tym, że za pomocą TLS/STARTTLS możemy zaszyfrować wiadomość tak, aby nie była ona możliwa do odkodowania podczas przesyłania przez serwery SMTP. Wówczas komunikacja jest szyfrowana, ale sam mail nie - ktoś, kto w jakiś sposób wejdzie na serwer SMTP do jego plików, może zobaczyć nasze wypociny. Dlatego można pokusić się o szyfrowanie maila w taki sposób, aby nawet serwer SMTP nie dostał jej w "czystej" formie i wyświetlić mógł wyłącznie nadawca oraz odbiorcy w swoich klientach pocztowych.

Poznajmy OpenPGP (Open Pretty Good Privacy), a więc protokół, który wykorzystuje klucze na podobnej zasadzie jak SSH do zaszyfrowania wiadomości kluczem publicznym odbiorcy, a potem odszyfrowania wiadomości przez odbiorcę swoim kluczem prywatnym. Wówczas wszyscy po drodze (łącznie z serwerami SMTP) widzą zakodowaną treść, której nie mogą przeczytać. To, oczywiście, oznacza, że nadawca musi najpierw pozyskać klucz publiczny odbiorcy (zazwyczaj wzajemnie), wgrać je do swoich klientów pocztowych i następnie szyfrować nim swoje wiadomości. Klient pocztowy pokazuje zresztą, czy dana wiadomość została zaszyfrowana.

Absolutnie nie wykorzystuje się tego do normalnych czy masowych maili wysyłanych przez aplikacje - nie spotkałem jeszcze aplikacji webowej (choć zapewne istnieją bardziej specjalizowane), który wymagałby podania klucza publicznego do tego celu. To rozwiązanie bardziej na wyjątkowo dyskretną komunikację z danymi wrażliwymi, osobami piastującymi odpowiedzialne stanowiska lub pracujące w działach np. bezpieczeństwa.

Warto przy tym wyjaśnić, skąd rozróżnienie na PGP, GPG i OpenPGP, gdyż faktycznie można się w tym pogubić. Zwłaszcza, że faktyczny obraz sytuacji wymyka się trochę intuicji:

• PGP (Pretty Good Privacy) - historyczny i komercyjny (co ważne) program Phila Zimmermanna, który wprowadził w ogóle ideę szyfrowania maili end-to-end pod strzechy.
• OpenPGP - na bazie PGP powstał standard (otwarty), opisujący jak wyglądają klucze, podpisy, zaszyfrowane wiadomości i generalnie cały proces. Ale czasem mówi się po prostu "PGP", co zresztą uczyniłem w tytule tego rozdziału.
• GPG lub GnuPG (GNU Privacy Guard) - konkretny darmowy program implementujący standard OpenPGP, który służy do wygenerowania kluczy PGP (o tym za chwilę) oraz do ich weryfikacji. Obawiam się, ze przestawienie liter PGP na GPG nie jest przypadkowe i świadczy o wyjątkowym poczuciu humoru w świecie informatycznym.

Jak utworzyć swoją parę kluczy PGP przez GPG (zaiste, jacyś żartownisie przy tym pracowali...)? Należy zainstalować GnuPG i wywołać komendę gpg --full-generate-key. Do wyboru są co najmniej dwa algorytmy szyfrowania, czyli krótszy ECC oraz historyczny i "mocny" RSA. Następnie użytkownik musi podać informacje bardzo podobne do tych, o które jest pytany przy generowaniu kluczy SSH, a więc personalia, firmę, hasło itd. Po przejściu tego procesu można wyeksportować klucz publiczny za pomocą gpg --armor --export [nasz mail] > public-key.asc (rozszerzenie kluczy OpenPGP to .asc), który przekazujemy naszym korespondentom do zaimportowania np. w Outlooku. Istnieje też możliwość wyeksportowania klucza prywatnego poprzez przełącznik --export-secret-keys.

Warto również wspomnieć, że sam Thunderbird ma mechanizmy do generowania kluczy, a samo GPG może posłużyć do cyfrowego podpisywania swoich commitów w Gicie (mimo że do samego łączenia się z repozytorium korzysta się z kluczy SSH).

Podsumowanie

Wbrew temu, co może się wydawać po przeczytaniu artykułu, wysyłanie maili z poziomu aplikacji nie jest tak naprawdę trudne - nowoczesne biblioteki w dużej mierze załatwiają dużo rzeczy za programistę. Natomiast czasem brakuje odpowiedniego fragmentu wiedzy, który mówi coś więcej o tym, co dzieje się pod spodem, a z czym może być kłopot w konkretnych sytuacjach. Z tego powodu wyszedł trochę dłuższy opis, pokazujący między innymi umiejscowienie i rodzaj szyfrowania w tym całym procesie. Ale mam nadzieję, że wiedza zawarta w tym artykule okaże się kiedyś przydatna.

Pozdrawiam i dziękuję - Jakub Rojek.