Sistemlerimizde e-posta gönderme sunucusu olarak (SMTP) tamamen açık kaynak (open source) olan Qmail yazılımını kullanıyoruz. Bu tercih, hem lisans maliyeti açısından, hem de özelleştirilebilirlik açısından hosting firmalarına birçok fayda sağlayan bir sistem.
Fakat sistemleriniz ne kadar stabil olursa olsun, internet birbiri içinde büyüklü – küçüklü sistemlerden oluşmuş bir yapıya sahip olduğundan dolayı bir takım aksaklıklar yaşamak mümkün. Bizim de sistemlerimiz diğer servis sağlayıcıları ile ortak çalışmak durumunda. Bunlardan en çok bilineni ve en önemlisi de Türk Telekom.
Qmail’in SMTP sunucusunu TCP Server üzerinde çalıştırıyoruz ve spam e-posta ile mücadele için de belirli politikalarımızın bir kısmı bu seviyede işliyor. Bu politikalardan bir tanesi de, istemci kullanıcının internete çıkış IP’sinin Ters DNS kaydının bulunması zorunluluğu. Bu sayede bir IP adresinin legal olup olmadığından daha çok emin olabiliyoruz. Bu ufak tanımlama yönetimi 2 gün önce (26.07.2010) bize büyük ve etkili bir sorun çıkardı ve müşterilerimizin bir kısmının e-posta gönderememesine sebep oldu.
Müşterilerimizin bir kısmı sorunsuz şekilde e-posta gönderip alabiliyorken, diğer bir kısmının sadece gönderememesinin sebeplerini araştırmaya başladık ve e-posta gönderemeyen kullanıcılarımızın hepsinin 85.105.x.x IP blogundan internet erişimi sağladıklarını farkettik. Daha sonra ise çalışmalarımızı bu alana yoğunlaştırdık.
Sunucumuzdan “netstat –aon” komutunu çalıştırdığımızda aşağıdaki gibi bir çıktı alıyorduk.
tcp 0 0 178.18.193.12:25 85.105.xxx.52:25 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.159:14770 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.100:56247 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.58:49536 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.245:33271 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.84:49717 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.100:17830 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.177:49491 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.54:49599 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.107:25 LAST_ACK
tcp 0 0 178.18.193.12:25 85.105.xxx.28:49323 LAST_ACK
….
….
….
Bu tabloyu yorumladığımızda gördük ki, müşterilerimizin sunucumuza herhangi bir bağlantı problemi yoktu. Sorun, sunucumuza erişim sağlanıp TCP HANDSHAKE gerçekleştikten sonraki prosedürdeydi. Bu prosedürlerin ilki de DNS kontrolleri olduğu için hemen DNS loglarına baktık ve sorunun nedenini anladık.
@400000004c4f0be50245b404 cached 1 ns1.ttnet.net.tr.
@400000004c4f0be50245b7ec cached 1 ns2.ttnet.net.tr.
@400000004c4f0be50245bfbc tx 0 12 xx.xx.105.85.in-addr.arpa. 105.85.in-addr.arpa. d49c0404 d49c0414 c10000c1
@400000004c4f0be51517027c servfail xxx.xxx.105.85.in-addr.arpa. input/output error
@400000004c4f0be51517121c sent 453156 43
@400000004c4f0be51571e034 query 453292 b212c102:fccb:eebc 12 144.xx.xx.xx.in-addr.arpa.
@400000004c4f0be51571ebec cached 12 144.xx.xx.xx.in-addr.arpa.
Sorun Türk Telekom’un DNS serverlarının çalışmaması ile ilgiliydi. Sunucumuz, Türk Telekom’un ns1.ttnet.net.tr ve ns2.ttnet.com.tr Name Server’larının hizmet vermemesi üzerine müşterilerimizin IP adreslerinin Ters DNS’lerini çözümleyinceye kadar bekliyordu ve müşterilerimizin SMTP istemci programları (Outlook, Thunderbird v.b ) “SMTP Timeout Error” veriyordu (timeout 90 saniye). Hemen TCP Server’ımızdaki gerekli kontrol mekanizmalarını bu Name Server’lar için kaldırdık ve müşterilerimiz sorunsuz e-posta göndermeye başladı.
Haklı olarak bir çok müşterimiz bu geçici sorundan rahatsız oldu ve birçok şikayet telefonu aldık. Fakat yine de sorunu çok hızlı çözüp müşterilerimize en az kesintiyle hizmet verdiğimiz için mutluyuz.