E-posta Gönderim Zamanlaması ve Throttling

Yeni kurduğun sunucudan üç bin kişilik bir listeye bülten gönderdin ve ilk yüz mesajdan sonra kuyruk tıkandı. Loglar 421 4.7.0 ve 450 4.7.1 satırlarıyla doldu, teslim edilenlerin bir kısmı spam klasöründe. İlk refleks genellikle "eşzamanlılığı artırayım, daha hızlı bitsin" olur — ve durumu tam olarak kötüleştiren şey de budur. E-posta gönderim zamanlaması ve throttling, mesajları hızlı göndermekle değil, karşı tarafın kabul edebileceği hızda göndermekle ilgilidir.

Bu rehberde alıcı sunucuların neden hız sınırı uyguladığını, Postfix'in giden trafiği nasıl frenlediğini, hedef bazlı transport tanımlarıyla Gmail'e ve diğer büyük sağlayıcılara ayrı hız verilmesini, yeni bir IP'nin ısıtma planını ve 4xx erteleme kodlarının nasıl okunacağını anlatacağım. Ayrıca gelen trafiğe hız sınırı koymayı ve ele geçirilmiş bir hesabın sunucuyu kara listeye sokmasını engelleyen kullanıcı bazlı limitleri de ele alacağım.

Alıcı Sunucular Neden Fren Yapar#

Bir alıcı sunucu için bilinmeyen bir IP'den gelen ani mesaj yığını, tanım gereği şüphelidir. Meşru bir kurumsal sunucu genellikle dengeli ve öngörülebilir hacimde gönderir; spam kaynakları ise kısa sürede maksimum hacmi geçirmeye çalışır. Bu yüzden büyük sağlayıcılar hem IP hem alan adı bazında bir itibar puanı tutar ve hacmin bu puana göre ölçeklenmesini bekler.

Fren, kalıcı bir ret olarak değil, geçici erteleme olarak uygulanır. Gördüğün 4xx kodları "bu mesajı kabul etmiyorum" değil, "şimdi değil, sonra tekrar dene" anlamına gelir. Bu ayrım kritik: 4xx alan bir mesaj kaybolmaz, kuyrukta bekler ve tekrar denenir.

Bir 4xx yığını gördüğünde yapılacak ilk şey hızı azaltmaktır. Aynı hedefe daha fazla eşzamanlı bağlantı açmak, alıcının hız korumasını daha sert tetikler ve bazı sağlayıcılarda geçici erteleme kalıcı engellemeye dönüşür.

Postfix'te Giden Hız Kontrolü#

Postfix'in giden trafiği kontrol eden dört ana parametresi var ve hepsi "hedef" (destination) başına uygulanır. Hedef burada genellikle alıcı alan adı demektir.

# /etc/postfix/main.cf

# Aynı hedefe iki teslimat arasındaki asgari bekleme
default_destination_rate_delay = 0s

# Aynı hedefe aynı anda kaç bağlantı açılabilir
default_destination_concurrency_limit = 20

# Tek mesajda aynı hedefe kaç alıcı gönderilebilir
default_destination_recipient_limit = 50

# Yeni bir hedefe başlarken kaç bağlantıyla başlanır
initial_destination_concurrency = 5

default_destination_rate_delay sıfırdan büyük bir değer aldığında Postfix o hedefe teslimatları sıraya sokar; bu parametreyi kullandığında eşzamanlılık limitini de 1 yapman gerekir, çünkü ikisi birlikte anlamlıdır. Genel varsayılanları düşürmek yerine, yavaşlatmak istediğin hedefe özel bir taşıma (transport) tanımlamak çok daha isabetli bir yaklaşımdır.

Önce master.cf içinde adlandırılmış bir SMTP taşıması oluştur:

# /etc/postfix/master.cf
# Büyük sağlayıcılara özel, yavaş çalışan taşıma
yavas     unix  -       -       n       -       -       smtp

Sonra main.cf içinde bu taşımanın hızını sınırla ve transport_maps ile hangi alan adlarının bu yoldan gideceğini söyle:

# /etc/postfix/main.cf
yavas_destination_rate_delay          = 2s
yavas_destination_concurrency_limit   = 1
yavas_destination_recipient_limit     = 20

transport_maps = hash:/etc/postfix/transport

# /etc/postfix/transport
gmail.com         yavas:
googlemail.com    yavas:
outlook.com       yavas:
hotmail.com       yavas:
yahoo.com         yavas:

postmap /etc/postfix/transport
postfix reload

Bu yapıyla Gmail'e saniyede en fazla bir mesaj gider, geri kalan hedefler ise varsayılan hızda çalışmaya devam eder. Büyük sağlayıcıların güncel gönderici beklentilerini Gmail ve Yahoo yeni gönderici kuralları yazısında topladım; hız kadar kimlik doğrulama kayıtları da bu kararı etkiliyor.

Kuyruk ve Yeniden Deneme Davranışı#

Bir mesaj 4xx aldığında kuyrukta bekler ve Postfix onu artan aralıklarla tekrar dener. Bu aralıkları kontrol eden parametreler, throttling stratejisinin ikinci yarısıdır:

# İlk yeniden deneme aralığı
minimal_backoff_time = 300s

# Aralığın çıkabileceği üst sınır
maximal_backoff_time = 4000s

# Kuyruk tarayıcısının çalışma sıklığı
queue_run_delay = 300s

# Bir mesajın kuyrukta kalabileceği azami süre
maximal_queue_lifetime = 5d

# Hata bildirimlerinin kuyrukta kalma süresi
bounce_queue_lifetime = 1d

maximal_queue_lifetime süresi dolduğunda mesaj kalıcı olarak başarısız sayılır ve gönderene bildirilir. Toplu gönderimlerde bu değeri artırmak cazip gelir ama dikkatli ol: beş günden uzun süre kuyrukta bekleyen bir mesaj, alıcı için zaten anlamını yitirmiş olur.

Kuyruğun ne durumda olduğunu görmek için qshape en kullanışlı araçtır; hangi hedefin ne kadar mesajı ne kadar süredir beklettiğini yaş dilimleri hâlinde gösterir:

# Ertelenen kuyruğun hedef bazında yaş dağılımı
qshape deferred | head -20

# Kuyruktaki toplam mesaj sayısı
postqueue -p | tail -1

# Belirli bir mesajın içeriğini ve hata satırını gör
postcat -q A1B2C3D4E5

# Kuyruğu hemen boşaltmaya çalış (dikkatli kullan)
postqueue -f

postqueue -f komutunu bir hız aşımı sırasında çalıştırmak en kötü fikirlerden biridir: zaten seni yavaşlatan sunucuya biriken tüm mesajları aynı anda göndermeye çalışırsın. Erteleme kaynaklı gecikmelerin genel mantığını greylisting ve mail gecikmesi yazısında da bulabilirsin.

Yeni IP Isıtma Planı#

Taze bir IP adresinin hiçbir itibarı yoktur ve bu, "kötü itibar" ile neredeyse aynı muameleyi görmek demektir. Isıtma (warm-up), hacmi kademeli artırarak alıcı sağlayıcılarda olumlu bir geçmiş oluşturma sürecidir. Aşağıdaki plan tek bir IP'den kurumsal hacimli gönderim yapan bir sunucu için makul bir başlangıçtır; kendi hacmine göre ölçekle.

Isıtma sırasında uyman gereken üç kural var. Birincisi, listeyi kaliteye göre sırala: ilk günlerde yalnızca son altı ayda mesajlarını açmış adreslere gönder. İkincisi, hacmi bir günde iki katından fazla artırma. Üçüncüsü, sert bounce (5xx) oranı yüzde 2'yi ya da şikâyet oranı binde 3'ü geçtiğinde artışı durdur ve bir önceki seviyeye dön.

Isıtma boyunca SPF, DKIM ve DMARC kayıtlarının eksiksiz olması şart; bunlar olmadan hiçbir hacim planı işe yaramaz. Gönderim altyapını hesaplarken bant genişliği tarafını da unutma — büyük ekli bülten gönderimlerinde kaba bir tahmin için bant genişliği hesaplayıcısını kullanabilirsin.

Gelen Trafiğe ve Kullanıcılara Sınır Koymak#

Throttling yalnızca giden yön için değil. Postfix'in anvil servisi, tek bir istemcinin sunucuna ne kadar yük bindirebileceğini sınırlar ve sözlük saldırılarını maliyetli hâle getirir.

# /etc/postfix/main.cf
# Sayaçların sıfırlanma aralığı
anvil_rate_time_unit = 60s

# Bir istemcinin dakikada açabileceği bağlantı sayısı
smtpd_client_connection_rate_limit = 30

# Bir istemcinin dakikada gönderebileceği mesaj sayısı
smtpd_client_message_rate_limit = 30

# Bir istemcinin dakikada deneyebileceği alıcı sayısı
smtpd_client_recipient_rate_limit = 60

# Kendi ağını bu sınırların dışında tut
smtpd_client_event_limit_exceptions = $mynetworks

Asıl kritik olan ise kullanıcı bazlı giden limit. Bir hesabın parolası ele geçirildiğinde saldırgan senin sunucundan meşru kimlik doğrulamayla spam gönderir; sunucun dakikalar içinde kara listeye girer. Bunu engelleyen tek şey, hesap başına saatlik bir gönderim tavanıdır. Postfix bunu tek başına yapamaz; postfwd gibi bir politika servisiyle çözülür:

# /etc/postfix/main.cf
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10040

# postfwd kuralı: bir SASL kullanıcısı saatte en fazla 300 alıcıya gönderebilir
id=SASL_LIMIT
  sasl_username=~^(.+)$
  action=rate(sasl_username/300/3600/450 4.7.1 Gonderim limiti asildi)

Bu tek kural, ele geçirilmiş bir hesabın verebileceği zararı saatlik 300 alıcıyla sınırlar ve sana müdahale etmek için zaman kazandırır. Limitin aşıldığını loglarda görmek, aynı zamanda saldırının erken uyarısıdır. Güçlü parolalar bu riskin diğer yarısıdır; hesap parolalarını şifre üretici ile üretmeni öneririm.

Sık Yapılan Hatalar ve Tuzaklar#

Erteleme görünce eşzamanlılığı artırmak. En yaygın ve en zararlı refleks budur. 421 ve 450 kodları "yavaşla" demektir; daha fazla bağlantı açmak alıcının korumasını sertleştirir ve geçici erteleme kalıcı engellemeye dönüşebilir.

postqueue -f ile kuyruğu zorlamak. Biriken mesajları aynı anda göndermeye çalışmak, hız aşımının kendisini yeniden üretir. Kuyruk zaten kendi takvimine göre tekrar deniyor; bırak denesin.

Tüm hedeflere aynı hızı uygulamak. Küçük bir kurumsal alıcıya saniyede bir mesaj göndermek gereksiz yavaşlıktır, Gmail'e yirmi eşzamanlı bağlantı açmak ise fazla agresif. transport_maps ile hedef bazında ayrıştır.

Isıtmayı atlamak. Yeni bir IP'den ilk gün on bin mesaj göndermek, o IP'nin itibarını daha başlamadan bitirir. Isıtma planı bir formalite değil, sonraki aylardaki teslimat oranını belirleyen tek yatırımdır.

Kullanıcı bazlı limit koymamak. Giden hızını hedef bazında ne kadar iyi ayarlarsan ayarla, ele geçirilmiş tek bir hesap sunucunu kara listeye sokar. Hesap başına saatlik tavan, mail sunucusunun en yüksek getirili tek güvenlik ayarıdır.

Bounce'ları temizlememek. Sert bounce alan adresleri listenden çıkarmazsan her gönderimde aynı geçersiz adreslere yazmaya devam edersin. Yüksek bounce oranı doğrudan itibar kaybıdır. Gmail'e teslimatta bu etkiyi Gmail'e mail gitmiyor yazısındaki tanı adımlarıyla birlikte değerlendirebilirsin.

Sıkça Sorulan Sorular#

Postfix'te günlük gönderim limiti nasıl koyarım#

Postfix'in kendi içinde "günde en fazla N mesaj" biçiminde bir sayaç yoktur; hız kontrolü hedef başına gecikme ve eşzamanlılık üzerinden çalışır. Günlük ya da saatlik bir tavan koymak istiyorsan check_policy_service ile bir politika servisi bağlaman gerekir. postfwd gibi araçlar SASL kullanıcısı, gönderen adresi ya da istemci IP'si bazında sayaç tutup limit aşıldığında geçici ret döndürür.

421 4.7.0 hatası alıyorum, ne yapmalıyım#

Bu kod alıcı sunucunun geçici olarak seni yavaşlattığını söyler ve mesajın kaybolmadığı anlamına gelir; kuyrukta bekler ve tekrar denenir. Doğru tepki, o hedefe giden eşzamanlılığı düşürmek ve teslimatlar arasına gecikme koymaktır. Hata sürekli tekrar ediyorsa hacmin karşı tarafın senin IP'n için kabul ettiği seviyenin üstünde demektir; ısıtma planına bir adım geri dön.

IP ısıtma ne kadar sürer#

Hedef hacme bağlı olarak genellikle iki ile dört hafta arasında sürer. Günde birkaç yüz mesaj gönderen bir kurumsal sunucu için bir hafta yeterli olabilirken, günde on binlerce mesaj hedefleyen bir gönderim altyapısı için bir ay makul bir plandır. Kritik olan takvim değil, artış oranı: hacmi bir günde iki katından fazla artırmamak ve bounce ile şikâyet oranlarını her adımda kontrol etmek.

Throttling teslimat oranımı düşürür mü#

Aksine yükseltir. Yavaşlatmak, alıcı sunucuların koruma mekanizmalarını tetiklememeni sağlar; bu da daha az erteleme, daha az spam sınıflandırması ve zamanla daha iyi itibar demektir. Hızlı göndermenin tek kazancı toplam sürenin kısalması, kaybı ise mesajların hiç ulaşmamasıdır. Toplu gönderimlerde bir kampanyanın dört saat yerine sekiz saatte bitmesi, teslim edilmemesinden çok daha iyidir.

Aynı anda kaç bağlantı açmalıyım#

Varsayılan yirmi eşzamanlı bağlantı, tanıdık ve orta hacimli hedefler için makuldür. Büyük sağlayıcılara ise iki ile beş arası bağlantı, aralarına birer saniyelik gecikme koyarak yeterlidir. Doğru sayıyı deneyerek bulman gerekir: qshape deferred çıktısında belirli bir hedefte birikme görüyorsan o hedefin limitini düşür, hiç birikme yoksa mevcut ayar zaten uygundur.

Gönderim limitimi hangi araçla izlerim#

En temel araç mail loglarıdır; grep ile status=deferred satırlarını hedef bazında saymak, hangi sağlayıcının seni yavaşlattığını hemen gösterir. qshape deferred komutu aynı bilgiyi yaş dilimleriyle birlikte verir ve sorunun ne zaman başladığını anlamanı sağlar. Uzun vadede büyük sağlayıcıların gönderici araçlarına kendi alan adını kaydedip şikâyet oranını da izlemeni öneririm.

Kapanış#

Gönderim hızı, mail sunucusu yönetiminde sezgilerin en çok yanıldığı alandır: doğru cevap neredeyse her zaman yavaşlamaktır. Aklında tutman gereken dört alışkanlık şu — 4xx gördüğünde hızlanma, yavaşla; büyük sağlayıcılara ayrı bir transport tanımlayıp gecikmeyi orada uygula; yeni bir IP'yi mutlaka kademeli ısıt ve hacmi günde iki katından fazla artırma; kullanıcı başına saatlik gönderim tavanı koyarak ele geçirilmiş bir hesabın sunucunu kara listeye sokmasını engelle. Kuyruğu qshape ile düzenli izlemek de bu işin rutinine girmeli.

Kendi gönderim altyapını kurmak yerine bu ayarların hazır geldiği bir yapıyla başlamak istersen, SMTP sunucu paketlerimiz Postfix, DKIM ve rDNS kaydı tanımlı olarak teslim edilir. Düzenli bülten gönderiyorsan e-posta pazarlama tarafındaki liste hijyeni ve itibar yönetimi araçları bu işi kolaylaştırır; sunucunun kuyruk ve teslimat takibini devretmek istersen sunucu yönetimi hizmetimiz bu izlemeyi de üstlenir.