Zmiana planu podróży linii lotniczej i porada dotycząca usług lotniskowych mogą wyglądać podobnie w skrzynce odbiorczej pasażera, ale mają inne uprawnienia, terminy i systemy. Nie traktuj domeny lotniska jako wymiennego aliasu linii lotniczej ani nie zakładaj, że dostawca powiadomień o podróżach może występować w imieniu obu. Pierwszym zadaniem jest ustalenie, czyje to przesłanie i kto obsługuje trasę.
Mapa autorytetu i pilności razem
Fikcyjna mapa przypisuje zmiany w planach podróży w zakresie wiadomości dla pasażerów, komunikatów lotniskowych, komunikatów dotyczących operacji na lotnisku i ogólnych powiadomień o podróżach do osobnego właściciela usługi. Dla każdej trasy zapisz wydarzenie, które utworzyło wiadomość, zamierzonego odbiorcę, domenę autora i ostatni użyteczny czas otrzymania. Właściciel operacyjny, a nie ogólny pulpit nawigacyjny poczty e-mail, musi określić ten termin.
Korzystaj z wymyślonych referencji lotów i wyraźnie oznaczonych porad dotyczących testów. Nie wysyłaj komunikatów o zakłóceniach testów do pasażerów, personelu obsługującego ani publicznych list dystrybucyjnych. Przeprowadzaj kompleksowe testy tylko na autoryzowanych kontach i środowiskach, stosując procedury zapobiegające pomyleniu syntetycznego alertu z prawdziwą instrukcją operacyjną.
Zweryfikuj tożsamość bez żądania dostawy
Prawidłowy dopasowany podpis obsługuje deklarowaną tożsamość domeny. Nie wynika z niego, że wiadomość wymknęła się z kolejki, dotarła do pasażera przed odlotem lub zawiera właściwą bramkę. W tym przykładzie sprzedawca powiadomień podróżnych podpisuje się za pomocą powiadomienia-vendor.test, podczas gdy From używa travel.fly.test. Nawet zakładając prawidłowy podpis, te hipotetyczne domeny nie są rygorystyczne DKIM wyrównanie. Nie jest to wykonany ani kompletny test tożsamości DMARC werdykt.
Przed zmianą danych przejrzyj udokumentowane opcje tożsamości dostawcy i własność konta usługi. Zachowaj odrębność władz linii lotniczej i lotniska. Zgoda zespołu operacyjnego lotniska nie daje pozwolenia na wysyłanie z domeny linii lotniczej, nawet jeśli organizacje współpracują podczas podróży.
Mierz terminowość jako swój własny wynik
SMTP pozwala na ponowne próby po tymczasowych niepowodzeniach. RFC 5321, sekcja 4.5.4, opisuje zachowanie ponawiania prób; nie jest to obietnica, że e-mail dotrzyma terminu lotniczego. Rejestruj oddzielnie utworzenie zdarzenia, wyjście z kolejki aplikacji, akceptację dostawcy i kontrolowany odbiór. Fikcyjne wydarzenie utworzone o godzinie 10:00 z użytecznym terminem odbioru o 10:10 i potwierdzeniem o 10:13 jest spóźnione, nawet jeśli uwierzytelnienie przejdzie.
Arytmetyka to 10:13 minus 10:00 = trzynaście minut i 10:13 minus 10:10 = trzy minuty spóźnienia. Są to wymyślone znaczniki czasu, a nie wykonany model zegara. Nie odtwarza kolejki sieciowej ani nie porównuje żadnych linii lotniczych. W prawdziwym teście należy udokumentować źródła zegara i uwzględnić niepewność znacznika czasu, zamiast udawać, że wszystkie systemy mają ten sam dokładny czas.
Zachowaj zatwierdzone kanały operacyjne
Skorzystaj z ustalonych w organizacji procedur bezpieczeństwa i powiadamiania pasażerów, jeśli poczta e-mail jest opóźniona lub niedostępna. W tym przewodniku nie zatwierdzono poczty elektronicznej jako środka kontroli o krytycznym znaczeniu dla bezpieczeństwa ani nie zalecono wymiany operacyjnych systemów ostrzegania. Zdefiniuj właścicieli odzyskiwania przed wdrożeniem, odizoluj trasę powiadamiania o błędach i zachowaj poprzednią zatwierdzoną konfigurację, jeśli to konieczne. Regulacje lotnicze, dostępność, prawa pasażerów i obowiązki w zakresie przechowywania wymagają kwalifikowanego przeglądu. Przepustka uwierzytelniająca nie stanowi autoryzacji operacyjnej ani dowodu zgodności.
Fikcyjna mapa tras
Poniższe wyraźne tożsamości stanowią przykładowe dane wejściowe, a nie rzeczywistą konfigurację klienta. Te domeny i odpowiedzialne role mają charakter hipotetyczny i nie dotyczą zatwierdzeń klientów ani dostarczonych podpisanych wiadomości. Nie wykonano żadnego testu kryptograficznego ani dostarczenia.
- Zmiana planu podróży: główny komunikat dla pasażerów; Z itinerary.fly.test; koperta i plan podróży osoby podpisującej DKIM .
- Alarm operacyjny lotniska: główny komunikator dotyczący operacji na lotnisku; Z ops.airport.test; koperta i podpis DKIM ops.airport.test.
- Powiadomienia o podróżach: Lider powiadomień o podróżach; Z travel.fly.test; koperta i powiadomienie podpisującego DKIM -vendor.test.
Zachowaj możliwość śledzenia późnego zdarzenia i środka zaradczego
Zapisz użyteczny termin powiadomienia obok rzeczywistego źródła dowodów dla każdego znacznika czasu. Jeżeli zegary lub obserwacje pokwitowań są na tyle niepewne, że mogą mieć wpływ na decyzję, należy uwidocznić tę niepewność, zamiast zapewniać dokładną realizację dostawy. Upoważniony właściciel operacyjny musi wybrać ustaloną reakcję; artykuł ten nie ustanawia procedury bezpieczeństwa ani nie zatwierdza działań informacyjnych dla pasażerów.
RFC 9989 sekcje 4.4, 5.3.5 i 5.4 nie zamieniaj uwierzytelnienia w gwarancję czasu lub treści. Oceń wszystkie odpowiednie, dopasowane ścieżki, aby uzyskać pełny werdykt wiadomości. Dla p=reject wdrożenia, sekcje 7.4 i 8 wymagają raczej prawidłowego DKIM SPF sam. Trzynastominutowy przykład dowodzi jedynie arytmetyki, a nie gotowości linii lotniczych.