SMTP YETKİSİ ve SPF, DKIM Ve DMARC oturum açmanın birbirinin yerine geçebilen yolları değildir. SMTP AUTH, bir istemcinin kimliğini bir SMTP sunucusuna doğrular. SPF gönderen ana bilgisayarı bir alanın zarf politikasına göre değerlendirir, DKIM bir mesaj imzasını doğrular ve DMARC görünür Kimden'e göre hizalanmış alan kimlik doğrulamasını değerlendirir. Başarılı bir hesap girişi, aşağı akışlı bir DMARC hatasıyla bir arada bulunabilir ve gelen İnternet postasının, gönderim hesabınızda kimlik doğrulaması yapmasına gerek yoktur.
İstemci-sunucu ilişkisini bulun
RFC 4954 AUTH uzantısını ve SASL mekanizmalarının kullanımını tanımlar. Sunucunun yetkilendirme politikası, kimliği doğrulanmış istemcinin ne yapabileceğini belirler. Kimliği doğrulanmış bir hesap adını bilmek, olası her zarfı veya görünür Gönderen adresini otomatik olarak yetkilendirmez. Gönderim hizmetleri genellikle ek gönderen, geçiş ve organizasyonel kısıtlamalar uygular.
RFC 6409 Mesaj gönderimini aktarmadan ayırır. Kimlik bilgilerini veya DNS değiştirmeden önce uygulamanın hangi hizmeti kullandığını belirleyin. Sağlayıcının kimlik doğrulamalı gönderim hizmetine bağlanan bir cihazın, İnternet postasını alan adınızın MX dağıtan uzak posta sunucusundan farklı bir ilişkisi vardır. Sıradan gelen kimlik doğrulama hatalarını, harici gönderenlere bir posta kutusu parolası vererek düzeltmeye çalışmayın.
Aşağı yöndeki etki alanı kanıtlarını takip edin
SPF RFC 7208 uyarınca bağlanan ana bilgisayarı ve ilgili zarf kimliğini kontrol eder. DKIM doğrulaması şunları kullanır: seçici ve ortak anahtar materyalini bulmak ve RFC 6376 kapsamında kapsanan içeriği doğrulamak için bir imzada alan adını imzalamak. DMARC geçen bir alan adı ile görünen Kimden alanı arasında uygun bir ilişki olmasını gerektirir. RFC 9989.
Bir uygulama, bir satıcı hesabında başarılı bir şekilde kimlik doğrulaması yapabilir, ardından hizalanmamış bir geri dönen etki alanı ve hizalanmamış bir DKIM imzalama etki alanıyla gönderebilir. DMARC başarısız olurken aşağı akış SPF ve DKIM her ikisi de geçebilir. Bunun tersine, uygun şekilde yapılandırılmış bir alan adı, alıcıya bakan atlama noktasında SMTP AUTH olmadan sunucular arasında teslim edilen postalarda DMARC iletebilir. Hesap kimlik bilgileri ve alan adı yetkilendirmesi kendi sınırlarında araştırılmalıdır.
Kanıtları sırları ifşa etmeden kullanın
Oturum açma hatası durumunda, kimlik bilgileri ve belirteçler hariç hizmet uç noktasını, güvenli aktarım durumunu, bildirilen yöntemleri ve tam hatayı kaydedin. Oturum açma sonrası gönderen reddi için, izin verilen gönderen politikasını ve reddedilen komutu yakalayın. Aşağı akış hatası için güvenilir alıcı sonuçlarını, zarf bilgilerini, DKIM d ve s değerlerini ve görünür From alanını elde edin. Kimlik doğrulama verilerini destek taleplerine veya makale örneklerine kopyalamaktan kaçının.
İki varsayımsal sonucu karşılaştırın
Durum A: Bir istemci bir gönderim hizmetinde kimlik doğrulaması yapar ve gönderim yapmasına izin verilir, ancak son alıcı vendor.example için SPF geçişini ve d=vendor.example ile DKIM geçişini bildirirken From brand.example öğesini kullanır. Geçerli bir DMARC politikası olduğu ve çözülmemiş bir değerlendirme hatası olmadığı varsayıldığında, her iki alan da hizalanmaz ve mesaj DMARC başarısız olur. Başka bir şifre bu etki alanı ilişkilerini değiştiremez.
Durum B: Bir sunucu, bu atlama noktasında SMTP AUTH olmadan sıradan gelen postayı alıcı MX teslim eder. Güvenilir bir alıcı geçerli bir DKIM imzası d=brand.example ile eşleşen From= brand.example ile. Geçerli bir politika olması ve çözülmemiş değerlendirme hatasının olmaması durumunda, bu hizalanmış imza bir DMARC geçişi sağlayabilir. Bu, güvenli içerik, gelen kutusu yerleşimi veya talep edilen bir iş eylemini gerçekleştirme izni sağlamaz. Her iki durum da icat edilmiş karşılaştırmalardır; hiçbir kimlik bilgisi, sağlayıcı girişi veya şifreleme testi kullanılmadı.
Sorumlu yapılandırmayı onarın
AUTH başarısız olursa sağlayıcının mevcut desteklenen kimlik doğrulama yöntemini ve aktarım gereksinimlerini izleyin. Eski bir makalede bahsedildiği için eski bir mekanizmayı etkinleştirmeyin. Kimliği doğrulanmış hesabın bir adresi kullanma izni yoksa, yetkili gönderen yapılandırmasını normal yönetim süreci yoluyla onarın. Aşağı akış ise hizalama başarısız olursa, başka bir parolanın yardımcı olacağını varsaymak yerine meşru gönderenin desteklenen zarfını veya DKIM etki alanını yapılandırın.
Onarımdan sonra, zararsız mesajları kullanarak hem gönderimi hem de nihai alıcı değerlendirmesini test edin. Farklı sonuçları koruyun: istemcinin kimliği doğrulandı, gönderene izin verildi, mesaj kabul edildi, etki alanı mekanizmaları değerlendirildi ve nihai düzenleme gözlemlendi. Tek bir başarı etiketi çok fazla şeyi gizler. İzlenecek yol bu sonuçların nasıl ayrılacağını öğretir; yürütülen protokol işlemeyi, DKIM doğrulamasını veya kiracı yapılandırmasını talep etmez.
Kabul sonuçlarını ayrı tutun
- İstemcinin kimliği doğrulandı: uç noktayı, desteklenen mekanizmayı ve sonucu kaydedin, sırrı asla kaydedin.
- Gönderene izin verildi: Hesabın bu zarf ve görünür gönderen için yetkili olduğunu doğrulayın.
- Mesaj kabul edildi: içerik aktarımından ve alıcı sunucudan sonra yanıtı saklayın.
- Etki alanı doğrulandı: Güvenilir SPF / DKIM sonuçlarını ve DMARC hizalamasını bağımsız olarak kaydedin.
- Teslimat gözlendi: Taşıma kabulünü gelen kutusu garantisine dönüştürmeden alıcı tarafındaki sonucu koruyun.