Exim ile Backup MX Yapılandırması

yazar

Mail altyapısında tek nokta arızası (single point of failure) her zaman en büyük kabuslardan biridir. Bir sabah birincil mail sunucunuzun çöktüğünü, saatlerdir mail alamadığınızı ve müşterilerinizin “maillerim nereye gitti?” diye aradığını düşünün. İşte tam bu senaryoyu önlemek için Backup MX yapılandırması hayat kurtarıcı hale gelir. Exim ile bu yapılandırmayı doğru şekilde kurmak, mail akışınızın kesintisiz devam etmesini sağlar.

Backup MX Nedir ve Neden Gereklidir?

Backup MX, birincil mail sunucunuz erişilemez olduğunda gelen mailleri geçici olarak depolayan ve birincil sunucu yeniden devreye girdiğinde bu mailleri ileten ikincil (veya üçüncül) mail sunucusudur. DNS’te MX kayıtlarının öncelik değerleri (priority) bu sistemi yönetir.

Gerçek dünyadan bir senaryo: Bir e-ticaret firmasının mail sunucusu kernel güncellemesi sonrası yeniden başlatma gerekti. Planlı bakım penceresi 2 saat olarak belirlenmişti ama beklenmedik bir disk sorunu çıkıp bu süre 6 saate uzadı. Backup MX olmadığı için gönderici sunucular bu 6 saat boyunca tekrar denedi, bir kısmı “geçici hata” döndürdü ama bazı kurumsal mail sunucuları 3 denemeden sonra mail’i reddetti. Backup MX olsaydı bu maillerIn hiçbiri kaybolmazdı.

MX Öncelik Değerleri

DNS’te MX kayıtları şu şekilde çalışır:

  • Düşük öncelik değeri (örn. 10): Birincil sunucu, ilk tercih
  • Yüksek öncelik değeri (örn. 20, 30): Yedek sunucular, birincil erişilemez olduğunda devreye girer
  • Gönderici sunucu, düşük değerli MX’e bağlanamadığında sıradaki yüksek değerli MX’i dener

Exim’in Backup MX Rolü

Exim’i backup MX olarak yapılandırmak, onu hem bir relay (aktarma) hem de geçici depolama sunucusu olarak çalıştırmak anlamına gelir. Temel görevler şunlardır:

  • Birincil sunucu çevrimdışıyken gelen mailleri kabul etmek
  • Mailleri kuyruğa alarak saklamak
  • Birincil sunucu yeniden erişilebilir olduğunda bekleyen mailleri iletmek
  • Spam ve kötü niyetli trafiği filtrelemek (opsiyonel ama önerilen)

Ön Hazırlık ve DNS Yapılandırması

DNS MX Kayıtları

Önce DNS tarafını düzgün kurmak gerekir. Zone dosyanıza şu kayıtları ekleyin:

; Birincil MX - düşük öncelik değeri = yüksek öncelik
example.com.    IN  MX  10  mail1.example.com.
; Backup MX - yüksek öncelik değeri = düşük öncelik (yedek)
example.com.    IN  MX  20  mail2.example.com.
; İkinci yedek (opsiyonel)
example.com.    IN  MX  30  mail3.example.com.

; A kayıtları
mail1.example.com.  IN  A  203.0.113.10
mail2.example.com.  IN  A  203.0.113.20

DNS değişikliklerinin yayılmasını beklerken (dig MX example.com ile kontrol edebilirsiniz) Exim yapılandırmasına geçebilirsiniz.

Reverse DNS (PTR) Kaydı

Backup MX sunucusunun IP adresi için de PTR kaydı tanımlanmalıdır. Birçok mail sunucusu PTR kaydı olmayan sunuculardan gelen mailleri reddeder:

# PTR kaydını kontrol et
dig -x 203.0.113.20 +short
# Beklenen çıktı: mail2.example.com.

# Veya host komutuyla
host 203.0.113.20

Exim Kurulumu ve Temel Yapılandırma

Debian/Ubuntu üzerinde Exim kurulumu:

apt update
apt install exim4 exim4-daemon-heavy

# Heavy daemon önemli: daha gelişmiş özellikler (content scanning, dkim vb.) içerir
# Yapılandırma dizini
ls /etc/exim4/

CentOS/RHEL üzerinde:

dnf install exim
systemctl enable exim
systemctl start exim

Exim Yapılandırma Dosyası Yapısı

Exim’in ana yapılandırma dosyası /etc/exim4/exim4.conf.template (Debian) veya /etc/exim4/exim4.conf (RHEL) üzerindedir. Debian split-config yapısı kullanıyorsa /etc/exim4/conf.d/ altında ayrı dosyalar bulunur. Biz monolitik yapılandırma üzerinden gideceğiz çünkü daha kolay yönetilir:

# Debian'da update-exim4.conf ile monolitik yapılandırma oluşturabilirsiniz
# ya da direkt /etc/exim4/exim4.conf dosyasını düzenleyin
cp /etc/exim4/exim4.conf /etc/exim4/exim4.conf.bak

Backup MX için Exim Yapılandırması

Ana Parametreler

/etc/exim4/exim4.conf dosyasının başına genel ayarları koyun:

# Temel kimlik ayarları
primary_hostname = mail2.example.com
domainlist local_domains = @ : localhost
domainlist relay_to_domains = example.com : example.org

# Backup MX olarak relay yapacağımız domainler
# Bu alan çok önemli - sadece yetkili olduğunuz domainler olmalı
hostlist relay_from_hosts = 127.0.0.1 : ::1

# Dinlenecek arayüzler
local_interfaces = 0.0.0.0

# Kuyruk yönetimi - backup MX için kritik
queue_only_on_queue = false
# Birincil sunucu down olduğunda mailleri kuyruğa al
queue_run_max = 5

# Yeniden deneme süresi (birincil sunucu erişilemezse ne kadar bekle)
# Default değerler çoğu zaman yeterli ama fine-tune etmek gerekebilir

Backup MX Router Yapılandırması

Exim’de router’lar mailin nasıl yönlendirileceğini belirler. Backup MX rolü için özel bir router tanımlaması gerekir:

begin routers

# Backup MX router - birincil sunucuya ilet
backup_mx_route:
  driver = manualroute
  domains = ! +local_domains
  # Sadece relay_to_domains listesindekiler için geçerli
  transport = remote_smtp
  route_list = example.com  mail1.example.com::25 ; 
               example.org  mail1-alt.example.com::25
  # Birincil sunucu down olsa kuyrukta beklet
  cannot_route_message = Birincil mail sunucusuna ulasilamiyor, 
                         mail kuyruga alindi
  # Host bulunamazsa hata döndürme, kuyruğa al
  no_more

Transport Yapılandırması

begin transports

remote_smtp:
  driver = smtp
  # TLS kullan (destekleniyorsa)
  hosts_try_starttls = *
  # Bağlantı zaman aşımı
  connect_timeout = 30s
  # Birincil sunucu geçici olarak erişilemezse (4xx hata) kuyruğa al
  # 5xx hata kalıcı hata anlamına gelir, bounce gönder
  retry_include_ip_address = true

Retry (Yeniden Deneme) Politikası

Bu backup MX yapılandırmasının kalbi burasıdır. Birincil sunucu down olduğunda Exim ne kadar süre denemeye devam etmeli?

begin retry

# Genel yeniden deneme kuralı
# Format: <domain> <error-type> <time-intervals>
# F,<time>: Sabit aralık
# G,<time>,<multiplier>: Geometrik artış
# H,<time>,<jitter>: Değişken aralık

# Birincil sunucu için yeniden deneme politikası
mail1.example.com   *   F,2h,15m; G,16h,2h,1.5; F,4d,8h

# Açıklaması:
# İlk 2 saat: Her 15 dakikada bir dene
# Sonraki 16 saat: 2 saat başlangıç, 1.5 çarpanla artan aralıklarla dene
# Sonraki 4 gün: Her 8 saatte bir dene
# 4 günden sonra: Mail bounce et

# Genel kural (diğer tüm hostlar için)
*   *   F,2h,15m; G,16h,1h,1.5; F,5d,6h

Bu yapılandırma özellikle hafta sonu veya tatil dönemlerinde birincil sunucunun uzun süre down olabileceği senaryolarda kritiktir. Varsayılan Exim ayarları 5 gün kuyrukta tutar, bu RFC 5321’e uygundur.

ACL (Access Control List) ile Güvenlik

Backup MX’in açık relay haline gelmemesi çok önemlidir. Yanlış yapılandırılmış bir backup MX, spam göndericilerin cenneti olabilir:

begin acl

acl_check_rcpt:
  # Yerel mailler her zaman kabul
  accept  domains = +local_domains

  # Relay izni olan hostlardan gelen mailler kabul
  accept  hosts = +relay_from_hosts

  # Sadece yetkili domainler için relay yap
  accept  domains = +relay_to_domains
          endpass
          message = Bu domain icin relay yetkimiz yok

  # Geçersiz alıcıyı reddet - bu önemli!
  # Birincil sunucu olmadan alıcı doğrulaması yapamayabiliriz
  # Bu yüzden dikkatli olun
  deny    message = Relay not permitted

acl_check_data:
  # Temel spam kontrolleri
  deny    condition = ${if >{$message_size}{52428800}}
          message = Mail boyutu 50MB limiti asiyor

  accept

Callout Doğrulaması

Backup MX olarak çalışırken geçersiz alıcılara mail kabul etmemek için birincil sunucudan alıcı doğrulaması yapabilirsiniz. Ancak bu, birincil sunucu down olduğunda sorun çıkarır. İki yaklaşım var:

Yaklaşım 1: Callout aktif, birincil down olduğunda geçici hata ver

acl_check_rcpt:
  # Birincil sunucu erişilebilirse callout yap
  deny    domains = +relay_to_domains
          !verify = recipient/callout=10s,defer_ok,use_sender
          message = Gecersiz alici adresi

Yaklaşım 2: Tüm mailleri kabul et (daha güvenli backup MX davranışı)

Birincil sunucu down olduğunda alıcı doğrulaması yapamazsınız. Bu yüzden genellikle tüm mailleri kabul edip birincil sunucu devreye girince iletmek daha güvenlidir. Ancak bu spam riskini artırır. Denge için sadece temel kontroller yapın:

acl_check_rcpt:
  accept  domains = +local_domains

  # Relay için sadece yetkili domainleri kabul et
  accept  domains = +relay_to_domains
          # DNSBL kontrolü ekle
          !hosts = +relay_from_hosts
          !dnslists = zen.spamhaus.org : bl.spamcop.net
          endpass
          message = IP adresiniz kara listede: $dnslist_domain

  deny

Birincil Sunucu Tespiti ve Otomatik Failover İzleme

Backup MX’in ne zaman devreye girdiğini ve ne zaman birincili tekrar denediğini izlemek önemlidir:

#!/bin/bash
# /usr/local/bin/check-primary-mx.sh
# Bu scripti cron ile her 5 dakikada çalıştırın

PRIMARY_MX="mail1.example.com"
PRIMARY_PORT=25
LOG_FILE="/var/log/backup-mx-status.log"
ALERT_EMAIL="[email protected]"

# SMTP bağlantısı test et
if timeout 10 bash -c "echo QUIT | nc -w 5 $PRIMARY_MX $PRIMARY_PORT" > /dev/null 2>&1; then
    STATUS="UP"
    # Eğer önceden down kaydı varsa, kuyruk işlemeyi tetikle
    if [ -f /tmp/primary-mx-was-down ]; then
        echo "$(date): Birincil MX yeniden erisilebilir. Kuyruk isleniyor..." >> $LOG_FILE
        /usr/sbin/exim -q -v >> $LOG_FILE 2>&1
        rm -f /tmp/primary-mx-was-down
        echo "Birincil MX $PRIMARY_MX yeniden devrede, kuyruk islendi" | 
            mail -s "Backup MX: Birincil Sunucu Geri Geldi" $ALERT_EMAIL
    fi
else
    STATUS="DOWN"
    echo "$(date): Birincil MX ERISILEMEDIGI TESPIT EDILDI" >> $LOG_FILE
    if [ ! -f /tmp/primary-mx-was-down ]; then
        touch /tmp/primary-mx-was-down
        echo "Birincil MX $PRIMARY_MX erisilemedigi tespit edildi!" | 
            mail -s "UYARI: Backup MX aktif" $ALERT_EMAIL
    fi
fi

echo "$(date): Birincil MX durumu: $STATUS" >> $LOG_FILE

Cron kaydı:

*/5 * * * * /usr/local/bin/check-primary-mx.sh

Kuyruk Yönetimi ve İzleme

Backup MX’te biriken mailleri yönetmek günlük operasyonların önemli bir parçasıdır:

# Mevcut kuyruğu listele
exim -bp

# Kuyruk özetini göster (kaç mail bekliyor)
exim -bpc

# Belirli bir domain için bekleyen mailleri göster
exim -bp | grep "example.com"

# Kuyruğu hemen işle (birincil sunucu geri geldiğinde)
exim -q

# Verbose modda kuyruk işle
exim -qv

# Sadece dondurulmuş (frozen) mailleri işle
exim -qff

# Belirli bir message ID'sini yeniden dene
exim -M <message-id>

# Kuyruktaki tüm mailleri birincil sunucuya doğru yeniden kuyruğa al
exim -bp | awk '/^ *[0-9]/{print $3}' | xargs -I{} exim -M {}

Kuyruğu İzlemek için Log Takibi

# Gerçek zamanlı log takibi
tail -f /var/log/exim4/mainlog

# Backup MX olarak relay edilen mailleri filtrele
grep "relay=" /var/log/exim4/mainlog | tail -50

# Hata durumlarını bul
grep "** " /var/log/exim4/mainlog | tail -20

# Belirli bir domain için logları filtrele
grep "@example.com" /var/log/exim4/mainlog | tail -30

SPF ve DKIM Değerlendirmeleri

Backup MX kullanırken SPF kayıtlarını da güncellemeniz gerekir:

# SPF kaydı - hem birincil hem backup MX'i dahil et
example.com.  IN  TXT  "v=spf1 mx ip4:203.0.113.10 ip4:203.0.113.20 -all"

# ya da sadece mx mekanizmasını kullanın (otomatik olarak tüm MX'leri kapsar)
example.com.  IN  TXT  "v=spf1 mx -all"

Backup MX tipik olarak mail iletmek (relay) için kullanıldığından, gönderen adresi değişmez ve DKIM imzası bozulmamalıdır. Ancak herhangi bir header değişikliği yaparsanız DKIM imzası bozulur, buna dikkat edin.

Yaygın Sorunlar ve Çözümleri

Sorun 1: Açık Relay

Backup MX’inizin açık relay olmadığını test edin:

# Harici bir makineden test et
telnet mail2.example.com 25
EHLO test.com
MAIL FROM: [email protected]
RCPT TO: [email protected]
# "550 Relay not permitted" almalısınız

Sorun 2: Mail Döngüsü

Backup MX, birincil sunucuya iletirken dikkat edilmesi gereken bir durum: birincil sunucu da backup’a iletecek şekilde yanlış yapılandırılmışsa döngü oluşur.

# exim4.conf'ta döngüyü önlemek için
# Birincil sunucu tarafında backup MX'in IP'sini güvenilir relay olarak tanımlayın
# ama backup'a iletmeyecek şekilde ayarlayın
trusted_hosts = 203.0.113.20  # Backup MX IP

# Route_data ayarında döngüyü önle
pass_router = dnslookup  # Bir sonraki router'a geç

Sorun 3: Dondurulmuş Mailler

Uzun süre kuyrukta kalan ve “frozen” durumuna düşen mailleri yönetin:

# Frozen mail sayısını kontrol et
exim -bp | grep frozen | wc -l

# Frozen mailleri tekrar aktif et
exim -qff

# Çok eski frozen mailleri sil (30 günden eski)
exiqgrep -z -o 2592000 | xargs exim -Mrm

# Exim konfigürasyonunda otomatik dondurma süresini ayarla
# exim4.conf'ta:
timeout_frozen_after = 7d  # 7 günden eski frozen mailleri sil

Performans Optimizasyonu

Backup MX’in ani yük altında çökmemesi için:

# exim4.conf'ta eşzamanlı bağlantı limitleri
smtp_accept_max = 100
smtp_accept_max_per_host = 10
smtp_connect_backlog = 20

# Kuyruk işleme aralığı
queue_interval = 15m

# Paralel kuyruk işleme
queue_run_max = 5

# Bellek ve süreç limitleri
deliver_queue_load_max = 10.0
# Sistem yükü 10'un üzerindeyse yeni teslimat başlatma

Tam Yapılandırma Örneği

Tüm parçaları bir araya getiren minimal ama fonksiyonel bir backup MX yapılandırması:

# /etc/exim4/exim4.conf - Backup MX Yapılandırması
# ================================================

primary_hostname = mail2.example.com

domainlist local_domains = @ : localhost
domainlist relay_to_domains = example.com : example.org

hostlist relay_from_hosts = 127.0.0.1 : ::1 : 203.0.113.10

# Logging
log_selector = +smtp_connection +smtp_incomplete_transaction 
               +tls_cipher +queue_run

# Güvenlik
smtp_banner = "$primary_hostname ESMTP"
helo_allow_chars =

# Performans
smtp_accept_max = 100
queue_run_max = 5
queue_interval = 15m
timeout_frozen_after = 7d

# ACL
acl_smtp_rcpt = acl_check_rcpt
acl_smtp_data = acl_check_data

begin acl

acl_check_rcpt:
  accept  hosts = : @[]
  deny    message = Gecersiz HELO/EHLO
          condition = ${if isip{$sender_helo_name}{true}{false}}
  accept  domains = +local_domains
  accept  hosts = +relay_from_hosts
  accept  domains = +relay_to_domains
          !dnslists = zen.spamhaus.org
          endpass
          message = IP kara listede: $dnslist_domain
  deny    message = Relay yetkisi yok

acl_check_data:
  deny    condition = ${if >{$message_size}{52428800}}
          message = 50MB boyut limiti asildi
  accept

begin routers

backup_mx_route:
  driver = manualroute
  domains = +relay_to_domains
  transport = remote_smtp_transport
  route_list = example.com  mail1.example.com ; 
               example.org  mail1-alt.example.com
  no_more

dnslookup:
  driver = dnslookup
  domains = ! +local_domains
  transport = remote_smtp_transport
  ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8
  no_more

begin transports

remote_smtp_transport:
  driver = smtp
  hosts_try_starttls = *
  connect_timeout = 30s

begin retry

mail1.example.com  *  F,2h,15m; G,16h,2h,1.5; F,4d,8h
*                  *  F,2h,15m; G,16h,1h,1.5; F,5d,6h

begin rewrite
begin authenticators

Yapılandırmayı uyguladıktan sonra test edin:

# Syntax kontrolü
exim -bV

# Yapılandırma testini çalıştır
exim -C /etc/exim4/exim4.conf -bV

# Test maili gönder (routing test)
exim -bt [email protected]

# Servisi yeniden başlat
systemctl restart exim4

# Durumu kontrol et
systemctl status exim4
journalctl -u exim4 -f

Sonuç

Exim ile backup MX yapılandırması, doğru yapıldığında mail altyapınıza ciddi bir dayanıklılık katıyor. Özetlemek gerekirse kritik noktalar şunlardır:

  • DNS MX öncelikleri doğru ayarlanmalı, backup MX yüksek değer almalı
  • ACL kuralları backup MX’i açık relay olmaktan korumalı
  • Retry politikaları birincil sunucunuzun tipik downtime süresine göre ayarlanmalı
  • SPF kayıtları backup MX IP’sini kapsayacak şekilde güncellenmeli
  • İzleme scriptleri birincil sunucu geri geldiğinde kuyruğu otomatik işlemeli
  • Log takibi düzenli yapılmalı, frozen mailler birikip taşmamalı

Bakım pencerelerinden önce backup MX’inizi gerçek bir failover testiyle mutlaka doğrulayın. Teoride çalışan bir yapılandırma, gerçek kriz anında sizi hayal kırıklığına uğratabilir. Ayda bir kez birincil sunucunuzu kasıtlı olarak kapatıp backup MX’in devreye girdiğini ve maillerin birincil geri gelince iletildiğini gözlemlemenizi kesinlikle öneririm.

Yorum yapın