Portal może przyjąć wniosek w przypadku niepowodzenia jego przyjęcia lub pomyślnie wysłać przypomnienie, gdy aktualizacja statusu korzysta z zapomnianego przekaźnika. W obu przypadkach obywatel doświadcza zepsutej usługi. Traktuj potwierdzenia, przypomnienia i powiadomienia o stanie jako trzy niezależne trasy, zanim zaczniesz korzystać z połączonej metryki uwierzytelniania.
Powiąż każde powiadomienie ze zmianą stanu
W przypadku potwierdzenia zidentyfikuj zdarzenie aplikacji, które je tworzy, oraz identyfikator łączący je z przesłaniem. Aby otrzymać przypomnienie o spotkaniu, zapisz system planowania, strefę czasową i zachowanie w zakresie zmiany harmonogramu. Aby uzyskać aktualizację statusu, określ przejście w zakresie zarządzania sprawami i wiarygodne miejsce, w którym obywatel może to zweryfikować. Trzymaj czas powiadomienia oddzielnie od czasu zdarzenia.
Mapuj każde zdarzenie na aplikację wysyłającą, dzierżawcę dostawcy, z domeny, nadawca kopertowy, DKIM domena i selektor. Domena portalu internetowego i certyfikat TLS nie pokazują, który system wysyła pocztę e-mail. Integracja aplikacji może wybrać innego dostawcę dla każdej rodziny powiadomień, nawet jeśli wszystkie wiadomości mają ten sam wygląd wizualny.
Projektuj testy wokół zmian, a nie tylko szczęśliwej ścieżki
Korzystaj z fikcyjnych aplikacji i autoryzowanych testowych skrzynek pocztowych. Uruchom przesłanie, zmianę spotkania, anulowanie spotkania i zmianę statusu w zatwierdzonym środowisku testowym, jeśli jest to możliwe. Sprawdź końcowe bajty wiadomości i wiarygodny wynik uwierzytelnienia odbiorcy. Potwierdź, że linki i wyświetlane odniesienia prowadzą do oczekiwanej oficjalnej usługi, bez uwzględniania szczegółów rzeczywistych przypadków obywateli w ogólnych dziennikach testów.
Przypomnienie ustawione w kolejce przed zmianą terminu może być poprawnie podpisane i nadal opisywać nieaktualne spotkanie. Uwierzytelnianie domeny nie rozwiązuje tej wady aplikacji. Śledź zdarzenie i wersję powiadomienia, aby operacje mogły odróżnić nieaktualną treść od błędu tożsamości. Podobnie zduplikowany paragon powinien zostać zbadany jako problem związany ze zdarzeniem lub ponowną próbą, a nie automatycznie klasyfikowany jako fałszowanie.
Zdecyduj, kto zatrzyma przerwaną podróż
Właściciel aplikacji powinien ocenić, czy obywatel może bezpiecznie kontynuować korzystanie z poczty, gdy poczta e-mail jest niedostępna. Właściciel harmonogramu powinien zająć się rozbieżnościami przypomnieniami, a operacje spraw powinny obsługiwać powiadomienia o statusie. Zdefiniuj zatwierdzoną alternatywną ścieżkę sprawdzania statusu i osobę kontaktową w sprawie eskalacji przed zaostrzeniem polityki. Nie obiecuj alternatywnego kanału, jeśli nie ma on prawdziwego wsparcia i personelu.
Jeśli nadawca nie jest wyrównany, sprawdź rzeczywiste możliwości domeny niestandardowej usługi i rekordy wygenerowane przez dzierżawcę. Zmień tylko zatwierdzoną ścieżkę tożsamości, przetestuj ją i zachowaj przestarzały plan wycofywania zmian. Unikaj szerokich SPF dodatki wprowadzone wyłącznie dlatego, że źródłowy adres IP wygląda znajomo. Dostawca może uwierzytelnić własną domenę, nie ustanawiając jej wyrównanie z domeną From usługi publicznej.
Monitoruj kompletność, a nie tylko wartości procentowe
Zapisz, które rodziny powiadomień zostały zaobserwowane, które zostały przetestowane, a które pozostają niezweryfikowane. Uwzględnij rzadkie zdarzenia cyklu życia i warianty w języku lokalnym, jeśli korzystają z różnych szablonów lub systemów. Używać raporty zbiorcze aby zidentyfikować wzorce w ich rzeczywistym zasięgu raportowania, a następnie zbadać brakujące lub uszkodzone trasy na podstawie dowodów serwisowych. Odśwież mapę po uaktualnieniu portalu, zmianie harmonogramu, zmianie dostawcy i zmianach w domenie Od. Nie określono tu żadnego konkretnego ustawowego terminu powiadomienia.
Przejrzyj trzy pisemne zapisy tras
Te zastrzeżone przykładowe domeny, selektory, role i przekazywanie przesłanek DKIM są fikcyjne. W takich przypadkach nie jest dostarczana ani wykonywana żadna podpisana wiadomość, klucz, weryfikacja kryptograficzna, wyszukiwanie DNS , transakcja SMTP ani test usługi na żywo. Do sprawdzenia poniższego rozumowania nie jest potrzebny żaden kod testowy ani próbka zewnętrzna.
- paragon: widoczny Z domeny receipts.civic.example ; DKIM d=receipts.civic.example; demo selektora1; przyjąć, że przepustka DKIM jest przeznaczona wyłącznie do tej pisemnej sprawy. POCZTA SPF Z tożsamości i wyniku nieznane; inne podpisy nieznane; faktyczne odkrycie i dostarczenie zasad jest nieznane. Proponowany właściciel: właściciel usługi aplikacji. Następna akcja: Uzyskaj wynik autoryzowanej próbki i zaufanego odbiorcy dla tego dokładnego najemcy.
- przypomnienie o spotkaniu: widoczne z domeny appointments.civic.example ; DKIM d=appointments.civic.example; demo selektora2; przyjąć, że przepustka DKIM jest przeznaczona wyłącznie do tej pisemnej sprawy. POCZTA SPF Z tożsamości i wyniku nieznane; inne podpisy nieznane; faktyczne odkrycie i dostarczenie zasad jest nieznane. Proponowany właściciel: Właściciel harmonogramu. Następna akcja: Potwierdź tę oddzielną trasę i związane z nią wydarzenie biznesowe, zamiast dziedziczyć wynik pierwszej trasy.
- informacja o statusie: widoczna Z domeny status.civic.example ; DKIM d=provider.example.net; demo selektora3; przyjąć, że przepustka DKIM jest przeznaczona wyłącznie do tej pisemnej sprawy. POCZTA SPF Z tożsamości i wyniku nieznane; inne podpisy nieznane; faktyczne odkrycie i dostarczenie zasad jest nieznane. Proponowany właściciel: Właściciel zarządzający sprawami. Następna akcja: Zapytaj zweryfikowanego dostawcę o obsługiwaną, wyrównaną ścieżkę podpisywania tego najemcy; nie rozszerzać uprawnień na całą swoją sieć.
Dla pierwszych dwóch określonych podpisów d= jest dokładnie równe domenie From, więc identyfikator spełnia zarówno ścisłe, jak i swobodne dopasowanie. Biorąc pod uwagę określony pomyślny wynik DKIM , dla tych hipotetycznych wiadomości istnieje dostosowana ścieżka uwierzytelniania. Trzeci sygnatariusz celowo nie jest powiązany z domeną autora i nie może zapewnić tej dopasowanej ścieżki. Nie dzwoń do trzeciej wiadomości a DMARC awaria: wyrównany SPF lub inne wyrównane przejście Podpis DKIM nadal mogłyby spełniać mechanizm, a te dane wejściowe są nieznane. Nie wnioskuj o rzeczywistym rozmieszczeniu ani umiejscowieniu skrzynki odbiorczej na podstawie żadnego wiersza.
Podpis kryptograficzny potwierdza odpowiedzialność domeny podpisującej, a nie prawdziwość lub autoryzację każdej instrukcji. Zmiany w objętych kanonizowanymi bajtach mogą unieważnić podpis; nie każda widoczna edycja koniecznie zmienia podpisane dane wejściowe. Uwierzytelnianie i akceptacja na poziomie aplikacji pozostają odrębne.
Rozwiąż przykład nieaktualnego przypomnienia
Załóżmy, że w fikcyjnym przypadku spotkanie C-01 w wersji 1 odbyło się o 10:00 GST, a wersja 2 przenosi je na 11:00 GST tego samego dnia. Przypomnienie w wersji 1, które już znajduje się w kolejce, ma przejść dostosowane DKIM . Wynik jego tożsamości nie oznacza, że godzina 10:00 jest aktualna. Właściciel harmonogramu powinien zastosować zatwierdzoną zasadę anulowania lub wymiany, zweryfikować aktualną wizytę na oficjalnym portalu i sprawdzić, czy korekta rzeczywiście została dostarczona. Jeśli zamiast tego wiadomość zawiera wersję 2, ale nie zawiera zaufanego dowodu uwierzytelnienia, sprawdź osobno trasę poczty. Nie wykorzystano tutaj żadnego prawdziwego przypadku, wiadomości, zadania zmiany harmonogramu ani wysłania korekty.
Stosuj standardy bez twierdzenia, że są zgodne
RFC 9989 sekcje 4.4 i 5.3.5 wspierają rozróżnienie wyrównania i mechanizmu. Jej sekcja 7.4 ostrzega o interoperacyjności poczty pośredniej: używanie domen p=reject musi używać prawidłowego DKIM , a nie samego SPF , a korzystanie z list mailingowych ogólnego przeznaczenia wymaga szczególnej ostrożności. Spis tras sam w sobie nie jest zezwoleniem na wymuszenie odrzucenia. RFC 6376 sekcje 3.4–3.7 i 6.1 opisz podpisane dane wejściowe i weryfikację. RFC 9990 sekcja 3.1 zapewnia kontekst raportowania, a nie dowód przybycia konkretnego odbiorcy. RFC 5321 sekcja 4.2.5 odróżnia odpowiedzialność za akceptację serwera od późniejszych wyników dostarczania. Wybory dotyczące przepływu pracy w sektorze są tutaj zaleceniami redakcyjnymi; zakres prawny, przydatność czynników i lokalne zezwolenia wymagają własnego, odpowiedzialnego przeglądu.