Zimbra Mail Sunucusu Nedir ve Mimarisi

E-posta altyapısı söz konusu olduğunda, kurumsal ortamlarda Exchange’e alternatif arayan sistem yöneticilerinin aklına ilk gelen açık kaynak çözümlerden biri Zimbra’dır. Yıllarca farklı ölçekteki kurumlarda Zimbra kurulumu yapıp yönettim; küçük bir belediyeden binlerce kullanıcıya sahip üniversitelere kadar. Bu yazıda Zimbra’nın ne olduğunu, nasıl bir mimariye sahip olduğunu ve bu mimarinin günlük yönetim kararlarınızı nasıl etkilediğini anlatmaya çalışacağım.

Zimbra Nedir?

Zimbra, Synacor tarafından geliştirilen (önceki sahipleri arasında Yahoo ve Telligent de yer alıyor) açık kaynak kodlu bir e-posta ve işbirliği platformudur. Sadece bir SMTP sunucusu değil; e-posta, takvim, kişiler, görev yönetimi ve dosya paylaşımını tek çatı altında toplayan tam kapsamlı bir Collaboration Suite‘tir.

İki farklı sürümü vardır:

• Zimbra Open Source Edition (OSE): Tamamen ücretsiz, topluluk destekli sürüm
• Zimbra Network Edition (NE): Ücretli, kurumsal destek, gelişmiş özellikler (S/MIME, HSM, Outlook connector vb.)

Pek çok kurum OSE ile başlayıp sonradan NE’ye geçer. Eğer Active Directory entegrasyonu veya Outlook desteği kritikse NE’yi doğrudan değerlendirmenizi öneririm; sonradan geçiş yapmak düşündüğünüzden daha zahmetli olabiliyor.

Zimbra’nın Genel Mimarisi

Zimbra, monolitik bir yapı değildir. Birden fazla servisin bir arada çalıştığı, her biri belirli bir işlevi üstlenen modüler bir mimariye sahiptir. Bu yapıyı anlamak, hem kurulum hem de sorun giderme süreçlerinde hayat kurtarır.

Temel olarak Zimbra şu bileşenlerden oluşur:

• MTA (Message Transfer Agent): Postfix tabanlı, gelen ve giden e-posta trafiğini yönetir
• Mailbox (Store) Servisi: E-postaların, takvimlerin ve kişilerin depolandığı katman
• LDAP: Kullanıcı ve yapılandırma bilgilerini tutan dizin servisi
• Proxy: HTTP ve IMAP/POP3 proxy katmanı (Nginx tabanlı)
• Antispam/Antivirus: Amavis, SpamAssassin ve ClamAV entegrasyonu
• Memcached: Oturum ve önbellekleme servisi
• Logger: İstatistik ve log toplama bileşeni

# Zimbra servislerinin durumunu görüntülemek için
su - zimbra
zmcontrol status

Tipik bir çıktı şöyle görünür:

Host mail.sirket.com.tr
        antispam                Running
        antivirus               Running
        ldap                    Running
        logger                  Running
        mailbox                 Running
        memcached               Running
        mta                     Running
        proxy                   Running
        snmp                    Running
        spell                   Running
        stats                   Running
        zmconfigd               Running

Eğer bu listede herhangi bir servis “Stopped” görünüyorsa, o servisin loglarına bakmak ilk adımınız olmalı.

MTA Katmanı: Postfix ve Zimbra’nın Bütünleşmesi

Zimbra’nın e-posta alıp gönderme işlemlerini Postfix üstlenir; ancak bu standart bir Postfix kurulumu değildir. Zimbra, Postfix’i kendi yapılandırma şablonları ve politikaları üzerinden yönetir.

Gelen bir e-postanın izlediği yol şöyledir:

• Dış dünyadan gelen SMTP bağlantısı Postfix’e ulaşır (port 25)
• Postfix, Amavis’e yönlendirir (port 10024) – spam ve virüs kontrolü burada yapılır
• Temiz olduğu doğrulanan mesaj tekrar Postfix’e döner (port 10025)
• Postfix, mesajı LMTP protokolü üzerinden Mailbox servisine iletir (port 7025)

# Postfix kuyruğunu görüntülemek
su - zimbra
postqueue -p

# Kuyruktaki tüm mesajları zorla göndermek
postqueue -f

# Belirli bir mesajı kuyruktan silmek
postsuper -d MESAJ_ID

Şunu da belirteyim: Zimbra’nın Postfix yapılandırmasını doğrudan /etc/postfix/main.cf üzerinden değiştirmeniz önerilmez. Zimbra’nın kendi araçlarını kullanmalısınız, aksi hâlde bir servis yeniden başlatıldığında değişikliklerinizin ezildiğini görebilirsiniz. Bu acı deneyimi bir üretim ortamında yaşamak istemezsiniz.

# Zimbra üzerinden Postfix parametresi değiştirme
zmprov mcf zimbraMtaMaxMessageSize 20480000

# Değişikliği uygulamak için MTA'yı yeniden başlat
zmmtactl restart

LDAP: Zimbra’nın Beyni

Zimbra, kullanıcı bilgilerini, domain yapılandırmalarını, dağıtım listelerini ve sistem politikalarını OpenLDAP tabanlı kendi LDAP sunucusunda tutar. Bu yapı çok önemlidir; çünkü Zimbra’nın neredeyse her bileşeni bu LDAP’a danışır.

# LDAP'ta bir kullanıcı aramak
su - zimbra
ldapsearch -x -H ldap://localhost:389 -D "uid=zimbra,cn=admins,cn=zimbra" 
  -w $(zmlocalconfig -s zimbra_ldap_password) 
  -b "dc=sirket,dc=com,dc=tr" 
  "([email protected])"

Zimbra’nın kendi komut satırı aracı olan zmprov ise bu LDAP işlemlerini soyutlar ve daha kullanıcı dostu hâle getirir:

# Tüm kullanıcıları listele
zmprov -l gaa

# Belirli bir kullanıcının detaylarını görüntüle
zmprov ga [email protected]

# Yeni kullanıcı oluştur
zmprov ca [email protected] GucluSifre123 
  displayName "Ahmet Yılmaz" 
  givenName "Ahmet" 
  sn "Yılmaz"

LDAP Replikasyonu ve Yüksek Erişilebilirlik

Çoklu sunucu kurulumlarında (multi-server deployment), bir LDAP master ve bir veya birden fazla LDAP replica kurulur. Replikasyon sorunları, son derece şaşırtıcı belirtilere yol açabilir: bazı kullanıcılar giriş yapabilirken diğerleri yapamaz, henüz silinmemiş bir kullanıcı var olmayan biri gibi davranabilir. LDAP replikasyonunu düzenli izlemenizi kesinlikle tavsiye ederim.

# LDAP replikasyon durumunu kontrol et
su - zimbra
ldapsearch -x -H ldap://localhost:389 
  -D "cn=config" 
  -w $(zmlocalconfig -s ldap_root_password) 
  -b "cn=config" 
  "(objectClass=olcSyncRepl)"

Mailbox Servisi: E-postaların Evi

Mailbox servisi (bazen “store” olarak da anılır), Tomcat üzerinde çalışan bir Java uygulamasıdır. E-postaların, takvimlerin, kişilerin depolanmasından; IMAP, POP3, HTTP ve SOAP isteklerinin işlenmesinden sorumludur.

Posta kutuları dosya sistemi üzerinde şu yapıda tutulur:

# Posta kutusu dizin yapısı
ls /opt/zimbra/store/0/

# Belirli bir kullanıcının mailbox ID'sini öğren
zmprov ga [email protected] zimbraMailboxId

# Posta kutusunun boyutunu kontrol et
zmmailbox -z -m [email protected] getMailboxSize

Mailbox Servisinin Java Heap Ayarları

Deneyimlerime göre Zimbra kurulumlarında en sık karşılaşılan performans sorunlarından biri, yetersiz Java heap boyutudur. Özellikle kullanıcı sayısı arttıkça mailbox servisi bellek baskısı altında kalır.

# Mevcut Java heap ayarlarını görüntüle
zmlocalconfig zimbra_server_xmx

# Heap boyutunu değiştir (örneğin 8GB'a çıkar)
zmlocalconfig -e mailboxd_java_heap_size=8192

# Değişikliği uygulamak için mailbox servisini yeniden başlat
zmmailboxdctl restart

Genel kural olarak: sunucunuzda 32GB RAM varsa ve yalnızca mailbox rolü çalışıyorsa, 16-20GB heap vermek makul bir başlangıç noktasıdır. Gerisi işletim sistemi ve disk önbellekleme için bırakılmalıdır.

Proxy Katmanı: Nginx’in Rolü

Zimbra Proxy, istemcilerden gelen HTTP(S), IMAP(S) ve POP3(S) bağlantılarını arka plandaki mailbox sunucularına yönlendiren bir reverse proxy katmanıdır. Nginx tabanlıdır ve Zimbra’nın çok sunuculu dağıtımlarında yük dağılımını da üstlenir.

# Proxy servisinin konfigürasyonunu görüntüle
zmprov gs $(zmhostname) | grep -i proxy

# Proxy üzerinden geçen bağlantıları anlık izle
tail -f /opt/zimbra/log/nginx.access.log

# HTTP proxy portunu değiştir
zmprov ms $(zmhostname) zimbraMailProxyPort 80
zmprov ms $(zmhostname) zimbraMailSSLProxyPort 443
zmproxyctl restart

Dış dünyaya açık olan portların proxy üzerinden geçmesi, güvenlik açısından iyi bir pratiktir. Mailbox servislerini doğrudan internete açmak yerine proxy katmanını kullanın.

Antispam ve Antivirus: Amavis, SpamAssassin ve ClamAV

Zimbra’nın spam ve virüs filtreleme altyapısı üç bileşenden oluşur:

• Amavis: Koordinatör görevi görür; e-postaları SpamAssassin ve ClamAV’a iletir, sonuçlara göre aksiyon alır
• SpamAssassin: Spam puanlama motoru
• ClamAV: Açık kaynak antivirüs motoru

# SpamAssassin skorunu test etmek
su - zimbra
echo "Test mesajı" | spamc -c

# ClamAV veritabanını güncelle
/opt/zimbra/common/bin/freshclam --config-file=/opt/zimbra/conf/freshclam.conf

# Amavis loglarını takip et
tail -f /opt/zimbra/log/zimbra.log | grep amavis

Spam Eşik Değerlerini Ayarlama

Varsayılan spam eşik değerleri her ortam için uygun olmayabilir. Çok agresif ayarlar meşru e-postaları bloklarken çok gevşek ayarlar spam yağmuruna neden olur.

# Spam işaretleme eşiğini görüntüle
zmprov gcf zimbraSpamKillPercent
zmprov gcf zimbraSpamTagPercent

# Spam eşik değerlerini ayarla
# 75: Spam olarak işaretle, 99: Engelle
zmprov mcf zimbraSpamTagPercent 75
zmprov mcf zimbraSpamKillPercent 99

Çok Sunuculu (Multi-Server) Mimari

Küçük kurumlar için tek sunucu yeterli olabilir; ancak binlerce kullanıcıya sahip ortamlarda rollerin farklı sunuculara dağıtılması gerekir.

Tipik bir kurumsal Zimbra mimarisi şöyle görünebilir:

• LDAP Master Sunucu: Merkezi dizin servisi
• MTA Sunucular: Gelen/giden e-posta trafiği (genellikle 2 adet, yüksek erişilebilirlik için)
• Mailbox Sunucular: Posta kutusu depolama (kullanıcı sayısına göre ölçeklenir)
• Proxy Sunucular: İstemci bağlantıları, yük dengeleme

# Bir sunucuya yüklü Zimbra rollerini görüntüle
zmprov gs $(zmhostname) zimbraServiceInstalled

# Tüm Zimbra sunucularını listele
zmprov gas

# Belirli bir sunucunun özelliklerini görüntüle
zmprov gs mailbox01.sirket.com.tr

Sunucular Arası İletişim

Zimbra bileşenleri arası iletişim için kullanılan bazı kritik portlar:

• 25: SMTP (MTA – dış dünya)
• 389/636: LDAP/LDAPS
• 443: HTTPS (Proxy – istemciler)
• 993/995: IMAPS/POP3S (Proxy – istemciler)
• 7025: LMTP (Postfix – Mailbox)
• 7071: Zimbra Admin Console
• 7110/7143: POP3/IMAP (iç, proxy arkasında)

# Sunucular arası bağlantıyı test et
su - zimbra
zmhostname
nc -zv ldap-sunucu.sirket.com.tr 389
nc -zv mailbox01.sirket.com.tr 7025

Veri Depolama ve Yedekleme Stratejisi

Zimbra’nın verileri birkaç farklı konumda bulunur ve yedekleme stratejiniz bunların hepsini kapsamalıdır:

• /opt/zimbra/store: E-posta mesajları
• /opt/zimbra/index: Arama indeksleri
• /opt/zimbra/db: MySQL/MariaDB veritabanı (metadata)
• /opt/zimbra/data/ldap: LDAP veritabanı

# Zimbra'nın yerleşik yedekleme aracını çalıştır (NE gerektirir)
zmbackup -f -a all

# OSE için manuel LDAP yedeği al
su - zimbra
/opt/zimbra/libexec/zmslapcat /yedek/dizin/

# MySQL/MariaDB yedeği için
mysqldump -u zimbra -p$(zmlocalconfig -s zimbra_mysql_password) 
  --all-databases > /yedek/dizin/zimbra_db_$(date +%Y%m%d).sql

Gerçek bir senaryodan bahsedeyim: Bir üniversite ortamında çalışırken disk dolduğu için Zimbra servisinin çöktüğüne tanık oldum. Sorun, arama indekslerinin düzgün temizlenmemesinden kaynaklanıyordu. O günden beri disk kullanımını ve indeks boyutlarını düzenli izlemenin ne kadar kritik olduğunu bilirim.

# Disk kullanımını Zimbra dizinleri özelinde kontrol et
du -sh /opt/zimbra/store/
du -sh /opt/zimbra/index/
du -sh /opt/zimbra/db/

# Eski log dosyalarını temizle
find /opt/zimbra/log -name "*.log.*" -mtime +30 -delete

Günlük İzleme ve Sorun Giderme

Zimbra’yı sağlıklı tutmanın anahtarı proaktif izlemedir. Sorun çıktıktan sonra koşturmak yerine erken uyarı sistemleri kurmak uzun vadede çok daha az yorucu.

# Zimbra log akışını izle
tail -f /opt/zimbra/log/zimbra.log

# Başarısız giriş denemelerini bul
grep "authentication failed" /opt/zimbra/log/zimbra.log | 
  awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

# Son 24 saatte gönderilen/alınan e-posta istatistikleri
zmprov -l gqu -a | awk '{sum += $3} END {print "Toplam kullanılan:", sum, "MB"}'

# Servis sağlık kontrolü scripti
su - zimbra -c "zmcontrol status" | grep -v Running

Zabbix veya Prometheus gibi izleme araçlarını kullanıyorsanız, Zimbra’nın SNMP desteğini aktif edebilir ve metrikleri bu sistemlere besleyebilirsiniz. Ayrıca Zimbra Admin Console üzerindeki “Monitor” bölümü temel istatistikleri görsel olarak sunar; ancak gerçek bir izleme çözümünün yerini tutmaz.

Sonuç

Zimbra, doğru anlaşıldığında ve doğru yapılandırıldığında kurumsal ortamlarda güçlü ve güvenilir bir e-posta platformu olabilir. Ancak “kur ve unut” mantığıyla yaklaşılacak bir sistem değil; mimarisini anlayan, servisler arası ilişkileri kavramış ve proaktif izleme kurmuş bir ekibin elinde en iyi şekilde çalışır.

Bu yazıda anlattığım mimariyi kavramak, ilerleyen aşamalarda yapacağınız kurulum, yapılandırma ve sorun giderme çalışmalarında sağlam bir temel oluşturacaktır. MTA’nın neden bağımsız bir katman olduğunu, LDAP’ın neden bu kadar merkezi bir rol oynadığını ve proxy katmanının neden atlanmaması gerektiğini anladığınızda, Zimbra yönetimi çok daha az sürpriz içerir.

Bir sonraki yazıda Zimbra’nın adım adım kurulum sürecine geçeceğiz; sunucu ön hazırlığından ilk servis başlatmaya kadar her aşamayı ele alacağız.