AUTORYZACJA SMTP i SPF, DKIM I DMARC nie są wymiennymi sposobami logowania. SMTP AUTH uwierzytelnia klienta na serwerze SMTP . SPF ocenia hosta wysyłającego pod kątem zasad koperty domeny, DKIM weryfikuje podpis wiadomości, a DMARC ocenia dopasowane uwierzytelnienie domeny względem widocznego źródła. Pomyślne logowanie do konta może współistnieć z awarią DMARC na dalszym etapie, a przychodząca poczta internetowa nie musi być uwierzytelniana na Twoim koncie przesyłania.
Znajdź relację klient-serwer
RFC 4954 definiuje rozszerzenie AUTH i wykorzystanie przez niego mechanizmów SASL. Polityka autoryzacji serwera określa, co może zrobić uwierzytelniony klient. Znajomość uwierzytelnionej nazwy konta nie autoryzuje automatycznie każdej możliwej koperty lub widocznego adresu Nadawcy. W przypadku usług przesyłania często obowiązują dodatkowe ograniczenia dotyczące nadawcy, przekazywania i organizacji.
RFC 6409 odróżnia przesyłanie wiadomości od przekazywania. Przed zmianą poświadczeń lub DNS określ usługę, z której korzysta aplikacja. Urządzenie łączące się z usługą uwierzytelnionego przesyłania dostawcy ma inną relację niż zdalny serwer poczty dostarczający pocztę internetową do serwera MX Twojej domeny. Nie próbuj naprawiać zwykłych błędów uwierzytelniania przychodzącego, podając nadawcom zewnętrznym hasło do skrzynki pocztowej.
Postępuj zgodnie z dowodami domeny w dół
SPF sprawdza łączącego hosta i odpowiednią tożsamość koperty zgodnie z RFC 7208 . Weryfikacja DKIM wykorzystuje selektor i podpisanie domeny w podpisie, aby znaleźć materiał klucza publicznego i zweryfikować treść objętą normą RFC 6376 . DMARC wymaga odpowiedniej relacji między przechodzącą domeną a widoczną domeną From under RFC 9989.
Aplikacja może pomyślnie uwierzytelnić się na koncie dostawcy, a następnie wysłać z niewyrównaną domeną zwrotną i niewyrównaną domeną podpisującą DKIM . Downstream SPF i DKIM mogą przejść pomyślnie, gdy DMARC ulegnie awarii. I odwrotnie, prawidłowo skonfigurowana domena może przekazywać DMARC w poczcie dostarczanej między serwerami bez SMTP AUTH w tym przeskoku skierowanym do odbiorcy. Poświadczenia konta i autoryzacja domeny muszą zostać sprawdzone w odpowiednich granicach.
Wykorzystaj dowody bez ujawniania tajemnic
W przypadku niepowodzenia logowania zapisz punkt końcowy usługi, stan bezpiecznego transportu, anonsowane metody i całkowity błąd, z wyłączeniem poświadczeń i tokenów. W przypadku odrzucenia nadawcy po zalogowaniu przechwyć zasady dotyczące dozwolonych nadawców i odrzucone polecenie. W przypadku awarii dalszego źródła uzyskaj wyniki zaufanego odbiornika, informacje o kopercie, wartości DKIM d i s oraz widoczną domenę From. Unikaj kopiowania ładunków uwierzytelniających do zgłoszeń lub przykładów artykułów.
Porównaj dwa hipotetyczne wyniki
Przypadek A: klient uwierzytelnia się w usłudze przesyłania i może wysyłać, ale odbiorca końcowy zgłasza przepustkę SPF dla vendor.example i przepustkę DKIM z d=vendor.example , podczas gdy From używa brand.example . Zakładając, że obowiązują zasady DMARC i nie ma nierozwiązanych błędów oceny, żadna z domen nie jest dopasowana, a wiadomość nie spełnia wymagań DMARC . Inne hasło nie może zmienić tych relacji domenowych.
Przypadek B: serwer dostarcza zwykłą pocztę przychodzącą do odbiorcy MX bez uwierzytelniania SMTP na tym przeskoku. Zaufany odbiorca zgłasza prawidłowy Podpis DKIM z d=brand.example dopasowanie From= brand.example . Przy obowiązującej polityce i braku nierozwiązanych błędów oceny ten dopasowany podpis może zapewnić przepustkę DMARC . Nie oznacza to bezpiecznej zawartości, umiejscowienia skrzynki odbiorczej ani pozwolenia na wykonanie żądanej czynności biznesowej. Obydwa przypadki są wymyślonymi porównaniami; nie zastosowano żadnych danych uwierzytelniających, loginu dostawcy ani testu kryptograficznego.
Napraw odpowiedzialną konfigurację
Jeśli AUTH nie powiedzie się, postępuj zgodnie z aktualnie obsługiwaną metodą uwierzytelniania i wymaganiami transportowymi dostawcy. Nie włączaj przestarzałego mechanizmu tylko dlatego, że wspomina o tym stary artykuł. Jeśli uwierzytelnione konto nie ma uprawnień do korzystania z adresu, napraw konfigurację autoryzowanego nadawcy w ramach normalnego procesu administracyjnego. Jeśli poniżej wyrównanie nie powiedzie się, skonfiguruj obsługiwaną kopertę lub domenę DKIM legalnego nadawcy, zamiast zakładać, że inne hasło pomoże.
Po naprawie przetestuj zarówno przesłanie, jak i końcową ocenę odbiorcy, używając nieszkodliwych wiadomości. Zachowaj różne wyniki: uwierzytelnienie klienta, zezwolenie nadawcy, zaakceptowanie wiadomości, ocena mechanizmów domeny i zaobserwowanie ostatecznej dyspozycji. Pojedyncza etykieta sukcesu kryje zbyt wiele. Przewodnik uczy, jak oddzielić te wyniki; nie wymaga obsługi protokołu, weryfikacji DKIM ani konfiguracji dzierżawcy.
Zachowaj oddzielne wyniki akceptacji
- Klient uwierzytelniony: zapisz punkt końcowy, obsługiwany mechanizm i wynik, nigdy tajemnicę.
- Nadawca dozwolony: sprawdź, czy konto jest autoryzowane dla tej koperty i widocznego nadawcy.
- Wiadomość zaakceptowana: zachowaj odpowiedź po przesłaniu zawartości i serwerze odbierającym.
- Zatwierdzona domena: niezależnie rejestruj zaufane wyniki SPF / DKIM i wyrównanie DMARC .
- Doręczenie przestrzegane: zachowanie wyniku po stronie odbiorcy bez przekształcania akceptacji transportu w gwarancję skrzynki odbiorczej.