Pasien mungkin melihat logo yang sama pada pengingat janji temu, pesan pendaftaran, dan email akses portal bahkan ketika tiga aplikasi berbeda mengirimkannya. Identifikasi layanan di balik setiap pesan. Kemudian uji identitas emailnya dan perilaku aplikasi yang membuat notifikasi berguna dan aman.
Identifikasi pemicu dan tujuannya
Untuk janji temu, catat acara penjadwalan mana yang memicu pesan dan bagaimana penjadwalan ulang atau pembatalan memengaruhi pengingat antrean. Untuk pendaftaran, catat aplikasi yang bertanggung jawab mencocokkan pesan dengan orang yang dituju. Untuk akses portal, identifikasi layanan akun dan tautan atau siklus hidup kode yang disetujui. Simpan penyedia dan penyewa email sebenarnya di samping setiap aplikasi, tidak hanya alamat situs web portal.
Catat domain Dari, identitas amplop, DKIM domain dan pemilih untuk setiap rute. Periksa tujuan balasan dan host portal yang disetujui sebagai bidang terpisah. Tanda tangan yang valid di bawah domain layanan tidak menetapkan bahwa tautan tersebut aman, terkini, atau ditujukan untuk penerima. Sebaliknya, URL portal yang familier tidak membuktikan bahwa email tersebut diotorisasi.
Uji perubahan siklus hidup dengan catatan fiksi
Buat kasus janji temu dan registrasi sintetis yang disetujui. Lakukan penunjukan baru, penjadwalan ulang, pembatalan, upaya pendaftaran duplikat, dan permintaan akses portal jika lingkungan pengujian mengizinkan. Konfirmasikan pesan mana yang benar-benar muncul, apakah pengingat lama disembunyikan oleh aplikasi dan apakah tautan mengarah ke portal pengujian yang diharapkan.
Untuk pesan akses akun, gunakan nilai demonstrasi yang tidak berfungsi atau akun pengujian terpisah yang disetujui. Jangan menyimpan tautan atau kode akses pasien yang dapat digunakan dalam bukti otentikasi umum. Email akses tertunda mungkin melewati DKIM saat tokennya telah habis masa berlakunya; itu adalah hasil siklus hidup aplikasi, bukan bukti cacat autentikasi.
Pisahkan tiga jenis kegagalan
Jika DKIM gagal atau tidak ada jalur yang selaras, tim email dan layanan harus menyelidiki perubahan penandatanganan, identitas, dan pesan. Jika pengingat memiliki waktu yang salah, pemilik penjadwalan harus menyelidiki versi acara dan penanganan zona waktu. Jika pesan mencapai alamat yang sudah ketinggalan zaman, tim registrasi dan identitas harus mengikuti proses koreksi penerima yang disetujui. Jangan selesaikan dua masalah terakhir dengan bersantai DMARC kebijakan.
Simpan catatan pengujian singkat yang berisi ID kasus sintetis, waktu kejadian, identitas pengirim, autentikasi yang diamati, hasil aplikasi, dan pemilik. Gunakan sedikit bukti yang telah disunting. Header email masih dapat berisi alamat pribadi dan informasi perutean, jadi perlakukan alamat tersebut sesuai dengan aturan akses dan penyimpanan organisasi daripada berasumsi bahwa header bersifat publik.
Tentukan keputusan penerimaan
Memerlukan identitas pengiriman yang benar ditambah perilaku aplikasi yang diharapkan untuk setiap kelompok pesan. Pass tanda tangan saja tidak dapat menyetujui perjalanan portal. Konfirmasikan jalur pemulihan yang disetujui dengan pemilik layanan ketika pengingat atau pemberitahuan akses gagal, tanpa membuat saluran komunikasi alternatif yang tidak disetujui.
Peta fiksi di bawah ini sengaja meninggalkan spesimen akses portal dengan tanda tangan domain penyedia yang tidak sejajar. Validitas kriptografi yang ditetapkan menggambarkan mengapa hanya mencari DKIM =pass saja tidak cukup. Kesiapan produksi memerlukan bukti pelayanan yang aktual dan aplikatif SPF atau DKIM penyelarasan, bukan premis tertulis.
Periksa kembali setelah penggantian penjadwal, perubahan registrasi, migrasi penyedia identitas, host portal baru, dan perubahan domain pengirim. Sertakan pengecualian bervolume rendah seperti janji temu yang dibatalkan dan akun yang dipulihkan. Ini adalah metode verifikasi operasional, bukan klaim bahwa platform layanan kesehatan atau produk EmailAuth mana pun telah menerapkan kontrol ini.
Periksa buku besar rute tertulis
Semua baris menggunakan domain fiktif yang dicadangkan, pemilik yang diusulkan, dan hasil DKIM yang ditetapkan. Demo pemilih1 adalah label ilustratif, bukan kunci yang terpasang. Hasil SPF , tanda tangan lainnya, penemuan kebijakan DNS , penerimaan aktual, dan keberhasilan aplikasi tidak diketahui. Tidak ada kunci, pesan yang ditandatangani, pelaksanaan pengujian, atau bukti pengiriman yang diberikan.
- janji temu: Dari appointments.care.example ; KIRIM DARI tidak dikenal; DKIM d=appointments.care.example, demo pemilih1, dianggap lulus; pemilik yang diusulkan Pemilik penjadwalan. Tindakan selanjutnya: Verifikasi jalur penandatanganan yang didukung penyewa ini dan kriteria penerimaan aplikasinya yang terpisah.
- registrasi: Dari registration.care.example ; MAIL DARI tidak diketahui; DKIM d=registration.care.example, demo pemilih1, dianggap lulus; pemilik yang diusulkan Pemilik pendaftaran. Tindakan selanjutnya: Verifikasi jalur penandatanganan yang didukung penyewa ini dan kriteria penerimaan aplikasinya yang terpisah.
- akses portal: Dari access.care.example ; MAIL DARI tidak diketahui; DKIM d=provider.example.net, demo pemilih1, dianggap lulus; pemilik yang diusulkan Pemilik layanan identitas. Tindakan selanjutnya: Verifikasi jalur penandatanganan yang didukung penyewa ini dan kriteria penerimaan aplikasinya yang terpisah.
Tanda tangan yang diasumsikan lewat yang d= sama persis dengan From menyediakan jalur yang benar-benar selaras untuk pesan hipotetis tersebut. D= yang tidak berhubungan tidak menyediakan jalur yang selaras dari tanda tangan itu. SPF yang tidak diketahui atau tanda tangan lainnya mencegah putusan kegagalan secara keseluruhan untuk kasus terakhir. Tempat tertulis ini tidak menetapkan konfigurasi langsung atau penempatan kotak masuk.
Bandingkan tiga keputusan siklus hidup
Gunakan kasus portal fiksi P-02 di penyewa pengujian yang diusulkan. Janji temu versi 1 pada pukul 09:00 GST dibatalkan sebelum pengingat antriannya dikeluarkan: bahkan izin masuk DKIM yang ditetapkan akan meninggalkan cacat penjadwalan. Pesan pendaftaran yang dialamatkan ke akun sintetis yang salah merupakan cacat pemetaan penerima. Tautan akses dengan asumsi masa berlaku berakhir pukul 09:10 GST dan berlaku pada pukul 09:12 GST harus dievaluasi berdasarkan aturan masa berlaku aplikasi; otentikasi tidak memperpanjang validitas. Penjadwalan, registrasi dan pemilik identitas masing-masing mencatat hasil yang diharapkan dan observasi terpisah. Di sini observasi tersebut tidak diberikan, jadi tidak ada tes yang lulus. Jangan menyalin token langsung, tautan pasien, atau kode yang dapat digunakan ke dalam paket bukti.
Jaga agar batasan bukti tetap eksplisit
RFC 9989 Bagian 4.4 dan 5.3.5 membedakan otentikasi dan penyelarasan; Bagian 5.4 menyerahkan penanganan pesan pada kebijakan penerima. Bagian 7.4 memerlukan DKIM yang valid dan bukan SPF saja untuk penerbitan domain p=reject dan memperingatkan terhadap penolakan untuk domain yang penggunanya memposting ke milis Internet. Byte terkanonikalisasi yang tercakup menentukan integritas DKIM berdasarkan RFC 6376 Bagian 3.4–3.7 dan 6.1. Tidak ada mekanisme yang memvalidasi otoritas klinis, pendidikan atau hukum. Kumpulkan bukti resmi terkini untuk penerapan aktual; daftar periksa operasional di sini adalah rekomendasi, bukan penilaian kepatuhan spesifik yurisdiksi.