[ DKIM ]

DKIM zaman damgalarını ve son kullanma tarihini yorumlama

Gecikmiş mesajların doğrulamada başarısız olması durumunda imzalayanın süresini, alınma süresini ve son kullanma tarihini ayırın.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • t ve x mutlak Unix dönemi zaman damgalarıdır; Her ikisi de göründüğünde x, t'yi geçmelidir.
  • Son kullanma tarihi tanılamadan önce güvenilir ilk giriş ve daha sonra yeniden kontrol sürelerini karşılaştırın.
  • DNS TTL, anahtar saklama ve imza süresinin dolması ayrı operasyonel kontrollerdir.
Bu sayfada

Gecikmiş bir mesaj zamanla ilgili bir arızaya neden olabilir DKIM kimse içeriğini değiştirmediğinde bile kontrol edin. Anahtarları döndürmeden veya ağ geçidini suçlamadan önce imzanın zaman alanlarını ve doğrulayıcının kararını teşhis edin. Mesajın Tarih başlığı, imza oluşturma zamanı ve alıcının varış zamanı farklı olayları açıklar.

T ve x'i doğru okuyun

bir DKIM-Signature başlık, t imza oluşturma zaman damgasıdır ve x mutlak süre sonu zaman damgasıdır; her ikisi de UTC'deki Unix döneminden bu yana saniye olarak ifade edilir. RFC 6376 bölüm 3.5, her iki etiketi de resmi olarak ÖNERİLEN olarak işaretler. Bunlar mevcut olmayabilir ancak bu ödenek, İSTEĞE BAĞLI gereklilik düzeyiyle karıştırılmamalıdır. X değeri geçerli zamana eklenecek bir süre değildir. Her ikisi de mevcut olduğunda x, t'den büyük olmalıdır. Eksik t, bilinmeyen bir yaratım zamanı anlamına gelir; eksik x, bu etiket tarafından imza süresinin sona erme tarihinin belirtilmediği anlamına gelir. DNS TTL farklı bir kavramdır ve x'i ayarlamaz. DNS DKIM anahtar kaydındaki t etiketi, bu imza zaman damgası değil, bir dizi bayraktır.

RFC 6376 bölüm 3.5 uygulamaların gelecekteki zaman damgasına sahip bir imzayı yok saymasına izin verir. Ayrıca, doğrulamanın süresi dolduğunda bir imzanın geçersiz sayılmasına da izin verir. Karşılaştırma için, doğrulama zamanı, eğer güvenilir bir şekilde mevcutsa, doğrulayıcının idari alanının mesajı ilk aldığı zaman olmalıdır, aksi takdirde geçerli zaman olmalıdır. Bu, bir olay kaydının evrensel bir ret kuralından ayırt etmesi gereken uygulama seçeneklerini bırakır.

Üç saatlik bir zaman çizelgesi oluşturun

Tam imzayı ve ham alıcı kanıtını yakalayın. Orijinal tam sayıları korurken t ve x'i okunabilir UTC'ye dönüştürün. İmzalayanın saatini, doğrulayan idari alanda ilk güvenilir alım zamanını ve teşhis yeniden kontrolünün zamanını kaydedin. İlgili kuyruk gecikmelerini ekleyin. Sistemin ne zaman mesaj aldığını kanıtlamak için güvenilmeyen bir Tarih başlığı kullanmayın.

Açıklayıcı senaryo: 10:00 UTC'de bir imza oluşturulur ve süresi 12:00 UTC'de sona erer. Mesaj alıcıya 11:50'de ulaşır ancak 12:15'te tekrar incelenir. Güvenilir ilk alındı ​​bilgilerine sahip bir doğrulayıcı 11:50'yi kullanabilir; daha sonraki bağımsız bir aracın yalnızca geçerli saati olabilir. Farklı sonuçlar tek başına bozuk içerik göstermez. Örnek, belirli bir sağlayıcıya ilişkin bir vaadi değil, protokolün zamanlama ayrımını açıklamaktadır.

Saat çarpıklığını dar bir pencereden ayırt edin

Yeni gönderilen imzalar gelecekten geliyor gibi görünüyorsa imzalayanın saat senkronizasyonunu ve zaman damgası oluşumunu inceleyin. Değerler makulse ancak posta düzenli olarak x'ten sonra geliyorsa, kuyruğu inceleyin, rotaları yeniden deneyin ve seçilen geçerlilik aralığını inceleyin. RFC 6376 evrensel bir ideal yaşam süresi önermez. Gerçek teslimat gereksinimlerinizi ve desteklenen imzalayan ayarlarınızı kullanarak bir tane belirleyin.

Kısa bir süre sonu, tam bir tekrar savunması değildir. RFC 6376 bölüm 3.5 açıkça x'in bu amaç için tasarlanmadığını söylüyor. Ayrıca anahtar korumasının veya kötüye kullanım izlemenin yerini almaz. Eski bir genel anahtarın kaldırılması, x'ten bağımsız olarak gecikmiş doğrulamayı imkansız hale getirebilir, bu nedenle sona erme politikasını anahtarın saklanması ile koordine edin.

Onarımı test edin ve farkı koruyun

Saat veya politika yapılandırmasını düzelttikten sonra, yavaş ve normal yollardan yeni kontrollü mesajlar gönderin. Zaman damgalarını ve alıcı sonuçlarını doğrulayın. Önceki arızanın zamanla, anahtar kullanılabilirliğiyle ilgili olup olmadığını gösteren kanıtları koruyun. vücut karması veya imza doğrulaması. Mevcut imzalı bir mesajda t veya x'i düzenlemeyin: bu değerler imzanın kapsamındadır ve bunların değiştirilmesi onarım değildir.

Bir dönem örneği üzerinde çalışın

Sentetik değerler t=1794132000 ve x=1794139200 8 Kasım 2026 10:00 UTC ve 12:00 UTC'ye karşılık gelir. Aralarındaki fark 7.200 saniye veya iki saattir, ancak x'in kendisi mutlak bir zaman damgası olarak kalır. Saat 11:50'de güvenilir bir ilk makbuz, son kullanma tarihinden öncedir; 12:15'te bağımsız bir yeniden kontrol onun peşinde. Doğrulayıcının seçtiği referans süresi ve izin verilen son kullanma tarihi olası farkı açıklar. Buna karşılık, x=t her iki etiket de mevcut olduğunda gerekli sıralamayı ihlal eder. Bu değerler yürütülen bir posta testini değil, aritmetik ve protokol kurallarını gösterir.

Kompakt bir araştırma kaydı tutun

İncelenmekte olan rota için önerilen bu çalışma sayfasını kullanın. Bu bir planlama yardımcısıdır, yürütülen bir testin kanıtı değildir.

  • İmza: orijinal t ve x değerleri, bunların UTC dönüşümleri, d ve seçici.
  • Zaman çizelgesi: imzalayanın saati, ilk güvenilir alındı ​​ve daha sonra yeniden kontrol, zaman dilimleriyle birlikte.
  • Bulgu: gelecekteki zaman damgası, süresi dolmuş imza, kullanılamayan anahtar veya başka bir doğrulama hatası.
  • Onarım: desteklenen saat veya ömür değişimi ve yeni gönderilen normal ve gecikmeli yol testlerinin sonuçları.

[ Götürmek ]

t ve x mutlak Unix dönemi zaman damgalarıdır; Her ikisi de göründüğünde x, t'yi geçmelidir. Son kullanma tarihi tanılamadan önce güvenilir ilk giriş ve daha sonra yeniden kontrol sürelerini karşılaştırın. DNS TTL, anahtar saklama ve imza süresinin dolması ayrı operasyonel kontrollerdir.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

UTC zaman çizelgesini koruyun

Ayrı imzalayan oluşturma, ilk alındı ​​ve daha sonra yeniden kontrol.

Sonraki adımlar

  1. Orijinal dönem değerlerini koruyun.
  2. Saat senkronizasyonunu kontrol edin.

CISO / SecOps

Tazeliği kötüye kullanım kontrolünden ayırın

Sona erme, alıcının amacını belirlemez veya tüm tekrarları engellemez.

Sonraki adımlar

  1. Kötüye kullanımı izlemeyi sürdürün.
  2. Anahtar saklamayı koordine edin.

Kurucu / Teknik Olmayan

Geciken iş postası hesabı

Meşru sıraya girmeyi kabul eden zamanlama politikalarını seçin.

Sonraki adımlar

  1. Geciken faturaları testlere dahil edin.
  2. Bir saat hizmeti sahibi atayın.

[ SSS ]

Sık sorulan sorular

xa t'den sonraki saniye sayısı mı?

Hayır. Bu mutlak bir Unix dönemi zaman damgasıdır. Her iki etiket de mevcutsa x, t'yi geçmelidir.

RFC 6376 §3.5

Eksik x ne anlama geliyor?

Bu imza etiketi tarafından herhangi bir son kullanma tarihi belirtilmez. Diğer doğrulama ve alıcı politikası kontrolleri hâlâ geçerlidir.

RFC 6376 §3.5

Gelecek başarısızlığa neden olabilir mi?

Uygulamalar, zaman damgaları gelecekte olan imzaları göz ardı edebilir. İmzalayanın saatini ve alıcı davranışını kontrol edin.

RFC 6376 §3.5

Hangi teslim alma süresi önemlidir?

RFC 6376 doğrulayıcının idari etki alanında güvenilir ilk alımı, aksi halde geçerli saati önerir.

RFC 6376 §3.5

DNS TTL imza ömrünü belirler mi?

Hayır. TTL, DNS önbelleğe almayla ilgilidir; x imzanın isteğe bağlı sona ermesiyle ilgilidir.

RFC 6376 §3.5

Geciken bir mesajda x'i değiştirebilir miyiz?

İmzalı başlığın değiştirilmesi orijinal imzayı geçersiz kılar. Yapılandırmayı düzeltin ve yeni mesajları test edin.

RFC 6376 §3.7

Kısa bir x tekrar oynatmayı durdurur mu?

Bu, tam bir tekrar savunması değildir ve açıkça RFC 6376 böyle bir savunma olarak tasarlanmamıştır.

RFC 6376 §3.5

Geçerlilik süresi ne kadar olmalıdır?

Desteklenen imzalayan davranışı kapsamında gözlemlenen sıraya alma ve teslimat gereksinimlerini kullanın; burada evrensel bir yaşam süresi öngörülmemiştir.

RFC 6376 §3.5

[ Kaynaklar ]

Kaynaklar

  1. RFC 6376 Etki Alanı Anahtarlarıyla Tanımlanan Posta İmzaları

    Bölümler §3.5 · §3.6.1 · §3.7 · §5.2 · §6.1.1 · §8.6

  2. RFC 9989 Etki Alanı Tabanlı Mesaj Kimlik Doğrulaması Raporlaması ve Uyumluluğu

    Bölümler Giriş · §4.4 · §5.3.5

  3. RFC 8601 Kimlik Doğrulama Sonuçları

    Bölümler §1.2 · §7.1

[ Sözlük ]

Sözlük

İmza zaman damgası (t)
Unix çağından bu yana saniye cinsinden ifade edilen, isteğe bağlı DKIM-Signature oluşturma süresi.

RFC 6376 §3.5

İmzanın geçerlilik süresi (x)
Doğrulayıcının imzayı geçersiz sayabileceği isteğe bağlı mutlak süre.

RFC 6376 §3.5

İlk makbuz
İleti doğrulayıcının yönetim alanına ilk girdiğinde, güvenilir bir şekilde mevcut olduğunda süre sonu karşılaştırması için kullanılır.

RFC 6376 §3.5

Saat çarpıklığı
Zamana dayalı imza kontrollerini etkileyebilecek sistem saatleri arasındaki fark.

RFC 6376 §3.5

DKIM seçici
Genel doğrulama anahtarını bulmak için imzalama alanıyla birlikte kullanılan s değeri.

RFC 6376 §3.5

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası