"Connection Timed Out" SMTP Hatası: Güvenlik Duvarı mı, Sunucu mu?

E-posta gönderme kuyruğunuz dolup taşıyor, log dosyalarında "connection timed out" satırları art arda sıralanıyor ve sisteminiz neden yanıt vermediğini söylemiyor. Bu yazıda söz konusu hatanın gerçek kaynaklarını, hangi katmanda oluştuğunu ve sistematik olarak nasıl çözüleceğini ele alıyoruz.

Hata Ne Anlama Geliyor?

RFC 5321, SMTP oturumunun her aşaması için yanıt bekleme sürelerini tanımlar. Buna göre bir SMTP istemcisi bağlantı kurma girişiminden itibaren belirli bir süre içinde karşı taraftan TCP SYN-ACK paketi almazsa oturumu sonlandırır ve "connection timed out" hatasını günlüğe yazar. Hata mesajının biçimi gönderen yazılıma göre değişir; Postfix'te connect to mail.example.com[1.2.3.4]:25: Connection timed out, Exim'de SMTP error from remote mail server: connection timeout şeklinde görülür. Her iki durumda da TCP üçlü el sıkışması (three-way handshake) tamamlanamamıştır.

Önemli bir ayrım: SMTP'nin 4xx serisi geçici hatalar, 5xx serisi kalıcı hatalar içindir (RFC 5321, Bölüm 4.2). "Connection timed out" ise bunların hiçbiri değildir; TCP katmanında oturum hiç kurulamamıştır. Bu nedenle pek çok izleme sistemi bu durumu ayrı bir kategori olarak raporlar.

Olası Nedenler ve Katmanlar

Hatayı doğru yere atfetmek, çözüm süresini önemli ölçüde kısaltır. Aşağıdaki tablo en yaygın nedenleri, hangi katmanda oluştuklarını ve ilk tespit yöntemini özetlemektedir:

Adım Adım Tanılama

1. Port Erişilebilirlik Testi

İlk kontrol noktası port erişilebilirliğidir. Klasik yöntem Telnet'tir:

telnet posta.hedef.com 25

Bağlantı kurulursa 220 posta.hedef.com ESMTP gibi bir karşılama mesajı görürsünüz. Eğer bağlantı birkaç saniye beklemenin ardından "Connection timed out" dönüyorsa paketler ağda ya da güvenlik duvarında düşürülüyor demektir. nc (netcat) ile de aynı testi yapabilirsiniz:

nc -zv -w 10 posta.hedef.com 25

Port 587 (STARTTLS ile gönderim) ve 465 (SMTPS) için testi tekrarlayın. RFC 8314, istemci gönderimleri için 587 ve 465 portlarının kullanımını önerir; modern altyapılarda port 25 yalnızca sunucular arası (MTA-to-MTA) iletişim için ayrılmıştır.

2. Güvenlik Duvarı Kurallarını İnceleyin

Linux tabanlı sistemlerde iptables veya nftables kurallarını listeleyin:

iptables -L -n -v | grep -E '25|587|465'

Bulut ortamlarında (AWS, Google Cloud, Azure) güvenlik grupları ve ağ erişim kontrol listeleri (NACL) ayrıca kontrol edilmelidir. AWS EC2 örneklerinde varsayılan olarak giden port 25 trafiği kısıtlıdır; AWS, bu kısıtlamayı kaldırmak için destek talebi açılmasını zorunlu kılar. Benzer kısıtlamalar Google Cloud ve Azure'da da mevcuttur.

3. ISP veya Barındırma Sağlayıcısı Engelini Sorgulayın

Bazı ISP'ler ve paylaşımlı barındırma sağlayıcıları spam önlemi gerekçesiyle port 25 çıkış trafiğini toptan kısıtlar. Bu durumu ayırt etmenin en hızlı yolu, testi farklı bir ağdan (örneğin mobil veri bağlantısı üzerinden) tekrarlamaktır. Farklı ağda başarılı oluyorsa sorun taşıyıcı katmanındadır.

4. IP İtibarını ve Kara Listeleri Kontrol Edin

Hedef sunucu gönderen IP adresini engellemişse TCP bağlantısı zaman zaman hiç kurulmadan düşürülebilir; bu da "connection timed out" olarak görünür. MXToolbox (mxtoolbox.com/blacklists.aspx), Spamhaus, Barracuda ve SORBS gibi veritabanlarını tarayarak IP itibarınızı doğrulayın. Eğer IP kara listedeyse ilgili sağlayıcıların kaldırma (delist) süreçlerini izleyin. Spamhaus'un SBL, XBL ve PBL listeleri en yaygın referans noktalarıdır.

5. DNS Kayıtlarını Doğrulayın

Gönderen sunucunuzun PTR (ters DNS) kaydı olmalı ve bu kayıt A kaydıyla tutarlı olmalıdır. Google ve Microsoft, PTR kaydı bulunmayan sunuculardan gelen bağlantıları reddedebilir. Microsoft'un posta kabul politikaları bu gereksinimi açıkça belgelemektedir.

dig -x GÖNDEREN_IP_ADRESI +short

Gönderen alan adınızın SPF kaydını RFC 7208'e göre, DKIM imzasını RFC 6376'ya göre ve DMARC politikasını RFC 7489'a göre yapılandırdığınızdan emin olun. Bu kayıtların eksikliği hedef sunucunun bağlantıyı erken sonlandırmasına neden olabilir.

6. Yerel SMTP Servisini Kontrol Edin

Hata giden değil gelen bağlantılarda yaşanıyorsa kendi SMTP sunucunuzun dinleme yapıp yapmadığını kontrol edin:

ss -tlnp | grep -E ':25|:587|:465'

Postfix için systemctl status postfix, Exim için systemctl status exim4 komutlarıyla servis durumunu doğrulayın. Log dosyaları Postfix'te /var/log/mail.log ya da /var/log/maillog, Exim'de /var/log/exim4/mainlog konumundadır.

Kurumsal Ortamlarda Ek Kontroller

Kurumsal ağlarda SMTP trafiği genellikle akıllı aktarıcı (smart host/relay) üzerinden yönlendirilir. Bu yapılarda güvenlik duvarı yalnızca relay sunucusuna izin verip doğrudan MX bağlantılarını engellemiş olabilir. Postfix'te relayhost parametresi, Exchange'de bağlayıcı (connector) yapılandırması bu mimarinin merkezindedir.

TLS zorunluluğu da zaman aşımlarına yol açabilir. Karşı sunucu eski TLS sürümlerini (TLS 1.0, 1.1) artık desteklemiyorsa ve sizin yapılandırmanız yalnızca bu sürümleri kullanıyorsa el sıkışma tamamlanmadan bağlantı düşebilir. OpenSSL ile el sıkışmayı doğrudan test edebilirsiniz:

openssl s_client -connect posta.hedef.com:587 -starttls smtp

Kalıcı Çözüm İçin Kontrol Listesi

Sorunu çözdükten sonra aşağıdaki adımların tamamını doğrulamanız önerilir: Güvenlik duvarında ilgili portların gelen ve giden yönlerde açık olduğunu onaylayın. Gönderen IP için PTR kaydının doğru yapılandırıldığını teyit edin. SPF, DKIM ve DMARC kayıtlarını test araçlarıyla doğrulayın; Google Postmaster Tools bu konuda gerçek zamanlı veriler sunar. IP itibarını düzenli aralıklarla izleyin. SMTP bağlantı denemelerini ve zaman aşımlarını loglayan bir izleme sistemi kurun.

Sık Sorulan Sorular