# E-posta Kuyruğunun Patlaması: TLS Politikası Değişikliğinden Sonra Postfix Gönderim Hatası - Bağlantı: https://musti.org/guncel-teknoloji/eposta-kuyruk-tls-politikasi-postfix-gonderim-hatasi/ - Yayımlanma: 2026-09-30T08:42:54+03:00 - Yazar: mmutlu 🎧 Bu yazıyı dinleyebilirsiniz Tarayıcınız ses oynatmayı desteklemiyor. Hafta ortasında, sabah kahvemi içerken posta sunucumuzun beklenenden çok daha fazla e-posta kuyruğu ürettiğini fark ettim. Normalde birkaç yüz mesajı rahatça işleyen Postfix, bir anda binlerce “deferred” (gecikmiş) ve “bounce” mesajıyla dolmuştu. IT altyapıda sık görülmeyen ama etkisi hissedilen sorunlardan biriydi; kullanıcılar gönderim hatası alıyor, iş akışları bloke oluyordu. Aşağıda bu durumun nasıl ortaya çıktığını, adım adım nasıl tespit edip çözdüğümü ve sonrası için hangi önlemleri aldığımızı anlatıyorum. ## Sorunun Ortaya Çıkışı Gözlem: Gönderilen e-postaların büyük kısmı alıcı tarafında reddediliyor veya teslim edilmeden kuyruğa düşüyordu. Destek hattından gelen şikâyetler; özellikle dışa gönderilen faturalarda ve sistem uyarılarında gecikmeler vardı. Mail loglarında kısa süre içinde tekrarlayan TLS/TLS handshake hataları görünüyordu. Çevre: Postfix (Linux), önünde bir antispam/antivirus appliance ve Let’s Encrypt ile yenilenen sertifika zinciri. Gece yarısı otomatik bir güvenlik güncellemesi ( openssl + cipher policy) ve aynı zamanda TLS politikamızda bir sıkılaştırma (zayıf şifreleri yasaklama) uygulanmıştı. ## Teshis: İlk Kontroller İlk işim sistem durumunu hızlıca özetlemek oldu: posta kuyruğu büyüklüğü, CPU/RAM, disk I/O ve disk doluluk. Ardından mail loglarını gerçek zamanlı izledim. ``` sudo tail -n 200 /var/log/maillog ``` Loglarda sıkça aşağı benzeri satırlar gördüm: “TLS is required, but peer does not support TLS” veya “SSL_connect: error:1408F10B:SSL routines:ssl3_get_record:wrong version number”. Bu TLS el sıkışma (handshake) sorununa işaret ediyordu. ## Teshis: Kuyruk İçeriğine Bakmak Kuyrukta bekleyen mesajları inceledim. ``` postqueue -p | head -n 50 ``` Burada hedef MX’e bağlanırken zaman aşımı/RCPT/SMTP hatası veren adresleri gördüm. Hedef domain’lere karşı bağlantı testleri yaparak el sıkışma sürecini doğruladım: ``` openssl s_client -starttls smtp -crlf -connect mx.hedefdomain.com:25 -servername mail.miz.com ``` Testlerde bazı sunucularla TLS bağlantısı kurulurken, bazılarında sertifika zinciri hatası veya hiç TLS başlamadan bağlantı kesiliyordu. Özellikle eski antispam/legacy sistemlere sahip birkaç büyük sağlayıcı ile görüşmede problemlerin yoğunlaştığını gördüm. ## Teshis: Değişiklikleri Geri İzleme Son yapılmış paket güncellemelerini ve config değişikliklerini inceledim (yum/apt history, /etc/cron.daily, konfig değişiklikleri için git/ansible kayıtları). Aynı gece otomatik olarak uygulanan “cipher policy” kuralının bazı eski TLS sürümlerini ve SNI davranışını etkilediğini tespit ettim. Ayrıca sertifika zincirinde Let’s Encrypt’in ara sertifikası tam yüklenmemişti; bazı alıcılar zinciri doğrulayamayınca bağlantıyı düşürüyordu. ## Çözüm — Adım Adım 1) Kısa süreli rahatlama: İlk olarak posta kuyruğunun daha da büyümesini engellemek için outbound hızını sınırladım ve kritik mesajların önceliklendirilmesini sağladım. Postfix’te transport/always_bcc gibi ağır operasyonları tetiklemeyecek şekilde yapılandırmayı geçici değiştirdim. ``` # geçici hız sınırlama (örnek) postconf -e 'smtp_destination_rate_delay = 2s' postfix reload ``` 2) Sertifika zincirini düzelttim: Let’s Encrypt için fullchain.pem dosyasını kontrol edip doğru ara sertifikayı ekledim ve Postfix’in ssl_cert dosyasına gösterdim. Sonra Postfix’i yeniden başlattım. ``` postfix stop cp /etc/letsencrypt/live/miz.com/fullchain.pem /etc/postfix/certs/fullchain.pem cp /etc/letsencrypt/live/miz.com/privkey.pem /etc/postfix/certs/privkey.pem chmod 600 /etc/postfix/certs/* postfix start ``` 3) TLS politikası değişikliğini kademeli geri çekme: Güvenlik ekibiyle koordine ederek sıkılaştırılmış cipher listelerini geçici olarak gevşettik. Hedef MX’lerle TLS uyumluluk testleri (openssl s_client ve swaks) yaptım; uyumsuz sunucular için daha yumuşak bir profil açtık ve iletişimi sürdürdük. ``` # openssl ile test örneği openssl s_client -starttls smtp -connect mx.hedef.com:25 -cipher 'HIGH:!aNULL' -crlf ``` 4) Kuyruğun temizlenmesi: Önce başarısız olan, ama yeniden denenebilecek olan mesajları yeniden kuyruğa aldım; açıkça hatalı/bounce olması gerekenleri uygun şekilde işaretledim. Büyük hacimli gereksiz bekleyen öğeleri temizlerken dikkatli davrandım. ``` # sadece deferred mesajları yeniden dene postfix flush # çok sayıda gereksiz mesaja manuel müdahale gerekiyorsa postsuper -d ALL deferred ``` 5) İletişim: Büyük alıcı sağlayıcılarla (özellikle zincir doğrulaması yapanlar) doğrudan iletişime geçtik; onların tarafında bir sıkı TLS zorunluluğu veya SNI beklentisi olup olmadığını teyit ettik. Partnerlerimizin çoğu kısa süre içinde uyum sağladı. ## Alınan Dersler * Değişiklikleri kademeli dağıt: TLS/cipher policy gibi kritik güvenlik değişikliklerini önce birkaç test hedefi ve küçük üretim diliminde deneyin. * Sintetik testler kur: Her sabah otomatik bir “canary” e-posta gönderimi olsun; hem teslimat hem de TLS el sıkışma testi yapsın. Sorun olduğunda alarm üretsin. * Rollback planı zorunlu: Her değişiklik için net ve hızlı uygulanabilir geri alma adımları olsun; otomatik rollback mümkünse daha güvenli. * Log’ları yorumlama pratiği: Maillog kısa mesajlarından TLS el sıkışma hatasını ayırabilmek hayat kurtarıyor — “wrong version number” ile “peer does not support TLS” farklı sebeplere işaret eder. * Partner havuzu yönetimi: Büyük hacimli dışa gönderim yapan sistemlerde alıcı taraf davranışları heterojendir; sıkı security kuralları bazı eski zincirlerle uyumsuz olabilir. Kapanışta küçük bir not: Teknik olarak hatayı bulmak keyifli ama gece yarısı posta kuyruğunu temizlemek insanı uykusuz bırakıyor — bir yanda log analizi, diğer yanda destekten gelen panik mesajları; sonuçta hep birlikte koşturduk ve sistemi tekrar normal akışına döndürdük. Sonrasında devops pipeline’ımıza küçük bir test adımı ekledim: her TLS konfig değişikliğinden sonra otomatik olarak 10 popüler MX ile el sıkışma testi yapılıyor artık. Bu olay, küçük bir konfigürasyon değişikliğinin bile iş süreçlerini ne kadar hızlı etkileyebileceğini tekrar hatırlattı.