Perubahan rencana perjalanan maskapai penerbangan dan saran layanan bandara mungkin terlihat serupa di kotak masuk penumpang, namun keduanya memiliki otoritas, tenggat waktu, dan sistem yang berbeda. Jangan memperlakukan domain bandara sebagai alias yang dapat dipertukarkan untuk maskapai penerbangan, atau berasumsi bahwa penyedia notifikasi perjalanan dapat mewakili keduanya. Tugas pertama adalah menentukan pesan siapa yang dikirimkan dan siapa yang mengoperasikan rute tersebut.
Petakan otoritas dan urgensi secara bersamaan
Peta fiksi memberikan perubahan rencana perjalanan pada pesan penumpang, saran bandara pada pesan operasional bandara, dan pemberitahuan perjalanan umum ke pemilik layanan terpisah. Untuk setiap rute, catat peristiwa yang membuat pesan, penerima yang dituju, domain penulis, dan waktu penerimaan terbaru yang berguna. Pemilik operasional, bukan dasbor email umum, yang harus menentukan tenggat waktu tersebut.
Gunakan referensi penerbangan yang ditemukan dan saran pengujian yang ditandai dengan jelas. Jangan mengirimkan pesan gangguan pengujian kepada penumpang, kru pengoperasian, atau daftar distribusi publik. Lakukan pengujian end-to-end hanya di akun dan lingkungan resmi, dengan prosedur yang mencegah kesalahan peringatan sintetis sebagai instruksi operasional sebenarnya.
Verifikasi identitas tanpa mengklaim pengiriman
Tanda tangan selaras yang valid mendukung identitas domain yang diklaim. Ini tidak menunjukkan bahwa pesan lolos dari antrian, sampai ke penumpang sebelum keberangkatan, atau berisi gerbang yang benar. Dalam contoh, vendor notifikasi perjalanan menandatangani dengan notifikasi-vendor.test sedangkan Dari menggunakan travel.fly.test. Bahkan dengan asumsi tanda tangan yang valid, domain hipotetis ini gagal total DKIM penyelarasan. Ini bukan tes identitas yang dijalankan atau selesai DMARC dakwaan.
Tinjau opsi identitas penyedia yang terdokumentasi dan kepemilikan akun layanan sebelum mengubah catatan. Pisahkan otoritas domain maskapai penerbangan dan bandara. Persetujuan tim operasi bandara tidak memberikan izin untuk mengirim dari domain maskapai penerbangan, bahkan ketika organisasi tersebut bekerja sama dalam sebuah perjalanan.
Ukur ketepatan waktu sebagai hasilnya sendiri
SMTP mengizinkan percobaan ulang setelah kegagalan sementara. RFC 5321, bagian 4.5.4, menjelaskan perilaku percobaan ulang; ini bukanlah janji bahwa sebuah email akan memenuhi tenggat waktu penerbangan. Catat pembuatan acara, keluar dari antrian aplikasi, penerimaan penyedia, dan penerimaan terkontrol secara terpisah. Peristiwa fiktif yang dibuat pada pukul 10:00 dengan batas waktu penerimaan yang berguna pada pukul 10:10 dan penerimaan pada pukul 10:13 terlambat meskipun autentikasi berhasil.
Hitungannya adalah 10:13 dikurangi 10:00 = tiga belas menit, dan 10:13 dikurangi 10:10 = terlambat tiga menit. Ini adalah stempel waktu yang diciptakan, bukan model jam yang dieksekusi. Itu tidak mereproduksi antrian jaringan atau membuat tolok ukur maskapai mana pun. Dalam pengujian sebenarnya, dokumentasikan sumber jam dan perhitungkan ketidakpastian stempel waktu daripada berpura-pura bahwa semua sistem berbagi waktu yang tepat.
Pertahankan saluran operasional yang disetujui
Gunakan prosedur keselamatan dan pemberitahuan penumpang yang ditetapkan organisasi ketika email tertunda atau tidak tersedia. Panduan ini tidak menyetujui email sebagai kontrol yang sangat penting bagi keselamatan atau merekomendasikan penggantian sistem peringatan operasional. Tentukan pemilik pemulihan sebelum penerapan, isolasi rute pemberitahuan yang gagal, dan pertahankan konfigurasi yang disetujui sebelumnya sebagaimana mestinya. Peraturan penerbangan, aksesibilitas, hak penumpang dan kewajiban retensi memerlukan tinjauan yang berkualitas. Kartu autentikasi bukanlah otorisasi operasional atau bukti kepatuhan.
Peta rute fiksi
Identitas eksplisit berikut adalah masukan ilustratif, bukan konfigurasi pelanggan sebenarnya. Domain dan peran yang bertanggung jawab ini bersifat hipotetis, bukan persetujuan pelanggan atau pesan bertanda tangan yang diberikan. Tidak ada tes atau pengiriman kriptografi yang dilakukan.
- Perubahan rencana perjalanan: Pemimpin pengiriman pesan penumpang; Dari rencana perjalanan.fly.test; amplop dan rencana perjalanan penandatangan DKIM .
- Peringatan operasional bandara: Pimpinan pengiriman pesan operasi bandara; Dari ops.airport.test; amplop dan penandatangan DKIM ops.airport.test.
- Pemberitahuan perjalanan: Petunjuk perjalanan; Dari perjalanan.fly.test; amplop dan penandatangan DKIM notifikasi-vendor.test.
Jaga agar kejadian yang terlambat dan solusinya dapat dilacak
Catat batas waktu pemberitahuan yang berguna di samping sumber bukti aktual untuk setiap stempel waktu. Jika jam atau pengamatan tanda terima cukup tidak pasti untuk mempengaruhi keputusan, pertahankan agar ketidakpastian tersebut tetap terlihat daripada menegaskan kinerja pengiriman yang sebenarnya. Pemilik operasional yang berwenang harus memilih respons yang ditetapkan; artikel ini tidak membuat prosedur keselamatan atau menyetujui penjangkauan penumpang.
RFC 9989 Bagian 4.4, 5.3.5 dan 5.4 jangan mengubah otentikasi menjadi jaminan waktu atau konten. Evaluasi semua jalur selaras yang relevan untuk mendapatkan keputusan pesan yang lengkap. Untuk p=reject penerapannya, Bagian 7.4 dan 8 memerlukan DKIM yang valid SPF sendiri. Contoh tiga belas menit hanya membuktikan aritmatika, bukan kesiapan maskapai penerbangan.