Önce soruyu ve alıcıyı tanımlayın
Satıcının imzalama sorununu teşhis etmek için kanıta ihtiyacı olabilir. hizalama uyumsuzluk veya raporlama tutarsızlığı. Organizasyondaki her alan için nadiren her rapora ihtiyaç duyar. Tam soruyu, ilgili ürünü ve hesabı, hedeflenen alıcıyı ve kanıtların hangi kararı vermesi gerektiğini belirterek başlayın. Bu, “ DMARC Verilerin gereksiz derecede geniş bir açıklama haline gelmesini önleyin.
Alıcının ilgili hizmetin yetkili destek veya mühendislik iletişim sorumlusu olduğunu doğrulayın. Tanıdık bir görünen ad veya iletilen istek, her ekin oraya gönderilmesi gerektiğini belirlemek için yeterli değildir. Bir paketin hazırlanması, onu iletme izninden ayrıdır. Bu makalede yalnızca hazırlık anlatılmaktadır ve e-posta, yükleme veya harici paylaşıma izin verilmemektedir.
Kapsamı etkilenen rotaya ve aralığa bağlı tutun. Kendi alındı iş akışını araştıran bir tedarikçi, sırf bu gözlemler aynı toplu dosyayı kapsıyor diye ilgisiz çalışan postası, pazarlama veya diğer tedarikçi trafiğini almamalıdır.
Raporun neler ortaya çıkarabileceğini anlayın
Raporları birleştir gönderenin altyapısının ve trafiğinin özelliklerini ortaya çıkarabilecek teknik gözlemler ve politika bilgileri içerir. RFC 9990 alıcılar ve rapor verileri için gizlilik hususlarını tartışır. Bir alan bir mesaj gövdesi olmasa bile satıcının görevi için gereksiz olabilir. Tüm toplu bilgilerin zararsız olduğunu varsaymak yerine, minimizasyona alan bazında bir karar olarak yaklaşın.
Arıza raporları altında ayrı ve potansiyel olarak daha ayrıntılı bir maruz kalma yüzeyine sahip olun RFC 9991. Bunları, "raporlar" için genel bir onay kapsamında toplu özetlerle bir araya getirmeyin. Raporun türünü, içeriğini ve alıcının amacını açıkça tanımlayın. Bir teşhis sorusu daha küçük bir özet veya düzeltilmiş alıntıyla yanıtlanabiliyorsa, bunu tam bir ham eser yerine tercih edin. RFC 9990 , bölüm 7.1 ve 7.2; RFC 9991 , bölüm 7.1 ve 7.2
Redaksiyondan önce bir veri alanı haritası oluşturun
Alan haritası her aday öğeyi, neden gerekli olduğunu, kesin bir değerin gerekli olup olmadığını, önerilen tedaviyi ve bunun kaldırılmasının sonuçlarını listelemelidir. Potansiyel öğeler arasında ilgili Gönderen alanı, imzalama alanı, seçici, zarf alanı, kaynak adresi, rapor aralığı, sayım ve değerlendirme sonucu. Bunların gerekliliği şu soruya bağlıdır; Her zaman gönderilmesi gereken evrensel bir paket yoktur.
Hizalamayı teşhis etmek veya hesaba özel bir yapılandırmayı bulmak için bazı kesin teknik kimliklere ihtiyaç duyulabilir. Bu değerler onaylanan kapsam kapsamında paylaşılamıyorsa yanıltıcı değerlerle değiştirmek yerine tanı sınırlamasını açıklayın. Diğer tanımlayıcılar kaldırılabilir veya ilişkiler korunurken tutarlı bir şekilde takma ad verilebilir. Özel eşlemeyi yalnızca gerektiğinde ve yetki verildiğinde saklayın ve bunu varsayılan olarak satıcı paketine dahil etmeyin.
İlgisiz satırları ve alanları, gereksiz alıcı adreslerini, mesaj içeriğini, dahili notları ve sırları kaldırın. Bir destek yapıtına asla parolaları, API anahtarlarını, oturum belirteçlerini veya kimlik bilgilerini dahil etmeyin. Görünür metinlerin yanı sıra dosya adlarını, meta verileri, ekran görüntülerini ve gizli e-tablo içeriğini inceleyin; Düzenlenmiş bir paragraf, ekin en aza indirileceğini garanti etmez.
Teşhis ilişkilerini koruyun
Yararlı bir kanıt örneği, ham kimlik doğrulama sonuçları ile hizalama arasındaki ayrımı korumalıdır. Soru DMARC neden başarısız olduğuyla ilgiliyse, her alan adını aynı yer tutucuyla değiştirmek satıcının anlaması gereken ilişkiyi silebilir. Kimliklerin eşit, ilişkili veya farklı olup olmadığını koruyun ve sorgulanacak gerçek DNS adlarıyla karıştırılmamaları için sentetik değiştirmeleri açıkça etiketleyin.
Raporlama aralığını, ilgili sonuç alanlarını ve kapsam notlarını bir arada tutun. Yalnızca seçilen satırlar paylaşılıyorsa örneğin filtrelendiğini belirtin ve seçim kuralını tanımlayın. Örneğin daha basit görünmesi için sonucu değiştirmeyin ve filtrelenmiş bir sayının kuruluşun toplam trafiğini temsil ettiğini ima etmeyin. Gerektiğinde, tutulan alanlarla birlikte kısa bir analist açıklaması sağlayın. RFC 9989 , bölüm 4.4; RFC 9990 , bölüm 3.1
Onay ve saklama çalışma sayfası
Alıcı, kuruluş, ürün, amaç, kesin dosya veya alanlar, etkilenen alan adı veya rota, zaman aralığı, hassasiyet, aktarım yöntemi ve saklama kararının yer aldığı bir onay kaydı hazırlayın. Satıcının materyali yalnızca vaka için tutabileceğini, başka bir amaç için kullanıp kullanamayacağını veya ileride paylaşıp paylaşamayacağını belirleyin. Genel bir destek ilişkisinin ilgisiz yeniden kullanıma veya geniş erişime izin verdiğini varsaymayın.
Saklama kararı hem satıcının kopyasını hem de kuruluşun çalışma kopyasını ele almalıdır. Amaçlanan süreyi veya silme tetikleyicisini ve önemli olduğu yerde tamamlanmayı kimin doğrulayabileceğini kaydedin. Bu, önerilen bir yönetim sürecidir; bir satıcı sözleşmesinin halihazırda belirli koşullar sağladığına dair bir iddia değildir. Mevcut koşullar veya alıcı erişimi net değilse, iletimden önce sorunu çözün.
Kabul, gözden geçirenin nihai paketi onaylanmış alan haritasıyla karşılaştırmasını gerektirir. Yalnızca bir açıklama değil, asıl ek de ilgisiz satırlar, gizli veriler ve tesadüfi sırlar açısından kontrol edilmelidir. Değişen bir alıcı, genişletilmiş bir veri kümesi veya yeni bir amaç, aynı paylaşımın zararsız bir devamı olarak değerlendirilmek yerine, yenilenen incelemeyi tetiklemelidir.
Tek imza rotası için kurgusal destek paketi
Uyumlu bir durumu araştıran kurgusal bir makbuz tedarikçisi hayal edin DKIM arıza. Kuruluşun ham toplu raporu aynı zamanda çalışanların postalarını ve kampanya gözlemlerini de içerir. Bu örnek için gerçek bir rapora veya satıcı isteğine erişilmedi. Önerilen paket yalnızca ilgili giriş yolu satırlarını, sınırlı raporlama aralığını, ilgili kimlik ilişkilerini ve belirsiz olanın kısa bir açıklamasını içerir.
Tedarikçinin sorusuna yanıt vermediği için çalışan ve kampanya satırları hariç tutuldu. Tedarikçinin tam bir imzalama alanına veya seçiciye ihtiyacı varsa kuruluşun bu değerleri söz konusu alıcı ve amaç için onaylaması gerekir. Bunları gizleyen, düzeltilmiş bir örnek, kavramsal bir tartışma için hâlâ faydalı olabilir ancak canlı bir DNS teşhisi için yeterli olarak sunulamaz.
Nihai onay aynı zamanda vakaya özel bir saklama kararını da kaydeder. Hiçbir paket yalnızca taslak tamamlandı diye gönderilmez. Tedarikçi daha sonra tam mesaj örnekleri isterse, bu, özellikle alıcıları veya mesaj gövdelerini tanıtıyorsa, farklı bir gizlilik profiline sahip yeni bir içerik talebidir. Bir sonraki adım, otomatik genişletme değil, kapsamlı bir incelemedir.
Kanıt ve yayın durumu
Katalog, bir veri alanı haritası ve açık bir saklama kararıyla birlikte onaylanmış minimum kanıt örneğini gerektirir. Bu makalede yalnızca bir hazırlama yöntemi ve kurgusal ambalaj tasarımı sunulmaktadır. Hiçbir gerçek numune onaylanmadı, hiçbir alıcı çözümlenmedi ve hiçbir iletim veya satıcının silinmesi doğrulanmadı.
Altı serbest bırakma kapısının tümü açık kalır. Nitelikli bir incelemeci, önerilen minimizasyonun alıcı ve amaç sınırlarına saygı göstererek tanı sorusunu koruduğunu kontrol etmelidir. Herhangi bir gerçek paylaşımdan önce, gerçek veriler ve hedef için gerekli yetkiyi alın. Güvenli bir şekilde hazırlanmış bir taslak değerli bir ilerlemedir ancak satıcının herhangi bir şeyi aldığına veya ele aldığına dair bir kanıt değildir.