Potwierdź ustalenia dotyczące wysyłania kodu centralnego
Urzędnik Centercode przewodnik po informacjach technicznych etykietuje swoje instrukcje jako mające zastosowanie do wszystkich wydań. Stwierdza, że SPF autoryzacja jest obowiązkowa dla platformy do wysyłania w imieniu domeny e-mail klienta, podczas gdy DKIM jest opcjonalny i dostępny na żądanie. Zachowaj to rozróżnienie: opcjonalny przepływ pracy DKIM dostawcy nie eliminuje żadnych oddzielnych wymagań organizacyjnych lub odbiorców. W tym manuskrypcie opisano udokumentowaną ścieżkę świadczenia usługi, a nie zaobserwowaną konfigurację dzierżawcy lub ukończoną implementację.
Zacznij od zidentyfikowania implementacji Centercode, domeny przeznaczonej do wiadomości wychodzących i odpowiedzialnego właściciela domeny. Nie zakładaj, że nazwa hosta witryny społecznościowej, widoczny adres e-mail i aktualny nadawca kopertowy są identyczne. Aplikacja może używać markowego adresu podczas transmisji za pośrednictwem infrastruktury kontrolowanej przez inną organizację. Zanim ktokolwiek dokona edycji DNS zapis akceptacji powinien określać, której domeny ma dotyczyć każdy element uwierzytelnienia.
Przewodnik publiczny nie podaje daty publikacji instrukcji technicznych w zachowanym tekście artykułu. Warunkiem udostępnienia pozostaje zatem jego zastosowanie do rachunku bieżącego i infrastruktury. Potwierdź aktualne instrukcje u autoryzowanego operatora, szczególnie w przypadku wdrożenia, w którym przeniesiono infrastrukturę lub odziedziczono ustawienia z wcześniejszej społeczności. Ani data w stopce, ani stara udana kampania nie określają aktualnej zgodności technicznej.
Wybieraj świadomie udokumentowany model autoryzacji SPF
Standardowy przykład dostawcy zawiera include:_spf.centercode.com. Oferuje również węższy model wykorzystujący adres IP specyficzny dla usługi lub zakres uzyskany od wsparcia. Są to różne opcje konserwacji. Szerokie uwzględnienie jest zgodne z opublikowaną zależnością autoryzacji dostawcy; adres wydany w ramach wsparcia ogranicza autoryzację do zidentyfikowanej infrastruktury, ale wymaga uwagi w przypadku zmian tej infrastruktury. Przewodnik wyraźnie ostrzega, że aktualizacja infrastruktury może wymagać aktualizacji autoryzowanego adresu. Informacje techniczne dotyczące kodu centralnego
Nie wnioskuj adresów dedykowanych implementacji ze strony internetowej dostawcy, adresu URL społeczności lub danych przychodzących Rekordy MX. Uzyskaj rzeczywiste autoryzowane wartości w ramach udokumentowanego procesu wsparcia, jeśli wymagany jest ten model. W tym artykule nie żąda się adresów, nie kontaktuje się z pomocą techniczną ani nie publikuje zgadywanego adresu IP. Decyzja o zastosowaniu węższego modelu powinna uwzględniać właściciela powiadomień o zmianach oraz rekord realizacji, której dotyczą podane adresy.
Przed zatwierdzeniem któregokolwiek modelu przeprowadź inwentaryzację istniejących legalnych nadawców w domenie. Przykładowa polityka Centercode nie zastępuje całkowicie polityki produkcyjnej firmy. Zachowaj wymagane uprawnienia, oceń kwalifikator zamówienia i terminala oraz udokumentuj dokładną zmianę. Usługa dodana do polityki obejmującej całą domenę może wpłynąć na inną grupę wiadomości, niż początkowo zakładał właściciel kampanii.
Zastosuj reguły protokołu SPF zamiast kopiować cały przykład
RFC 7208 , sekcja 3.2 zabrania wielu rekordów, które powodują, że SPF wybiera więcej niż jedną politykę. Połącz zatwierdzony mechanizm w jedną spójną politykę TXT u odpowiedniego właściciela, zamiast dodawać drugą konkurencyjną politykę. Przykład dostawcy obejmuje również mx i zakończenie typu soft-fail; ich obecność w przykładzie nie oznacza, że oba są odpowiednie dla każdej istniejącej domeny. Zachowaj decyzje właściciela polisy, zamiast zmieniać niepowiązane zachowanie jako efekt uboczny.
Sekcja 4.6.4 ogranicza oceniane terminy SPF zależne od DNS, w tym ocenę zagnieżdżoną. Nie jest to po prostu liczba widocznych ciągów znaków, pakietów DNS lub braków pamięci podręcznej. Dodanie kodu Centercode wymaga przejrzenia odpowiednich ścieżek w całej zasadzie. Mechanizm IP4 lub IP6 objęty pomocą techniczną ma inne zachowanie podczas wyszukiwania, ale wybranie go nadal powoduje opisaną powyżej zależność konserwacyjną. Niższa liczba wyszukiwań nie wystarczy, aby uzasadnić kopiowanie niezweryfikowanych adresów.
SPF ocenia tożsamości zdefiniowane w transakcji SMTP . RFC 7208 , sekcja 2.4 opisuje MAIL FROM, łącznie ze specjalną obsługą pustej ścieżki zwrotnej. Rekord w widocznej domenie From nie jest dowodem na to, że dana wiadomość używa tej domeny do oceny SPF . Zapisz rzeczywistą tożsamość koperty podczas oddzielnie autoryzowanej procedury akceptacyjnej i porównaj ją z sprawdzaną polityką.
Poproś o materiały DKIM specyficzne dla wdrożenia
Udokumentowana trasa DKIM Centercode rozpoczyna się od prośby o pomoc z czatu implementacji lub podanego kanału pomocy. Zespół IT zwraca klucz publiczny administratorowi DNS klienta. W przewodniku opisano cc. _domainkey właściciela w domenie klienta i wartość DKIM TXT zbudowaną na podstawie dostarczonego klucza publicznego. Skorzystaj z instrukcji dotyczących konkretnej implementacji i dokładnie zamierzonej domeny; nie kopiuj domeny zastępczej przewodnika ani nie twórz kluczowych materiałów. Prośba o wsparcie DKIM
Publiczny klucz weryfikacyjny nie jest prywatnym kluczem podpisującym. Ten przepływ pracy nie wymaga od klienta uzyskiwania ani rozpowszechniania prywatnych materiałów do podpisu dostawcy. Zachowaj otrzymany klucz publiczny, nazwę właściciela i numer konta razem, aby osoba sprawdzająca DNS mogła odróżnić żądaną konfigurację od niepowiązanego klucza już znajdującego się w strefie. Jeśli istnieje selektor właściciel koliduje z proponowaną wartością, zatrzymaj się w celu skoordynowanego przejścia, zamiast nadpisywać ją bez oceny aktywnego użytkowania.
Poradnik opisuje, jak zamówić i opublikować dostarczone materiały, ale nie stanowi dowodu, że podpisywanie zostało aktywowane dla konkretnego konta. Zapisz potwierdzenie zakończenia współpracy z dostawcą oddzielnie od zmiany DNS . RFC 6376 , sekcja 3.5 definiuje domenę podpisu i pola selektora. Te pola w próbce autoryzowanej otrzymanej wiadomości określają, jakiego klucza faktycznie używa wiadomość; sam opublikowany klucz nie oznacza, że osoba podpisująca go użyła.
Trzymaj DMARC i akceptację dostawy oddzielnie
Przewodnik Centercode przypisuje DMARC właścicielowi domeny klienta. Przed zmianą zasad przejrzyj trasę platformy wraz z innymi nadawcami organizacji. Prośba o pomoc dotyczącą klucza DKIM nie autoryzuje nowych miejsc docelowych raportowania ani zmian w egzekwowaniu zasad w całej domenie. Przechowuj te decyzje u odpowiedniego właściciela i niezależnie dokumentuj ich zakres.
RFC 9989 , sekcja 4.4 wyjaśnia, że DMARC wymaga relacji pomiędzy widoczną domeną autora a przekazującym uwierzytelnionym identyfikatorem. Przechodzący, dopasowany wynik SPF lub przechodzący, dopasowany wynik DKIM mogą spełnić ten warunek uwierzytelnienia. Nie tłumacz obowiązkowego warunku wstępnego SPF Centercode na twierdzenie protokołu, że DMARC powszechnie potrzebuje obu mechanizmów do zaliczenia. Podobnie nie ma podpisu niepowiązanego dostawcy wyrównanie z domeną klienta.
Dostawca sugeruje publiczne wyszukiwanie SPF w ramach jednego sprawdzenia. Może to pomóc w ustaleniu publikacji, ale nie może ustalić faktycznego podpisania, akceptacji odbiorcy ani umieszczenia w skrzynce odbiorczej. Kompletny proponowany przegląd akceptacji oddziela publiczny DNS , konfigurację dostawcy i obserwacje zaufanego odbiorcy. Używaj nieszkodliwych treści testowych zamiast opinii uczestników, poufnych opisów produktów lub danych członków społeczności. Dla tego przewodnika nie przesłano żadnego zewnętrznego narzędzia sprawdzającego, nie zapytano ani nie wysłano żadnej wiadomości.
Fikcyjna diagnoza i pusty arkusz akceptacji
Fikcyjny zespół sprzętowy, Harbor Finch, używa adresu przyznanego przez pomoc techniczną do implementacji Centercode. Po planowanym przeniesieniu infrastruktury zespół zachowuje starą autoryzację, ponieważ witryna społeczności nadal ładuje się normalnie. Jej recenzent identyfikuje brakującą zależność: dostępność strony internetowej nie jest dowodem na to, że adres usługi wychodzącej pozostał taki sam. Proponowanym rozwiązaniem jest potwierdzenie nowej trasy u odpowiedzialnego operatora, sprawdzenie autoryzowanej zmiany i zebranie dowodów na nowy komunikat. Jest to przypadek fikcyjny, a nie wymierny incydent czy przeprowadzona migracja.
- Potwierdzenie wdrożenia, wydania i aktualnej instrukcji: ______
- Docelowa domena autora i obserwowana tożsamość koperty: ______
- Standard obejmuje lub wspiera decyzję adresową i właściciela: ______
- Istniejąca polityka TXT , zatwierdzona zmiana i przegląd oceny: ______
- Powiadomienie o migracji infrastruktury i odpowiedzialność za konserwację: ______
- Numer wniosku DKIM , właściciel publiczny, klucz i potwierdzenie podpisu: ______
- Autoryzowane tożsamości odebranych wiadomości i wyniki dopasowania: ______
- Właściciel polityki DMARC , nierozwiązane zależności i decyzja o wydaniu: ______
Dokładne dowody wdrożenia katalogu, aktualne zastosowanie, przegląd zagadnień związanych z człowiekiem, trasy produkcyjne, dostępność wizualna i zezwolenie właściciela pozostają otwarte. Artykuł stanowi wersję roboczą dokumentu, a nie dowód, że dzierżawca, strefa DNS lub strumień komunikatów zostały skonfigurowane lub przetestowane.