Şüpheli bir e-posta aldınız ve gerçekten nereden geldiğini anlamak istiyorsunuz. Başlığı açıyorsunuz ve Received, Authentication-Results ve Return-Path alanlarından oluşan karmaşık bir duvarla karşılaşıyorsunuz; hiçbiri From ile uyuşmuyor. Gerçek soru şu: hangi alana güvenilebilir ve hangisini herhangi bir gönderici istediği gibi yazabilir?
Kısa cevap: SMTP protokolü açısından, başlıktaki neredeyse hiçbir alanın "imzası" yoktur. Göndericinin kendisinin eklediği her şey sahte olabilir. Kanıt değeri taşıyan tek şey, ara sunucuların eklediği Received zinciri ve sizin alıcı sunucunuzun yazdığı kimlik doğrulama sonucudur.
E-posta başlığı tamamen farklı iki aileden oluşur
Başlık alanları RFC 5322'de tanımlanmıştır, ancak pratik kullanım açısından asla karıştırmamanız gereken iki kategoriye ayrılırlar.
- Yol alanları (trace fields):
Received,Return-Path,Authentication-Results. Bunları sunucular yazar ve sıralamaları anlamlıdır. - Mesaj alanları (message fields):
From,To,Subject,Reply-To,Date,Message-ID. Bunları gönderici yazar ve hiçbir garantileri yoktur.
Her hafta gördüğüm yaygın hata: birisi From: support@bank-x.ir görüyor ve e-postanın bankadan geldiği sonucuna varıyor. Bu alan sadece bir metin dizesidir. Hatta Reply-To bile tamamen alakasız bir alan adına işaret edebilir ve yanıtınız doğrudan saldırgana gidebilir.
Received zincirini aşağıdan yukarıya okuyun
Mesajı teslim alan her sunucu, başlığın üstüne bir Received satırı ekler. Yani son satır (en alttaki) kaynağa, ilk satır (en üstteki) sizin sunucunuza aittir. Yukarıdan aşağıya okursanız, yolu tersten kat edersiniz ve kaybolursunuz.
Received: from mail.example.com (mail.example.com [203.0.113.45])
by mx.servernet.cloud (Postfix) with ESMTPS id 4A2B1C3D
for <you@yourdomain.ir>; Tue, 14 Jan 2025 09:12:44 +0330Her satırda üç şeyi kontrol edin: bildirilen ana makine adı, köşeli parantez içindeki IP ve bu ikisinin eşleşme sonucu. Ana makine adı IP ile uyuşmazsa, alıcı sunucu genellikle unknown veya boş helo= kaydeder. Göndericinin iddiasını gerçek ağ durumuyla karşılaştırabileceğiniz tek yer burasıdır.
Çoğu kişinin gözden kaçırdığı nokta: güvendiğiniz son sunucunun üstündeki Received satırları tamamen sahte olabilir. Saldırgan, yolu daha uzun ve daha masum göstermek için başlığa birkaç uydurma satır ekleyebilir. Güven sınırı tam olarak kendi sunucunuzun yazdığı satırdır.
Authentication-Results güvenmeniz gereken tek alandır
Bu başlığı gönderici değil, alıcı sunucu ekler. Mesaj Gmail'den geldiyse şuna benzer bir satır görürsünüz:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.i=@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comÜç değer önemlidir ve önem sıralaması tam olarak şöyledir: dmarc, sonra dkim, sonra spf. Nedeni basittir. SPF yalnızca göndericinin IP'sini kontrol eder ve mesaj içeriğiyle ilgilenmez; saldırgan sizin yetkili sunucunuzdan gönderirse SPF geçer. DKIM, başlık ve gövde üzerindeki kriptografik imzadır, dolayısıyla içerik değiştirilmesini yakalar. DMARC bu ikisini From'da görüntülenen alan adına bağlar ve alan adı sahteciliğini engelleyen şey tam olarak budur.
dmarc=fail görüp spf=pass görüyorsanız, bu birinin sizin yetkili altyapınızı kullanarak başka bir alan adıyla gönderdiği anlamına gelir. Bu klasik mesaj yönlendirme (forward) kalıbıdır, illa saldırı değildir. Farkı header.from ile karşılaştırarak değerlendirin.
Burada hata yapıyorlar
En yaygın hata: gerçek göndericiyi tespit etmek için Return-Path'e güvenmek. Return-Path, SMTP zarfındaki MAIL FROM ile aynıdır ve From'dan tamamen bağımsız olarak ayarlanabilir. İşareti de şudur: spam raporlarında Return-Path alakasız bir alan adında görünür ama From sizin markanızın adını gösterir ve kullanıcı e-postanın sizden geldiğini düşünür. Return-Path yalnızca bounce ve DMARC raporlaması için kullanılır, kimlik için değil.
Pahalıya mal olan ikinci hata: katlanmış (folded) satırları doğru açmayan istemcilerle başlık okumak. Uzun başlıklar boşluk veya tab ile bir sonraki satıra kırılır. Aracınız bunu görmezden gelirse, DKIM imzasını eksik okur ve yanlış sonuca varır.
Hangi alanlara asla güvenmemelisiniz
| Alan | Kim yazar | Sahte olabilir mi? |
|---|---|---|
From | Gönderici | Evet, DMARC geçmedikçe |
Reply-To | Gönderici | Evet, tamamen |
Return-Path | Kaynak sunucu | Evet |
Message-ID | Gönderici | Evet, hiçbir geçerliliği yok |
Date | Gönderici | Evet, yıllarca geride olabilir |
Received | Her ara sunucu | Yalnızca güven sınırının üstündeki satırlar |
Authentication-Results | Alıcı sunucu | Hayır, kendi sunucunuzdan geldiyse |
Önemli bir istisna: Authentication-Results da güven sınırınızın üstündeyse sahte olabilir. Saldırgan uydurma bir dkim=pass satırı ekleyebilir. Bu başlığın, son Received'i kaydeden sunucu tarafından yazıldığını her zaman doğrulayın.
Pratik inceleme için ne yapmalıyız
Ham başlığı önizlemeden değil, istemciden alın. Gmail'de üç nokta menüsünden "Show original" seçeneğini, Thunderbird'de Ctrl+U tuşunu kullanın. Ardından yolu aşağıdan yukarıya doğru, kontrolünüz dışındaki ilk sunucuya ulaşana kadar takip edin.
Göndericinin alan adının gerçekten düzgün bir e-posta altyapısına sahip olup olmadığını anlamak istiyorsanız, önce MX kayıtlarını kontrol edin; MX kaydı sorgulama, alan adının arkasında gerçek bir sunucu mu yoksa sadece törensel bir kayıt mı olduğunu görmenin en hızlı yoludur. Spam'e giden ve nedenini başlıkta göremediğiniz mesajlar için spam sorunu giderme rehberi, yaygın kalıpları başlık örnekleriyle açıklamaktadır.
Kendi e-posta sunucunuz varsa ve giden başlıklarınızın temiz olmasını istiyorsanız, transactional e-posta kurulumu, paylaşımlı hosting'den toplu gönderimin neden çıkmaza girdiğini ve doğru alternatifin ne olduğunu açıklar. Linux hosting üzerinde çalışan sunucular için aynı Postfix ve OpenDKIM ayarları doğrudan uygulanabilir.
Mesaj hacmi yüksekse ve başlık analizini otomatikleştirmek istiyorsanız, dokümantasyon ve bilgi tabanı, komut satırı araçlarıyla başlık ayrıştırma örneklerini içerir.
Sıkça Sorulan Sorular
E-posta başlığındaki From alanı sahte olabilir mi?
Evet, tamamen. From yalnızca göndericinin mesaja yazdığı bir metin dizesidir ve SMTP'nin bunu doğrulamak için hiçbir mekanizması yoktur. Bunu engelleyen tek şey, hedef alan adındaki DMARC politikasıdır. Bir alan adının p=reject ile DMARC'ı yoksa, herkes o adla e-posta gönderebilir ve sunucunuz da teslim eder.
Return-Path ile From arasındaki fark nedir?
Return-Path, SMTP zarfındaki MAIL FROM komutundan oluşturulur ve bounce'ların dönüş adresidir. From ise kullanıcının istemcide gördüğü şeydir. Bu ikisi tamamen farklı iki alan adına işaret edebilir ve meşru gönderimlerde de çoğu zaman böyledir. Gönderici kimliğini tespit etmek için From'u Return-Path ile değil, DMARC sonucuyla karşılaştırın.
Received başlığı neden birkaç kez tekrarlanmış?
Mesajın geçtiği her sunucu, başlığın üstüne bir Received satırı ekler. Bu satırların sayısı, mesajın atlama (hop) sayısına eşittir. Sayıları anormal fazlaysa veya zamanları birbiriyle uyuşmuyorsa, değiştirilme olasılığı vardır. Güven sınırınız, kendi sunucunuzun yazdığı son satırdır.
E-postanın gerçekten iddia ettiği alan adından geldiğini nasıl anlarım?
Authentication-Results satırına bakın ve dmarc değerini kontrol edin. dmarc=pass ise ve header.from beklediğiniz alan adıysa, mesaj o alan adının yetkili altyapısından gelmiştir. dmarc=fail veya none ise hiçbir garanti yoktur ve mesajın doğruluğunu başka bir kanaldan teyit etmelisiniz.