Exim ile Gönderen Doğrulama ve Callout Yapılandırması

yazar

Mail sunucunuza gelen her mesajı körü körüne kabul etmek, spam ve sahte gönderici saldırılarına davetiye çıkarmak demektir. Exim’in sunduğu Sender Verification ve Callout mekanizmaları, tam da bu noktada devreye girerek gelen mailin gerçekten var olan bir göndericiden gelip gelmediğini doğrulamanızı sağlar. Bu yazıda bu iki güçlü özelliği derinlemesine inceleyeceğiz, gerçek dünya senaryolarını ele alacağız ve yapılandırma tuzaklarından nasıl kaçınacağınızı göstereceğiz.

Sender Verification Nedir?

Sender Verification, SMTP oturumu sırasında gelen mailin zarf gönderici adresini (envelope sender, yani MAIL FROM) doğrulama işlemidir. Exim bu doğrulamayı birkaç farklı seviyede yapabilir:

  • Sözdizimi kontrolü: Adres geçerli bir format mı?
  • Domain MX/A kaydı kontrolü: Göndericinin domain’i çözümlenebiliyor mu?
  • Callout: Hedef mail sunucusuna bağlanarak adresin gerçekten var olup olmadığını test etme

Sender Verification olmadan, herhangi biri MAIL FROM: diyerek size mail gönderebilir ve siz bunu fark etmeden kabul edersiniz. Özellikle backscatter sorunuyla boğuşuyorsanız, bu mekanizma hayat kurtarır.

Temel Kavramlar

Exim ACL (Access Control List) yapısı içinde sender verification çalışır. acl_smtp_rcpt veya acl_smtp_data aşamasında tetikleyebilirsiniz. En yaygın kullanım acl_smtp_rcpt aşamasındadır çünkü alıcı bilinmeden önce gönderici doğrulaması yapılır ve gereksiz veri transferinin önüne geçilir.

# /etc/exim4/exim4.conf.template veya exim.conf içinde
# acl_smtp_rcpt bölümüne eklenecek örnek

acl_check_rcpt:
  # Yerel ağdan gelen maillerde sender verification atla
  accept  hosts = +relay_from_hosts

  # Sender verification uygula
  require verify = sender
         message = Gonderen adres dogrulanamadi: $sender_address

  accept

Bu basit konfigürasyonda verify = sender direktifi Exim’e gönderici adresini doğrulamasını söyler. Doğrulama başarısız olursa require bloğu maili reddeder.

Callout Mekanizması

Callout, sender verification’ın ileri bir adımıdır. Sadece domain’in MX kaydının var olduğunu kontrol etmekle kalmaz, aynı zamanda hedef mail sunucusuna gerçek bir SMTP bağlantısı açarak adresin gerçekten var olup olmadığını sorgular.

Callout şu adımları izler:

  • Hedef domain’in MX kayıtlarını çözümle
  • MX sunucusuna TCP bağlantısı aç
  • EHLO/HELO gönder
  • MAIL FROM: gönder (boş gönderici, çünkü bu bir probe’dur)
  • RCPT TO: gönder
  • Yanıta göre adresin var olup olmadığına karar ver
  • QUIT gönder ve bağlantıyı kapat
# Callout ile birlikte sender verification
acl_check_rcpt:
  accept  hosts = +relay_from_hosts

  # Callout önbelleği ile birlikte sender verification
  require verify        = sender/callout
         message        = Gonderen adresi callout dogrulamasinda basarisiz: $sender_address

  accept

Callout Parametreleri

Callout direktifi birçok opsiyonel parametre alır. Bunları iki nokta üst üste ile ayırarak belirtirsiniz:

# Detayli callout parametreleri
require verify = sender/callout=30s,defer_ok,use_sender,postmaster

# Parametreler aciklamali:
# callout=30s         : Her callout icin zaman asimi 30 saniye
# defer_ok            : Callout basarisiz olursa (timeout vb.) maili kabul et
# use_sender          : MAIL FROM olarak gercek gonderici adresini kullan
# postmaster          : Postmaster adresiyle de dogrulama yap

callout=süre: Callout zaman aşımı süresi. Varsayılan 30 saniyedir. Düşük tutarsanız yanlış reddetme riski artar, yüksek tutarsanız SMTP oturumu uzar.

defer_ok: Hedef sunucuya ulaşılamazsa (geçici hata) maili reddetmek yerine kabul et. Üretim ortamında genellikle bu tercih edilir.

no_cache: Callout sonuçlarını önbellekleme. Normalde önbellekleme açıktır, bu parametre kapatır.

postmaster: Ek olarak postmaster@domain adresini de doğrula. Bazı sunucular tüm adreslere 250 döner ama postmaster’a 550 dönerse domain sahte demektir.

use_sender: Callout sırasında MAIL FROM olarak boş adres yerine gerçek gönderici adresini kullan. Bazı sunucular boş MAIL FROM‘u kabul etmez.

fullpostmaster: postmaster parametresinin daha sert versiyonu.

Callout Önbelleği

Her gelen mail için callout yapmanız sunucunuzu yavaşlatır ve hedef sunucular tarafından kötüye kullanım olarak algılanabilir. Exim bu nedenle callout sonuçlarını bir veritabanında önbellekler.

# Exim callout önbellegini gormek icin
exim -bh 192.168.1.100

# Önbellegi temizlemek (dikkatli kullanin)
exim_tidydb -t 1d /var/spool/exim/db/callout

# Önbellek durumunu kontrol et
exim_dumpdb /var/spool/exim/db/callout

Önbellek varsayılan olarak /var/spool/exim/db/callout konumunda tutulur. Pozitif sonuçlar (adres var) ve negatif sonuçlar (adres yok) ayrı ayrı önbelleğe alınır. Bu süreleri konfigürasyonunuzda ayarlayabilirsiniz:

# exim.conf ana konfigurasyonu
callout_positive_expire = 24h
callout_negative_expire = 2h
callout_domain_positive_expire = 12h
callout_domain_negative_expire = 1h

Negatif sonuçların daha kısa tutulması mantıklıdır çünkü birisi yeni bir mail adresi açmış olabilir.

Gerçek Dünya Senaryosu 1: E-ticaret Sitesinde Backscatter Sorunu

Bir e-ticaret şirketinin mail sunucusunu yönettiğinizi düşünün. Sunucunuz spam göndericilerin hedefi olmuş ve gerçekte var olmayan adreslerden sipariş bildirimleri gelmeye başlamış. Bounce mesajları üçüncü taraf adreslere gidince siz backscatter kaynağı oluyorsunuz.

# /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt dosyasi
# (Debian/Ubuntu icin bolumlu konfigurasyon)

acl_check_rcpt:
  # RFC gerekliligi: postmaster her zaman kabul
  accept  local_parts   = postmaster
          domains       = +local_domains

  # Kimlik dogrulanmis kullanicilara izin ver
  accept  authenticated = *
          control       = submission/sender_retain

  # Yerel agdan gelen maillere izin ver
  accept  hosts         = +relay_from_hosts
          control       = submission

  # Yerel domainler icin alici kontrolu
  accept  domains       = +local_domains
          endpass
          verify        = recipient

  # Relay icin izin verilen domainler
  accept  domains       = +relay_to_domains
          endpass
          verify        = recipient

  # Dis dunyadan gelen maillerde sender verification + callout
  deny    message       = Gonderen adres gecersiz
          !verify       = sender/callout=20s,defer_ok

  accept

Bu yapılandırma, dışarıdan gelen her mail için callout doğrulaması yapar. defer_ok parametresi sayesinde hedef sunucuya ulaşılamazsa mail reddedilmez.

Gerçek Dünya Senaryosu 2: Büyük Ölçekli Hosting

Yüzlerce domain barındıran bir hosting ortamında her callout için ayrı bağlantı açmak ciddi performans sorunlarına yol açar. Bu durumda daha akıllı bir yaklaşım gerekir:

# Yuksek hacimli ortam icin optimize edilmis yapilandirma
acl_check_rcpt:
  accept  hosts = +relay_from_hosts

  # Kotu bilinen IP'leri direkt reddet
  deny    hosts        = +blocklist_hosts
          message      = IP adresiniz kara listede: $sender_host_address

  # SPF kontrolunden gecen maillerde callout atla
  accept  spf          = pass

  # DKIM dogrulanmis maillerde callout atla
  accept  condition    = ${if def:h_DKIM-Signature {yes}{no}}

  # Geri kalan maillere callout uygula, ama agresif onbellekleme ile
  require verify       = sender/callout=15s,defer_ok
          message      = Gonderen adresi dogrulanamadi

  accept

SPF veya DKIM ile doğrulanmış maillerde callout atlamak hem performansı artırır hem de meşru maillerin yanlışlıkla reddedilme riskini azaltır.

Sender Verification Günlük Takibi

Exim log dosyaları sender verification sonuçlarını kaydeder. Bu logları düzenli takip etmek önemlidir:

# Callout redlerini goster
grep "sender verify fail" /var/log/exim4/mainlog | tail -50

# Callout hatalarini goster (timeout vs)
grep "callout" /var/log/exim4/mainlog | grep -i "defer|error|fail" | tail -30

# En cok reddedilen gonderici domainleri
grep "sender verify fail" /var/log/exim4/mainlog | 
  grep -oP 'sender_address=K[^s]+' | 
  awk -F@ '{print $2}' | 
  sort | uniq -c | sort -rn | head -20

Bu log analizleri size hangi domainlerin sıkça sahte adres kullandığını, hangi meşru sunucuların callout testini geçemediğini ve sisteminizdeki genel sağlık durumunu gösterir.

Whitelist ile İnce Ayar

Bazı meşru mail sunucuları callout testlerini engeller veya yanıt vermez. Bu durum meşru maillerin reddedilmesine yol açabilir. Whitelist kullanarak bu sunucuları atlayabilirsiniz:

# /etc/exim4/sender_verify_whitelist dosyasi
# Her satira bir domain veya IP
example.com
mailchimp.com
192.168.100.0/24

# exim.conf veya konfigurasyon dosyasinda
acl_check_rcpt:
  # Whitelist'teki host'lardan gelen maillerde verification atla
  accept  hosts        = /etc/exim4/sender_verify_whitelist

  # Normal akis
  require verify       = sender/callout=20s,defer_ok
          message      = Gonderen adresi dogrulanamadi

  accept
# Alternatif: Domain bazli whitelist
acl_check_rcpt:
  # Gonderen domain whitelist'te ise dogrulama atla
  accept  condition    = ${if match_domain{$sender_address_domain}
                         {/etc/exim4/trusted_domains}{yes}{no}}

  require verify       = sender/callout=20s,defer_ok
          message      = Gonderen adresi dogrulanamadi: $sender_address

  accept

Recipient Verification

Sender verification’ın yanı sıra alıcı doğrulaması da kritik öneme sahiptir. Özellikle Exim’i bir relay olarak kullandığınızda, arkadaki mail sunucusunda olmayan adreslere gelen mailleri erken aşamada reddetmek istersiniz:

# Relay senaryosunda recipient callout
acl_check_rcpt:
  # Kimlik dogrulanmis kullanicilara izin ver
  accept  authenticated = *

  # Dis domainler icin alici dogrulamasi
  require domains      = +relay_to_domains
          verify       = recipient/callout=20s,defer_ok
          message      = Alici adres mevcut degil: $local_part@$domain

  accept

Bu yapılandırma özellikle Exchange veya başka bir iç mail sunucusunun önünde Exim’i spam filtresi olarak kullandığınızda çok işe yarar. Var olmayan adreslere gelen mailler arkadaki sunucuya hiç iletilmez.

Test ve Sorun Giderme

Konfigürasyonunuzu canlıya almadan önce mutlaka test edin:

# Exim konfigurasyon syntax kontrolu
exim -C /etc/exim4/exim4.conf.template -bV

# Belirli bir adres icin manuel sender verification testi
exim -bh 192.168.1.100 << 'EOF'
EHLO test.example.com
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
QUIT
EOF

# Callout veritabanini kontrol et
exim_dumpdb /var/spool/exim/db/callout 2>/dev/null | head -30

# Belirli bir adresin callout durumunu sorgula
exim -bh 127.0.0.1 -oMa 127.0.0.1 << 'EOF'
EHLO localhost
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
DATA
Subject: Test
Test mesaji
.
QUIT
EOF
# Exim'in bir adresi nasil yonlendirdigini test et
exim -bt [email protected]

# Gonderen verification'i interaktif test et
exim -bh remotehost.example.com

# ACL trace modu ile detayli log
# exim.conf'a ekleyin:
# log_selector = +all
# Sonra test edin ve /var/log/exim4/mainlog'u takip edin
tail -f /var/log/exim4/mainlog | grep -E "callout|verify|sender"

Yaygın Sorunlar ve Çözümleri

Sorun 1: Meşru Mailler Reddediliyor

Bazı büyük servis sağlayıcılar (özellikle toplu mail gönderenler) callout testlerini engelleyebilir. defer_ok parametresi bu durumda ilk savunma hattınızdır. Ek olarak:

# Defer durumunda ne olacagini belirle
acl_check_rcpt:
  warn    !verify      = sender/callout=10s
          log_message  = Callout basarisiz: $sender_address ($acl_verify_message)

  # Sadece kesin fail'lerde reddet, defer'da kabul et
  deny    condition    = ${if eq{$acl_verify_message}{Callout: RCPT response was 5xx}{yes}{no}}
          message      = Gonderen adres mevcut degil

  accept

Sorun 2: Callout Döngüsü

Eğer iki Exim sunucusu birbirini doğrulamaya çalışırsa sonsuz döngüye girebilirsiniz. Bunu engellemek için:

# Callout probe'larini tanimla ve atla
acl_check_rcpt:
  # Bos gonderici adresli callout probe'larini kabul et
  accept  condition    = ${if eq{$sender_address}{}{yes}{no}}
          hosts        = +relay_from_hosts

  # Normal akis
  require verify       = sender/callout
  accept

Sorun 3: Yüksek CPU/Bekleme Süresi

Callout bağlantıları zaman aşımına uğradığında SMTP oturumları uzuyor ve kuyruklar şişiyor olabilir. Bu durumda:

# Zaman asimini dusur ve rate limiting ekle
acl_check_rcpt:
  # Ayni IP'den cok fazla basarisiz deneme varsa kara listeye al
  defer   ratelimit    = 5 / 1m / strict / $sender_host_address
          message      = Gecici red: Cok fazla basarisiz deneme

  require verify       = sender/callout=10s,defer_ok,no_cache

  accept

Güvenlik Hususları

Callout mekanizmasının kendisi de istismar edilebilir. Bir saldırgan sizin sunucunuzu kullanarak üçüncü taraf sunucularına callout probe’ları gönderebilir (DHA – Directory Harvest Attack). Bunu sınırlamak için:

  • Callout önbelleğini aktif tutun (varsayılan açıktır)
  • Rate limiting ile callout sayısını sınırlayın
  • Şüpheli kaynaklardan gelen maillerde callout yapmadan önce ek kontroller ekleyin

Ayrıca bazı mail sunucuları callout probe’larını (boş MAIL FROM ile gelen RCPT TO sorgularını) directory harvest saldırısı olarak algılayıp IP’nizi bloklar. Bu nedenle callout’u dikkatli kullanın ve gerektiğinde use_sender parametresiyle gerçek gönderici adresini kullanın.

Exim ile SPF Entegrasyonu

Modern bir mail güvenlik altyapısında sender verification ve callout, SPF ve DKIM ile birlikte çalışmalıdır. Exim’de SPF desteği için exim-gnutls paketini veya libspf2 kütüphanesini kullanabilirsiniz:

# SPF ve callout birlikte kullanimi
acl_check_rcpt:
  accept  hosts        = +relay_from_hosts

  # SPF pass ise callout atla
  accept  spf          = pass
          add_header   : X-SPF-Result: pass

  # SPF fail ise direkt reddet
  deny    spf          = fail
          message      = SPF dogrulama basarisiz: $sender_address 
                         $spf_smtp_comment

  # SPF sonucu yoksa callout ile dogrula
  require verify       = sender/callout=20s,defer_ok
          message      = Gonderen adresi dogrulanamadi

  accept

Bu katmanlı yaklaşım hem performansı optimize eder hem de güvenlik seviyesini artırır.

Sonuç

Exim’in sender verification ve callout mekanizmaları, doğru yapılandırıldığında spam ve sahte gönderici saldırılarına karşı son derece etkili bir savunma hattı oluşturur. Ancak bu güçlü araçlar dikkatli kullanılmazsa meşru maillerin reddedilmesine, performans sorunlarına ve üçüncü taraf sunucularla ilişkilerin bozulmasına yol açabilir.

Pratik önerilerle özetlemek gerekirse:

  • Üretim ortamına almadan önce mutlaka test sunucusunda deneyin
  • defer_ok parametresini varsayılan olarak ekleyin, çok agresif reddetme yapmayın
  • Callout önbelleğini aktif bırakın, gereksiz bağlantıları azaltır
  • Whitelist oluşturun ve güvendiğiniz kaynakları ekleyin
  • Logları düzenli izleyin, yanlış pozitif oranını takip edin
  • SPF/DKIM ile entegre edin, callout’u son çare olarak kullanın
  • Rate limiting ekleyerek sisteminizin kötüye kullanılmasını önleyin

Mail güvenliği tek bir araçla çözülen bir mesele değildir. Sender verification ve callout, daha geniş bir güvenlik mimarisinin parçası olarak değerlendirildiğinde gerçek değerini gösterir. Exim’in esnekliği sayesinde bu mekanizmaları kendi ortamınıza özel ince ayarlarla kullanabilir, hem güvenliği hem de kullanıcı deneyimini optimize edebilirsiniz.

Yorum yapın