Wychodząca brama bezpieczeństwa lub usługa podpisu korporacyjnego mogą sprawdzać i modyfikować pocztę, gdy aplikacja już ją podpisała. Stajnia DKIM design stawia ostatni etap autoryzowanego podpisywania po wymaganych zmianach treści i weryfikuje całą trasę. Ważne pytanie dotyczy tego, który komponent wysyła końcowy komunikat, a nie który produkt jako pierwszy wyświetla włączone ustawienie DKIM .
Narysuj rzeczywistą kolejność przetwarzania
Przesyłanie map, kontrola treści, zrzeczenie się odpowiedzialności lub wstawienie podpisu, serializacja MIME , podpisywanie DKIM i dostarczanie zewnętrzne. Uwzględnij alternatywne trasy używane przez aplikacje i awaryjne przełączanie awaryjne. Nie zakładaj, że poczta w skrzynce pocztowej pracowników i poczta aplikacyjna podążają tą samą ścieżką.
Dla każdego komponentu zapisz, czy zmienia treść, wybrane nagłówki, tożsamość koperty, czy tylko metadane routingu. Blok podpisu w firmowej wiadomości e-mail to treść; nie ma to związku z kryptografią DKIM-Signature nagłówek pomimo wspólnego słowa „podpis”. Przepisywanie adresów URL, obsługa załączników i przebudowa HTML mogą również mieć wpływ na omawianą treść.
RFC 6376 §5.3 I RFC 6376 §5.5 wymagać od podpisującego działania na zamierzonej przesłanej reprezentacji i modyfikowania przez osoby podpisujące, aby dokonały zmian przed ponownym złożeniem podpisu. Projekt powinien sprawić, że sekwencjonowanie będzie widoczne i możliwe do przetestowania.
Wybierz domenę i właściciela klucza
Brama może dodać ważny podpis w ramach własnej domeny. Nie spełnia to automatycznie wymagań DKIM wyrównanie dla Twojej domeny autora pod RFC 9989 §4.4.1. Jeśli wymagany projekt wykorzystuje niestandardowe podpisywanie domeny, sprawdź udokumentowane możliwości produktu, wygenerowane wartości DNS i opiekę nad kluczem prywatnym. Nie wymyślaj selektor nazwy lub skopiuj konfigurację innego dzierżawcy.
Zdecyduj, kto może zmieniać konfigurację podpisywania, zmieniać klucze i zmieniać ostateczny potok treści. Chroń klucze prywatne przed eksportem do notatek o zdarzeniach lub pakietów testowych. Publikowanie klucza publicznego to tylko jedna część konfiguracji; prawdziwe wiadomości wychodzące muszą mieć pasujący podpis utworzony po ostatecznym przetworzeniu.
Przetestuj potok za pomocą dwóch kontrolek
Projekt ilustracyjny A najpierw podpisuje, a następnie dołącza korporacyjny blok kontaktowy. Oryginalny podpis całego ciała może zawieść. Projekt B wstawia blok, kończy serializację MIME , a następnie podpisuje autoryzowaną dopasowaną domenę. Zamierzony podpis może przetrwać, jeśli późniejsze przetwarzanie pozostawi objęte dane nienaruszone. Są to oczekiwania testowe, a nie twierdzenie dotyczące wskazanego dostawcy.
Wyślij zwykły tekst, HTML, zawartość inną niż ASCII i załącznik zamierzoną trasą. W stosownych przypadkach uwzględnij komunikaty generowane przez aplikację i obsługiwaną trasę przełączania awaryjnego. Przechwyć wiadomość po ostatnim procesorze i u zaufanego odbiornika zewnętrznego. Powiąż każdy wynik z d i s, zamiast akceptować etykietę niezróżnicowanego przebiegu.
Zachowaj kontrolę bezpieczeństwa w projekcie
Przeniesienie podpisywania na później nie powinno po cichu przenosić kontroli poza chroniony przepływ pracy ani pomijać wymaganego skanowania. Jeśli ostateczny sygnatariusz nie może uruchomić usługi po obowiązkowej usłudze przepisywania, oceń obsługiwane integracje lub inną granicę autoryzowanego podpisywania. Unikaj używania l do wykluczania późniejszej treści jedynie w celu obliczenia liczby przejść; RFC 6376 §8.2 wyjaśnia ryzyko związane z niepodpisaną treścią.
Dalszy nowy podpis może współistnieć z wcześniejszym, który się nie powiódł. Sprawdź, który podpis zapewnia zamierzone wyrównanie i w jaki sposób zgłasza to usługa odbierająca. Nie usuwaj dowodów wcześniejszej awarii z zapisów testów.
Obsługuj granicę jako usługę kontrolowaną przez zmiany
Zachowaj schemat trasy, odpowiedzialnych właścicieli, plan przechowywania kluczy i zestaw testów formatu. Przetestuj ponownie po aktualizacji bramy, zmianie szablonu marki, zmianie routingu i aktywacji przełączania awaryjnego. Sukces wymaga zamierzonej treści, prawidłowej, dopasowanej ścieżki uwierzytelniania i prawidłowego dostarczania, przy czym zatwierdzenie przez człowieka jest nadal niezależne od wyniku technicznego.
Zapisz następną decyzję
W przypadku hipotetycznej wiadomości zapisz kolejność procesorów, oczekiwane zmiany treści, każdą parę d/s, werdykt i wyrównanie odbiorcy. Jeśli brama podpisuje się tylko jako niepowiązana domena dostawcy, oznacz wyrównany DKIM nierozwiązany, nawet jeśli jego podpis przejdzie pomyślnie. Jeśli przeniesienie podpisującego spowodowałoby ominięcie inspekcji, zatrzymaj tę zmianę projektu i poszukaj wspieranej integracji. Są to kryteria planowania, a nie wykonane testy trasy.