SMTP timeout neden “belirsiz” görünür?
SMTP iletimindeki en zor vakalar genellikle “timeout” veya “connection reset” gibi net olmayan belirtilerle başlar. Çünkü SMTP, tek bir uygulama katmanı protokolü gibi görünse de; DNS çözümleme, TCP bağlantısı, ağ yönlendirme, güvenlik cihazları, TLS pazarlığı ve karşı sunucunun politikaları birlikte çalışır. Bu zincirin herhangi bir halkasında yaşanan küçük bir aksama, istemcinin yalnızca “bağlanamadım” demesine neden olabilir.
Bu rehber, SMTP gönderiminde ve sunucular arası teslimatta görülen bağlantı odaklı hataları sistematik şekilde teşhis etmek için tasarlanmıştır. Amaç, rastgele deneme-yanılma yerine katman katman ilerleyerek kök nedeni bulmaktır.
En sık görülen belirtiler ve tipik hata mesajları
Farklı MTA’lar ve istemciler aynı sorunu farklı metinlerle raporlayabilir. Yine de aşağıdaki başlıklar, olayın bağlantı/TLS/ağ tarafında olduğunu güçlü şekilde işaret eder:
- Connection timed out: TCP üçlü el sıkışma tamamlanamıyor veya yol üzerinde paketler düşüyor.
- Connection refused: Hedef IP’ye gidiliyor ama ilgili portta servis dinlemiyor veya firewall aktif olarak reddediyor.
- Network is unreachable / No route to host: Yönlendirme problemi, yanlış IP, hatalı policy routing veya upstream blok.
- Connection reset by peer: Karşı uç (veya aradaki cihaz) bağlantıyı aniden kapatıyor. Sık neden: TLS/STARTTLS sorunları veya güvenlik cihazı müdahalesi.
- 421/451 temporary failure: Karşı taraf geçici ret veriyor; bazen rate limit, bazen de güvenlik kontrolleri (örn. TLS zorlaması) nedeniyle.
- SSL/TLS handshake failure: Sertifika zinciri, SNI, protokol sürümü, şifre takımı veya STARTTLS akışında uyumsuzluk.
Önce yönü belirleyin: Gönderim mi, alım mı, istemci erişimi mi?
Aynı “SMTP” kelimesi üç farklı trafik tipini kapsar ve teşhis yaklaşımı değişir:
- SMTP Submission (kullanıcı gönderimi): Genellikle 587 veya 465. Kullanıcı istemcileri buraya bağlanır.
- SMTP Relay / Sunucudan sunucuya teslim: Genellikle 25. Dış dünyaya teslim veya dış dünyadan alım bu hat üzerinden yürür.
- İç ağdan MTA’ya bağlantı: Firewall segmentleri, VPN, SD-WAN gibi unsurlar daha baskın olabilir.
Hata hangi yönde? “Biz dışarı gönderemiyoruz” ile “dışarıdan mail alamıyoruz” aynı değildir. Loglarda hedef IP/port ve bağlantı denemesinin nereden yapıldığı netleşmeden çözüm üretmeyin.
Adım adım teşhis: DNS, TCP, TLS, uygulama
1) DNS çözümleme ve hedef seçimi
Sunucudan sunucuya teslimde ilk adım DNS’dir: MX kayıtları, ilgili A/AAAA kayıtları ve bazen de yanlış yapılandırılmış IPv6, yanlış hedefe gitmenize yol açabilir. Tipik senaryolar:
- MX, artık kullanılmayan eski bir hosta işaret ediyordur.
- MX hostunun AAAA kaydı vardır ama IPv6 çıkışı yoktur; MTA IPv6’ı dener ve timeout yaşar.
- Split-horizon DNS yüzünden iç ağ farklı, dış ağ farklı cevap dönüyordur.
Çözüm: Sorun yaşayan sistemin kendisinden DNS sorgusu yaparak hangi IP’nin seçildiğini doğrulayın. Gerekirse IPv6 denemelerini geçici olarak sınırlamak veya doğru IPv6 çıkışını sağlamak gerekebilir.
2) TCP bağlantı testi: Port açık mı, yol temiz mi?
DNS doğruysa bir sonraki adım saf TCP testidir. “Connection refused” genellikle hedefte servis yok veya port firewall tarafından aktif reddediliyor demektir. “Timeout” ise daha çok yol üzerinde filtreleme, asimetrik routing, NAT sorunları veya upstream bloklara işaret eder.
Bu noktada şu soruları cevaplayın:
- Testi aynı sunucudan mi yapıyorsunuz? Masaüstü bilgisayardan test etmek yanıltıcı olabilir.
- Hedef port: 25 mi, 587 mi, 465 mi? Yanlış port seçimi sık görülür.
- Çıkış firewall’ınız outbound 25 trafiğini kısıtlıyor mu? Bazı ağlarda 25 dışarı kapalı olabilir.
3) Firewall, NAT ve state table problemleri
SMTP bağlantıları uzun süre açık kalabildiği için firewall state yönetimi önemlidir. Özellikle yüksek hacim veya yoğun tekrar denemelerde state table dolabilir, bağlantılar yarıda kesilebilir. Ayrıca NAT arkasındaki sistemlerde “hairpin NAT”, yanlış port yönlendirme veya kısa NAT timeout değerleri bağlantı kopmalarına neden olabilir.
Dikkat edilmesi gerekenler:
- Outbound ve inbound kurallarının ayrı ayrı doğrulanması (özellikle 25/587/465).
- IPS/IDS cihazlarının STARTTLS trafiğini yanlış sınıflandırıp bağlantıyı kapatması.
- NAT timeout değerlerinin SMTP oturumları için çok kısa olması.
Belirti: Bağlantı kurulur, banner gelir; STARTTLS veya AUTH sonrasında aniden reset olur. Bu durumda aradaki güvenlik cihazlarını devre dışı bırakmadan önce loglarını kontrol etmek kritiktir.
4) MTU ve PMTUD: “Görünmez” paket kaybı
Bazı ağ sorunları sadece belirli paket boyutlarında ortaya çıkar. Özellikle VPN, PPPoE, tünelleme veya yanlış ICMP blokları varsa Path MTU Discovery düzgün çalışmayabilir. Sonuç: küçük paketler gider, büyük paketler kaybolur; TLS handshake gibi daha büyük paketli akışlar takılabilir.
Pratikte bu durum şu şekilde görünür:
- TCP bağlantısı kurulur ama TLS pazarlığı sırasında timeout olur.
- Bazı alıcılara sürekli sorun varken bazılarına hiç sorun olmaz (yol farklılığı).
Çözüm yaklaşımı: MTU değerlerini ve tünel/wan hatlarını inceleyin; ICMP’nin tamamen kapatılmasının yan etkilerini değerlendirin. Gerekirse ilgili arayüzlerde MTU/MSS ayarıyla sorunu stabilize edin.
5) TLS/STARTTLS pazarlığı ve sertifika kaynaklı kopmalar
SMTP’de TLS çoğunlukla STARTTLS ile “aynı port üzerinde yükseltme” şeklinde çalışır. Bu aşamada yaşanan sorunlar bağlantının resetlenmesi veya handshake failure olarak yansır.
Sık nedenler:
- Yanlış sertifika zinciri (ara sertifika eksik).
- Sertifika hostname ile uyuşmuyor (özellikle load balancer veya farklı isimler).
- Eski TLS sürümleri veya şifre takımları yüzünden uyumsuzluk.
- SNI bekleniyor ama istemci göndermiyor ya da tersine.
Karşı taraf MTA-STS veya kurumsal TLS politikaları uyguluyorsa, TLS sorunları “geçici” gibi görünen 4xx’lerle de ortaya çıkabilir. Bu nedenle sadece hata koduna değil, aynı zamanda hangi aşamada koptuğuna bakın.
Uygulama katmanı kontrolleri: Yetkilendirme, oran limitleri, içerik değil bağlantı
Bazı hatalar bağlantı sorunu gibi görünse de uygulama politikasıdır. Örneğin submission tarafında yanlış kullanıcı adı/parola, zorunlu AUTH politikası veya IP kısıtı “bağlandı ama gönderemedi” şeklinde yaşanır. Sunucudan sunucuya teslimde ise bazı sistemler şüpheli davranışta (çok hızlı deneme, hatalı HELO, anormal hacim) 4xx ile yavaşlatma uygulayabilir.
Bu aşamada yapılacaklar:
- Loglarda “connect” sonrasındaki komut akışını inceleyin: EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO.
- Hatanın hangi komutta geldiğini not edin. RCPT TO’daki 450 ile connect timeout aynı şey değildir.
- Deneme sayısı, eşzamanlı bağlantı sayısı ve yeniden deneme aralıklarını gözden geçirin.
Hızlı kök neden eşleştirme tablosu (pratik)
- Timeout (her hedefte): Çıkış firewall, ISP blokları, routing, DNS yanlışlığı.
- Timeout (bazı hedeflerde): Uzak tarafın IP bazlı blokları, yol/peering sorunları, MTU.
- Refused: Hedef port kapalı, yanlış port, yanlış IP.
- Reset (STARTTLS sonrası): TLS uyumsuzluğu, sertifika zinciri, güvenlik cihazı müdahalesi.
- 421/451: Uzak taraf geçici politika, rate limit veya güvenlik kontrolleri; yeniden deneme mantığını doğrulayın.
Kalıcı önleme: İzleme, değişiklik yönetimi ve test rutini
SMTP bağlantı sorunları çoğu zaman bir değişiklik sonrası patlar: firewall kural güncellemesi, sertifika yenilemesi, WAN sağlayıcı değişimi, yeni bir IPS profili, DNS güncellemesi gibi. Bu yüzden teknik önlemler kadar operasyonel disiplin de önemlidir.
- Değişiklik öncesi temel testler: DNS çözümleme, port erişimi, STARTTLS doğrulaması.
- Değişiklik sonrası doğrulama: Aynı testlerin tekrarı ve loglarda anomali kontrolü.
- Alarm ve metrikler: Queue büyümesi, bağlantı hata oranları, TLS handshake hata sayıları.
- Yedek yol planı: Alternatif çıkış IP’si veya failover MX tasarımı (ihtiyaca göre).
Sonuç: Sistematik yaklaşım, daha hızlı çözüm
SMTP timeout ve bağlantı hatalarını çözmenin anahtarı “tek bir ayar” aramak değil, zincirin hangi halkasının koptuğunu bulmaktır: DNS doğru mu, TCP yolunda engel var mı, firewall/NAT oturumu doğru yönetiyor mu, MTU/TLS gibi hassas alanlarda paket kaybı var mı, uygulama politikaları bağlantıdan sonra mı devreye giriyor?
MX1Mail gibi kurumsal e-posta altyapılarında bu tür teşhisler yapılırken, logların doğru yorumlanması ve kontrollü testlerin aynı kaynaktan (sorunu yaşayan sunucudan/istemciden) yapılması süreyi ciddi biçimde kısaltır. Kök nedeni netleştirdiğinizde çözüm genellikle basittir: doğru port ve kural, doğru DNS hedefi, doğru TLS zinciri veya doğru ağ parametresi.