[ Teslim edilebilirlik ve gönderen kuralları ]

Abonelikten çıkma işlemleri ve gerekli başlıkların DKIM kapsamı

Geçerli bir DKIM imzasının her iki abonelikten çıkma alanını da kapsadığından emin olun, ardından aşağı akış işleminin imzalı işlemi koruduğunu doğrulayın.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • Geçerli bir DKIM imzasının her iki abonelikten çıkma alanını da kapsadığından emin olun, ardından aşağı akış işleminin imzalı işlemi koruduğunu doğrulayın.
  • Aynı geçerli DKIM imzası her iki abonelikten çıkma alanını da kapsamalıdır; bir imzanın geçişini diğerinin kapsamıyla birleştirmeyin.
Bu sayfada

Bir mesajın geçerli bir değeri olabilir DKIM imzası abonelikten çıkma alanları imzasızken. Bu anlamlı bir boşluktur: Mesajı doğrulayan alıcının, reklamı yapılan devre dışı bırakma eylemini mutlaka doğrulamamış olması gerekir. İmzanın kapsamını inceleyin, yalnızca genel bir kapsamı değil DKIM geçiş etiketi.

İşlemi koruyan imzayı bulun

RFC 8058 en az bir geçerli DKIM imzası gerektirir List-Unsubscribe ve List-Unsubscribe-Post . Her iki alan da söz konusu geçerli imzanın h= etiketinde görünmelidir. Gerekli imzanın eksik olması, alıcının spesifikasyon kapsamında tek tıkla abonelikten çıkma teklifinde bulunmamasının bir nedenidir. RFC 8058 bölüm 4.

Bir mesaj birden fazla imza taşıyabilir. Birinin geçerliliğini diğerinin başlık kapsamıyla birleştirmeyin ve çifti yeterli olarak adlandırmayın. Gerekli alanları kapsayan tek bir geçerli imza belirleyin ve ardından imzalayanı koruyun, seçici ve doğrulama sonucu. Bu, hangi imzanın katkıda bulunduğunu kontrol etmekten farklıdır. DMARC hizalama.

Başlıkları ilgili imzalama adımından önce yerleştirin

Mesaj oluşturma hattını eşleyin: uygulama şablonu, liste işleme, ağ geçidi dönüşümleri, imzalayan ve son giden rota. Bir hizmet, imzalandıktan sonra abonelikten çıkma alanlarını eklerse, daha önceki bir imza, bunları kapsamadan geçerli kalabilir. Düzeltme, alanları uygun imzanın önüne yerleştirmek veya daha sonra geçerli bir imzanın bunları kapsamasını sağlamaktır.

Gönderilen son mesajı okuyun. RFC 6376 tekrarlanan alan adlarının nasıl işleneceği de dahil olmak üzere h= listesi ve başlık seçim kurallarını tanımlar. Mesajın herhangi bir yerinde "liste-abonelikten çık" şeklinde yapılan dize araması bir kapsam testi değildir. Yinelenen alanlar ve dönüşümler, gerçek imza girişinin dikkatli bir şekilde incelenmesini gerektirir. RFC 6376 bölüm 3.5 ve 5.4.

İmzalı ve imzasız değişiklikleri ayırt etme

Aksi takdirde geçerli imzası her iki abonelikten çıkma alanını da kapsayan kontrollü bir test mesajı düşünün. İmzalı URI'yi farklı bir değere değiştirmek imzalı girişi değiştirir; normal DKIM doğrulaması altında, orijinal imza artık değiştirilen girişi doğrulamaz. Buna karşılık, her iki alanı da içermeyen bir imza, imzasız değerler değiştikten sonra da geçerli kalabilir. Bu, genel bir geçişin neden her alanda kimlik doğrulaması yapamadığını açıklar.

Bunlar, yürütülen bir şifreleme donanımı değil, protokole dayalı beklentilerdir. Gerçek bir yetkili mutasyon testinin tam orijinal baytlara, seçilen imzaya ve doğru doğrulama anahtarına ihtiyacı vardır. Enjekte edilen bir test anahtarı, genel DNS kaynağını veya geçmiş alma sonucunu değil, yalnızca o testin kriptografik ilişkisini gösterir. Orijinali koruyun ve ayrı bir kopyayı değiştirin.

İmzalı yolun tamamını kontrol edin

Kapsamı düzelttikten sonra, yetkili bir test mesajını amaçlanan rota üzerinden yeniden gönderin ve alıcı tarafta doğrulayın. Bağlantının yeniden yazılması, ağ geçidi düzenlemeleri veya daha sonraki bir liste işlemcisi kapsanan alanı değiştirebilir. Sahibinin doğrulamanın farklılaştığı ilk aşamayı bulabilmesi için mümkün olduğunda ön dönüşüm ve son numuneleri saklayın.

Alanları h=. Bu, RFC 8058 gereksinimi karşılanmadan kalırken imzanın korunmasını kolaylaştırabilir. Bir ağ geçidinin eylemi dönüştürmesi gerekiyorsa, son imzalama sınırını koordine edin ve dönüştürülen URI'nin hâlâ doğru alıcıya ve listeye eşleştiğinden emin olun.

Operasyonel kontrolü tamamlayın

İmza kapsamı, reklamı yapılan alanların kimliğini doğrular; uç noktanın istenen engellemeyi gerçekleştirdiğini kanıtlamaz. POST'u ve aşağı akış sonraki gönderim hariç tutmasını ayrı ayrı test etmek için kontrollü bir abonelik kullanın. Tersine, çalışan bir uç nokta eksik imza kapsamını onarmaz.

Kapanış kaydı, geçerli kapsayan imzayı, kesin nihai mesajı, uç nokta kapsamını ve gözlemlenen gizleme sonucunu tanımlamalıdır. Sağlayıcı kullanıcı arayüzü ekranını, doğru imzalamanın vaat edilen bir sonucu yerine ayrı bir gözlem olarak tutun.

İmzaya özgü bir kapanış kaydını tutun

Söz konusu imzaya ilişkin son mesajı, imzalayanı, seçiciyi, kapsanan iki alanı ve doğrulama sonucunu kaydedin. Uç nokta ve bastırma sonuçlarını ayrı ayrı kaydedin. Daha sonraki bir ağ geçidi alanları değiştirirse, gerekli kapsamı düşürmek yerine imzalama sınırını onarın.

[ Götürmek ]

Geçerli bir DKIM imzasının her iki abonelikten çıkma alanını da kapsadığından emin olun, ardından aşağı akış işleminin imzalı işlemi koruduğunu doğrulayın.

[ 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

Nihai kaplama imzasını doğrulayın

İşlem hattı sırası neyin korunacağını belirler.

Sonraki adımlar

  1. h= ve geçerliliği birlikte inceleyin.
  2. Aşağı yöndeki mutasyonların izini sürün.
  3. Amaçlanan rotayı tekrar test edin.

CISO / SecOps

Eylem bütünlüğünü koru

İmzasız bir kapsam dışında kalma hedefi, ilgisiz kapsamı geçersiz kılmadan değişebilir.

Sonraki adımlar

  1. Yinelenen başlıkları inceleyin.
  2. Üretim anahtarlarını koruyun.
  3. Yalıtılmış mutasyon fikstürleri kullanın.

Kurucu / Teknik Olmayan

Geçiş rozetinin ötesinde kanıt iste

Geçerli bir imza, önemli alanları atlayabilir.

Sonraki adımlar

  1. Kapsam kanıtlarını isteyin.
  2. Ağ geçidi sahipliğini atayın.
  3. Ayrı imzalama ve bastırma kabulü.

[ SSS ]

Sık sorulan sorular

DKIM geçişi abonelikten çıkma başlıklarının kapsandığını kanıtlıyor mu?

Hayır. Geçerli imzanın h= listesini inceleyin.

Bir imzanın kapsamı diğerinin geçerliliğiyle birleştirilebilir mi?

Hayır. Geçerli bir imzanın kendisi gerekli her iki alanı da kapsamalıdır.

Başlıklar imzalandıktan sonra eklenmeli mi?

Daha sonra geçerli bir imza bunları kapsamadığı sürece hayır.

Neden bir URL mutasyonunu test etmelisiniz?

İmzanın reklamı yapılan abonelikten çıkma hedefini gerçekten koruyup korumadığını gösterir.

Mutasyon örneği neyi öngörüyor?

Kapsanan URI'nin değiştirilmesi imzalı girişi değiştirir; atlanmış bir alanı değiştirmek, aksi takdirde geçerli olan bir imzayı olduğu gibi bırakabilir. Bunlar beklentilerdir, kayıtlı doğrulama sonuçları değil.

Enjekte edilen bir test anahtarı genel DNS yetkilendirmesini kanıtlar mı?

Hayır. Test anahtarı doğrulaması, DNS kaynağını veya geçmiş alıcı sonucunu değil, yalnızca test edilen şifreleme ilişkisini kurar.

Alanları h= öğesinden kaldırmak RFC 8058 uyumluluğunu çözebilir mi?

Hayır. İmza geçerli kalsa bile gerekli teminatı kaldırır.

İmza kapsamı bastırmanın işe yaradığını kanıtlar mı?

Hayır. Uç nokta davranışını ve aşağı yöndeki dışlamayı ayrı ayrı test edin.

[ Kaynaklar ]

Kaynaklar

  1. RFC 8058 Tek Tıklamayla Abonelikten Çıkma

    Bölümler §3.1 · §3.2 · §4 · §5 · §6

  2. RFC 6376 DKIM

    Bölümler §3.5 · §5.4 · §6.1

  3. RFC 9989 DMARC

    Bölümler §4.4 · §5.3.5

[ Sözlük ]

Sözlük

Başlık kapsamı
DKIM imzasının imzalı girişinde yer alan belirli mesaj alanları.
h= tag
İmzalı başlık alanı adlarını listeleyen DKIM imza etiketi.
İmza sınırı
Korunan mesaj içeriğinin doğrulanabilir kalması gereken ardışık düzen noktası.

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ı