[ Standartlar ve DMARCbis ]

Hala RFC 7489 alıntı yapan sağlayıcı kılavuzunun değerlendirilmesi

Hala geçerli olan ürün adımlarını, değişen standart dilini ve doğrulanmamış uygulama davranışını ayırarak RFC 7489 alıntı yapan sağlayıcı kılavuzunu inceleyin.

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

[ Anahtar noktalar ]

  • Eski bir alıntı her ürün talimatını geçersiz kılmaz.
  • Mevcut bir standart, bir sağlayıcının kullanıma sunma durumunu kanıtlamaz.
  • Kılavuzun tamamını kabul etmek veya reddetmek yerine her adıma açıklama ekleyin.
Bu sayfada

Ya hep ya hiç incelemesinden kaçının

Bir sağlayıcı yardım sayfası yine de alıntı yapabilir RFC 7489 cari hesap ekranını veya desteklenen gönderim yolunu doğru bir şekilde tanımlarken. Tersine, yeni tarihli bir sayfa geçmiş protokol tavsiyelerini tekrarlayabilir. Yararlı inceleme birimi, yalnızca alıntının yaşı değil, bireysel talimat veya iddiadır. Bir denetçi, neyin geçerli kaldığını, mevcut standartlarda nelerin değiştiğini ve neyin sağlayıcının fiili uygulamasına bağlı olduğunu belirlemelidir.

RFC 9989 mevcut çekirdeği sağlar DMARC spesifikasyonu ve RFC 7489 değişiklikleri açıklar. Toplama ve arıza raporlaması artık ayrı ayrı belirtiliyor RFC 9990 Ve RFC 9991. Protokol bildirimlerini değerlendirmek için bu kaynakları kullanın, ancak bunları bir sağlayıcının zaten her kullanıcı arayüzü alanını veya konuşlandırılan değerlendiriciyi değiştirdiğinin kanıtı olarak görmeyin. RFC 9989 , Ek C; RFC 9990 , bölüm 1; RFC 9991 , bölüm 1

Tam ürün bağlamını koruyun

Bir kılavuza açıklama eklemeden önce, URL'sini, saklanan tarihi, ürünü, planı veya belirtilen yerlerde hesap kapsamını, bölgeyi, rotayı ve ilgili ön koşulları kaydedin. Bir satıcı markası, farklı yapılandırma yollarına sahip birden fazla posta ürünü içerebilir. Özel bir SMTP yoluna yönelik kılavuz, varsayılan API yoluna uygulanmayabilir ve barındırılan bir posta ürününe ilişkin talimatlar, aynı şirkete ait başka bir ürünü kapsamayabilir.

Hesap tarafından oluşturulan değerleri açıklayıcı örneklerden farklı tutun. Bir rehber örneği seçici veya DNS hedefi evrensel bir üretim değeri olarak kopyalanmamalıdır. Benzer şekilde, bir kullanıcı arayüzü talimatı, çevresindeki standartların açıklamasının güncellenmesi gerektiğinde bile yararlı kalabilir. Bu ayrımı koruyun; böylece okuyucu, yalnızca girişte geçmiş bir RFC göründüğü için geçerli bir katılım önkoşulunu göz ardı etmez.

Bu yazı, adı geçen bir sağlayıcının cari hesabını denetlemez veya belirli bir hizmetin uyumsuz olduğunu iddia etmez. Gelecekte kaynak temelli bir inceleme için bir yöntem sağlar. Herhangi bir gerçek ürün talimatı, uygun şekilde sunulmadan önce okunabilir bir ana kılavuza ve yetkili hesap bağlamına göre kontrol edilmelidir.

Her talimatı otoriteye göre sınıflandırın

En az dört ek açıklama kategorisi kullanın: ürün iş akışı, protokol gereksinimi, sağlayıcıya özel uygunluk veya politika ve açıklayıcı öneri. Ürün iş akışları, mevcut sağlayıcı kanıtlarına ihtiyaç duyar. Protokol gereksinimleri uygun spesifikasyon bölümüne ihtiyaç duyar. Sağlayıcının uygunluğu, protokolün minimumundan daha katı veya farklı bir kapsamda olabilir ve her alıcıya genelleştirilmemelidir. Önerilerin gerekçeleri ve sınırları açıklanmalıdır.

Her satıra aktörü ve koşulu yazın. Alıcının politika keşfetme davranışı, alan sahibinin DNS yayınlama görevinden farklıdır. Standardın kayıt sözdizimini değiştirmeden, söz konusu hizmet için belirli bir hesap alanını yapılandırma gereksinimi gerekli olabilir. Bir rapor hedefinin alma izni, gönderenin oraya rapor gönderme talebinden farklıdır.

Bir cümle kategorileri birleştirdiğinde onu bölün. Örneğin, bir raporlama adresini girme talimatı geçerli bir kullanıcı arayüzü adımı olabilirken, herhangi bir harici adresin raporları otomatik olarak aldığına dair bir iddia eksik olabilir. İnceleme, kılavuzun tamamını genel tavsiyelerle değiştirmek yerine, yararlı adımı korumalı ve eksik yetkilendirme koşulunu eklemelidir.

Belirli değiştirilmiş kavramları karşılaştırın

Geçerli çekirdek DMARC sürüm değeri DMARC1 kalır. İnceleme, bir DMARC2 kaydı icat etmemeli veya bir RFC alıntısını güncellemenin DNS sürüm değişikliği gerektirdiğini ima etmemelidir. Mevcut spesifikasyon aynı zamanda pct'nin kaldırılmasını da belgeliyor; tutulan IANA kayıt defteri ise bu etiketi geçmiş olarak işaretliyor. Bu gerçekler, dağıtılan her sağlayıcının bunu nasıl ele aldığını kanıtlamadan, pct'nin güncel bir temel standart örnekleme kontrolü olduğu yönündeki iddianın düzeltilmesini desteklemektedir.

Politika keşfi ve organizasyonel alan belirlemenin aynı zamanda eski basitleştirilmiş bir algoritma yerine mevcut spesifikasyonla karşılaştırılmasına ihtiyacı vardır. Raporlama ifadeleri uygun şekilde RFC 9990 veya RFC 9991 göre kontrol edilmelidir. Tam farkı ve operasyonel önemini kaydedin; kullanmayın”DMARCbis bölüm düzeyinde değerlendirmenin yerine her şeyi değiştirdi”. RFC 9989 , bölüm 4.7, 4.10 ve Ek A.6; IANA DMARC Etiketler kaydı

Ek açıklama çalışma sayfası ve kabul kriterleri

Kılavuz alıntısını, kaynak anlık görüntüsünü, ürün kapsamını, talimat kategorisini, mevcut yetkiyi, önerilen ek açıklamayı ve hala gerekli olan uygulama kanıtlarını içeren bir çalışma sayfası oluşturun. Dört sonuçtan birini atayın: uygun olduğu şekilde tutulur, bir kapsam notu ile birlikte tutulur, standartların iddiası değiştiği için güncellenir veya çözümlenmemiş bekleyen sağlayıcı kanıtı. Bunlar editoryal sonuçlardır, herhangi bir üretim sisteminin testi geçtiği iddiası değildir.

Çalışma sayfası ayrıca hesaba özgü değerleri ve davranışı belirlemek için gereken ayrı olarak yetkilendirilmiş testleri doğrulayabilecek sahibi de tanımlamalıdır. Sağlayıcı kılavuzuna erişilemiyorsa, genel bir kurulum sırasını değiştirmek ve bunu doğrulanmış olarak adlandırmak yerine kaynak boşluğunu etiketleyin.

Kabul, her açıklamanın kendi deliline dayanmasını gerektirir. Gözden geçiren kişi, bir protokol açıklaması revize edilirken ekran gezinme adımının neden muhafaza edildiğini görebilmelidir. Değişikliğin yanlışlıkla yeni bir taahhüt, desteklenmeyen özellik veya evrensel teslim edilebilirlik vaadi getirmemesi için orijinal alıntıyı ve önerilen ifadeleri bir arada tutun.

Eskiden alıntı yapılan bir kurulum sayfasının kurgusal incelemesi

Üç talimat içeren kurgusal bir sağlayıcı sayfası hayal edin: hesap tarafından oluşturulan DKIM kayıtları yönetin, ayarlar ekranı aracılığıyla bir raporlama adresi ekleyin ve mevcut standardın kullanıma sunma kontrolü olarak pct'yi kullanın. Sayfa RFC 7489 alıntı yapıyor. Burada böyle adlandırılmış bir sayfa denetlenmedi; bu icat edilen talimatlar sınıflandırma yöntemini göstermektedir.

Geçerli ürün belgeleri ve hesap değerlerinin desteklemesi durumunda DKIM adımı geçerli kalabilir. Raporlama adresi adımı, ek bir dış yetkilendirme açıklaması gerektirmesine rağmen bir kullanıcı arayüzü eylemi olarak geçerli kalabilir. Pct beyanı güncel standartlar açıklamasına ihtiyaç duyarken, sağlayıcının bu alanı fiili olarak ele alması bir uygulama sorusu olarak kalacaktır. Bu nedenle bir alıntı üç farklı inceleme sonucuna yol açar.

Önerilen bir sonraki eylem, desteklenen ürün talimatlarını korumak, standart dilini düzeltmek ve çözülmemiş davranışlar için sağlayıcıya özel kanıtlar elde etmektir. Mevcut tüm kayıtları silmek, kurulum gereksinimlerini atlamak veya sağlayıcıyı güvensiz ilan etmek değildir. Kurgusal örnek, erişim veya test sonuçlarında aşırı talepte bulunmadan dikkatli bir incelemenin ne kadar yararlı olabileceğini göstermektedir.

Operasyonel ve editoryal yayınları ayrı tutun

Bir editoryal güncelleme, üretim doğrulaması tamamlanmadan önce, limitlerinin görünür olması koşuluyla, bir kılavuzu iyileştirebilir. Açıklamalı bir belgeyi, canlı bir hesabın doğru şekilde yapılandırıldığının kanıtı olarak tanımlamayın. Bunun tersine, başarılı bir hesap testi her müşteri planına, bölgeye veya alıcı uygulamasına genellenmemelidir.

Katalog, hangi adımların geçerli kaldığını, hangilerinin değiştiğini ve hangilerinin sağlayıcının uygulamasına bağlı olduğunu tanımlayan ek açıklamalar gerektirir. Bu taslak için gerçek bir kaynağa özel açıklamalı kılavuz açık kalmıştır. Mevcut adlandırılmış sağlayıcı sunumu, hesapta gezinme, DNS düzenlemesi veya mesaj testi talep edilmemektedir. Orijinal delil kapısı ve diğer beş tahliye kapısı açık kalır.

Operasyonel yayınlamadan önce, gerçek okunabilir sağlayıcı kaynağını edinin ve tam alıntıları, kaynak tarihlerini ve mevcut standart referanslarını saklayın. Nitelikli bir incelemeci, saklanan her talimatın ürün kapsamıyla eşleştiğini ve çözümlenmemiş uygulama davranışının çözümlenmemiş olarak kaldığını kontrol etmelidir. Bu yaklaşım, eski bir alıntının tek başına doğruluğunu ya da başarısızlığını kanıtladığını iddia etmeden kullanışlı bir rehber üretir.

[ Götürmek ]

Değiştirilen standart taleplerini ve çözülmemiş uygulama bağımlılıklarını işaretlerken ürüne özel geçerli adımları koruyun.

[ Role göre ]

Bu sizin için ne anlama geliyor?

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

Dokümantasyon editörü

Bireysel hak taleplerini inceleyin

Bir sayfada geçerli adımlar ve güncel olmayan açıklamalar bir arada bulunabilir.

Sonraki adımlar

  1. Kesin alıntıları koruyun.
  2. Ayrı ürün ve protokol yetkisi.

Sağlayıcı yöneticisi

Hesap kapsamını onaylayın

Oluşturulan değerler ve iş akışları ürüne göre değişiklik gösterebilir.

Sonraki adımlar

  1. Mevcut desteklenen talimatları kullanın.
  2. Evrenselleştirilmiş örnekleri kopyalamayın.

Standartları inceleyen kişi

Kullanıma sunma varsayımlarından kaçının

Bir spesifikasyonun yayınlanması dağıtımın kanıtı değildir.

Sonraki adımlar

  1. Değiştirilen kavramları bölümlere bağlayın.
  2. Uygulama sorularını açık tutun.

[ SSS ]

Sık sorulan sorular

RFC 7489 alıntı yapmak her talimatı yanlış yapar mı?

Hayır. Ürüne özel adımlar ve protokol açıklamaları ayrı değerlendirme gerektirir.

RFC 9989 DMARC2 gerektirir mi?

Hayır. Sürüm değeri DMARC1 olarak kalır.

RFC 9989: DMARC

PCT'nin tutulan kayıt durumu nedir?

IANA DMARC Etiketler kaydı, pct'nin tarihi olduğunu işaret ediyor.

IANA : DMARC Etiketleri kaydı

Kayıt defteri, bir sağlayıcının bir kullanıcı arayüzü alanını kaldırdığını kanıtlayabilir mi?

Hayır. Sağlayıcının uygulaması ve hesap davranışı ayrı kanıtlara ihtiyaç duyar.

İddiaların raporlanmasında yalnızca eski temel belge mi kullanılmalı?

Mevcut toplu ve arıza raporlama spesifikasyonları RFC 9990 ve RFC 9991 .

RFC 9989: DMARC

Genel bir kurulum, erişilemeyen bir ürün kılavuzunun yerini alabilir mi?

Hayır. Doğrulanmış bir sağlayıcı iş akışı talep etmek yerine kaynak açığını koruyun.

Adlandırılmış bir sağlayıcı denetlendi mi?

Hayır. Çalışılan sayfa kurgusaldır ve herhangi bir hesap veya mevcut kullanıma sunma test edilmemiştir.

Hala hangi kanıtlara ihtiyaç var?

Tutulan, değiştirilen ve uygulamaya bağlı adımları tanımlayan kaynağa özgü bir ek açıklama açık kalır.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989: DMARC

    Bölümler §2.4 Kapsam Dışı · §4.4 Tanımlayıcı Hizalamasının Açıklaması · §4.7 DMARC Politika Kayıt Formatı · §4.10 DNS Ağacı Yürüyüşü · §5 DMARC Katılımı · §6 DMARC Geri Bildirimi · Ek A.6 "pct" Etiketinin Kaldırılması · Ek C RFC 7489 Değişiklikler

  2. RFC 9990 : DMARC Toplu Raporlama

    Bölümler §3.1 Toplu Raporlar · §3.3 Raporlama Dönemi Sırasındaki Politika Değişiklikleri · §3.4 Rapor Talebi Keşfi · §3.5 Rapor Teslimatı · §4 Harici Hedefleri Doğrulama · §5 Genişletilebilir Raporlama · §8.1 İçeriği Saldırı Olarak Raporlama · §8.2 Yanlış Bilgi · §9 Operasyonel Hususlar · §9.3 Rapor Depolama · Ek A DMARC XML Şeması · §1 Giriş

  3. RFC 9991 : DMARC Arıza Raporlaması

    Bölümler §2 DMARC Arıza Raporları · §4 Raporlama Formatı Güncellemesi · §5 Harici Hedefleri Doğrulama · §7 Gizlilik Hususları · §1 Giriş

  4. IANA : DMARC Etiketleri kaydı

    Bölümler DMARC Etiketler

[ Sözlük ]

Sözlük

Talimat kategorisi
Bir ürün adımını veya protokol talebini değerlendirmek için gereken yetki türü.
Kapsam açıklaması
Saklanan talimatı desteklenen ürün ve koşullarla sınırlayan bir not.
Uygulamanın askıya alınması
Sağlayıcıya özgü davranış kanıtı gerektiren çözülmemiş bir soru.
Tarihsel etiket
Evrensel dağıtılmış işlemeyi ima etmeden, tutulan kayıt defterinde tarihi olarak işaretlenmiş bir etiket.

IANA : DMARC Etiketleri kaydı

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ı