Obsługa wielu adresów e-mail z poziomu jednej skrzynki przez lata była bardzo wygodnym rozwiązaniem. Przekierowania pozwalały zebrać wiadomości w jednym miejscu, a dodatkowe tożsamości umożliwiały odpowiadanie z adresu, na który pierwotnie została wysłana wiadomość.
Technicznie jednak taki mechanizm nie zawsze oznacza, że wiadomość rzeczywiście jest wysyłana przez konto widoczne dla odbiorcy w polu „Od”. I właśnie tutaj zaczynają się problemy.
Coraz bardziej restrykcyjne mechanizmy antyspamowe i anty-spoofingowe powodują, że serwery pocztowe dokładniej kontrolują zgodność pomiędzy kontem użytym do uwierzytelnienia SMTP a adresem deklarowanym jako nadawca.
W praktyce może to doprowadzić do sytuacji, w której konfiguracja działająca przez wiele lat nagle zaczyna zwracać błąd:
550 5.7.1 – Rejected by policy: From header domain does not align with authenticated domain
W tym artykule przyjrzymy się problemowi od strony technicznej: czym różni się tożsamość od rzeczywistego konta SMTP, czym jest SMTP AUTH, dlaczego przekierowanie poczty nie daje automatycznie prawa do wysyłania wiadomości oraz dlaczego przy większej liczbie firmowych skrzynek wygodniejszym rozwiązaniem może być lokalny klient pocztowy obsługujący wiele niezależnych kont.
Adres widoczny w polu „Od” to niekoniecznie konto wysyłające wiadomość
Dla przeciętnego użytkownika sprawa wydaje się oczywista.
Jeżeli podczas pisania wiadomości widzimy:
Od: biuro@firma-a.pl
to można założyć, że wiadomość została wysłana właśnie z konta biuro@firma-a.pl.
Nie musi tak być.
Pod spodem działa kilka niezależnych mechanizmów. Klient pocztowy lub webmail łączy się z określonym serwerem SMTP, następnie uwierzytelnia użytkownika, a dopiero później przekazuje wiadomość zawierającą określone nagłówki.
W uproszczeniu proces może wyglądać tak:
Użytkownik|vWebmail / klient pocztowy|vSerwer SMTP||-- SMTP AUTH: konto-a@domena-a.pl||-- From: konto-b@domena-b.pl|vSerwer odbiorcy
Właśnie różnica pomiędzy SMTP AUTH a From: może stać się źródłem problemu.
Czym jest SMTP AUTH?
SMTP, czyli Simple Mail Transfer Protocol, odpowiada za przesyłanie poczty elektronicznej.
Współczesne serwery pocztowe zazwyczaj nie pozwalają przypadkowemu użytkownikowi internetu połączyć się z serwerem i wysyłać dowolnych wiadomości. Przed wysłaniem poczty wymagają uwierzytelnienia.
W dużym uproszczeniu klient pocztowy przekazuje:
Serwer SMTP: smtp.example.comLogin: biuro@firma-a.plHasło: ********
Po prawidłowym uwierzytelnieniu serwer wie, jakie konto próbuje wysłać wiadomość.
To właśnie SMTP AUTH.
Jeżeli następnie w wiadomości pojawia się:
From: biuro@firma-a.plwszystko jest logiczne.
Uwierzytelniony użytkownik oraz deklarowany nadawca są zgodni.
Problem może pojawić się wtedy, gdy konfiguracja wygląda następująco:
SMTP AUTH:biuro@firma-a.plFrom:kontakt@firma-b.pl
Użytkownik zalogował się jako konto z domeny A, ale próbuje wysłać wiadomość wyglądającą tak, jakby pochodziła z domeny B.
Serwer musi zdecydować, czy powinien na to pozwolić.
Po co istnieją tożsamości e-mail?
Tożsamość jest bardzo wygodnym rozwiązaniem stosowanym przez wiele webmaili.
Załóżmy, że użytkownik posiada główną skrzynkę:
glowna@domena-a.plDo niej przekierowane są wiadomości z:
kontakt@domena-b.plsprzedaz@domena-c.plinfo@domena-d.pl
Z punktu widzenia odbierania poczty wszystko działa bardzo dobrze.
Wiadomość wysłana na:
kontakt@domena-b.plzostaje przekazana do:
glowna@domena-a.plUżytkownik nie musi sprawdzać kilku skrzynek.
Jeżeli webmail pozwala dodatkowo utworzyć tożsamość kontakt@domena-b.pl, podczas odpowiadania można wybrać ją jako nadawcę.
Odbiorca widzi wtedy:
From: kontakt@domena-b.plProblem polega na tym, że sama możliwość wpisania innego adresu w polu From: nie musi oznaczać, że serwer SMTP uznaje użytkownika za uprawnionego do jego używania.
Przekierowanie i skrzynka pocztowa to dwie różne rzeczy
To również warto rozróżnić.
Przekierowanie:
kontakt@domena-b.pl|vglowna@domena-a.pl
oznacza zasadniczo:
Wiadomości przychodzące na pierwszy adres należy dostarczyć również lub zamiast tego na drugi adres.
Nie wynika z tego automatycznie prawo do wysyłania poczty.
Normalna skrzynka posiada natomiast własne konto, hasło i możliwość uwierzytelnienia na odpowiednim serwerze pocztowym.
Dlatego z punktu widzenia infrastruktury pocztowej istnieje zasadnicza różnica pomiędzy:
adres e-mail -> przekierowaniea:
adres e-mail -> skrzynka -> login -> hasło -> SMTPW pierwszym przypadku adres może służyć wyłącznie jako punkt odbioru i przekazania wiadomości.
W drugim jest samodzielnym kontem pocztowym.
Dlaczego serwer może blokować zmianę pola From?
Wyobraźmy sobie, że serwer SMTP bez żadnych ograniczeń pozwala każdemu uwierzytelnionemu użytkownikowi ustawić dowolny adres nadawcy.
Użytkownik posiadający:
konto@moja-firma.plmógłby próbować wysłać wiadomość jako:
ksiegowosc@inna-firma.plalbo jako adres należący do banku, operatora płatności czy innej organizacji.
To oczywisty problem bezpieczeństwa.
Dlatego dostawcy poczty mogą wprowadzać dodatkowe mechanizmy sprawdzające, czy uwierzytelnione konto ma prawo używać określonego nadawcy.
Jeżeli nie, serwer może zakończyć próbę wysłania błędem klasy 5xx.
Jednym z takich komunikatów jest:
550 5.7.1Rejected by policy:From header domain does not alignwith authenticated domain
Nie oznacza to problemu z dostarczeniem wiadomości do skrzynki odbiorcy.
Wiadomość może zostać odrzucona już przez serwer SMTP nadawcy, zanim w ogóle rozpocznie normalną podróż przez internet.
Gdzie w tym wszystkim znajdują się SPF, DKIM i DMARC?
Przy problemach z nadawcą często automatycznie pojawiają się trzy skróty:
SPF, DKIM i DMARC.
Są niezwykle ważne dla współczesnej poczty, ale nie należy wrzucać wszystkich problemów z wysyłką do jednego worka.
SPF pozwala określić, jakie serwery są uprawnione do wysyłania poczty dla określonej domeny.
DKIM umożliwia podpisanie wiadomości kryptograficznie przez system pocztowy.
DMARC określa między innymi zasady dotyczące zgodności domen wykorzystywanych przez mechanizmy uwierzytelnienia z domeną widoczną dla użytkownika.
Natomiast kontrola:
SMTP AUTHvs.From:
może zostać wykonana jeszcze wcześniej przez serwer, z którego próbujemy wysłać wiadomość.
Dlatego poprawienie rekordu SPF nie musi rozwiązać błędu:
From header domain does not alignwith authenticated domain
Jeżeli wiadomość zostaje zablokowana przez serwer wysyłający na etapie autoryzacji nadawcy, problem występuje zanim zewnętrzny serwer odbiorcy zacznie analizować SPF czy DMARC.
Dlaczego stara konfiguracja może nagle przestać działać?
To jedno z bardziej irytujących pytań:
„Przecież przez kilka lat działało. Dlaczego teraz nie działa?”
W przypadku usług pocztowych brak zmian po stronie użytkownika nie oznacza braku zmian po stronie operatora.
Dostawca może zmienić politykę bezpieczeństwa, zaostrzyć kontrolę nadawców, zmodyfikować konfigurację serwerów SMTP albo przenieść część kont na inną infrastrukturę.
Możliwe jest również współistnienie kilku generacji usług.
Przykładowo jedna skrzynka może być obsługiwana przez starszą platformę wykorzystującą Roundcube jako webmail, podczas gdy inna działa już na Zimbrze.
W efekcie dwie pozornie podobne konfiguracje niekoniecznie zachowują się identycznie.
Roundcube i Zimbra to nie to samo co SMTP
Tutaj warto wyjaśnić jeszcze jedno częste nieporozumienie.
Roundcube jest przede wszystkim webowym klientem pocztowym.
Zimbra jest znacznie szerszą platformą pocztową i pracy grupowej.
To, że użytkownik widzi Roundcube albo Zimbrę podczas logowania do poczty, nie opisuje jeszcze całej infrastruktury odpowiedzialnej za SMTP, autoryzację czy filtrowanie wiadomości.
W praktyce podczas diagnozowania problemu warto rozdzielić:
Interfejs użytkownika|vRoundcube / Zimbra / klient desktopowySerwer odbiorczy|vIMAPSerwer wysyłający|vSMTPAutoryzacja|vLogin + hasło + polityka serwera
To kilka różnych elementów jednego systemu pocztowego.
IMAP odpowiada za coś innego niż SMTP
Kolejne istotne rozróżnienie:
IMAP służy przede wszystkim do pracy z zawartością skrzynki.
SMTP służy do wysyłania wiadomości.
Dlatego klient pocztowy może mieć przykładowo konfigurację:
IMAP:imap.provider.exampleport 993SSL/TLSSMTP:smtp.provider.exampleport 465 lub 587SSL/TLS / STARTTLS
Dzięki IMAP program widzi wiadomości i foldery znajdujące się na serwerze.
Dlatego operacje wykonywane na folderach w kliencie mogą być widoczne również później w webmailu.
Skąd bierze się bałagan z folderami IMAP?
Przy migracjach i korzystaniu z kilku klientów pocztowych często pojawia się inny problem.
Jeden program używa:
SentTrashJunkDrafts
inny:
Sent MessagesDeleted MessagesSpamDraft
Do tego dochodzą foldery utworzone wcześniej przez webmail.
Po kilku latach można otrzymać strukturę przypominającą:
INBOXSentSent MessagesWysłaneTrashDeletedJunkSpamDraftsArchive
Nie wszystkie z tych folderów muszą być duplikatami, ale część może być pozostałością po wcześniejszych konfiguracjach.
Dlatego automatyczne mapowanie folderów IMAP jest bardzo istotną funkcją klienta pocztowego.
Dlaczego testowany Mailspring okazał się mniej wygodny?
Podczas poszukiwania klienta do obsługi wielu skrzynek jednym z testowanych programów był Mailspring.
Sam program prezentował się dobrze i oferował nowoczesny interfejs.
Problem pojawił się właśnie przy folderach.
W przypadku używanych przeze mnie skrzynek część mapowania wymagała ręcznej konfiguracji.
Przy dwóch kontach można to zrobić bez większego problemu.
Przy większej liczbie zaczyna to być uciążliwe, ponieważ dla kolejnych skrzynek trzeba sprawdzać:
Sent -> ?Drafts -> ?Trash -> ?Spam -> ?
Technicznie nie jest to poważna wada. Dla użytkownika posiadającego wiele kont jest jednak dodatkową pracą, której można uniknąć, jeżeli inny klient poprawnie rozpozna strukturę automatycznie.
Dlaczego Mailbird rozwiązał problem inaczej niż webmail?
Kluczowa zmiana nie polegała tak naprawdę na samym przejściu z jednego interfejsu na drugi.
Zmieniła się architektura obsługi poczty.
Wcześniej:
Adres A ----\Adres B -----+--> główna skrzynkaAdres C ----/ |vjedna sesja SMTP|+--> zmieniane tożsamości
Po skonfigurowaniu niezależnych kont w kliencie pocztowym:
Skrzynka A ---> SMTP ASkrzynka B ---> SMTP BSkrzynka C ---> SMTP CSkrzynka D ---> SMTP D\ | /\ | /+------ Mailbird ------+
Z punktu widzenia użytkownika wszystkie konta znajdują się w jednym programie.
Z punktu widzenia serwerów nadal są jednak niezależnymi kontami pocztowymi.
I to jest zasadnicza różnica.
Sam problem z autoryzacją SMTP był jednak tylko jednym z powodów zmiany sposobu zarządzania pocztą. Równie ważna okazała się wygoda codziennej obsługi kilkunastu firmowych adresów, automatyczna konfiguracja folderów IMAP oraz możliwość korzystania ze wspólnej skrzynki odbiorczej. Cały proces wyboru odpowiedniego programu, doświadczenia z pocztą OVH oraz praktyczne zalety Mailbird Premium zostały opisane szerzej w osobnym artykule: Jak wygodnie obsługiwać wiele firmowych skrzynek e-mail? Od problemu z OVH do Mailbird Premium.
Każde konto korzysta z własnego SMTP AUTH
Załóżmy, że w programie skonfigurowane są trzy konta:
biuro@domena-a.plinfo@domena-b.plkontakt@domena-c.pl
Każde ma własne dane dostępowe.
Wysyłając z pierwszego:
SMTP AUTH: biuro@domena-a.plFrom: biuro@domena-a.pl
z drugiego:
SMTP AUTH: info@domena-b.plFrom: info@domena-b.pl
a z trzeciego:
SMTP AUTH: kontakt@domena-c.plFrom: kontakt@domena-c.pl
Nie trzeba przekonywać serwera, że jedno konto ma prawo podszywać się — nawet w całkowicie legalnym i zamierzonym celu — pod inne konto.
Każda skrzynka reprezentuje samą siebie.
Tożsamość nadal może być przydatna, ale nie zawsze jest najlepszą architekturą
Nie oznacza to, że funkcja tożsamości jest zła.
Wręcz przeciwnie.
Jeżeli operator pocztowy oficjalnie pozwala jednemu kontu wysyłać wiadomości jako alias albo delegowany adres, tożsamości są bardzo wygodne.
Problem zaczyna się wtedy, kiedy budujemy na nich cały system obsługi wielu niezależnych domen.
Im więcej domen i dostawców, tym więcej potencjalnych wyjątków.
Przy kilkunastu niezależnych skrzynkach znacznie czytelniejszy staje się model:
1 adres=1 rzeczywiste konto=1 uwierzytelnienie SMTP
natomiast program pocztowy odpowiada wyłącznie za pokazanie wszystkich kont w jednym interfejsie.
Dlaczego taki model jest łatwiejszy do diagnozowania?
Ma to również dużą zaletę administracyjną.
Jeżeli wiadomości z jednego adresu przestają wychodzić, od razu wiadomo, którego konta dotyczy problem.
Można sprawdzić:
Czy działa IMAP?Czy działa SMTP?Czy login jest prawidłowy?Czy hasło jest aktualne?Czy port SMTP jest poprawny?Czy działa TLS?Czy domena ma poprawny SPF?Czy wiadomości otrzymują DKIM?
Problem jest ograniczony do konkretnego konta.
W systemie opartym na jednej głównej skrzynce, wielu przekierowaniach i licznych tożsamościach trzeba dodatkowo ustalać, czy serwer pozwala konkretnemu uwierzytelnionemu użytkownikowi wysłać wiadomość z konkretnym adresem From:.
Klient pocztowy nie przenosi poczty z serwera
Czasami pojawia się obawa, że dodanie skrzynki do programu desktopowego oznacza „przeniesienie poczty na komputer”.
Przy IMAP tak to nie działa.
Podstawowa kopia wiadomości nadal znajduje się na serwerze.
Klient synchronizuje jej zawartość i stan.
Schemat wygląda mniej więcej tak:
+--> komputer 1|Serwer IMAP -----+--> webmail|+--> komputer 2|+--> telefon
Przeczytanie lub przeniesienie wiadomości może zostać zsynchronizowane z pozostałymi urządzeniami.
Dlatego przejście z webmaila na Mailbirda nie oznacza konieczności rezygnacji z webmaila.
W razie potrzeby nadal można zalogować się do niego przez przeglądarkę.
Usuwanie folderów z poziomu klienta wymaga ostrożności
Możliwość zarządzania folderami IMAP z poziomu programu jest bardzo wygodna, ale należy pamiętać o jednej rzeczy.
Jeżeli folder znajduje się na serwerze i zostanie usunięty przez IMAP, operacja może dotyczyć rzeczywistych danych na serwerze, a nie tylko wyglądu programu.
Dlatego przed usunięciem folderów takich jak:
SentSent MessagesArchiveTrashJunk
warto sprawdzić ich zawartość.
Szczególnie ostrożnie należy podchodzić do starych folderów „Wysłane”, ponieważ mogą zawierać wiadomości, których nie ma w aktualnie używanym folderze systemowym.
Wspólne podpisy przy wielu kontach
Przy większej liczbie skrzynek pojawia się jeszcze jeden problem administracyjny — podpisy.
Jeżeli kilka adresów należy do tej samej organizacji, często korzystają z identycznej stopki zawierającej nazwę firmy, stronę WWW czy inne wspólne informacje.
Możliwość utworzenia jednego podpisu i przypisania go do kilku kont upraszcza późniejsze zmiany.
Zamiast edytować:
podpis konta 1podpis konta 2podpis konta 3podpis konta 4
można zmienić jeden wspólny szablon.
Przy kilku skrzynkach różnica jest niewielka. Przy kilkunastu zaczyna być znacząca.
Czy Mailbird jest technicznym rozwiązaniem problemu OVH?
I tak, i nie.
Mailbird nie zmienia polityki serwerów OVH i nie wyłącza ich zabezpieczeń.
Rozwiązuje problem poprzez zmianę sposobu korzystania z infrastruktury pocztowej.
Zamiast:
jedno konto SMTP+wiele adresów From
otrzymujemy:
wiele kont SMTP+każde wysyła jako własny adres
Nie obchodzimy więc zabezpieczenia.
Konfigurujemy system w taki sposób, aby nie powodować konfliktu, który zabezpieczenie ma wykrywać.
To istotna różnica.
Co sprawdzić przy błędzie 550 dotyczącym nadawcy?
Jeżeli serwer zwraca błąd podobny do:
550 5.7.1From header domain does not alignwith authenticated domain
warto sprawdzić przede wszystkim cztery elementy:
1. Jakim loginem klient uwierzytelnia się na SMTP?
Nie należy patrzeć wyłącznie na pole „Od”.
2. Jaki adres znajduje się w nagłówku From?
Jeżeli jest inny niż login SMTP, należy sprawdzić, czy operator oficjalnie pozwala na takie wysyłanie.
3. Czy używany adres jest prawdziwą skrzynką, aliasem czy tylko przekierowaniem?
To trzy różne mechanizmy.
4. Czy można skonfigurować ten adres jako niezależne konto SMTP?
Jeżeli tak, często jest to najprostsze rozwiązanie.
Kiedy jedna główna skrzynka nadal ma sens?
Centralizacja poczty przez przekierowania nadal może być bardzo wygodna.
Sprawdza się szczególnie wtedy, gdy dodatkowe adresy służą przede wszystkim do odbierania wiadomości.
Jeżeli jednak regularnie wysyłamy pocztę z wielu adresów należących do różnych domen, sytuacja jest inna.
W takim przypadku niezależne konta SMTP mają kilka zalet:
- prostszą autoryzację,
- łatwiejszą diagnostykę,
- mniejszą zależność od wyjątków dotyczących tożsamości,
- czytelniejszą konfigurację,
- łatwiejszą zmianę dostawcy jednej skrzynki bez przebudowy pozostałych.
Jedna aplikacja nie musi oznaczać jednej skrzynki
To chyba najważniejszy wniosek z całego problemu.
Przez lata wygoda obsługi poczty była dla mnie równoznaczna z umieszczeniem wszystkich wiadomości w jednej głównej skrzynce.
Nie jest to konieczne.
Można pozostawić:
konto A jako konto Akonto B jako konto Bkonto C jako konto Ckonto D jako konto D
i jednocześnie pracować tak, jakby wszystkie znajdowały się w jednym miejscu.
Warstwą integrującą nie musi być serwer.
Może nią być klient pocztowy.
Podsumowanie
Błąd 550 5.7.1 dotyczący niezgodności adresu From z uwierzytelnionym kontem SMTP dobrze pokazuje, jak bardzo zmieniła się współczesna poczta elektroniczna.
Dawniej możliwość ustawienia dodatkowej tożsamości często wystarczała do wygodnego wysyłania poczty z wielu adresów. Obecnie operatorzy znacznie dokładniej kontrolują, kto i w imieniu jakiej domeny próbuje wysłać wiadomość.
Przy niewielkiej liczbie adresów można nadal korzystać z aliasów, delegacji i tożsamości.
Przy większej liczbie firmowych skrzynek warto jednak rozważyć inną architekturę:
niezależna skrzynka+własne uwierzytelnienie SMTP+własny adres From+wspólny klient pocztowy
W moim przypadku takim klientem został Mailbird. Nie dlatego, że zmienia sposób działania SMTP, ale dlatego, że pozwala wygodnie zarządzać wieloma niezależnymi kontami bez konieczności łączenia ich na poziomie serwera.
Ostatecznie problem nie został więc rozwiązany poprzez znalezienie sposobu na dalsze wysyłanie wiadomości z „obcej” tożsamości.
Został rozwiązany w bardziej uporządkowany sposób: każdy adres wysyła pocztę przez konto, do którego rzeczywiście należy, a wszystkie skrzynki są połączone dopiero na poziomie programu pocztowego.
Przy kilku domenach i większej liczbie firmowych adresów jest to rozwiązanie nie tylko wygodniejsze, ale również znacznie bardziej przejrzyste od strony technicznej.
