Zakres uwierzytelniania RMail do używanej trasy
RMail może przetwarzać wiadomości biznesowe poprzez integrację aplikacji i routing SMTP , więc zacznij od trasy, z której faktycznie korzysta Twoja organizacja. Zapisz aplikację źródłową lub klienta poczty, ścieżkę usługi RMail, domenę nadawcy, późniejszą bramę i kontrolowanego odbiorcę użytego do testowania. Traktuj dowód doręczenia, szyfrowanie i uwierzytelnienie domeny jako osobne pytania dotyczące akceptacji. Potwierdzenie może być użytecznym dowodem operacyjnym, ale nie stanowi dowodu na to, że serwer pocztowy odbiorcy zauważył wyrównanie SPF Lub DKIM przechodzić.
W tym przewodniku opisano przepływ pracy przy uwierzytelnianiu i weryfikacji wspomaganym przez dostawcę. Publiczne materiały własne stwierdzają, że RMail obsługuje udostępnianie SPF i DKIM , ale pobrana dokumentacja nie zapewnia kompletnego, powszechnie stosowanego Rekord SPF, wartość DKIM specyficzna dla konta, selektor lub samoobsługową sekwencję kontrolną. Szczegóły te pozostają objęte zakresem do czasu dostarczenia aktualnych instrukcji przez przedstawiciela RMail organizacji. Nie zastępuj przykładu strony trzeciej tylko po to, aby lista kontrolna wyglądała na kompletną.
Oddziel uprawnienia wysyłające od obsługi potwierdzeń
RPost Omówienie integracji hybrydowego SMTP odróżnia uwierzytelnianie systemu wysyłającego i adresu nadawcy od routingu, formatowania wiadomości i obsługi potwierdzeń zwrotnych. Lista uwierzytelnień obejmuje uwierzytelnianie IP, weryfikację domeny, SPF i DKIM . Są to tematy dotyczące udostępniania dla rzeczywistej integracji, a nie dowód, że jakakolwiek organizacja już je włączyła.
Stwórz małą mapę tras, która oddziela wiadomość biznesową dostarczoną odbiorcy od potwierdzeń lub potwierdzeń zwracanych nadawcy. Dla każdego z nich określ, który system je wysyła i która skrzynka pocztowa je otrzymuje. Pokwitowania wykorzystującego domenę From należącą do dostawcy nie należy mylić z wiadomością oryginalnej organizacji. Podobnie pomyślne przyjęcie do wewnętrznej skrzynki pocztowej nie potwierdza zewnętrznej trasy skierowanej do klienta.
Zapytaj właściciela aplikacji, jakie tryby są używane w produkcji. Wiadomość Track & Prove, wiadomość zaszyfrowana i zautomatyzowany przepływ aplikacji powinny zostać poddane oddzielnym testom, gdy ich przetwarzanie jest różne. Zachowaj proporcjonalność matrycy testów: jeden reprezentatywny komunikat może obejmować identyczne ustawienia, ale jedna etykieta produktu nie powinna łączyć naprawdę różnych ścieżek w jeden wynik.
Uzyskaj kompletny zestaw rekordów z RMail
Poproś o pisemne instrukcje dotyczące dokładnej domeny nadawcy i wdrożenia usługi. Żądanie powinno identyfikować zamierzoną domenę From, bieżące zachowanie koperty, jeśli jest znane, organizację odpowiedzialną za DNS i to, czy brama zmienia wiadomości po RMail. Zapytaj o pełnego właściciela rekordu, typ DNS , wartość i wymagany krok aktywacji. Jeśli zmieniana jest istniejąca domena, zapytaj, jak przejście wpłynie na wiadomości znajdujące się już w kolejce.
RPost Formularz wniosku DKIM opisuje implementację dostarczonych informacji DNS , sprawdzenie rekordu selektora, a następnie wysłanie testowej wiadomości RMail w celu potwierdzenia. Formularz publiczny jest odniesieniem do przepływu pracy, a nie wypełnionym kluczem dla Twojej firmy. Nie wyprowadzaj niepublikowanego selektora z adresu pomocy technicznej ani nie twórz wartości TXT na podstawie odgadniętej konwencji nazewnictwa.
Poproś RMail o potwierdzenie, czy niestandardowa konfiguracja koperty i domeny jest obsługiwana dla konkretnego wdrożenia, jeśli SPF wyrównanie jest wymogiem biznesowym. Dowody publiczne nie ustanawiają tutaj uniwersalnego zwyczaju Return-Path procedura. Jeśli nie można spełnić tego wymagania, oceń, czy obsługiwany, dostosowany DKIM spełnia wymagania organizacji DMARC kryteria akceptacji. Udokumentuj rzeczywisty wynik zamiast raportować oba mechanizmy zgodnie z założeniami.
Przygotuj zmiany DNS bez poszerzania niepowiązanego zaufania
Przed wprowadzeniem zmian wyeksportuj istniejące rekordy u każdego właściciela, którego to dotyczy. Zachowaj uprawnienia SPF używane przez inne usługi na żywo i zidentyfikuj istniejące selektory DKIM . Sprawdź, czy wydany właściciel koliduje z innym rekordem lub delegowaną usługą. Zamiast nadpisywać aktywną integrację, eskaluj konflikt do odpowiednich administratorów.
SPF uwierzytelnia SMTP POCZTA OD tożsamość, z odrębnością HELO ocena, pod RFC 7208. Publikowanie autoryzacji w widocznej domenie From pomaga tylko wtedy, gdy jest to domena oceniana dla trasy. Przed podjęciem decyzji, gdzie należy proponowana zmiana SPF , określ obserwowaną lub potwierdzoną przez dostawcę tożsamość koperty. Rozpoznawalny adres firmy w treści wiadomości nie ma wpływu na tę decyzję.
Jeśli polityka SPF wymaga modyfikacji, zachowaj jedną politykę u tego właściciela i oblicz całkowity koszt zapytań DNS, łącznie z zależnościami dostawców zagnieżdżonych. Nie wklejaj drugiego rekordu v=spf1 obok bieżącego. Nie przekształcaj kwalifikatora terminala przykładowej zasady w decyzję dotyczącą bezpieczeństwa obejmującą całą firmę bez sprawdzenia. Jeśli RMail nie może dostarczyć wymaganych informacji, pozostaw zmianę niezaimplementowaną i jawnie śledź brakujące dane wejściowe.
Publikuj i sprawdzaj publiczne materiały DKIM
Skopiuj wartości publiczne wydane przez dostawcę do zatwierdzonej zmiany DNS . Sprawdź sposób traktowania przez redaktora nazw względnych i przyrostków stref. Zachowaj zamierzoną wartość logiczną TXT , przestrzegając formatu wejściowego hosta DNS . W formularzu wspomniano o różnicach w składni pomiędzy systemami DNS ; jest to powód, aby zweryfikować otrzymaną odpowiedź, a nie dodawać na ślepo ukośniki odwrotne lub znaki interpunkcyjne.
Po zapisaniu zapytaj o dokładnego właściciela selektora publicznego i porównaj go z wystawioną wartością. Zapisz czas obserwacji i TTL. Pod RFC 6376, Podpis DKIMWartości „sd= i s= identyfikują domenę i selektor używany do wyszukiwania kluczy. Rekord pod pobliskim, ale innym nazwiskiem, nie zweryfikuje podpisu. Publikacja DNS nie może również ustalić, czy system wysyłający rozpoczął podpisywanie tym kluczem.
Poproś RMail o potwierdzenie stanu udostępnienia przed szeroko zakrojonymi testami. Trzymaj klucze prywatne, sekrety API i dane uwierzytelniające SMTP poza arkuszem DNS . Ogranicz pakiet dowodów do konfiguracji publicznej, odpowiednich zredagowanych nagłówków i potwierdzenia dostawcy. Zgłoszenie serwisowe powinno zawierać wystarczający kontekst, aby zdiagnozować trasę bez kopiowania poufnych umów, faktur czy korespondencji z klientem.
Uruchom zarówno potwierdzenie dostawcy, jak i niezależne testy odbiornika
Formularz żądania wymaga wysłania wiadomości testowej Track & Prove lub zaszyfrowanej na adres testowy DKIM dostawcy, z kopią przedstawiciela RMail. Zorganizuj ten test w ramach zatwierdzonego przez organizację procesu wsparcia i korzystaj z nieszkodliwych treści. Przed wysłaniem potwierdź aktualnego odbiorcę i instrukcje u przedstawiciela; opublikowany formularz nie eliminuje konieczności przestrzegania obowiązujących w organizacji zasad dotyczących przekazów zewnętrznych.
Wysyłaj także kontrolowane wiadomości do zewnętrznych skrzynek pocztowych, których nagłówki może sprawdzić administrator. Przechwytywanie identyfikatora wiadomości, czasu UTC, widocznego źródła, Return-Path , DKIM d= i s=, oraz zaufanego systemu odbierającego Authentication-Results. Unikaj polegania na nagłówku wstawionym przez nadawcę, który jedynie zapewnia sukces. Przetestuj rzeczywisty tryb przetwarzania i dowolną bramę podrzędną, a nie uproszczony komunikat omijający trasę produkcyjną.
Używać RFC 9989 aby porównać przechodzącą tożsamość SPF lub DKIM z widoczną domeną From. Zapisz dostosowany mechanizm i obowiązujący tryb rozluźniony lub rygorystyczny. Prawidłowy podpis domeny dostawcy może być przydatnym uwierzytelnieniem, ale nadal nie jest zgodny z atrybutem From organizacji. I odwrotnie, wyrównany DKIM może zapewnić przepustkę DMARC , gdy SPF nie jest wyrównany. Nie obiecuj umieszczenia w skrzynce odbiorczej żadnego z wyników.
Diagnozuj awarie bez osłabiania kontroli komunikatów
W przypadku braku DKIM sprawdź najpierw aktywację i wybór trasy. W przypadku niepowodzenia podpisu sprawdź dokładnego właściciela klucza i czy później przetwarzasz zmodyfikowaną podpisaną treść. W przypadku awarii SPF zidentyfikuj ocenianą domenę i ostateczne źródło wysyłania przed dostosowaniem uprawnień. W przypadku awarii DMARC wraz z mechanizmem przekazywania należy sprawdzić wyrównanie, zamiast dodawać więcej niepowiązanych rekordów DNS .
Podczas diagnozowania uwierzytelnienia zachowaj nienaruszone wymagania dotyczące szyfrowania lub potwierdzenia. Pominięcie RMail może zmienić funkcję biznesową, jakiej oczekuje nadawca, nawet jeśli bezpośredni test platformy-skrzynki pocztowej zakończy się pomyślnie. Zdefiniuj plan odzyskiwania wraz z właścicielem aplikacji, na przykład wstrzymanie przepływu pracy, którego dotyczy problem, lub przywrócenie zatwierdzonej konfiguracji. Nie przełączaj po cichu poufnej komunikacji na niezaszyfrowaną trasę, aby uzyskać czystszy wynik uwierzytelnienia.
Arkusz implementacji RMail
- Biznesowy przepływ pracy i tryb przetwarzania RMail: ____.
- Aplikacja inicjująca, konto dostawcy i odpowiedzialny administrator: ____.
- Miejsce docelowe, domena koperty i ostateczna trasa wychodząca: ____.
- Instrukcje SPF wydane przez dostawcę i przegląd zasad: ____.
- Właściciel DKIM , wartość publiczna, obserwacja DNS i dowód aktywacji: ____.
- Oddzielne miejsce docelowe i tożsamość zwracanych rachunków: ____.
- Test potwierdzający dostawcę i referencje dotyczące testu niezależnego odbiorcy: ____.
- Identyfikator wiadomości, czas UTC, tożsamość DKIM i zaufane wyniki: ____.
- Dostosowany mechanizm DMARC , nierozwiązane wymagania i właściciel odzyskiwania: ____.
Fikcyjny przykład wprowadzającego w błąd paragonu
Tylko fikcyjny przypadek pisemny: RM-01 zakłada, że zwrócone potwierdzenie dotarło pomyślnie, natomiast osobna wiadomość skierowana do klienta zawiera adres Od adviser@example.org i przekazujący podpis z niepowiązanej domeny dostawcy. Dokładna domena dostawcy, selektor i wynik SPF pozostają nieznane. Potwierdzenie nie rozstrzyga o autentyczności oryginalnej wiadomości; administrator powinien uzyskać obsługę administracyjną specyficzną dla konta i ponownie przetestować rzeczywistą chronioną trasę. Nie zostanie wywnioskowany żaden pełny werdykt DMARC i nie można ominąć szyfrowania. Żadne konto, paragon ani wiadomość nie zostały sprawdzone.
Zachowaj blokadę zakresu do czasu pojawienia się dowodów na koncie
Ogólna wartość SPF , wydany selektor, klucz, stan aktywacji i obsługa niestandardowych kopert pozostają nierozwiązane w przypadku prawdziwego dzierżawcy. Oczekuje się na żywo DNS i nagłówki, inspekcja najemców, ocena wizualna i zatwierdzenie przez MŚP. Przewodnik ten pozostaje niepublikowany i nie należy go oznaczać jako ukończonej konfiguracji produkcyjnej.
Oddziel przekazywaną wiadomość od gotowości do egzekwowania
RFC 9989 sekcja 7.4 wymaga prawidłowego DKIM dla domeny publikującej p=reject i ostrzega o interoperacyjności poczty pośredniej. Pojedynczy dopasowany wynik SPF sam w sobie nie uzasadnia wdrożenia zasady odrzucania. Przejrzyj wszystkie legalne trasy i zasady własności niezależnie od konfiguracji tego dostawcy.