En ändring av flygbolagets resplan och en flygplatsservicerådgivning kan se likadana ut i en passagerarinkorg, men de har olika myndigheter, deadlines och system. Behandla inte en flygplatsdomän som ett utbytbart alias för flygbolaget, eller anta att en reseaviseringsleverantör kan tala för båda. Den första uppgiften är att fastställa vems meddelande det är och vem som trafikerar rutten.
Kartlägg auktoritet och brådska tillsammans
Den fiktiva kartan tilldelar resplanändringar för passagerarmeddelanden, flygplatsrådgivning till meddelanden om flygplatsdrift och allmänna resemeddelanden till en separat tjänsteägare. För varje rutt, registrera händelsen som skapar meddelandet, den avsedda mottagaren, författarens domän och den senaste användbara mottagningstiden. Den operativa ägaren, inte en generisk e-postinstrumentpanel, måste definiera den deadline.
Använd uppfunna flygreferenser och tydligt markerade testråd. Skicka inte meddelanden om testavbrott till passagerare, driftpersonal eller offentliga distributionslistor. Utför end-to-end-tester endast i auktoriserade konton och miljöer, med procedurer som förhindrar att en syntetisk varning förväxlas med en verklig driftsinstruktion.
Verifiera identitet utan att göra anspråk på leverans
En giltig justerad signatur stöder den påstådda domänidentiteten. Den visar inte att meddelandet undkom en kö, nått passageraren före avgång eller innehåller rätt gate. I exemplet signerar reseaviseringsleverantören med notification-vendor.test medan From använder travel.fly.test. Även om man antar en giltig signatur, misslyckas dessa hypotetiska domäner strikt DKIM inriktning. Detta är inte ett utfört identitetstest eller komplett DMARC dom.
Granska leverantörens dokumenterade identitetsalternativ och tjänstens kontoägande innan du ändrar register. Håll flygbolags- och flygplatsdomänmyndigheten åtskilda. En flygplatsdriftsteams godkännande ger inte tillstånd att skicka från en flygbolagsdomän, även när organisationerna samarbetar på en resa.
Mät aktualitet som sitt eget resultat
SMTP tillåter omförsök efter tillfälliga fel. RFC 5321, avsnitt 4.5.4, beskriver ett nytt försöksbeteende; det är inte ett löfte att ett e-postmeddelande kommer att hålla en flygtidsfrist. Registrera händelseskapande, applikationsköavslut, leverantörsacceptans och kontrollerat kvitto separat. En fiktiv händelse skapad klockan 10:00 med en deadline för användbara kvitton på 10:10 och ett kvitto klockan 10:13 är försenat även om autentiseringen går igenom.
Aritmetiken är 10:13 minus 10:00 = tretton minuter och 10:13 minus 10:10 = tre minuter försenad. Dessa är uppfunna tidsstämplar, inte en exekverad klockmodell. Den återger inte en nätverkskö eller jämför något flygbolag. I ett verkligt test, dokumentera klockkällor och ta hänsyn till tidsstämpel osäkerhet snarare än att låtsas att alla system delar exakt tid.
Bevara de godkända driftskanalerna
Använd organisationens etablerade säkerhets- och passageraraviseringsprocedurer när e-post är försenat eller otillgängligt. Den här guiden godkänner inte e-post som en säkerhetskritisk kontroll eller rekommenderar att man byter ut operativa varningssystem. Definiera återställningsägare före implementering, isolera den felaktiga aviseringsrutten och behåll den tidigare godkända konfigurationen vid behov. Luftfartsreglering, tillgänglighet, passagerarrättigheter och skyldigheter att hålla kvar behöver kvalificerad översyn. Ett autentiseringskort är varken operativ auktorisation eller bevis på överensstämmelse.
Fiktiv vägkarta
Följande explicita identiteter är illustrativa indata, inte riktig kundkonfiguration. Dessa domäner och ansvariga roller är hypotetiska, inte kundgodkännanden eller levererade signerade meddelanden. Inget kryptografiskt test eller leverans utfördes.
- Ändring av resväg: Ledning för passagerarmeddelanden; Från itinerary.fly.test; kuvert och DKIM signer itinerary.fly.test.
- Flygplatsvarning: Meddelandeledning för flygplatsdrift; Från ops.airport.test; kuvert och DKIM -undertecknare ops.airport.test.
- Resemeddelande: Resemeddelanden leder; Från travel.fly.test; kuvert och DKIM signer notification-vendor.test.
Håll den sena händelsen och åtgärden spårbara
Anteckna meddelandets användbara deadline tillsammans med den faktiska beviskällan för varje tidsstämpel. Om klockor eller kvittoobservationer är tillräckligt osäkra för att påverka beslutet, håll den osäkerheten synlig istället för att hävda en exakt leveransprestanda. En auktoriserad operativ ägare måste välja det etablerade svaret; den här artikeln skapar inte en säkerhetsprocedur eller godkänner passagerares räckvidd.
RFC 9989 avsnitt 4.4, 5.3.5 och 5.4 gör inte autentisering till en tids- eller innehållsgaranti. Utvärdera alla relevanta anpassade sökvägar för den fullständiga meddelandedomen. För p=reject distribution, avsnitt 7.4 och 8 kräver giltig DKIM snarare än SPF ensam. Det tretton minuter långa exemplet bevisar bara aritmetik, inte flygbolagets beredskap.