Mail sunucularının çalışmasını kontrol etmek için pek çok yöntem bulunuyor. Kullanıcılar genellikle posta alabildikleri sürece sistemde sorun olmadığını düşünüyor. Biz sistem yöneticileri açısından ise iş biraz daha farklı. Bir sunucunun ilgili porttan cevap vermesi, posta kutusuna erişimin çalışması ve mesajların gerçekten teslim edilmesi birbirinden ayrı kontroller. Bu makaleyi ilk hazırladığımda Telnet ile POP3 servisine bağlanarak posta kutusundaki mesajları listeleme, okuma ve silme işlemlerini göstermiştim. Eski laboratuvarı ve dokuz ekran görüntüsünü koruyarak, günümüzde bu yöntemin nerede kullanılabileceğini ve nerede kullanılmaması gerektiğini de açıklamak istiyorum.
Ekim 2026 güncellemesi: Aşağıdaki ekran görüntüleri 2008 yılındaki Exchange/POP3 laboratuvarına aittir. O dönemin kullanıcı adı ve parola ile şifresiz port 110 üzerinde oturum açma yöntemi, günümüzün üretim sistemleri için güvenli bir uygulama değildir. Bu bölüm tarihsel bir protokol örneği olarak okunmalıdır.
Telnet ile posta sunucusunda hangi servisi test ediyoruz?
Eski makaledeki örnek, başlıktan düşünülebileceğinin aksine SMTP ile e-posta gönderimini değil, POP3 ile posta kutusuna erişimi gösteriyor. Telnet burada uzak sunucuda Telnet Server (TCP 23) servisini açmak için değil, belirli bir TCP bağlantı noktasına metin tabanlı bağlantı kurmak için kullanılan istemci araçtır. Bir Windows makinesinde Telnet Client bileşeninin bulunması ile sunucuda Telnet Server açılması aynı şey değildir.
POP3 için geleneksel port 110, TLS ile baştan şifreli POP3S için 995 kullanılır. SMTP için 25 genellikle sunucular arası iletim, 587 ise istemcilerin gönderim (submission) senaryolarında kullanılır. IMAP için 143 ve TLS bağlantısı için 993 yaygındır. Bu portların açık olması tek başına kimlik doğrulamanın veya posta akışının sağlıklı olduğunu göstermez.
Özgün laboratuvar: POP3 servisini açma ve bağlantı
2008 yılında Exchange Server/Windows Server üzerinde POP3 servisi her kurulumda aktif değildi. Bu nedenle örnekte önce hizmet durumunu kontrol ediyor, ihtiyaç varsa laboratuvar ortamında başlatıyordum. Bugün ise üretim sunucusunda POP3 erişimini yalnızca gerçek bir ihtiyaç varsa ve uygun TLS ile kimlik doğrulama ayarlarını yapılandırdıktan sonra etkinleştirmek gerekiyor.
İlk ekranda eski hizmet yönetimi penceresini görüyorsunuz. Güncel Exchange Server kurulumlarında POP3 servis yapılandırması sürüme bağlıdır; yalnızca eski ekran görüntüsüne bakarak servis açmamak gerekir.
Ardından istemcide komut penceresini kullanarak sunucuya POP3 portundan bağlantı kuruluyordu. Bu yalnızca şifrelenmemiş laboratuvar örneğidir:
telnet posta-sunucusu.example 110
Sunucu yanıtındaki +OK ifadesi POP3 servisinin isteğe cevap verdiğini gösterir. Bu, sunucunun tüm e-posta hizmetlerinin sorunsuz çalıştığını kanıtlamaz.
POP3 oturumunda USER, PASS, LIST ve RETR
Klasik POP3 protokolünde kullanıcı adını USER, parolayı PASS komutuyla göndermek mümkündür. Ancak TLS olmadan bu komutlar parolayı ağ üzerinde açık metin olarak taşıyabilir. Bu nedenle aşağıdaki eski akışı artık canlı hesaplarla çalıştırmayı önermiyorum. Örnek kullanıcı/parola değerleri gösterim amaçlıdır, gerçek bir parolayı terminale yazmayın.
USER ornek-kullanici PASS <ornek-parola>
Oturum doğrulandıktan sonra LIST komutu mesaj numaralarını ve yaklaşık boyutlarını döndürür. RETR 1 ise birinci mesajın başlıklarını ve gövdesini getirir. Bu işlemler de gizlilik açısından sadece yetkili olunan test posta kutularında yapılmalıdır.
STAT LIST RETR 1
Eski örnekte alınan yanıt içinde gönderen, alıcı, konu ve mesaj tarihini inceliyordum. Buradaki mesaj başlıklarının görüntülenmesi ile sunucunun SMTP üzerinden yeni ileti kabul etmesi aynı kontrol değildir.
DELE komutuna dikkat
DELE, POP3 oturumunda ilgili mesajı silinmek üzere işaretler. POP3 protokolünde silmenin kalıcı hale gelmesi genellikle oturumun QUIT ile normal sonlandırıldığı güncelleme aşamasında gerçekleşir. Bu nedenle canlı posta kutusunda teşhis amacıyla DELE çalıştırılmamalıdır. Ekran görüntüsündeki işlem yalnızca özgün laboratuvarı belgelemek amacıyla korunuyor.
DELE 1 # Eski laboratuvar örneği; üretimde çalıştırmayın QUIT
Günümüzde güvenli bağlantı testi nasıl yapılır?
Önce TCP bağlantısının kurulup kurulamadığını PowerShell ile kontrol edebiliriz. Bu test herhangi bir kullanıcı parolası göndermez ve sunucudaki POP3 hizmetini otomatik olarak etkinleştirmez.
Test-NetConnection -ComputerName posta-sunucusu.example -Port 995 Test-NetConnection -ComputerName posta-sunucusu.example -Port 110 Test-NetConnection -ComputerName posta-sunucusu.example -Port 25 Test-NetConnection -ComputerName posta-sunucusu.example -Port 587
Buradaki TcpTestSucceeded=True bilgisi yalnızca TCP el sıkışmasının tamamlandığını gösterir. TLS sertifikası, protokol yanıtları, kimlik doğrulama veya gerçek posta teslimi için ayrı testler gerekir. Port 110 açık diye bu porta parolayla bağlanmak doğru değildir.
TLS destekleyen bir istemcide port 995 üzerinden protokol yanıtını kontrol etmek için uygun ortamda OpenSSL kullanılabilir:
openssl s_client -connect posta-sunucusu.example:995 -servername posta-sunucusu.example -crlf
Bu bağlantıda sertifika zinciri ve sunucu adı doğrulaması da ayrıca kontrol edilmeli; bağlantı kurulması tek başına güvenli olduğu anlamına gelmemelidir. Port 110 üzerinde STARTTLS test edilecekse sunucunun bu özelliği gerçekten desteklediğinden ve TLS oturumunun başarıyla kurulduğundan emin olunmalıdır.
Exchange Server ve Exchange Online için durum
Şirket içi Exchange Server ortamlarında POP3/IMAP4 erişimi gereken sistemlerde servisler, sertifikalar ve posta kutusu izinleri birlikte yapılandırılmalıdır. Microsoft belgelerinde POP3 için 995/TLS ve 110 üzerinden STARTTLS seçenekleri yer alır. Ancak birçok kuruluş modern istemcilerde HTTP tabanlı Exchange protokollerini tercih eder.
Exchange Online tarafında ise POP ve IMAP için Basic Authentication kaldırılmıştır. Bu nedenle eski makaledeki USER ve PASS adımları Microsoft 365 posta kutularında kullanılamaz. Desteklenen uygulamalarda OAuth 2.0 tabanlı kimlik doğrulama gerekir. Eski POP3 ekran görüntülerini bugünün Exchange Online yapılandırması gibi değerlendirmemek gerekiyor.
Bu yöntemi özellikle protokolün nasıl çalıştığını göstermek için faydalı buluyorum. Üretim ortamında ise önce bağlantı, ardından TLS ve kimlik doğrulama, son olarak da gerçek posta akışı ayrı ayrı test edilmeli. Ayrıca bağlantı sorunu yaşandığında sadece posta sunucusuna değil aradaki güvenlik duvarı, DNS ve sertifika yapılandırmasına da bakılmalıdır.
