Wspólna pula adresów IP stwarza rzeczywistą zależność od usługi wysyłającej i innego ruchu. Nie zwalnia to Klienta z odpowiedzialności za własne komunikaty. Diagnozuj równolegle infrastrukturę współdzieloną i konfigurację uwierzytelniania klienta, aby jedno wyjaśnienie nie przesłaniało drugiego.
Oddziel własność puli od własności wiadomości
Amazon SES dokumentuje wspólne adresy używane przez wielu klientów oraz dedykowane alternatywy o różnych charakterystykach operacyjnych. To konkretny przykład puli kontrolowanej przez usługi, a nie opis produktu routingowego każdego dostawcy. Uzyskaj rzeczywiste szczegóły puli i usług dla badanego konta. Opcje IP SES.
Klient zazwyczaj kontroluje zamiary biznesowe, wybór odbiorców i niektóre ustawienia domeny, podczas gdy usługa kontroluje infrastrukturę wychodzącą. Zapisz rzeczywisty podział, zamiast go zakładać. Określ, kto może naprawić podpisywanie, konfigurację domeny koperty, propagację tłumienia i routing IP, ponieważ mogą to być różne zespoły.
Sprawdź ścieżkę uwierzytelniania specyficzną dla klienta
Sprawdź końcową wiadomość ze strumienia, którego dotyczy problem. Zapisz domenę podpisującą i selektor, widoczny Z domeny i tożsamości koperty, wraz z rzeczywistą oceną odbioru. DKIM weryfikacja dotyczy podpisanej wiadomości i opublikowanego klucza podpisu; jakiś Reputacja IP problem sam w sobie nie wyjaśnia uszkodzonego podpisu. RFC 6376.
Sprawdź, czy brama zmieniła podpisaną treść lub czy dla konta nigdy nie włączono konfiguracji domeny niestandardowej. Prawidłowy klucz publiczny nie świadczy o tym, że usługa podpisała nim próbkę. Przed wprowadzeniem zmian zachowaj dokładną wersję wiadomości i dowody DNS .
Użyj porównania, które pozwoli rozróżnić przyczyny
Porównaj inny autoryzowany strumień w tej samej puli ze strumieniem, którego to dotyczy, kontrolowaną trasą alternatywną, tylko jeśli taki test jest dostępny i zatwierdzony. Staraj się, aby warunki miejsca docelowego, treści i odbiorcy były tak porównywalne, jak to możliwe. Nie wysyłaj niechcianych wiadomości ani nie omijaj ograniczeń dostawcy jedynie w celu wygenerowania testu.
Załóżmy, że dwa hipotetyczne strumienie dzielą tę samą pulę: jeden ma potwierdzony defekt podpisywania, a oba napotykają podobną diagnostykę trasy. Wymaga to przeprowadzenia dwóch dochodzeń, a nie wyboru między nimi. Potwierdź konfigurację podpisywania pierwszego strumienia i poproś właściciela infrastruktury o wyjaśnienie faktycznej odmowy. Sama powszechna diagnostyka nie dowodzi, że spowodowała to reputacja.
Są to wymyślone fakty na potrzeby przykładu decyzji, a nie sprawdzenie wykonanych reguł lub test podpisu. Ustalenia dotyczące produkcji wymagają faktycznego zaufanego odbiorcy lub dowodów kryptograficznych oraz zapisów transportu specyficznych dla danej trasy.
Eskaluj bez nadmiernego udostępniania
Podaj właścicielowi usługi odpowiedni adres IP, znaczniki czasu, usługę docelową, dokładną odpowiedź i identyfikatory zredagowanych wiadomości. Zapytaj, czy trasa uległa zmianie, czy znany jest incydent i jakie dalsze dowody są wymagane. Nie żądaj prywatnego ruchu innych klientów ani nie przedstawiaj strony trzeciej lista zablokowanych jako dowód zachowania każdego odbiorcy.
Kontynuuj naprawianie zweryfikowanych usterek lokalnych, podczas gdy dostawca sprawdza infrastrukturę współdzieloną. Jeśli proponowana jest migracja, wymagaj planu, który zachowa uwierzytelnianie, tłumienie i ciągłość wiadomości krytycznych. Przeniesienie już uszkodzonej konfiguracji może rozwiązać problem, jednocześnie zwiększając reputację.
Zamknij obie ścieżki niezależnie
Oznacz naprawę uwierzytelniania klienta jako ukończoną dopiero wtedy, gdy nowa próbka zademonstruje poprawioną trasę. Oznacz badanie puli jako zakończone jedynie z własnym wynikiem potwierdzającym lub jasno określonymi nierozwiązanymi ograniczeniami. Należy odróżniać skargi odbiorców i obserwacje dotyczące miejsca docelowego od obu.
Dzięki temu rozdzieleniu firma otrzymuje użyteczny raport: co kontrolowała i naprawiła, co ustalił dostawca i co nadal wymaga dowodów. Infrastruktura współdzielona jest zależnością, którą należy zarządzać, a nie ogólnym wyjaśnieniem każdego niepowodzenia w dostawie.
Zamknij naprawiony podpis bez zamykania skrzynki trasy
W hipotetycznym następstwie autoryzowana próbka z tego samego strumienia ma teraz zaufaną przepustkę DKIM , ale późniejsza wiadomość nadal otrzymuje odpowiednią tymczasową odmowę transportu. Zapisz, której wiadomości dotyczy każdy wynik i zachowaj adres IP, usługę odbiorcy i czas. Nie dołączaj do niepowiązanych codziennych ostrzeżeń tylko dlatego, że mają ten sam adres IP.
Naprawę podpisu można wesprzeć nową próbką, dopóki kwestia trasy pozostaje otwarta. Przed uogólnieniem zapytaj, czy treść, klasa odbiorcy lub routing zmieniły się pomiędzy próbkami. To uczy niezależnego zamknięcia, a nie wymiernego ożywienia dostawcy lub powodu do natychmiastowej migracji.
Oddziel naprawę klienta od badania basenu
- Sprawdź podpisanie i ocenioną tożsamość wiadomości, której dotyczy problem.
- Zachowaj rzeczywistą trasę, miejsce docelowe i dowody diagnostyczne.
- Przypisz jawnie właściciela konfiguracji i właściciela infrastruktury.
- Zamknij każdą obsługiwaną usterkę według własnego, skorygowanego wyniku.
- Udostępniaj tylko wąskie, autoryzowane dane dotyczące incydentów; nie żądaj ruchu innych klientów.