Gmail "Bu mesaj tehlikeli görünüyor" uyarısı ve gri listeleme: iki ayrı arızayı header ve log'dan teşhis etmek
Gmail'in kırmızı "tehlikeli" banner'ı bir kara-liste sorunu değil; neredeyse her zaman DMARC hizalama, taklit görünen display name veya From/Return-Path uyuşmazlığıdır. Gri listeleme ise normal bir 4xx yumuşak reddidir ve retry'niz doğruysa kendi kendine düzelir. İki arızayı "Orijinali göster" çıktısı, mail.log satırları ve swaks ile kesin olarak ayırıp gideriyoruz.
EvilMail Team16 Temmuz 202611 dk okuma
İki farklı arıza sürekli aynı cümlede birleşir: "Gmail bizi engelliyor." Ama biri okuma ekranında çıkan kırmızı "Bu mesaj tehlikeli görünüyor" banner'ı, diğeri alıcı sunucunun mesajı hiç kabul etmeden geri ittiği gri listeleme. Farklı yerlerde olurlar, farklı yerlerden teşhis edilirler ve tamamen farklı çözülürler. Kırmızı banner bir kara-liste meselesi değildir; neredeyse her zaman DMARC hizalama, taklit görünen bir display name ya da From/Return-Path uyuşmazlığıdır. Gri listeleme ise hata bile değildir; tasarımın kendisidir ve retry'niz doğruysa kendiliğinden düzelir. Paniğe kapılıp elle yeniden göndermek veya kuyruğu zorla tetiklemek işleri yalnızca kötüleştirir.
Aşağıda ikisini header çıktısı, mail.log satırları, postqueue ve swaks ile kanıta dayalı ayırıyor, sonra tam DNS kayıtları ve Postfix ayarlarıyla gideriyoruz. Tahmin yok.
İki ayrı arıza, tek panik: banner ≠ gri liste
Önce ayrımı netleştirelim, çünkü yanlış teşhis yanlış çözümü getirir.
Gmail "Bu mesaj tehlikeli görünüyor" ve Gri Listeleme Teşhisi | evilmail.pro — EvilMail Blog
Kırmızı "tehlikeli" banner
Gri listeleme
Nerede olur
Mesaj Gmail kutusuna girmiştir
Mesaj alıcı MTA'ya hiç ulaşmamıştır
Ne olur
Okuma ekranında uyarı bandı çıkar
4xx ile ertelenir, gönderende kuyrukta bekler
Nereden görürsün
Gmail arayüzü + "Orijinali göster"
Kendi mail.log / postqueue çıktın
Kök neden
Kimlik/içerik sezgisi, DMARC hizalama
Alıcı MTA'nın triplet politikası
Çözüm
DMARC/hizalama/display name düzelt
Retry'e uy, sabret, whitelist
Kritik nokta: banner çıktıysa kimlik doğrulaman zaten geçmiştir ki mesaj kutuya girsin — sorun içerik ve tutarlılık katmanında. Gri listede ise henüz DATA aşamasına bile gelmedin. Bu yüzden "SPF kaydımı düzelttim ama banner hâlâ çıkıyor" ile "DMARC ekledim ama hâlâ deferred" tamamen farklı hikâyelerdir.
"Orijinali göster" ile teşhis: Authentication-Results satırı
Banner teşhisi Gmail'in kendi arayüzünde başlar. Mesajı aç, üç nokta menüsü > Orijinali göster. En üstteki Authentication-Results bloğu her şeyi anlatır:
`spf=pass ... [email protected]` — Return-Path (zarf gönderen) domaini kanıtlanmış. SPF hizalaması için bu domainin header.from domaini ile eşleşmesi gerekir.
`dkim=pass ... header.d=evilmail.pro header.s=default` — imza geçerli. DKIM hizalaması için imzayı atan d= (burada header.d) domaininin header.from ile eşleşmesi gerekir.
`dmarc=pass ... header.from=evilmail.pro` — DMARC en az bir hizalı pass gördü. Ama parantez içindeki `p=NONE` kritik: politika "hiçbir şey yapma" diyor.
SPF veya DKIM'den en az biri hem pass hem de From ile hizalı olursa DMARC geçer. relaxed hizalamada organizational domain eşleşmesi (ör. mail.evilmail.pro ile evilmail.pro) yeter; strict hizalamada birebir eşleşme şarttır. p=none durumunda kimlik doğrulanır ama Gmail'e "bu domaini taklit eden mesajları bize bildir ve kısıtla" sinyali gitmez — banner riskinin büyüdüğü yer tam burasıdır.
Kırmızı banner neden çıkıyor: hizalama, taklit ad, From/Return-Path uyuşmazlığı
Auth geçmesine rağmen banner çıkıyorsa, gerçek tetikleyiciler şunlardır:
`p=none` politikası. Auth var, güven yok. Gmail hizalamayı görür ama domain sahibinin taklidi ciddiye aldığına dair politika sinyali göremez. En az p=quarantinee çıkmak banner olasılığını belirgin düşürür.
Taklit görünen display name."PayPal Destek" <[email protected]> gibi bir From, Gmail'in phishing sezgisini doğrudan tetikler. Marka veya kişi adı taklit eden display name, teknik olarak her şey geçse bile banner sebebidir.
From/Return-Path farklı domainlerde. ESP veya mailing list üzerinden gönderirken From: [email protected] ama Return-Path: [email protected] olması SPF hizalamasını bozar. DKIM de hizalı değilse DMARC birlikte düşer.
Domain yaşı ve ilk temas. Yeni yayınlanmış domain artı alıcıyla ilk kez yazışma; itibar sinyali yokken temkinli davranış getirir.
Gövde sinyalleri. IP-literal linkler (http://203.0.113.10/...), kısaltılmış URL'ler, tek görsel artı sıfır metin gibi klasik phishing kalıpları.
Bunu spam'den ayırt et: banner, mesaj kutudayken çıkar. Doğrudan spam klasörüne düşmek ayrı bir karardır (genelde itibar artı içerik ağırlıklı). Aşağıdaki karar haritası, güvenin hangi katmanda kırıldığını gösteriyor:
DNS tarafını sağlama alma: SPF, DKIM, DMARC, PTR ve FCrDNS
Banner'ı kalıcı çözmek için üç kaydın da hem geçerli hem hizalı olması gerekir. evilmail.pro örneğiyle tam kayıtlar:
dns
; SPF — sert -all, sadece kendi mail çıkışın
evilmail.pro. IN TXT "v=spf1 ip4:203.0.113.10 -all"
; DKIM — selector 'default'
default._domainkey.evilmail.pro. IN TXT "v=DKIM1; k=rsa; p=MIGf..."
; DMARC — quarantine + strict hizalama + raporlama
_dmarc.evilmail.pro. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=s; aspf=s; pct=100"
dig -x çıktısındaki isim, HELO/EHLO adınla ve o adın A kaydının tekrar aynı IP'ye çözülmesiyle eşleşmeli — buna forward-confirmed reverse DNS (FCrDNS) denir. Eşleşmezse birçok MTA seni daha ilk elden cezalandırır.
DMARC'ı `p=none; rua=...` ile başlat, birkaç gün rapor topla, hizalama temizse p=quarantinee, sonra p=rejecte çık. adkim=s; aspf=s strict hizalama ister; ESP kullanıyorsan önce relaxed (varsayılan) ile başla. Bonus güven sinyalleri: MTA-STS, TLS-RPT ve marka için BIMI. Ve Google Postmaster Tools (postmaster.google.com) — domain/IP reputation ve spam oranını orada izle; hedef %0.3'ün altı.
2024 sonrası Gmail toplu gönderen kuralları bunu zaten zorunlu kılıyor: SPF artı DKIM artı DMARC şart, List-Unsubscribe-Post ile tek tıkla abonelikten çıkış ve spam oranı %0.3 altı.
Şimdi tamamen farklı bir arıza. Gri listede Gmail arayüzünde görülecek hiçbir şey yok — kanıt seninmail.log'unda:
text
postfix/smtp[2211]: A1B2C3: to=<[email protected]>,
relay=mx.corp.example[203.0.113.9]:25, delay=2.1, delays=0.3/0/1.5/0.3,
dsn=4.7.1, status=deferred (host mx.corp.example said:
451 4.7.1 Greylisting in effect, please come back later
(in reply to RCPT TO command))
Alıcı taraf (genelde Postgrey) her yeni bağlantıyı bir triplet ile tanır: (client IP, zarf gönderen, zarf alıcı). İlk kez görülen triplet 451 4.7.1 ile geri çevrilir ve varsayılan 300 saniye bekletilir. Meşru bir MTA bu süre dolunca tekrar dener; ikinci denemede triplet tanıdık olduğu için 250 ile kabul edilir ve o üçlü otomatik whitelist'e alınır. Spam gönderenlerin çoğu retry yapmaz — mantığın tamamı budur. dsn=4.7.1 ve 451 = geçici. 550/5.x.x görüyorsan bu gri liste değil kalıcı redtir; retry onu düzeltmez, ikisini karıştırma.
Retry'yi doğru ayarlamak (ve yapılmaması gerekenler)
Gönderen tarafında gri listeyi "çözmezsin"; ona uyumlu davranırsın. Postfix main.cf backoff parametreleri:
`postqueue -f` ile tüm kuyruğu zorla tetikleme. Her flush yeni bir deneme sayılır; alıcı rate-limit veya gri liste sertleşmesiyle cevap verir. Kuyruğu kendi haline bırak.
Retry'yi kısaltıp saldırgan hale getirme. 30 saniyede bir denemek, birçok alıcıda "come back later" penceresinin altında kalır ve boşa gider.
Her denemede farklı IP'den çıkma. Triplet'in IP bileşeni değişirse üçlü asla tamamlanmaz. Çıkış IP'ni sabit tut, gönderen adresini de sabitle.
Yeni IP'yi warm-up etmeden hacim basma. Hacmi kademeli artır.
Alıcı taraf sen isen, bilinen partnerleri Postgrey'de muaf tut:
bash
# /etc/postgrey/whitelist_recipients (bu alıcılara gelenler gri listelenmez)
# /etc/postgrey/whitelist_clients (bu IP/host'lardan gelenler muaf)
swaks ile uçtan uca üretip doğrulama
Tahmin etme, SMTP oturumunu kendin kur. swaks gri listeyi canlı gösterir:
Gmail'e attığın testi "Orijinali göster" ile aç ve dmarc=pass ... header.from=evilmail.pro görene kadar döngüyü tekrarla. Gri liste testinde ilk 451'i, ardından ikinci denemedeki 250'yi kendi gözünle görürsün — kanıt tam olarak budur.
Hızlı teşhis kontrol listesi
1.Ayrımı yap: Mesaj kutuda mı (banner) yoksa hiç ulaşmadı mı (gri liste)? Yanlış teşhis, yanlış çözüm demektir.
2.Banner ise Gmail'de "Orijinali göster" > Authentication-Results satırını oku.
3.spf=passvesmtp.mailfrom domaini header.from ile hizalı mı? Değilse Return-Path'i düzelt.
4.dkim=passved= domaini From ile eşleşiyor mu? Değilse imzalamayı düzelt.
5.dmarc=pass ama p=NONE mı? En az p=quarantinee çık.
6.Display name bir marka/kişi taklit ediyor mu? Temizle.
7.dig ile SPF -all, DKIM selector ve DMARC kaydını doğrula; dig -x ile FCrDNS'i kontrol et.
8.Gri liste ise grep -iE 'greylist|451 4.7.1|deferred' /var/log/mail.log ve postqueue -p ile teyit et; 4xx mı 5xx mi ayır.
9.Postfix backoff parametrelerini kontrol et; kuyruğu zorla tetikleme, sabit IP artı sabit gönderenle bekle.
10.Google Postmaster Tools'a domaini ekle; spam oranını %0.3 altında tut, swaks ile dmarc=pass görene kadar test et.
Banner bir güven sorunudur, gri liste bir zamanlama sorunudur. İkisini ayırdığın an ikisini de çözersin.
