Büyük Kampanyaları ISP Throttling'e Takılmadan Dağıtmak: Postfix ile Per-ISP Pacing
Throttling tek seferde çözülen bir itibar sorunu değil, her alıcı domain için ayrı çalıştırdığınız kapalı bir kontrol döngüsüdür. Sabit concurrency ile blast atmayı bırakın, 4xx deferral'ı hata değil geri bildirim sinyali olarak okuyun ve trafiği Postfix transport'larıyla ISP başına şekillendirin.
EvilMail Team16 Temmuz 202613 dk okuma
Kampanya kuyruğunda 400.000 mesaj var, MTA'yı açtınız, ilk on dakika harika gidiyor. Sonra log'da 421'ler belirmeye başlıyor, kuyruk şişiyor, panikle "IP yandı" diye düşünüyorsunuz. Yanmadı. ISP size düz Türkçe konuşuyor: "Bu hızda alamıyorum, yavaşla." Sorun IP itibarınız değil, sabit concurrency ile her alıcı domain'e aynı basıncı uygulamanız.
Throttling, tek seferde "çözülen" bir itibar meselesi değildir. Her büyük alıcı domain için ayrı ayrı çalıştırdığınız bir geri besleme döngüsüdür. Gmail'in 10 eşzamanlı bağlantıda sorunsuz kabul ettiğini Yahoo 421 ile geri çevirir; tek bir global default_destination_concurrency_limit ile ikisini birden memnun edemezsiniz. Pacing'i klişe ("IP'ni ısıt, itibarına dikkat et") yerine log'dan doğrulanabilir, ölçülebilir bir mühendislik problemi olarak ele almak gerekir.
Deferral bir hata değil, sinyaldir: 4xx'i doğru okumak
SMTP dönüş kodlarını üç kovaya ayırın ve bu ayrımı asla bulanıklaştırmayın:
2xx (250) — kabul. Mesaj alıcının kuyruğuna girdi.
En pahalı hata bir 4xx'i 5xx gibi işleyip alıcıyı listeden atmaktır. Geçici bir rate-limit deferral'ını "hard bounce" sanan bir sistem, birkaç kampanyada temiz aboneleri eritir ve sonra "listem neden küçülüyor" diye şaşırır. Deferral kaybedilen adres değildir; geciken adrestir.
4xx'in içindeki nüansı okumak işin özü. Aynı 421 kodu farklı sebeplerden gelir:
Greylisting — ilk denemeyi reddet, retry'da kabul et. Tek yapmanız gereken sabırlı retry.
Connection/rate limit — çok fazla bağlantı veya çok hızlı gönderim. Basıncı azaltın.
Complaint-based defer — abuse sinyali. Bu bir teknik ayar sorunu değil, içerik/liste sorunudur; hızı düşürmek semptomu maskeler ama kök nedeni çözmez.
Büyük ISP'lerin döndürdüğü gerçek mesajları tanıyın, çünkü doğru tepki koda gömülüdür:
text
Gmail: 421-4.7.28 [1.2.3.4] Our system has detected an unusual rate
of unsolicited mail originating from your IP address. Please
try again later.
Yahoo/AOL: 421 4.7.0 [TSS04] Messages from 1.2.3.4 temporarily deferred
due to user complaints
Microsoft: 451 4.7.500 Server busy. Please try again later.
Microsoft: 421 4.7.0 ... temporarily rate limited
Gmail'in 4.7.28'i saf hacim/itibar sinyalidir — pacing'i düşürünce düzelir. Yahoo'nun [TSS04]'ü complaint temellidir; concurrency'yi kısmak deferral oranını düşürür ama asıl mesajınız "bu listeye vurmayı kes" demektir. Microsoft'un 451 4.7.500'ü genelde ani hacim sıçramasına verilen anlık tepkidir ve backoff ile hızla açılır. Aynı reçete üçüne de uymaz.
Trafiği ISP başına ayırın: Postfix transport'ları
Tek global kuyruk, tek global geri besleme demektir. Gmail'e uygun agresif ayar Yahoo'yu boğar; Yahoo'ya uygun temkinli ayar Gmail throughput'unu ziyan eder. Çözüm trafiği alıcı domain'e göre ayrı transport'lara bölmek, böylece her ISP'nin kendi concurrency'si, kendi rate'i ve kendi syslog etiketi olur.
master.cf içinde her büyük alıcı için özel bir SMTP client servisi tanımlayın:
Artık postfix-gmail, postfix-yahoo, postfix-ms log satırlarını syslog_name ile ayrı ayrı süzebilir, her ISP'nin deferral oranını bağımsız ölçebilir ve o metriğe göre yalnızca o transport'un parametresine dokunabilirsiniz. Ayrı kuyruklar, ayrı düğmeler.
İki düğme: concurrency mi, rate_delay mi?
Postfix'te gönderim basıncını iki parametre belirler ve bunları karıştırmak en yaygın tuning hatasıdır.
`smtp_destination_concurrency_limit` — aynı hedefe aynı anda kaç paralel bağlantı. Throughput'u genişletir.
`smtp_destination_rate_delay` — aynı hedefe iki gönderim arasındaki minimum bekleme. Hızı sıkar.
Kritik kural: `rate_delay` set edildiği an, o hedefin concurrency limiti zorla `1`'e düşer. İkisi birlikte çalışmaz — rate_delay tanımı gereği seri (tek bağlantı) gönderim demektir. rate_delay=2s, transport başına kabaca saatte 1800 mesaj tavanı koyar. concurrency=5 yazıp tek bağlantı görünce şaşırmak tam olarak buradan gelir.
Postfix'in genelde göz ardı edilen bir üstünlüğü var: 4xx aldıkça concurrency'yi kendi başına kısar. Adaptif mekanizmanın gerçek default'ları:
Mantık şu: Postfix initial_destination_concurrency=5 ile başlar. Bir "cohort" (bir tur bağlantı) tamamen başarısız olursa (failed_cohort_limit=1), hedefi geçici ölü sayar ve concurrency'yi düşürür (negative_feedback). Başarılı gönderimlerde yavaşça yukarı çıkar (positive_feedback). Yani motor zaten bir kontrolcü; sizin işiniz tavanı (concurrency_limit) ISP'ye göre makul koymak ve agresif ISP'lerde tabanı rate_delay ile sabitlemek.
Pratik karar: yüksek hacim + toleranslı ISP (Gmail) → concurrency ile genişlet. Agresif rate-limit'li ISP (Yahoo, complaint hassasiyeti yüksek) → rate_delay ile serileştir ve yavaşlat.
Gerçek limitler: Gmail, Yahoo/AOL, Microsoft
Rakamlar başlangıç değeridir; nihai değer sizin IP itibarınıza göre oturur. Ama davranış kalıpları sabittir:
Gmail — bağlantı yeniden kullanımını sever. smtp_connection_reuse_time_limit=300s ve smtp_connection_cache_on_demand=yes ile tek TCP oturumunda çok mesaj gönderin; Gmail bunu itibar için olumlu okur. Concurrency 10-20 arası tolere edilir. 4.7.28 görürseniz sorun bağlantı sayısı değil, gönderim itibarı/hacim eğrisidir.
Yahoo/AOL — complaint sinyaline sert tepki verir. [TSS04] gördüğünüz an concurrency'yi 3-5'e çekin, rate_delay=2s koyun ve asıl olarak Complaint Feedback Loop verinize bakın. Yahoo'da teknik pacing, kirli listeyi kurtarmaz.
Microsoft (Outlook/Hotmail/Live) — ani hacme aşırı hassas. Düşük concurrency (3) ile başlayın; 451 4.7.500 bir felaket değil, backoff'un doğru çalıştığının işaretidir. Rampayı yavaş tutun, SNDS'te IP durumunuzu "green" görene kadar zorlamayın.
Bağlantı yeniden kullanımı throttling'i doğrudan azaltır: her mesaj için yeni TCP+TLS el sıkışması hem yavaştır hem de ISP'ye "bağlantı seli" gibi görünür. smtp_connection_cache_on_demand=yes bunu büyük ölçüde çözer.
Warmup ve pacing takvimi
Pacing'den önce kimlik doğrulama gelir. Bunlar oturmadan hız ayarı yapmak, delik teknede kürek çekmektir:
SPF pass veriyor olmalı.
DKIM 2048-bit anahtarla imzalanmalı.
DMARCp=quarantine veya p=reject, ve rua ile raporlama açık.
Bunlar tamam ise IP ve domain itibarını ayrı ayrı ısıtırsınız — çünkü ISP'ler ikisini ayrı izler. Yeni bir IP'den yeni bir domain gönderiyorsanız iki bilinmeyen birden var; rampayı buna göre temkinli tutun. ISP başına günlük cap örneği:
text
Gün 1: 50 Gün 8: 5.000
Gün 2: 100 Gün 12: 20.000
Gün 3: 250 Gün 20: 100.000
Gün 5: 1.000 Gün 30: tam hacim
Her adım yalnızca bir önceki günün deferral + complaint oranı temizse ilerler. Deferral fırlarsa o günü tekrarlayın, atlamayın.
Kampanya günü içinde de aynı prensip: 09:00'da tüm hacmi tek sivri tepede boşaltmak (peaked blast) Yahoo ve Microsoft'ta anında 421 tetikler. Aynı hacmi gün boyu düz bir plato olarak yayın — toplam sayı aynı, ama anlık basınç ISP eşiğinin altında kalır.
Kontrol döngüsünü kapatın: ölçüm ve geri besleme
Pacing'i "his" ile değil, log'dan gelen metrikle ayarlarsınız. Deferral oranını canlı çıkarın:
bash
# Hangi relay defer ediyor, kaç kez?
grep 'status=deferred' /var/log/mail.log \
| grep -oE 'relay=[^ ]+' | sort | uniq -c | sort -rn
# Toplam 421 sayısı (ani sıçrama = throttle başladı)
grep -c '421' /var/log/mail.log
# Günlük özet, deferral bölümü
pflogsumm -d today /var/log/mail.log | grep -iA5 deferr
syslog_name sayesinde bunu transport bazında daraltabilirsiniz — grep 'postfix-yahoo' | grep -c 421 size yalnızca Yahoo'nun basıncını verir. Kural basit: bir transport'un deferral oranı belirlediğiniz eşiği (örneğin %5) aşarsa, o transport'un concurrency'sini bir kademe düş veya rate_delay ekle, log temizlenince yavaşça geri aç. Bu, döngünün insan eliyle işletilen versiyonu; olgunlaştığında bir cron script'i deferral oranını okuyup postconf/postmap ile parametreyi otomatik oynatır. evilmail.pro'da yüksek hacimli kampanya trafiğini böyle bir per-ISP shaper'dan geçirip pacing'i canlı deferral metriğine bağlıyoruz.
ISP'lerin kendi paneli, log'un göremediğini gösterir:
Google Postmaster Tools — domain + IP reputation, spam rate. Gmail'in 2024+ toplu gönderici kuralı net: spam oranı %0.3'ü aşarsa hard throttle; hedefiniz %0.1 altı.
Microsoft SNDS + JMRP — IP durum rengi ve complaint akışı.
Yahoo CFL — Complaint Feedback Loop kaydı; [TSS04]'ün arkasındaki gerçek şikayet oranını buradan görürsünüz.
Backoff testi: küçük bir test batch ile 421 aldığınızda Postfix'in gerçekten yavaşladığını log'dan doğruladınız.
Throttling'i bir kez "çözemezsiniz" — onu izler, okur ve her ISP için ayrı ayrı yönetirsiniz. Sabit concurrency ile blast atan bir gönderici her zaman duvara toslar; deferral'ı sinyal olarak okuyan bir gönderici duvarın nerede olduğunu her kampanyada yeniden öğrenir.
