Exchange Server

Exchange Server SMTP Reverse DNS Mismatch – Reverse DNS does not match SMTP Banner – FQDN for receive connector

Her geçen gün mail sistemleri spam maillere karşı daha korunaklı olmak için yeni teknolojiler veya çözümler kullanmaya başlamaktadır. Bu teknolojilerin pek çoğunu alında biliyoruz. En temel MX kayıtlarını kontrol ile başlayan süreç içerisinde Reverse DNS (PTR), SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) gibi yeni kavramlar ile tanışmış ve bunlara alışmış olduk. Ancak yine de bazı durumlarda her ne kadar bilinen bu gereksinimleri yerine getirsek bile mail sistemlerimiz bazı diğer mail sistemleri tarafından spam mail gönderen bir sistem olarak algılanabilir, yani aslında buradaki esas değişken karşılıklı olarak sistemlerin neleri kontrol ettiğidir. Örneğin SPF ilk yaygınlaşmaya başladığında pek çok mail sistemi SPF kaydını sorgulamıyordu veya sorgulasa bile eğer kendisine mail atan sistemin SPF kaydı yok ise yine de maillerin geçmesine izin veriyoruz, çünkü aksi halde pek çok iletişim problemi yaşama riski vardı. Ancak artık herkes SPF kullandığı için nerede ise tüm anti spam sistemlerinde SPF kaydı artık zorunluluk gibi. Tabiki yine bir sistem admin olarak siz kendi sahip olduğunuz mail sistemi üzerindeki ayarlarsan veya mail sistemini koruyan Anti Spam gateway yazılımındaki ayarlardan bunu değiştirebilirsiniz.

clip_image002

Yukarıdaki şekilde DKIM için bir çalışma şeması paylaşılmıştır.

Günümüzde ise mail sistemleri daha farklı teknolojiler kullanarak gelen mailin gerçekten sizin domain’ e ait olan mail sunucusundan geldiğini doğrulamaktadır. Benzer şekilde şu an itibari ile tüm mail sistemleri bunu yapmamak ile beraber makalemizin konusu olan SMTP Reverse DNS uyuşmazlığı aslında pek çok sistemcinin başına gelmiştir. Malum günde yüzlerce belki binlerce hatta banka ve benzeri bir kurum ise milyonlarca mail gönderiyor olabilir ve bunların içlerinde mutlaka birkaç veya daha fazla sistem için bu hatayı alıyor olabilirsiniz. Öncelikle Reverse DNS kısmını biliyoruz diye düşünüyorum eğer bu konuda bilgiye ihtiyacınız var ise aşağıdaki temel tanımı kullanabilirsiniz;

http://sozluk.cozumpark.com/goster.aspx?id=1684&kelime=rdns-Reverse-DNS

Bir diğer kavram olan SMTP banner, mail sunucunuz 25 nolu port üzerinden karşı mail sistemlerine cevap verirken kullanıldığı text içeriğidir. Yani bir mail sunucusu sizin mail sunucunuza 25 nolu port üzerinden (veya 587) bağlantı kurmak istediğinde mail sunucunuz cevabı bu banner ile beraber verir ve bu banner aslında temel bilgiler içerir. Aslında bu bilgileri de biz sistem adminleri değiştirebiliyoruz. Örneğin varsayılan olarak burada sunucu ismi gelirken biz güvenlik nedeni ile bunu domain ismi ile değiştirebiliriz ki makaledeki uygulama noktamızda bu olacak.

Bunu hızlı bir şekilde internet üzerinden veya telnet ile kontrol edebilirsiniz

clip_image003

clip_image004

SMTP Banner da mail sunucum için ismi “postaci.cozumpark.local” olarak görüyorum.

Veya aşağıdaki adres üzerinden kontrol edebilirsiniz

https://mxtoolbox.com/diagnostic.aspx

Tabiki bu adres daha detaylı bilgiler vermektedir.

clip_image006

Peki gelelim asıl konumuza. Sorun burada başlıyor, yani örneğin cozumpark.com gibi sizin bir domain adınız var ve bunun için bir MX ve yine PTR kayıtları var, ama PTR kaydı içerisindeki isim ile SMTP banner içerisindeki isim eşleşmiyor ise eğer bazı mail sistemleri sizin maillerinizi kabul etmiyor. Peki bu durumda ne yapmamız gerekiyor?

Bunun için öncelikle Exchange Server 2010, 2013 veya 2016 sistemlerinde yapacaklarımız aynı. Yani iste ara yüz olsun istek komut seti çok benzer bir değişiklik yapacağız.

Öncelikle varsayılan olarak 25 nolu portu dinleyen receive connector üzerindeki izinleri değiştirmemiz gerekiyor. Bunun için aşağıdaki yolu izleyebilirsiniz

Mail flow – receive connectors – Default Frontend üzerine çift tıklıyoruz

clip_image008

İzinler bölümüne geliyoruz

clip_image010

Burada “Exchange Server authentication” kutucuğunu kaldırıyoruz. Yani bu connector e bir başka Exchange server bağlanırken kendi sunucu kimlik bilgisini kullanmayacak. Ancak zaten normal şartlarda bu connector için gerekli bir durum değildir. Bu konuyu yani özellikle birden çok sunucu olan ortamlarda iç mesajlaşma için hangi connectorler kullanılır ve yapılan değişikliler nasıl sonuçlar doğurur noktasında aşağıdaki ücretli eğitimimi inceleyebilirsiniz

https://www.udemy.com/exchange-server-2016-egitimi-bolum3/learn/v4/overview

Eğer connector konusuna hakimseniz devam edebiliriz.

Bu işlemi yaptıktan sonra scoping bölümüne geliyoruz

clip_image012

Alt bölümde yer alan FQDN alanını DNS kayıtlarınızdaki PTR ile eşitliyoruz. Örneğin benim için bu kayıt mail.cozumpark.com

Not: Eğer security sekmesindeki değişikliği yapmayı unutur iseniz aşağıdaki gibi bir hata alırsınız

If the AuthMechanism attribute on a Receive connector contains the value ExchangeServer, you must set the FQDN parameter on the Receive connector to one of the following values: the FQDN of the transport server “OX-Exch1.ad.oxfordsbsguy.com”, the NetBIOS name of the transport server “postaci.cozumpark.local”, or $null.

clip_image014

Benzer şekilde bunu komut seti ile de yapmamız mümkün, öncelikle mevcut connector’ leri listeleyelim

Get-ReceiveConnector

clip_image016

Daha sonra değişiklik yapacağımız connector’ ü seçiyoruz

Get-ReceiveConnector -Identity “POSTACI\Default Frontend postaci” | fl FQDN

clip_image018

Gördüğünüz gibi mevcut FQDN bilgisi geliyor, daha sonra izinleri değiştirmemiz gerekiyor

Set-ReceiveConnector -identity “POSTACI\Default Frontend POSTACI” -AuthMechanism Tls, Integrated, BasicAuth, BasicAuthRequireTLS

Son olarak ise FQDN i değiştirebilirsiniz

Set-ReceiveConnector -identity “POSTACI\Default Frontend POSTACI” -Fqdn mail.cozumpark.com

Ve kontrol ediyoruz

clip_image020

Hepsi bu kadar. Umarım faydalı bir makale olmuştur. Bu konu ile ilgili sorularınız için ÇözümPark Bilişim Portalı forumlarını kullanabilirsiniz, bu konuda pek çok kez bilgi paylaşımında bulundum, arama yapmanız yeterli olacaktır.

 

 

 

 

Hakan Uzuner

2002 yılından beri aktif olarak bilişim sektöründe çalışmaktayım. Bu süreç içerisinde özellikle profesyonel olarak Microsoft teknolojileri üzerinde çalıştım. Profesyonel kariyerim içerisinde eğitmenlik, danışmanlık ve yöneticilik yaptım. Özellikle danışmanlık ve eğitmenlik tecrübelerimden kaynaklı pek çok farklı firmanın alt yapısının kurulum, yönetimi ve bakımında bulundum. Aynı zamanda ÇözümPark Bilişim Portalı nın Kurucusu olarak portal üzerinde aktif olarak rol almaktayım. Profesyonel kariyerime ITSTACK Bilgi Sistemlerinde Profesyonel Hizmetler Direktörü olarak devam etmekteyim.

Related Articles

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Back to top button