Bir mail sunucusu başkasının mesajını üçüncü bir adrese aktardığında, alıcı taraf o mesajı senin IP'nden ama başka bir alan adının kimliğiyle görür. SPF bunu sahtecilik sayar ve reddeder. SRS (Sender Rewriting Scheme), tam olarak bu çıkmazı çözmek için tasarlanmış bir adres yeniden yazma yöntemidir: yönlendirme sırasında zarf gönderenini kendi alan adına çevirir, ama geri dönüş yolunu kaybetmeyecek şekilde orijinal adresi kodlayarak saklar.
Bu yazıda SRS'in ne yaptığını, ürettiği garip görünen adreslerin nasıl okunduğunu, iki yönlü çalışmasının neden zorunlu olduğunu ve Postfix ile postsrsd kullanarak nasıl kurulacağını anlatacağım. En önemlisi, SRS'in neyi çözmediğini de netleştireceğim — çünkü SRS'i DMARC sorunlarının genel çaresi sanmak, yıllardır tekrar eden bir yanlış anlama.
SRS Hangi Sorunu Çözer#
SPF, bağlanan IP adresini zarf gönderenin (MAIL FROM) alan adıyla eşleştirir. Yönlendirme yaptığında zarf göndereni değiştirmeden mesajı aktarırsın, dolayısıyla alıcı senin IP'ni yabancı bir alan adının kaydında arar ve bulamaz. Bu mekanizmanın ayrıntısını mail yönlendirmenin SPF'i neden bozduğu yazısında adım adım ele almıştım.
SRS'in çözümü basit ve zekicedir: zarf gönderenini kendi alan adına çevir, ama orijinal adresi bu yeni adresin içine kodla. Böylece iki şey birden sağlanır — alıcı SPF kontrolünü senin alan adın üzerinden yapar ve geçer; teslimat hatası olursa bounce mesajı senin sunucuna döner, sen de kodlanmış adresi çözüp gerçek gönderene iletirsin.
# SRS öncesi (yönlendirme sırasında)
MAIL FROM:<[email protected]> -> alıcı SPF kontrolü: FAIL
# SRS sonrası
MAIL FROM:<[email protected]> -> SPF kontrolü: PASS
Kritik noktayı tekrar vurgulayayım: değişen şey yalnızca zarf göndereni. Kullanıcının ekranda gördüğü From: başlığı hiç dokunulmadan kalır, yani alıcı mesajı yine [email protected] adresinden gelmiş gibi görür.
SRS Adresinin Anatomisi#
İlk kez gördüğünde şifreli bir dizeye benzeyen SRS adresi aslında düz bir biçime sahiptir. Alanlar = işaretiyle ayrılır ve sırayla okunur:
[email protected]
| | | | | |
| | | | | +-- yeniden yazan sunucunun alan adı
| | | | +----------- orijinal adresin yerel kısmı
| | | +------------------- orijinal alan adı
| | +------------------------- zaman damgası (base32, iki karakter)
| +------------------------------ kriptografik özet (hash)
+------------------------------------ SRS sürüm etiketi
| Alan | İçerik | Amacı |
|---|---|---|
SRS0 | Sabit etiket | İlk kez yeniden yazıldığını belirtir |
| Hash | Gizli anahtarla üretilmiş özet | Adresin taklit edilmesini engeller |
| Zaman damgası | Base32, iki karakter | Adresin geçerlilik penceresini sınırlar |
| Orijinal alan adı | ornek.com | Geri çözme için gerekli |
| Yerel kısım | ayse | Geri çözme için gerekli |
Hash alanı bu tasarımın güvenlik ayağıdır. Onsuz, herkes senin alan adında geçerli görünen bir SRS adresi uydurup üzerinden spam gönderebilirdi. Hash yalnızca senin sunucundaki gizli anahtarla üretilebildiği için, geri çözme aşamasında adresin gerçekten senin tarafından yazıldığını doğrularsın.
Zaman damgası da benzer bir amaca hizmet eder: SRS adresleri sonsuza kadar geçerli kalmaz, birkaç haftalık bir pencere sonrası reddedilir. Böylece eski bir bounce adresi ele geçirilse bile sınırsız süre kullanılamaz.
Mesaj birden fazla yönlendirmeden geçerse SRS0 etiketi SRS1 olur ve zincir sarmalanarak taşınır. Bu, adresin her hopta uzamasını önleyen bir sıkıştırma mekanizmasıdır.
postsrsd Kurulumu ve Yapılandırması#
Postfix'in kendi içinde SRS desteği yoktur; işi harici bir arka plan servisine devredersin. En yaygın seçenek postsrsd; küçük, tek amaçlı ve Postfix'in arama tablosu protokolünü konuşan bir daemon'dur.
# Debian / Ubuntu
apt install postsrsd
# Servis durumunu kontrol et
systemctl status postsrsd
Yapılandırmada üç şey önemli: hangi alan adının SRS adreslerinde kullanılacağı, hangi alan adlarının yeniden yazma dışında bırakılacağı ve gizli anahtarın nerede durduğu.
# Sürüme göre /etc/default/postsrsd veya /etc/postsrsd.conf
# SRS adreslerinde kullanılacak alan adı (MX kaydı bu sunucuya bakmalı)
SRS_DOMAIN=firmaniz.com
# Kendi alan adlarını yeniden yazma; yerel teslimat bozulur
SRS_EXCLUDE_DOMAINS=firmaniz.com,ornek.com,ikinci-marka.com
# Yalnızca yerel arayüzü dinle, dışarıya açma
SRS_LISTEN_ADDR=127.0.0.1
SRS_FORWARD_PORT=10001
SRS_REVERSE_PORT=10002
# Gizli anahtar dosyası
SRS_SECRET=/etc/postsrsd.secret
Gizli anahtar dosyasını mutlaka kilitle ve yedekle. Anahtarı kaybedersen ya da değiştirirsen, dolaşımdaki tüm SRS adreslerinin hash'i geçersiz olur ve o mesajların bounce'ları çözülemez.
# Anahtarı yalnızca root okuyabilsin
chmod 600 /etc/postsrsd.secret
chown root:root /etc/postsrsd.secret
# Yedeğini güvenli bir yere al
cp /etc/postsrsd.secret /kok-disi-yedek/postsrsd.secret.$(date +%F)
Şimdi Postfix tarafını bağla. Buradaki dört satırın her biri farklı bir yönü kapsar ve hiçbiri isteğe bağlı değildir:
# /etc/postfix/main.cf
# Giden yönde: zarf gönderenini SRS adresine çevir
sender_canonical_maps = tcp:127.0.0.1:10001
sender_canonical_classes = envelope_sender
# Gelen yönde: SRS adresini gerçek adrese geri çöz
recipient_canonical_maps = tcp:127.0.0.1:10002
recipient_canonical_classes = envelope_recipient
Yeni postsrsd sürümleri TCP yerine soket eşlemesi (socketmap) kullanır; o durumda tcp:127.0.0.1:10001 yerine paketin belgelendirdiği socketmap:unix:...:forward biçimini yazarsın. Mantık aynı kalır. Değişiklikten sonra:
postfix check
systemctl reload postfix
İki Yönlü Çalışma: Geri Çözme Neden Zorunlu#
SRS'i kuran çoğu kişi yalnızca ileri yönü (sender_canonical_maps) yapılandırıp durur ve haftalar sonra "bounce mesajları teslim edilemiyor" sorunuyla karşılaşır. Oysa SRS iki yönlü bir mekanizmadır ve tek yönlü kurulum yarım çalışan bir sistem üretir.
Akış şöyle işler:
- Yönlendirme sırasında zarf göndereni
[email protected]adresine çevrilir. - Hedef sunucu mesajı teslim edemez ve bounce mesajını bu SRS adresine gönderir.
- Bounce senin sunucuna gelir; çünkü
firmaniz.comMX kaydı sana bakıyor. recipient_canonical_mapsdevreye girer, hash doğrulanır, adres[email protected]olarak çözülür.- Bounce gerçek gönderene iletilir.
Dördüncü adım eksikse, sunucun kendi alan adında var olmayan bir kutuya gelen mesaj görür ve bounce'u reddeder — orijinal gönderen mesajının iletilemediğini asla öğrenemez. Kurulumu doğrulamak için her iki yönü de elle sorgula:
# İleri yön: normal adres -> SRS adresi
postmap -q "[email protected]" tcp:127.0.0.1:10001
# Örnek çıktı: [email protected]
# Geri yön: SRS adresi -> normal adres
postmap -q "[email protected]" tcp:127.0.0.1:10002
# Örnek çıktı: [email protected]
# Kendi alan adın yeniden yazılmamalı (çıktı boş olmalı)
postmap -q "[email protected]" tcp:127.0.0.1:10001
Üçüncü test en sık atlanan kontroldür. Kendi alan adın SRS_EXCLUDE_DOMAINS listesinde değilse, sunucun kendi kullanıcılarının giden mesajlarını da yeniden yazmaya başlar ve bu, DMARC hizalamanı bozar.
SRS'in Çözmediği Şey: DMARC Hizalaması#
Bu bölümü ayrı yazmamın sebebi, SRS hakkındaki en yaygın yanlış beklentiyi düzeltmek. SRS SPF'i geçirir, ama DMARC'ı hizalamaz.
DMARC, doğrulanan alan adının kullanıcının gördüğü From: alan adıyla eşleşmesini ister. SRS'ten sonra tablo şöyle görünür:
| Kimlik | Değer | DMARC açısından |
|---|---|---|
MAIL FROM (SRS sonrası) | [email protected] | SPF geçer, ama From ile eşleşmez |
From: başlığı | [email protected] | DMARC referansı budur |
| DKIM imzası | d=ornek.com | Bozulmadıysa hizalı ve geçerli |
Yani DMARC'ın geçmesi hâlâ tamamen DKIM'in sağ kalmasına bağlıdır. SRS'in gerçek katkısı üç yerde: sert -all politikası uygulayan alıcıların mesajı SPF aşamasında kapıda kesmesini önler, bounce mesajlarının doğru adrese dönmesini sağlar ve sunucunu geri saçılma (backscatter) kaynağı olmaktan çıkarır.
Bu yüzden SRS'i tek başına değil, "mesajı hiç değiştirme" kuralıyla birlikte uygula. Yönlendirilen mesaja alt bilgi ekliyor, konuya etiket koyuyorsan DKIM kırılır ve SRS kurmuş olman hiçbir şeyi kurtarmaz. Alan adı taklidine karşı genel savunma katmanlarını e-posta spoofing önleme yazısında toplu olarak ele aldım.
Sık Yapılan Hatalar ve Tuzaklar#
Kendi alan adlarını hariç tutmamak. SRS_EXCLUDE_DOMAINS boş bırakılırsa sunucun kendi kullanıcılarının giden mesajlarını da yeniden yazar. Kullanıcı kendi adresinden mesaj gönderir, alıcı zarf göndereni SRS adresi olarak görür, DMARC hizalaması bozulur. Kendi alan adlarının tamamını bu listeye yaz.
SRS alan adının MX kaydı olmaması. SRS_DOMAIN olarak seçtiğin alan adının MX kaydı senin sunucuna bakmalıdır. Aksi halde bounce mesajları hiçbir yere ulaşmaz ve sessizce kaybolur.
Gizli anahtarı yedeklememek. Sunucuyu yeniden kurduğunda ya da taşıdığında anahtarı taşımazsan, dolaşımdaki tüm SRS adresleri geçersiz olur. Anahtarı yapılandırma yedeklerinin içine dahil et.
Yalnızca ileri yönü kurmak. En sık görülen kurulum hatası budur; recipient_canonical_maps satırı olmadan bounce'lar çözülemez.
recipient_canonical_classes değerini gereğinden geniş tutmak. Bazı belgelerde header_recipient de eklenir; bu, başlıklardaki SRS adreslerini de düzeltir ve genellikle istenen davranıştır. Ancak kendi kurulumunda test etmeden kopyalama — yanlış sınıf seçimi, alıcı başlıklarında beklenmedik değişikliklere yol açabilir.
SRS'i sorunun tamamı sanmak. SRS kurduktan sonra hâlâ spam'e düşen yönlendirmeler görüyorsan, sorun SPF'te değil DKIM'dedir. Hedefteki mesajın Authentication-Results başlığını oku; dkim=fail görüyorsan yönlendirme yolunda mesajı değiştiren bir bileşen var demektir.
Sıkça Sorulan Sorular#
SRS kurmadan yönlendirme yapabilir miyim#
Evet, yapabilirsin ve pek çok kurulum SRS olmadan da çalışır — özellikle DKIM imzası bozulmadan aktarılıyorsa DMARC geçtiği için mesaj teslim edilir. SRS'e ihtiyacın olduğunu anlayacağın işaretler şunlardır: bounce mesajlarının kaybolması, sert SPF politikası olan gönderenlerin mesajlarının reddedilmesi ve sunucunun geri saçılma nedeniyle kara listeye girmesi. Bu belirtiler yoksa SRS'i acele etmeden planlayabilirsin.
SRS adresleri neden bu kadar uzun ve garip görünüyor#
Çünkü adresin içine dört ayrı bilgi kodlanıyor: sürüm etiketi, güvenlik özeti, zaman damgası ve orijinal adresin tamamı. Bu bilgiler olmadan bounce mesajını geri çözmek ya da adresin sahte olup olmadığını anlamak mümkün olmazdı. İyi haber şu ki bu adres yalnızca zarf katmanında yaşar; kullanıcı hiçbir zaman görmez, çünkü From: başlığı olduğu gibi kalır.
SRS gizli anahtarını değiştirirsem ne olur#
Anahtar değiştiğinde daha önce üretilmiş tüm SRS adreslerinin hash doğrulaması başarısız olur ve o adreslere gelen bounce mesajları reddedilir. Pratikte bu, birkaç haftalık bir pencerede yolda olan hata bildirimlerinin kaybolması demektir. Anahtar rotasyonu gerekiyorsa bunu düşük trafikli bir dönemde yap ve mümkünse eski anahtarı bir süre daha kabul eden bir yapılandırma kullan.
SRS DMARC sorunumu çözer mi#
Hayır. SRS zarf gönderenini değiştirir ve SPF'i geçirir, ancak DMARC kullanıcının gördüğü From: başlığına bakarak hizalama arar. SRS From: başlığına dokunmadığı için hizalama sağlanmaz ve DMARC kararı tamamen DKIM'in sağ kalıp kalmadığına bağlı olur. DMARC sorunun varsa çözüm, yönlendirme yolunda mesajı değiştiren bileşeni bulup kaldırmaktır.
cPanel veya paylaşımlı hostingte SRS var mı#
Paylaşımlı hosting ortamlarında yönlendirme genellikle sağlayıcı tarafından yapılandırılır ve SRS uygulanıp uygulanmadığı sunucunun kurulumuna bağlıdır. Kendi başına bir SRS servisi kurman mümkün değildir, çünkü Postfix yapılandırmasına erişimin yoktur. Kalıcı bir aktarım kuruyorsan yönlendirme yerine hedef hesaptan IMAP ile çekmeyi tercih etmek, bu bağımlılığı tamamen ortadan kaldırır.
SRS kurulumunun çalıştığını nasıl doğrularım#
En hızlı yöntem postmap -q ile hem ileri hem geri yönü elle sorgulamaktır; ileri yönde SRS adresi üretilmeli, geri yönde orijinal adres geri gelmelidir. Ardından kendi kontrolündeki harici bir hesaptan yönlendirilen adrese mesaj gönder ve hedef kutudaki Return-Path başlığında SRS adresini gördüğünü doğrula. Son testte kasıtlı olarak var olmayan bir hedefe yönlendirme yapıp bounce mesajının orijinal gönderene ulaştığını kontrol et.
Kapanış#
SRS, yönlendirmenin SPF ile çatışmasını çözen dar ama işini iyi yapan bir araçtır. Aklında kalması gereken dört şey var: SRS yalnızca zarf göndereni değiştirir, From: başlığına dokunmaz; iki yönlü çalışır ve geri çözme olmadan bounce'lar kaybolur; kendi alan adlarını mutlaka hariç tut; ve gizli anahtarı yedeklemeden sunucu taşıma. En önemlisi, SRS'i DMARC'ın çaresi sanma — DMARC'ı ayakta tutan şey mesajı hiç değiştirmemek ve DKIM'i sağ tutmaktır.
Yönlendirme ve kimlik doğrulama katmanını kendin kurmak yerine hazır bir yapı istiyorsan, kurumsal e-posta çözümlerimizde bu ayarlar kurulumda tanımlanır. Kendi mail sunucunu işletiyorsan SMTP sunucu paketlerimiz Postfix, DKIM ve rDNS kaydı hazır teslim edilir; yapılandırmanın bakımını devretmek istediğinde sunucu yönetimi hizmetimiz bu katmanı da üstlenir.