Bir maili göndermek neden bu kadar zor? Kendi mail sunucumdan öğrendiklerim

Bu siteyi yayına aldıktan sonra aklıma bir soru takıldı: "Kayıt ol" butonuna bastığında gelen doğrulama maili, arka planda tam olarak ne yaşıyor? Her gün onlarca mail gönderiyorum ama bir mailin bir sunucudan çıkıp başka birinin gelen kutusuna nasıl ulaştığını hiç gerçekten düşünmemiştim.

Hazır servisler var tabii. Birkaç tıkla bir hesap açıyorsun, bir API anahtarı alıyorsun ve mailler gidiyor. Ama o birkaç tıkın arkasında neler olduğunu bilmiyordum. Merak ettim, karşıma hangi zorlukların çıkacağını görmek istedim. Üstüne iki ödülü de vardı: Kimseye ücret ödemeyecektim ve verilerim tamamen bende kalacaktı.

Bu yazı, kendi mail sunucumu kurarken düştüğüm çukurların hikâyesi. Bir de o çukurlardan çıkarken öğrendiklerimin.

Kurulum: Kolay kısım

Sitem zaten Hetzner'de bir sanal sunucuda çalışıyor ve sunucuyu HestiaCP ile yönetiyorum. HestiaCP, web sitelerini, veritabanlarını, DNS'i ve maili tek bir panelden yönetmeni sağlayan açık kaynak bir kontrol paneli. Mail tarafında arkada Exim (mail gönderip alan sunucu), Dovecot (posta kutularını IMAP ile sunan sunucu) ve Roundcube (tarayıcıdan mail okumak için) hazır geliyor.

Deneme olsun diye maili sadece bu sitenin alan adı için açtım. Bir posta kutusu oluşturdum, Roundcube'a girdim, ilk mailimi yazdım ve gönder'e bastım.

Mail gitmedi.

Kapalı kapılar: Port 25 ve 465

Panelde her şey yolunda görünüyordu. Hata mesajı yoktu, sadece mail bir türlü yola çıkmıyordu. Neden gönderemediğimi araştırınca sorunun bende değil, sunucunun bulunduğu altyapıda olduğunu öğrendim.

Önce biraz arka plan. Mail sunucuları birbirleriyle port 25 üzerinden konuşur. Gmail'e bir mail gönderdiğinde, senin sunucun Gmail'in sunucusunun 25 numaralı kapısını çalar. Port 465 ise şifreli bağlantıyla mail göndermek için kullanılır.

Hetzner, yeni bulut sunucularda bu iki porttan dışarı giden trafiği varsayılan olarak kapalı tutuyor. Sebebi anlaşılır: Ucuz bir sunucu kiralayıp ondan binlerce spam mail göndermek çok kolay. Kapıları baştan kapatmak, sağlayıcının IP adreslerinin itibarını koruyor. Normalde bu portların açılması için bir süredir müşteri olman, ilk faturanı ödemiş olman ve bir destek talebinde ne göndereceğini anlatman gerekiyor.

Destek talebini açtım. Hetzner'de uzun zamandır web hosting müşterisi olduğum için benden hiçbir belge istenmedi, portlar otomatik olarak açıldı. İkisi de kapalıydı.

Bir portun dışarıya açık olup olmadığını terminalden kendin de test edebilirsin:

nc -vz gmail-smtp-in.l.google.com 25

Bağlantı kurulursa kapı açık. Sonsuza kadar beklerse büyük ihtimalle bir yerde birisi kapıyı kapatmış.

İlk ders: Hata her zaman senin kodunda ya da ayarında değildir. Bazen kapı daha sen gelmeden kapatılmıştır.

DNS: Mailin kimlik kartı

Portlar açıldı, mailler gitmeye başladı. Ama gitmek, ulaşmak demek değil. Karşı taraftaki sunucu, maili kabul etmeden önce şunu sorar: "Bu mail gerçekten söylediği yerden mi geliyor?" Bu sorunun cevabı DNS kayıtlarında saklı.

Bu kayıtların çoğu benim için yeniydi. Ne işe yaradıklarını tek tek araştırmam gerekti. Kısaca şöyle:

• A kaydı: Bir ismi bir IP adresine bağlar. server1.example.net → sunucunun IP adresi.
• MX kaydı: "Bu alan adına gelen mailleri şu sunucuya teslim et" der. Biri ornek@example.com adresine mail gönderdiğinde, gönderen sunucu önce bu kayda bakar.
• PTR kaydı (rDNS, ters DNS): A kaydının tersi. IP adresinden isme gider. Karşı sunucu "Bu IP kim?" diye sorduğunda cevap buradan gelir. Bu kayıt alan adının DNS'inde değil, IP'nin sahibinde, yani Hetzner'in panelinde ayarlanır.
• SPF: "Bu alan adı adına şu sunucular mail gönderebilir" listesi. Listede olmayan bir yerden senin alan adın adına mail gelirse şüphelidir.
• DKIM: Her mailin üzerine basılan dijital bir mühür. Sunucum maili gizli bir anahtarla imzalıyor, açık anahtar ise DNS'te duruyor. Alıcı, imzayı DNS'teki anahtarla kontrol ediyor. İmza tutuyorsa mail yolda değiştirilmemiş ve gerçekten benim sunucumdan çıkmış demektir.
• DMARC: SPF ve DKIM'in üstündeki kural. "SPF ya da DKIM tutmazsa ne yapayım?" sorusunu cevaplar: hiçbir şey yapma (none), spama at (quarantine) ya da reddet (reject). Bir de rapor adresi verirsen, büyük sağlayıcılar sana senin adına kimlerin mail göndermeye çalıştığını raporlar.

Örnek olarak kayıtlar kabaca şöyle görünüyor (isimler ve IP adresi örnek):

example.com.                  MX   10 server1.example.net.
example.com.                  TXT  "v=spf1 a mx ip4:203.0.113.10 -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=quarantine; rua=mailto:ornek@example.com"

Bunu bir mektup gibi düşünebilirsin. SPF, postanenin "Bu şirket adına sadece şu postacılar mektup taşır" listesi. DKIM, zarfın üzerindeki mühür. DMARC, mühür kırıksa ya da postacı listede yoksa ne yapılacağını söyleyen talimat. PTR de postacının yaka kartı.

Sondaki o küçük nokta

Yukarıdaki kayıtlarda her ismin sonunda bir nokta var: server1.example.net. Yazım hatası değil. DNS'te o nokta çok önemli.

DNS'te her tam isim aslında bir noktayla biter. O nokta, bütün DNS ağacının kökünü temsil eder ve "isim burada bitti" demektir. Tarayıcıda bunu hiç görmeyiz, çünkü arka planda bizim yerimize ekleniyor.

DNS bölge dosyalarında (zone file) ve birçok panelde ise sonu noktayla bitmeyen bir isim, eksik bir isim sayılır. Sistem onu tamamlamak için sonuna kendi alan adını ekler:

; doğru: sondaki nokta "isim burada bitti" der
example.com.  MX  10  server1.example.net.

; yanlış: nokta unutulmuş, alan adı sonuna eklenir
example.com.  MX  10  server1.example.net
; sonuç: server1.example.net.example.com.

İkinci kayıt hiçbir hata vermez. Sadece mailler, var olmayan bir sunucuya gitmeye çalışır. Bazı paneller noktayı kendisi ekliyor, bazıları eklemiyor. Bu yüzden bir kaydı girdikten sonra dig MX example.com +short gibi bir komutla gerçekte ne yazdığına bakmak alışkanlık olmalı.

Tek isim, birden fazla alan adı

Burada bir karar vermem gerekti. İlk aklıma gelen, her alan adı için ayrı bir mail sunucusu ismi kullanmaktı: mail.example.com gibi. Kulağa düzenli geliyor ama bir sorunu var: Bir IP adresinin yalnızca tek bir PTR kaydı olabilir.

Sunucum başka sunuculara kendini tanıtırken bir isim söylüyor (buna HELO/EHLO deniyor). Karşı taraf IP'nin PTR kaydına bakıyor, bir isim buluyor. Sonra o ismin A kaydına bakıp aynı IP'ye geri dönüp dönmediğini kontrol ediyor. Bu üçü birbirini tutmazsa mail en baştan şüpheli sayılıyor.

Bu yüzden bütün alan adları için tek bir sunucu ismi kullanıyorum. PTR kaydı bu isme, bu ismin A kaydı aynı IP'ye işaret ediyor. Sunucu kendini bu isimle tanıtıyor, TLS sertifikası da bu isim için alınmış.

Peki example.com adına gönderilen mail, server1.example.net isimli bir sunucudan çıkınca sorun olmuyor mu? Olmuyor. Sunucunun adı ile gönderenin alan adının aynı olması gerekmiyor. Alan adının "bu mail gerçekten benden" demesini SPF ve DKIM sağlıyor. PTR'nin işi sadece sunucunun kendisini doğrulamak.

Bu yazıyı yazarken öğrendiğim şey

Bu kararı vermiştim ama bir yeri unutmuşum. Bu yazı için kayıtlarımı tekrar kontrol ederken fark ettim: Alan adımın MX kaydı hâlâ ilk kurulumdan kalan mail.example.com gibi ayrı bir ismi gösteriyordu. O ismin kendi TLS sertifikası da yoktu.

Gelen mailler buna rağmen sorunsuz geliyordu. Çünkü MX kaydındaki isim PTR ile eşleşmek zorunda değil, sadece doğru IP'ye çıkması yetiyor. Sunucular arasındaki şifreli bağlantılarda da sertifika çoğu zaman sıkı kontrol edilmiyor. Yani hiçbir şey bozuk görünmüyordu. Ama bana mail gönderen her sunucu, isimle uyuşmayan bir sertifika görüyordu.

MX kaydını tek sunucu ismine çevirdim. Artık mail gönderirken de alırken de her şey aynı isimde buluşuyor. Küçük bir ek bilgi: MX kaydı bir CNAME'i değil, doğrudan A kaydı olan bir ismi göstermeli.

Çalışıyor olması, doğru olduğu anlamına gelmiyor. Bunu yazmasaydım belki hiç fark etmeyecektim.

Test siteleri: Karnemi görmek

Kayıtları girdim ama doğru mu girdim? Bunu tahmin etmek yerine ölçmek gerekiyor. Burada birkaç site çok işime yaradı:

• mail-tester.com: Sana geçici bir adres veriyor, o adrese mail gönderiyorsun ve 10 üzerinden bir not alıyorsun. SPF, DKIM, DMARC, PTR, kara listeler ve mailin içeriği tek tek kontrol ediliyor.
• MXToolbox: DNS kayıtlarını tek tek sorgulamak ve IP'nin kara listelerde olup olmadığını kontrol etmek için.
• internet.nl: Mail ayarlarını modern standartlara göre değerlendiren, Hollanda merkezli bir test sitesi.
• learndmarc.com: Bir mail gönderiyorsun, SPF, DKIM ve DMARC kontrollerinin adım adım nasıl yapıldığını görsel olarak gösteriyor. Konuyu öğrenmek için çok iyi.

Bir ipucu daha: Gmail'de bir mailin "Orijinali göster" seçeneğinde SPF, DKIM ve DMARC sonuçlarını PASS ya da FAIL olarak görebilirsin.

mail-tester'dan ilk aldığım not 4,5'ti. Sebep DKIM'di: İmza doğrulanamıyordu. Onu düzelttikten sonra not 9,5'e çıktı. Tek bir kayıt, notun yarısından fazlasını belirliyordu.

Her şey doğru, yine de spam

9,5 aldım, kayıtlar tamam, mühür sağlam. Gmail'e ve Outlook'a deneme maili gönderdim.

İkisi de spam klasörüne düştü.

İşte bu yazının asıl dersi burada: Teknik olarak doğru olmak, güvenilir olmak demek değil. Büyük mail sağlayıcıları sadece kayıtlarına bakmıyor. "Bu IP adresinden daha önce ne geldi? Ne kadar zamandır mail gönderiyor? Alıcılar bu mailleri açıyor mu, spam diye mi işaretliyor?" diye de soruyorlar.

Benim IP adresimin bir geçmişi yok. Yeni bir IP, mail dünyasında kredi geçmişi olmayan biri gibi: Borcunu hiç aksatmamış olabilirsin ama bankanın elinde bunu gösteren bir kayıt yok. Bulut sağlayıcılarının IP blokları da spam göndericileri tarafından çok kullanıldığı için baştan biraz şüpheyle karşılanıyor.

Bunun için yapılabilecekler:

• Kara listeleri kontrol et. MXToolbox ile IP'nin herhangi bir listede olup olmadığına bak. Varsa listenin sitesinden kaldırma talebi gönder.11 Bazı kara listeler tek bir IP'yi değil, bütün bir sağlayıcının IP bloğunu listeliyor ve hızlı çıkarma için ücret istiyor. Bu listelerin büyük sağlayıcılar tarafından pek dikkate alınmadığı söyleniyor. Para ödemeden önce iyice araştır.
• Büyük sağlayıcılara kendini tanıt. Microsoft için SNDS (Smart Network Data Services) ve JMRP'ye kaydolabilir, Outlook'a gönderici destek formu doldurabilirsin. Google tarafında Postmaster Tools var. Ama o da ancak belirli bir hacmin üzerinde veri gösteriyor.
• Alıcılardan yardım iste. Spam klasöründeki maili "Spam değil" olarak işaretlemek ve adresi kişilere eklemek, sağlayıcıya güçlü bir sinyal veriyor.
• Yavaş ve gerçek mail gönder. Bir anda yüzlerce mail göndermek yerine gerçek kişilerle gerçek yazışmalar. Buna IP'yi "ısıtmak" deniyor.
• Bir relay kullan. Mailleri itibarı oturmuş bir servis üzerinden göndermek sorunu bir gecede çözer. Ama bu, bu deneyin amacına ters. O yüzden bu yolu seçmedim.

Ben kara listeler ve sağlayıcılar için gerekli başvuruları yaptım. Mailler hâlâ zaman zaman spam klasörüne düşüyor. Bunun bir ayarı yok. İtibar satın alınmıyor, zamanla kazanılıyor. Sabırlı olmak gereken bir süreç.

Beklenmedik bir ödül: Umlautlu bir adres

Bu deneyin karşılığını beklemediğim bir yerde aldım.

İşte bir müşterimiz posta kutusuna giriş yapamıyordu. Mail adresinde "ä" ve "ö" gibi umlaut harfleri vardı. Mail sunucusu kurarken öğrendiğim bir şey aklıma geldi: DNS ve mail sistemlerinin büyük bölümü aslında sadece İngilizce harflerle çalışıyor. ü, ö, ä ya da ş gibi harfler içeren alan adları, arka planda Punycode denen bir yöntemle sadece ASCII karakterlerden oluşan bir karşılığa çevriliyor. Bu karşılığın başında hep xn-- yazıyor.

Örneğin:

müller.de  →  xn--mller-kva.de

Tarayıcı bu çeviriyi sen fark etmeden yapıyor. Ama her mail programı ve her sistem aynı şekilde davranmıyor. Kimi umlautlu hali kabul ediyor, kimi sadece xn-- ile başlayan halini anlıyor. Bunu bildiğim için sorunun nerede olduğunu hemen gördüm ve müşteriye birkaç dakikada yardımcı olabildim.

Mail sunucusu kurmasaydım xn-- ile başlayan bir adres görünce büyük ihtimalle bir hata olduğunu düşünürdüm.

Başarısızlık değil, sonuç

Bu süreçte hiç pes etmeyi düşünmedim. Aksine her başarısız deneme bir şey öğretti: Gitmeyen mail portları, 4,5'lik not DKIM'i, spam klasörü de itibarı.

Bu bana Edison'la ilgili meşhur bir hikâyeyi hatırlattı. Genelde "Başarısız olmadım, sadece işe yaramayan 10.000 yol buldum" diye ve ampulle anlatılır. Asıl hikâye biraz farklı.22 Hikâyenin bilinen en eski kaynağı Dyer ve Martin'in 1910'da yayımlanan Edison: His Life and Inventions adlı biyografisi. Orijinali: "Results! Why, man, I have gotten a lot of results! I know several thousand things that won't work." Sayı farklı anlatımlarda 700'den 50.000'e kadar değişiyor. Edison ve ekibi aylardır nikel-demir aküsü üzerinde çalışıyordu ve binlerce deney yapmışlardı. Arkadaşı Walter S. Mallory laboratuvara gelip bu kadar emeğe rağmen hiç sonuç alamamalarının yazık olduğunu söyleyince Edison gülümseyerek cevap vermiş:

"Sonuç mu? Bir sürü sonuç aldım! İşe yaramayan birkaç bin şey biliyorum."

Bir alıntının bile aslını kontrol etmek gerekiyor. Bu da bu yazının konusuna yakışan bir ders.

Sen de bir şey kur

Tavsiyem şu: Hazır servisleri kullanmaya devam et, onlar işini iyi yapıyor. Ama hayatında bir kez, merak ettiğin bir şeyi kendin kur. Bir mail sunucusu, bir VPN, bir ev sunucusu ya da bir DNS sunucusu olabilir. Ve karşılaştığın zorlukları yaz.

Bir sistemi gerçekten anlamanın yolu, onun bozulduğu yerleri kendi gözünle görmek. Bir şey çalıştığında sadece çalıştığını öğreniyorsun. Çalışmadığında ise neden çalışması gerektiğini öğreniyorsun.

Ben yazdım, sıra sende. Sen en son neyi sırf merak ettiğin için kurdun?