Bir portal, alımı başarısız olduğunda bir uygulamayı kabul edebilir veya durum güncellemeleri unutulmuş bir geçiş kullanırken başarılı bir şekilde hatırlatıcılar gönderebilir. Her iki durumda da vatandaş hizmetin aksadığını yaşıyor. Birleşik bir kimlik doğrulama ölçüsüne güvenmeden önce makbuzları, hatırlatıcıları ve durum bildirimlerini bağımsız olarak sahip olunan üç yol olarak değerlendirin.
Her bildirimi bir durum geçişine bağlayın
Alındı için, onu oluşturan uygulama olayını ve onu gönderime bağlayan tanımlayıcıyı tanımlayın. Randevu hatırlatıcısı için planlama sistemini, saat dilimini ve yeniden planlama davranışını kaydedin. Durum güncellemesi için vaka yönetimi geçişini ve vatandaşın bunu doğrulayabileceği yetkili yeri tanımlayın. Bildirim zamanını temel olay zamanından ayrı tutun.
Her olayı gönderen uygulamayla, satıcı kiracıyla, Etki alanından, Zarf göndereni, DKIM etki alanı ve seçici. Web portalının etki alanı ve TLS sertifikası hangi sistemin e-posta gönderdiğini göstermiyor. Uygulama entegrasyonu, tüm mesajlar aynı görsel tasarımı paylaşsa bile her bildirim ailesi için farklı bir sağlayıcı seçebilir.
Yalnızca mutlu yolu değil, değişiklikleri de kapsayan tasarım testleri
Kurgusal uygulamaları ve yetkili test posta kutularını kullanın. Mümkün olduğunda onaylı bir test ortamında gönderimi, randevuyu değiştirmeyi, iptal edilen randevuyu ve durum değişikliğini tetikleyin. Son mesaj baytlarını ve alıcının güvenilir kimlik doğrulama sonucunu inceleyin. Bağlantıların ve görüntülenen referansların, genel test günlüklerine gerçek vatandaş vakası ayrıntılarını dahil etmeden, beklenen resmi hizmete yol açtığını doğrulayın.
Yeniden planlamadan önce kuyruğa alınan bir hatırlatıcı doğru şekilde imzalanabilir ve yine de geçerliliğini yitirmiş bir randevuyu açıklayabilir. Etki alanı kimlik doğrulaması bu uygulama kusurunu çözmez. İşlemlerin eski içeriği kimlik hatasından ayırt edebilmesi için bildirimin kaynak olayını ve sürümünü izleyin. Benzer şekilde, yinelenen bir alındı makbuzunun otomatik olarak sınıflandırılması yerine bir olay veya yeniden deneme sorunu olarak araştırılması gerekir. sahtekarlık.
Kırık bir yolculuğu kimin durduracağına karar verin
Başvuru sahibi, e-postanın kullanılamadığı durumlarda vatandaşın güvenli bir şekilde devam edip edemeyeceğine karar vermelidir. Planlama sahibi, hatırlatma tutarsızlıklarını ele almalı ve vaka operasyonları durum bildirimlerini ele almalıdır. Sıkılaştırma politikasından önce onaylı alternatif durum kontrol yolunu ve üst kademeye iletme iletişim kişisini tanımlayın. Gerçekten desteklenmedikçe ve kadro sağlanmadıkça alternatif bir kanal vaat etmeyin.
Gönderen hizalanmamışsa hizmetin gerçek özel etki alanı özelliğini ve kiracı tarafından oluşturulan kayıtları doğrulayın. Yalnızca onaylanmış kimlik yolunu değiştirin, test edin ve tarihli bir geri alma planı bulundurun. Genişten kaçının SPF yalnızca kaynak IP tanıdık geldiği için yapılan eklemeler. Bir sağlayıcı, kurulum başarısız olmasına rağmen kendi alan adının kimliğini doğrulayabilir hizalama kamu hizmetinin From alanıyla.
Yalnızca yüzdelerden ziyade bütünlüğü izleyin
Hangi bildirim ailelerinin gözlemlendiğini, hangilerinin test edildiğini ve hangilerinin doğrulanmadığını kaydedin. Farklı şablonlar veya sistemler kullandıklarında nadir yaşam döngüsü olaylarını ve yerel dil değişkenlerini dahil edin. Kullanmak toplu raporlar Gerçek raporlama kapsamlarındaki kalıpları belirlemek, ardından eksik veya başarısız rotaları hizmet kanıtlarıyla birlikte araştırmak. Portal yükseltmeleri, zamanlayıcı değişiklikleri, satıcı değişimi ve Kimden etki alanında yapılan değişiklikler sonrasında haritayı yenileyin. Burada belirli bir yasal bildirim son tarihi belirtilmemiştir.
Üç yazılı rota kaydı üzerinde çalışın
Bu ayrılmış örnek alanlar, seçiciler, roller ve geçen DKIM tesisleri kurgusaldır. Bu durumlar için hiçbir imzalı mesaj, anahtar, kriptografik doğrulama, DNS araması, SMTP işlemi veya canlı hizmet testi sağlanmaz veya yürütülmez. Aşağıdaki gerekçeyi incelemek için herhangi bir test koduna veya harici numuneye gerek yoktur.
- makbuz: görünür Alan receipts.civic.example ; DKIM d=receipts.civic.example; seçici demo1; DKIM geçişini yalnızca bu yazılı durum için varsayalım. SPF POSTADAN kimlik ve sonuç bilinmiyor; diğer imzalar bilinmiyor; gerçek politika keşfi ve teslimatı bilinmiyor. Önerilen sahip: Uygulama hizmeti sahibi. Sonraki eylem: Tam olarak bu kiracı için yetkili bir numune ve güvenilir alıcı sonucu edinin.
- randevu hatırlatıcısı: görünür appointments.civic.example alanından; DKIM d=appointments.civic.example; seçici demo2; DKIM geçişini yalnızca bu yazılı durum için varsayalım. SPF POSTADAN kimlik ve sonuç bilinmiyor; diğer imzalar bilinmiyor; gerçek politika keşfi ve teslimatı bilinmiyor. Önerilen sahip: Planlama sahibi. Sonraki eylem: İlk rotanın sonucunu devralmak yerine bu ayrı rotayı ve iş olayını onaylayın.
- durum bildirimi: görünür Etki alanından status.civic.example ; DKIM d=provider.example.net; seçici demo3; DKIM geçişini yalnızca bu yazılı durum için varsayalım. SPF POSTADAN kimlik ve sonuç bilinmiyor; diğer imzalar bilinmiyor; gerçek politika keşfi ve teslimatı bilinmiyor. Önerilen sahip: Vaka yönetimi sahibi. Sonraki eylem: Doğrulanmış tedarikçiden bu kiracının desteklenen hizalanmış imzalama yolunu isteyin; Yetkilendirmeyi tüm ağı kapsayacak şekilde genişletmeyin.
Belirtilen ilk iki imza için d=, From alanına tam olarak eşittir, dolayısıyla tanımlayıcı hem katı hem de rahat hizalamayı karşılar. Öngörülen başarılı DKIM sonucu göz önüne alındığında, bu varsayımsal mesajlar için uyumlu bir kimlik doğrulama yolu mevcuttur. Üçüncü imzalayan, yazarın etki alanıyla kasıtlı olarak ilgisizdir ve bu hizalanmış yolu sağlayamaz. Üçüncü mesaja a deme DMARC başarısızlık: hizalanmış SPF veya başka bir hizalanmış geçiş DKIM imzası hala mekanizmayı tatmin edebilir ve bu girdiler bilinmemektedir. Herhangi bir satırdan gerçek dağıtım veya gelen kutusu yerleşimi sonucunu çıkarmayın.
Kriptografik imza, her talimatın doğruluğunu veya yetkisini değil, imzalayan alanın sorumluluğunu doğrular. Kapsanan kurallı baytlarda yapılan değişiklikler imzayı geçersiz kılabilir; her görünür düzenlemenin imzalı girişi değiştirmesi zorunlu değildir. Kimlik doğrulama ve uygulama düzeyinde kabul ayrı kalır.
Eski bir hatırlatma örneğini çözümleyin
Kurgusal vaka C-01 randevu sürüm 1'in 10:00 GST olduğunu ve sürüm 2'nin aynı gün 11:00 GST'ye aktardığını varsayalım. Zaten sıraya alınmış bir sürüm-1 hatırlatıcısının, hizalanmış DKIM iletmesi şart koşulmuştur. Kimlik sonucu 10:00'ı geçerli kılmaz. Planlama sahibi, onaylanmış iptal veya değiştirme kuralını uygulamalı, mevcut randevuyu resmi portalda doğrulamalı ve gerçekten bir düzeltme yapılıp yapılmadığını kontrol etmelidir. İleti sürüm 2'yi taşıyorsa ancak güvenilir kimlik doğrulama kanıtı yoksa, posta yolunu ayrı olarak araştırın. Burada gerçek bir vaka, mesaj, yeniden planlama işi veya düzeltme gönderimi kullanılmadı.
Uyumluluk talebinde bulunmadan standartları uygulayın
RFC 9989 Bölüm 4.4 ve 5.3.5 Hizalamayı ve mekanizma ayrımını destekler. Bölüm 7.4, dolaylı postaların birlikte çalışabilirliği konusunda uyarıyor: p=reject Yalnızca SPF değil, geçerli DKIM kullanılmalıdır ve genel amaçlı posta listesi kullanımı özel dikkat gerektirir. Rota envanterinin kendisi reddetmeyi zorunlu kılma iznine sahip değildir. RFC 6376 Bölüm 3.4–3.7 ve 6.1 İmzalı girişleri ve doğrulamayı açıklayın. RFC 9990 Bölüm 3.1 alıcı başına varış kanıtı değil, raporlama bağlamı sağlar. RFC 5321 Bölüm 4.2.5 Sunucu kabul sorumluluğunu daha sonraki teslimat sonuçlarından ayırır. Buradaki sektör iş akışı seçenekleri editoryal tavsiyelerdir; yasal kapsam, faktör uygunluğu ve yerel yetkilendirmenin kendi sorumlu incelemelerine ihtiyacı vardır.