E-Posta Sunucusu Disk Doldu: Acil Temizleme ve Önleme Rehberi

Sabah ilk iş e-postanızı göndermeye çalıştığınızda sunucunun yanıt vermediğini, gelen kutunuzun yeni mesaj almadığını ya da kullanıcıların "452 4.3.1 Insufficient system storage" hatasıyla karşılaştığını fark ettiniz. Bu, e-posta sunucusu diskinin dolduğunun en yaygın belirtisidir ve dakikalar içinde müşteri iletişimini, sipariş akışını ve kurumsal itibarı doğrudan etkiler. Aşağıdaki rehber, acil müdahaleden kalıcı önleme stratejilerine kadar sistematik bir yol haritası sunar.

Sorunun Anatomisi: Disk Neden Dolar?

E-posta sunucularında disk dolması tek bir nedene bağlı değildir. RFC 5321'de tanımlanan SMTP protokolü, teslim edilemeyen mesajları yeniden deneme kuyruğuna (deferred queue) alır; bu kuyruk zamanla onlarca gigabayta ulaşabilir. Bunun yanı sıra Postfix, Exim veya Sendmail gibi MTA'ların (Mail Transfer Agent) ürettiği log dosyaları, düzgün döndürülmediğinde (log rotation) hızla büyür. Kullanıcı posta kutularındaki büyük ekler, özellikle IMAP protokolüyle sunucuda depolanan mesajlar, kurumsal ortamlarda en öngörülemeyen disk tüketim kaynağı olur.

Spam ve kötü amaçlı yazılım kaynaklı posta patlamaları da kritik bir etkendir. Bir kullanıcı hesabı ele geçirildiğinde sunucu dakikada binlerce mesaj üretebilir; bu hem kuyruğu hem de log dizinini şişirir. Aynı zamanda Dovecot, Cyrus veya Courier gibi IMAP/POP3 sunucularının indeks ve önbellek dosyaları da beklenmedik ölçekte yer kaplayabilir.

Acil Durum Müdahalesi: Adım Adım

1. Durumu Tespit Edin

İlk adım hangi bölümün dolu olduğunu anlamaktır:

df -h
du -sh /var/log/mail* /var/spool/postfix/* /var/mail/* 2>/dev/null | sort -rh | head -20

df -h çıktısında %100 ya da Use% sütununda yüksek değer gören bölümü not edin. Genellikle suçlu /var veya kök bölümdür.

2. Postfix Kuyruğunu Temizleyin

Deferred (ertelenmiş) kuyruk hızla şişer. Kuyruğun boyutunu görmek için:

postqueue -p | tail -1

Tüm ertelenmiş mesajları silmek için:

postsuper -d ALL deferred

Yalnızca belirli bir gönderenden gelen mesajları silmek için:

postqueue -p | grep "spammer@example.com" | awk '{print $1}' | tr -d '!' | postsuper -d -

3. Exim Kuyruğunu Temizleyin

Exim kullanan sunucularda (cPanel/WHM ortamları dahil) dondurulmuş mesajları temizlemek için:

exim -bp | exiqgrep -z | xargs exim -Mrm

Kuyrukta toplam mesaj sayısını görmek için exim -bpc komutunu kullanın.

4. Log Dosyalarını Temizleyin

/var/log/mail.log ya da /var/log/maillog dosyaları gigabaytlara ulaşmış olabilir. Dosyayı silmeden içini boşaltmak için:

# Dosyayı silmeden içini temizle (çalışan process dosyayı tutmaya devam eder)
> /var/log/mail.log

# Logrotate ile hemen döndür
logrotate -f /etc/logrotate.d/rsyslog

5. Büyük Dosyaları Bulun ve Değerlendirin

find /var /home /root -type f -size +100M 2>/dev/null | xargs ls -lh | sort -k5 -rh | head -20

Bu komut 100 MB'ın üzerindeki dosyaları boyuta göre sıralar. Eski .gz log arşivleri, atıl veritabanı yedekleri veya büyük ek dosyaları burada görünür.

Disk Kullanımı Dağılımı: Tipik Senaryo

Sunucuyu Yeniden Başlatmadan Önce

Disk dolduğunda MTA'lar genellikle yeni bağlantı kabul etmeyi durdurur ve gönderici sunuculara 452 (geçici hata) ya da 552 (kalıcı hata) SMTP durum kodlarını döner. RFC 5321 Bölüm 4.2'ye göre 4xx serisi geçici hata, 5xx serisi ise kalıcı redddir. Gönderici sunucu, 4xx kodunu aldığında RFC 5321 Bölüm 4.5.4'te belirtilen yeniden deneme mekanizmasını devreye sokar ve mesajı kendi kuyruğunda tutar; bu nedenle disk sorununuzu çözdükten sonra gönderici taraftaki mesajlar otomatik olarak yeniden iletilir.

Temizleme işlemleri tamamlandıktan sonra MTA'yı yeniden başlatın:

# Postfix
systemctl restart postfix

# Exim
systemctl restart exim4

Kalıcı Önleme Stratejileri

Log Rotasyonu Yapılandırın

/etc/logrotate.d/postfix dosyasına aşağıdaki gibi bir yapılandırma ekleyin:

/var/log/mail.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        systemctl reload postfix > /dev/null 2>&1 || true
    endscript
}

Posta Kutusu Kotaları Tanımlayın

Dovecot'ta kullanıcı başına kota tanımlamak için /etc/dovecot/conf.d/90-quota.conf dosyasını düzenleyin:

plugin {
    quota = maildir:User quota
    quota_rule = *:storage=5G
    quota_warning = storage=90%% quota-warning 90 %u
}

Bu yapılandırma her kullanıcıyı 5 GB ile sınırlar ve %90 dolduğunda uyarı gönderir.

Disk Kullanımı İçin Otomatik Uyarı Kurun

Basit bir cron + bash betiğiyle disk kullanımını izleyebilirsiniz:

#!/bin/bash
THRESHOLD=85
USAGE=$(df / | awk 'NR==2 {print $5}' | tr -d '%')
if [ "$USAGE" -ge "$THRESHOLD" ]; then
    echo "DİKKAT: / bölümü %$USAGE dolu." | mail -s "Disk Uyarısı" admin@domain.com
fi

Bu betiği /etc/cron.d/disk-check olarak saatlik çalışacak şekilde tanımlayın.

SPF, DKIM ve DMARC ile Spam Hacmini Azaltın

Gelen spam trafiği kuyrukları ve log dosyalarını besler. RFC 7208'de tanımlanan SPF (Sender Policy Framework), RFC 6376'da tanımlanan DKIM (DomainKeys Identified Mail) ve RFC 7489'da tanımlanan DMARC politikalarının doğru yapılandırılması, alanınızı taklit eden sahte mesajların sunucunuza girmesini önler. Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services) panelleri, alanınızın itibarını ve gelen spam oranını ücretsiz olarak izlemenize olanak tanır.

Amavis / SpamAssassin Karantinasını Sınırlayın

Amavis karantina dizininin TTL'sini (time-to-live) kısıtlayın; aksi takdirde tespit edilen spam mesajları sonsuza dek birikir:

# /etc/amavis/conf.d/50-user
$max_age_of_quarantine = 7;  # gün

İzleme ve Raporlama

Pflogsumm, Postfix log dosyalarını ayrıştırarak günlük özet raporlar üretir ve hangi alanların en fazla trafiği oluşturduğunu gösterir. mailgraph aracı ise RRDtool tabanlı grafiklerle saatlik/günlük trafik ve hata oranlarını görselleştirir. Kurumsal ortamlarda Prometheus'un node_exporter modülü disk kullanım metriklerini toplar; Grafana üzerinde tanımlanan eşik uyarıları (alert rules) disk dolmadan önce operasyon ekibini bilgilendirir.

Sık Sorulan Sorular