Mevcut kurulum boşluğunu görünür tutun
Bu taslak, başlangıç noktası olarak mevcut Simpro Yardım Kılavuzu ile simPRO'ya atfedilen postaları ele almaktadır. Mevcut birinci taraf yapılandırma kanıtları için beklemede kalır. Yardım Kılavuzu açılış sayfası bir listeler SPF Kayıtları konu ve Yardım Masası rotası, ancak SPF Bu araştırmada genel bir makale portalına bağlantı çözüldü. Bu alma işlemi gerekli SPF değerini veya mevcut imzalama prosedürünü oluşturmadı.
A sağlayıcı tarafından barındırılan DKIM tartışması Talepte bulunan kişiyi desteğe yönlendiren Eylül 2021 tarihli bir personel yanıtı içerir. Bu, güncel bir kullanılabilirlik vaadi, bir self-servis prosedürü veya hesaba özgü DNS değerleri kaynağı değil, destek yolunun faydalı tarihsel kanıtıdır. Bu cevabı evrensel bir kurulum tarifine dönüştürmeyin.
Etkilenen işletme mesajıyla başlayın
İşletmenin iletmesi gereken asıl mesajı belirleyin. Bir fiyat teklifi, fatura veya bildirim, kaynak iş akışına ve sorumlu sahibine bağlanmalıdır. Yalnızca kuruluşun dağıtımında mevcut olan iş akışlarını ekleyin. Benzer markalı eklentilerin veya entegrasyonların çekirdek uygulamanın giden altyapısını paylaştığını varsaymayın.
Örnek tanımlayıcıyı, ürünü veya modülü, görünür gönderen etki alanını ve bilinen herhangi bir posta geçişini kaydedin. Birkaç iş birimi farklı etki alanlarını kullandığında ayrı satırlar oluşturun. Teknik sorumlunun, sorunun her mesajı, tek bir iş akışını, tek bir göndereni veya tek bir alıcı sistemini etkileyip etkilemediğini bilmesi gerekir. Bu ayrım, hangi kanıtın isteneceğini ve yararlı bir yeniden testin neye benzeyeceğini belirler.
Ayrıca iş sonucunu da kaydedin. Gecikmiş bir iç bildirim, planlı bir soruşturmaya izin verebilir; Zaman açısından hassas bir belge bekleyen bir müşteri, önceden onaylanmış bir geri dönüş sürecine ihtiyaç duyabilir. Kimlik doğrulama çalışması sessizce fatura kopyaları oluşturmamalı, müşteri taahhütlerini değiştirmemeli veya partinin tamamını yeniden göndermemelidir.
Cevaplanabilecek bir destek talebi hazırlayın
Doğrulanmış mevcut sağlayıcı kanalından, tam örnek ve alan adı için kimlik doğrulama gereksinimlerini onaylamasını isteyin. "Etkinleştir" yönünde geniş bir talep yerine, amaçlanan gönderenin kimliğini ve kontrollü bir mesaj tanımlayıcısını sağlayın. DMARC.” Etkinleştirmeyi hangi ekibin gerçekleştirdiğini, DNS sahibinin hangi kayıtları yayınladığını ve tamamlamanın nasıl onaylandığını sorun.
İçin DKIM, desteklenen imzalama alanını isteyin, seçici, kayıt sahibi, kayıt türü ve genel değer. Kapsamın bir alan adı mı, örnek mi yoksa başka bir hesap sınırı mı olduğunu ve birden fazla alanın ayrı çalışma gerektirip gerektirmediğini sorun. SPF için geçerli desteklenen yetkilendirmeyi ve geçerli olduğu zarf kimliğini isteyin. Özel zarf desteği için, bir yanıt adresinden sonuç çıkarmak yerine, özellik ve geri dönme işlemi hakkında açıkça bilgi alın.
Yanıtı tarihi ve kapsamıyla birlikte saklayın. Destek ekibi farklı bir ürün veya dağıtım için belge sağlıyorsa herhangi bir şeyi yayınlamadan önce açıklama isteyin. Bu taslak bir destek talebi açmaz veya desteğin bir yapılandırmayı onayladığını iddia etmez.
Önerilen DNS değişikliğini bağlamda inceleyin
Bir değişikliğe izin verilmeden önce mevcut ilgili kayıtları dışa aktarın ve yetkili DNS sahibini belirleyin. Önerilen seçici adını mevcut kayıtlarla karşılaştırın. Bir çarpışma, başka bir hizmetin anahtarının üzerine yazılarak değil, sağlayıcıyla çözülmelidir. Farklı bir müşterinin örneğindeki anahtarı, seçiciyi veya sunucu yetkilendirmesini kopyalamaktan kaçının.
RFC 7208 dahil olmak üzere SPF işlemeyi tanımlar. DNS arama sınırı. Önerilen eklemeden sonra politikanın tamamını değerlendirin ve ilgisiz etkin gönderenleri koruyun. Yalnızca örneğin web adresine benzediği için geçmiş sunucu ana bilgisayar adını kullanmayın. Tarayıcı ana bilgisayar adı ve posta gönderen sistem ayrı gözlemlerdir.
RFC 6376 imzalama alanının ve seçicinin DKIM doğrulama anahtarını nasıl tanımladığını tanımlar. Destek değerleri yayınladıktan sonra, genel DNS bu kesin değerlerle karşılaştırın ve gözlem sürelerini kaydedin. Kaydedilmiş bir DNS formu, alıcıların doğru anahtarı alabileceğini göstermez.
Yayını ve sağlayıcı aktivasyonunu koordine edin
Sağlayıcıyla işlem sırası üzerinde anlaşın. DNS ne zaman yayınlandığını, sağlayıcının bunu ne zaman kontrol ettiğini ve her alan adı için imzalamanın ne zaman etkinleştirildiğini kaydedin. Geçen bekleme süresi tek başına etkinleştirmenin kanıtı değildir. Başarılı bir kayıt araması, uygulamanın yeni oluşturulan bir mesajda hangi anahtarı kullandığını da belirleyemez.
İlk örnekte beklenen imza yoksa etkinleştirme sonrasında ve amaçlanan iş akışı yoluyla oluşturulduğunu doğrulayın. Farklı bir gönderen alan adının veya aracı rotanın sonucu açıklayıp açıklamadığını kontrol edin. Orijinal isteğin durumu belirsizken tekrar tekrar yeni anahtarlar vermekten kaçının; konfigürasyonun birden fazla versiyonunu dolaşımda bırakabilir.
Özel anahtarları, oturum açma kimlik bilgilerini ve ilgisiz müşteri içeriğini kanıt paketinin dışında tutun. Yayınlama adımı, hesap sırlarıyla değil, herkese açık doğrulama kayıtlarıyla ilgilidir. Herhangi bir hesap girişi veya kimlik bilgisi yapılandırması, kendi onaylı sürecini gerektirir.
Gerçek müşteri yükümlülükleri oluşturmadan test edin
İzin verilen bir test ortamını veya işletme sahibiyle mutabakata varılan zararsız, kontrollü bir iş akışını kullanın. Yalnızca bir e-posta örneği oluşturmak için gerçek bir ücretlendirme, kabul tarihi veya müşteriye yönelik taahhüt oluşturmayın. Mevcut tek yol sonuç odaklıysa, bunu rutin postayla sorun giderme olarak ele almak yerine durun ve kesin test için onay alın.
Her anlamlı etki alanı ve iş akışı sınırı için bir örnek yakalayın. Desteğin gözlemleri ilişkilendirebilmesi için mesaj tanımlayıcıyı, UTC gönderme zamanını ve alıcı sistemini saklayın. Çalışanın posta kutusundan gönderilen sıradan bir e-posta, her ikisi de aynı Gönderen adresini gösterse bile uygulama tarafından oluşturulan rotayı doğrulayamaz.
Görünen son Kimden, Yanıtla, zarf etki alanını, her DKIM d= ve s= çiftini ve güvenilen alıcının kimlik doğrulama sonuçlarını kaydedin. RFC 9989 açıklıyor hizalama; Yalnızca " SPF yeşil" veya "teslim edildi" ifadesini kaydetmek yerine gerçek geçiş yolunu tanımlayın. Gelen kutusu yerleşimini ve iş makbuzunu ayrı sonuçlar olarak tutun.
Örnek ve belge iş akışı çalışma sayfasını kullanın
Aşağıdaki satır içi destek ve mesaj doğrulama çalışma sayfası, destek yazışmasını, etki alanını, DNS değişikliğini, etkinleştirme olayını ve alınan örneği birbirine bağlar. Ayrıca testin bir iş yükümlülüğü oluşturup oluşturmadığı ve güvenli yöntemi kimin onayladığı da kayıt altına alınır. Geçerli sağlayıcı değerlerini, doğrulanmış bir kanal aracılığıyla sağlanana kadar boş bırakın.
Birden fazla şirket kimliğinin veya iş akışının olduğu durumlarda kapsam kararı alınması gerekir. Sahibi ya bir test sağlamalı ya da sürüm kapsamı dışındaki rotayı açıkça işaretlemelidir. Bir şubeden gelen başarılı bir numunenin diğer tüm gönderenleri sessizce onaylamasına izin vermeyin.
İkinci bir iş alanını içeren kurgusal teşhis vakası
Yalnızca kurgusal örnek: Harbor Mechanical incelemeleri, başvuru tarafından oluşturulan belgeleri reddetti. Bir iş biriminin kontrollü mesajı amaçlanan hizalanmış imzaya sahipken, başka bir birim farklı bir Gönderen etki alanını kullanıyor ve kullanmıyor. Yönetici başlangıçta ilk sonucu uygulamanın tamamen yapılandırıldığının kanıtı olarak değerlendirir.
Çalışma sayfası eksik etki alanı satırını ortaya koyuyor. Ekip, ikinci alanın kapsamını ve aktivasyon durumunu doğrulamak için destek ister ve ardından zararsız bir yeniden test hazırlar. Tüm kuruluşun politikasını değiştirmek yerine kullanıma sunma işlemini eksik bırakır. Bu örnekte herhangi bir Harbor hesabı, Simpro destek durumu, DNS kaydı veya başarılı aktivasyon gözlemlenmedi.
Rotayı kurtarın ve kabul bekletmesini koruyun
Herhangi bir üretim değişikliğinden önce bir geri dönüş üzerinde anlaşın. Yeni bir yapılandırma önemli bir iş akışını kesintiye uğratırsa, bu dağıtımı duraklatın ve kurtarma işlemini uygulama, posta ve DNS sahipleriyle koordine edin. Sıradaki mesajların hâlâ ihtiyaç duyabileceği bir anahtarı silmeyin ve gerçek reddetme durumunu anlamadan alıcı atlamalarını genişletmeyin.
Geriye kalan kapılar, sağlayıcıya ait mevcut kurulum talimatları, tam orijinal ürün kapsamı, desteklenen hesap değerleri, canlı DNS ve alınan mesaj kanıtlarıdır. Görsel inceleme ve insan KOBİ onayı da beklemededir. Bu, açık bir kurulum bekletme içeren eksiksiz bir araştırma ve doğrulama taslağıdır; herhangi bir simPRO rotasının doğrulandığının kanıtı değildir.
Satır içi destek ve mesaj doğrulama çalışma sayfası
Yetkili bir operatör kanıt sağlayana kadar tüm alanlar beklemededir. Sırları ve müşteri içeriğini bu kaydın dışında tutun.
- Örnek, ürün, iş akışı ve sahibi: beklemede.
- Gönderenin alanı, yanıtın işlenmesi ve etkilenen belge: beklemede.
- Gecikmenin sonucu, güvenli test yöntemi ve onay: beklemede.
- Güncel destek referansı, tarihli talimatlar ve uygulanabilirlik: beklemede.
- Verilen DKIM alanı, seçici, sahip, tür ve genel değer: beklemede.
- SPF yetkilendirmesi, değerlendirilen zarf alanı ve özel zarf desteği: beklemede.
- DNS yayını, arama ve sağlayıcı etkinleştirme zaman damgaları: beklemede.
- Kontrollü mesaj referansı, son Kimden, Yanıtla, zarf ve tüm DKIM kimlikleri: beklemede.
- Güvenilir alıcı sonuçları, uyumlu mekanizma ve rota kapsamı: beklemede.
- Geri dönüş sahibi, sıraya alınmış mesaj bağımlılıkları ve çözümlenmemiş sürüm kapıları: beklemede.
Mesaj kabulünü politikanın kullanıma sunulmasından ayırın
Başarılı bir hizalanmış SPF sonucu, bir mesaj değerlendirmesini karşılayabilir, ancak tek başına tüm alanın reddedilmek üzere taşınmasını haklı çıkarmaz. RFC 9989 Bölüm 7.4, alan yayınlama için geçerli DKIM gerektirir p=reject ve dolaylı postaların birlikte çalışabilirliği konusunda uyarıda bulunur. Politika sahibi uygulamayı onaylamadan önce tüm meşru gönderenlerin ve dolaylı yolların envanterini çıkarın. Bu makale için hiçbir DNS değişikliği, kiracı işlemi veya alınan ileti testi yürütülmedi.