VPS üzerinde Mailpit ile tek kullanımlık e-posta kurulumu

Tek kullanımlık e-posta kutusu nedir

Tek kullanımlık e-posta kutusu, her adrese gelen postayı kabul eden ancak hiçbirini iletmeyen küçük bir SMTP (simple mail transfer protocol) sunucusudur. Hazırlık (staging) ortamındaki uygulamanız, gerçek bir e-posta sağlayıcısı yerine bu sunucuya gönderim yapar ve tüm iletiler burada durur. Gelen iletileri bir web arayüzü üzerinden okursunuz; böylece hatalı bir alıcı listesi veya bozuk bir şablon size bir maliyet çıkarmaz, çünkü posta kutudan asla dışarı çıkmaz.

Bu kılavuz, Docker Compose kullanarak tek bir VPS üzerinde böyle bir sistemin nasıl kurulacağını açıklar. Mailpit, tüm postaları yakalayan bir havuz görevi görür. SMTP dinleyicisi yalnızca uygulamanızın erişebileceği şekilde sınırlandırılmış, web arayüzü ise nginx arkasında transport layer security (TLS) ve parola koruması ile yapılandırılmıştır; ayrıca bir saklama sınırı, posta kutusunun diski doldurmasını engeller. Eğer Compose yapısına aşina değilseniz, VPS için temel Compose bilgileri bölümü, bu kılavuzun varsaydığı dosya düzenini kapsamaktadır.

Elde edilen sonuç bir e-posta sunucusu değil, bir test aracıdır. Hesap yönetimi, posta iletimi veya spam filtreleme özellikleri bulunmaz. Gerçek kullanıcılar için gerçek posta kutuları Mailcow gibi tam kapsamlı bir e-posta sunucusu gerektirir ve çok daha büyük bir iş yüküdür.

Mailpit, Inbucket ve MailHog: hangi e-posta havuzu kullanılmalı

Bu işi yapan üç araç mevcuttur. Bu araçları birbirinden ayıran özellikler; bakım durumları, dinledikleri portlar ve mesajları kabul ettikten sonra neler yapabildikleridir. Aşağıdaki sürümler Ağustos 2026 itibarıyla kontrol edilmiştir.

MailHog (mailhog/mailhog), SMTP için 1025 numaralı portu dinler ve arayüzünü 8025 üzerinden sunar. Hâlâ çalışmaktadır. Varsayılan dalı Ağustos 2022'den beri herhangi bir commit almamıştır ve takip sisteminde 250'den fazla açık sorun bulunmaktadır; bu nedenle test ortamınızda yamalanmamış bağımlılıklar çalıştırıyor olursunuz. Yeni projelerde kullanmayınız.

Inbucket (inbucket/inbucket), SMTP için 2500, web arayüzü için 9000 ve POP3 (post office protocol version 3) için 1100 numaralı portları dinler. Sürüm 3.1.1, Aralık 2025'te yayınlanmıştır. Mesajları /storage altında dosya olarak saklar ve bunları kendi kendine temizler: imaj, INBUCKET_STORAGE_RETENTIONPERIOD=72h ve INBUCKET_STORAGE_MAILBOXMSGCAP=300 değerlerini ayarlar. Bir testin HTTP çağrısı yerine bir POP3 istemci kütüphanesi ile e-posta toplaması gerektiğinde bu aracı seçin.

Mailpit (axllent/mailpit), MailHog ile aynı portları (1025 ve 8025) kullanır; bu sayede uygulama yapılandırmasına dokunmadan MailHog'un yerini alır. Sürüm 1.30.7, 8 Ağustos 2026 tarihinde yayınlanmıştır. Bu kılavuzun ihtiyaç duyduğu özellikleri ikili dosya (binary) içerisinde barındırır: web arayüzü ve API (application programming interface) için parola dosyası, mesaj sınırı, yaş sınırı ve alıcı filtresi. Bu kılavuzun geri kalanında Mailpit kullanılmaktadır.

Catch-all mekanizması nasıl çalışır ve DNS neden devreye girmez

Uygulamanız burada nereye teslimat yapacağını sorgulamaz. Uygulamaya bir host ve port verirsiniz, o da bir TCP bağlantısı açar ve RCPT TO:<anyone@example.test> bildirimi yapar. Mailpit, alıcı ne derse desin bunu kabul eder, iletiyi depolar ve hiçbir yere iletmez. Alan adı hiçbir zaman çözümlenmez; bu nedenle .test alan adı sistemi (DNS) içinde hiçbir yerde bulunmayan ayrılmış bir isim olsa bile example.test çalışır.

Tüm mekanizma bundan ibarettir ve gelen kutusunun varsayılan olarak güvenli olmasının nedeni budur. Hiçbir MX (mail exchanger) kaydı devreye girmez, teslimat denemesi yapılmaz ve hiçbir ileti gerçek bir kişiye ulaşamaz.

Staging uygulamanızı sink noktasına yönlendirin

Uygulama aynı Compose projesi içerisinde bir container olarak çalıştığında SMTP sunucusunu mailpit, ana makine (host) üzerinde çalıştığında ise 127.0.0.1 olarak ayarlayın. Portu 1025 olarak belirleyin, TLS özelliğini kapatın ve kullanıcı adı ile parola alanlarını boş bırakın. Mailpit anonim postaları kabul eder.

Bazı framework'ler kimlik bilgileri olmadan gönderim yapmayı reddeder. MP_SMTP_AUTH_ACCEPT_ANY=1 ayarı, Mailpit'in herhangi bir kullanıcı adı ve parolayı kabul etmesini sağlar; MP_SMTP_AUTH_ALLOW_INSECURE=1 ise şifrelenmemiş bir bağlantı üzerinde PLAIN ve LOGIN mekanizmalarına izin verir. Bu iki ayar, yalnızca dinleyici internete kapalı olduğu için burada güvenlidir; aşağıdaki dağıtım yapılandırması da bunu zorunlu kılar.

MP_SMTP_ALLOWED_RECIPIENTS ayarının ilk günden yapılması önerilir. Bu ayar bir düzenli ifade (regular expression) alır ve bu ifadeyle eşleşmeyen tüm alıcıları reddeder. Ayarı test alan adınıza yönlendirin; böylece gerçek müşteri adresi içeren bir staging veritabanı, mesajın sessizce sink noktasına düşmesi yerine uygulama günlüğünde görünür bir hata üretir.

Docker Compose dosyası

Önce dizini oluşturun ve web arayüzü için bir parola dosyası hazırlayın. htpasswd -B bir bcrypt özeti yazar; Mailpit hem bcrypt hem de düz metin formatını okuyabilir.

mkdir -p ~/mailpit/data
cd ~/mailpit
sudo apt update && sudo apt install -y apache2-utils
htpasswd -B -c data/ui-auth qa

compose.yaml dosyasını oluşturun:

services:
  mailpit:
    image: axllent/mailpit:v1.30
    container_name: mailpit
    restart: unless-stopped
    ports:
      - "127.0.0.1:8025:8025"
      - "127.0.0.1:1025:1025"
    volumes:
      - ./data:/data
    environment:
      MP_DATABASE: /data/mailpit.db
      MP_MAX_MESSAGES: 2000
      MP_MAX_AGE: 14d
      MP_UI_AUTH_FILE: /data/ui-auth
      MP_SMTP_AUTH_ACCEPT_ANY: 1
      MP_SMTP_AUTH_ALLOW_INSECURE: 1
      MP_SMTP_ALLOWED_RECIPIENTS: '@example\.test$$'

Çift dolar işareti bir yazım hatası değildir. Compose, tek bir $ işaretini genişletilecek bir değişkenin başlangıcı olarak algılar; bu nedenle $$, konteynere tek bir gerçek dolar işareti aktarmanın yoludur. Düzenli ifade (regex), Mailpit'e @example\.test$ olarak ulaşır.

Servisi başlatın ve sağlık durumunu kontrol edin:

docker compose up -d
docker compose ps

STATUS sütunu Up ... (healthy) değerini göstermelidir. İmaj, her 15 saniyede bir /mailpit readyz komutunu çalıştıran kendi sağlık kontrolü mekanizmasına sahiptir; bu nedenle starting durumunda kalan veya unhealthy durumuna geçen bir konteyner, içeride 8025 numaralı port üzerinden hizmet vermiyor demektir. Başka bir değişiklik yapmadan önce docker compose logs mailpit dosyasını okuyun.

Yayınlanan her iki port da bir adres taşır ve bu adres güvenlik kontrolünü sağlar. Mailpit, konteyner içerisinde 0.0.0.0 portunu dinler; konteynerin kendi ağ ad alanı (network namespace) olduğu için bu durum sorun teşkil etmez. Eşleştirmenin sol tarafı, dışarıdan kimin erişebileceğini belirler. 8025:8025 yazarsanız, Docker genel IP adresi dahil olmak üzere ana makinedeki tüm adreslere bağlanır.

Eğer test uygulamanız aynı dosya içerisindeki bir servis ise, 1025 eşleştirmesini tamamen silin ve uygulamayı 1025 numaralı port üzerinden mailpit ana makine adına yönlendirin. Paylaşımlı bir Compose ağı üzerindeki konteynerler birbirlerine doğrudan erişebilir; bu sayede SMTP portu hiçbir şekilde ana makineye temas etmez. Compose ağlarının servis adlarını nasıl çözümlediği konusu bu eşleştirmeyi açıklamaktadır.

Bir mesaj gönderin ve ulaştığını doğrulayın

python3 - <<'EOF'
import smtplib
from email.message import EmailMessage

m = EmailMessage()
m["From"] = "staging@example.test"
m["To"] = "anyone@example.test"
m["Subject"] = "Mailpit smoke test"
m.set_content("If this appears in the web interface, the sink works.")
with smtplib.SMTP("127.0.0.1", 1025) as s:
    s.send_message(m)
EOF

Komut dosyası başarılı olduğunda herhangi bir çıktı vermez. Mesajın API üzerinden depolandığını şu şekilde doğrulayın:

curl -s -u qa:yourpassword http://127.0.0.1:8025/api/v1/messages

Bu komut, depolanan mesajları listeleyen bir JSON çıktısı döndürür. -u bayrağını kaldırırsanız aynı istek reddedilir; çünkü MP_UI_AUTH_FILE hem API'yi hem de web arayüzünü birlikte korur. Gelen kutusunu okuyan her testin bu kimlik bilgilerini de göndermesi gerekir.

Python betiğinden gelen bir ConnectionRefusedError hatası, 127.0.0.1:1025 üzerinde hiçbir servisin dinleme yapmadığı anlamına gelir. SMTP eşlemesini kaldırdıysanız bu beklenen bir sonuçtur; bu durumda kontrolün aynı Compose ağı üzerindeki bir container içinden çalıştırılması gerekir.

Web arayüzünü nginx üzerinden parola ile yayınlama

Arayüz şu anda yalnızca loopback adresi üzerinden yanıt vermektedir. nginx, TLS sonlandırmasını gerçekleştirir ve herhangi bir istek kendisine ulaşmadan önce parola sorar.

sudo htpasswd -B -c /etc/nginx/mailpit.htpasswd qa

server {
    listen 443 ssl;
    server_name mail-test.example.com;

    ssl_certificate     /etc/letsencrypt/live/mail-test.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail-test.example.com/privkey.pem;

    auth_basic           "mailpit";
    auth_basic_user_file /etc/nginx/mailpit.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:8025;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Sözdizimi kontrolünden sonra sudo nginx -t && sudo systemctl reload nginx ile yeniden yükleme yapın. Eğer bu ilk proxy yapılandırmanız ise Bir reverse proxy bloğundaki her yönergenin işlevi başlıklı yazıyı bir kez okumanız faydalı olacaktır.

nginx dosyasında ve data/ui-auth içinde aynı kullanıcı adı ve parolayı kullanın. nginx, tarayıcının Authorization başlığını yukarı yöne (upstream) iletir; bu sayede eşleşen kimlik bilgileri tek bir istem ile her iki kontrolü de karşılar. Farklı kimlik bilgileri kullanılması durumunda tarayıcı, ikinci kontrolün reddedeceği bir kimlik bilgisi setini tutmaya devam eder.

Upgrade ve Connection başlıkları süsleme amaçlı değildir. Mailpit, yeni postaları açık bir sayfaya WebSocket üzerinden iletir; bu başlıklar olmadan HTTP/1.1 çalıştıran bir proxy bağlantıyı yükseltemez (upgrade). Bu durumda sayfa düzgün yüklenir ancak hiçbir zaman güncellenmez: posta gelir, API bunu gösterir ancak siz sayfayı yenileyene kadar liste sabit kalır.

Her iki kilidi de koruyun. nginx parolası genel adresi korur, MP_UI_AUTH_FILE ise 8025 numaralı portun kendisini korur. Bu önemlidir çünkü staging uygulamanızın oluşturduğu her parola sıfırlama bağlantısı bu arayüz üzerinden okunabilir durumdadır.

Sink'in açık bir relay haline gelmesine asla izin vermeyin

Açık relay, herhangi birinden mesaj alıp bunu herhangi bir hedefe ileten bir SMTP sunucusudur. Spam göndericiler sürekli olarak bu tür sunucuları tarar; bir tane bulduklarında adresiniz kötüye kullanım raporlarıyla dolar ve hesabınız askıya alınır.

Mailpit, varsayılan olarak bir açık relay değildir çünkü asla iletme yapmaz. MP_SMTP_RELAY_CONFIG ile bir relay yapılandırma dosyası belirtmediğiniz sürece relay özelliği kapalı kalır ve arayüzdeki "release" (serbest bırakma) eylemi siz bunu yapana kadar hiçbir işlev görmez. Bu ayarın yapılandırılmamış bırakılması bilinçli bir tercihtir.

Bu özelliği kaybetmenin iki yolu vardır. Bir relay yapılandırıp "release" butonunu çalışır hale getirdikten sonra SMTP portunu internete açarsanız, çalışan bir açık relay oluşturmuş olursunuz. Portu relay olmadan açarsanız, yabancılar sizin üzerinizden e-posta gönderemez ancak depolama alanınızı doldurabilir ve ekibinizin güvendiği arayüze içerik yerleştirebilirler.

Docker ana bilgisayarındaki tuzak güvenlik duvarıdır. Bir portu dışarı açmak, Docker'ın kendi kurallarını nat tablosuna yazmasına neden olur; bu durumda konteynere yönelik trafik, ufw (uncomplicated firewall) kuralları devreye girmeden önce burada eşleşir. sudo ufw deny 1025/tcp başarı raporu verir ancak hiçbir şeyi değiştirmez. Docker neden portları ufw'yi devre dışı bırakarak yayınlar belgesi, zincir sırasını detaylıca açıklar.

Çözüm, güvenlik duvarı kuralı değil, eşleme (mapping) içindeki adrestir. Nelerin bağlı olduğunu kontrol edin:

sudo ss -ltnp | grep -E ':(1025|8025)'

Sağlıklı bir çıktı 127.0.0.1:1025 ve 127.0.0.1:8025 değerlerini gösterir. 0.0.0.0:1025 şeklinde bir satır, eşlemenin adresini kaybettiği ve sink'in interneti dinlediği anlamına gelir. Başka bir makineden yapılan nc -vz mail-test.example.com 1025 bağlantı denemesi zaman aşımına uğramalı veya reddedilmelidir.

Uygulama farklı bir sunucuda barındırılıyorsa, ikisini birbirine bağlamak için 1025 numaralı portu açmayın. Her iki makineyi de özel bir ağa veya VPN tüneline dahil edin ve eşlemeyi bu arayüz adresine bağlayın.

Yalnızca gerçek gelen e-postaları istiyorsanız MX kayıtlarını yayınlayın

Bir MX (mail exchanger) kaydı, diğer posta sunucularına bir alan adı için postayı hangi ana bilgisayarın kabul ettiğini bildirir. Geçici alan adınızda MX kaydı bulunmadığında, internetten hiçbir e-posta ulaşamaz; çünkü gönderen sunucuların postayı teslim edeceği bir yer yoktur. Gelen kutusu yalnızca kendi uygulamalarınızın gönderdiklerini tutar; test posta kutusunun amacı da budur.

Gerçek e-posta almak, sunucuyu işaret eden bir MX kaydı, 25 numaralı portta (MP_SMTP_BIND_ADDR=0.0.0.0:25) dinleme yapan Mailpit ve bu portun açık olması anlamına gelir. O andan itibaren, alan adındaki her adres için herkese açık bir "catch-all" (tümünü yakala) sistemi çalıştırıyor olursunuz. Aşağıdakilerin farkında olun.

• Kayıt göründükten sonraki birkaç gün içinde spam başlar, çünkü harvesters (veri toplayıcılar) DNS kayıtlarını okur. Sözlük saldırıları (dictionary attacks) yaygın isimleri dener ve her deneme için bir iletiyi depolar.
• Yabancılardan gelen ekler diskinize iner ve orada kalır. Bunları filtreleyen hiçbir şey yoktur; bu nedenle bilinmeyen bir göndericiden gelen arşiv, kendi test postalarınızın yanında durur.
• Alan adını öğrenen herkes, bu alan adındaki bir adresle üçüncü taraf hizmetlere kaydolabilir ve onay postası sunucunuza teslim edilir. Parola koruması bir şekilde aşılırsa, bu hesaplar gelen kutusunu okuyan herkesin eline geçer.
• Saklama sınırları artık bir temizlik işlemi olmaktan çıkıp yük taşıyıcı hale gelir, çünkü hacim artık sizin kontrolünüzde değildir.

Teslim edilebilirlik kontrolü için gerçek gelen e-postaya ihtiyacınız varsa, buna özel bir alt alan adı (subdomain) atayın, MP_MAX_AGE süresini kısa tutun ve içindeki her şeyi herkese açık olarak değerlendirin. İnsanların güvendiği posta kutularına ihtiyacınız varsa, bunun yerine filtreleme ve yedekleme özelliklerine sahip gerçek bir posta sunucusu çalıştırın.

Saklama: Sınırsız bir catch-all diski nasıl doldurur

Mailpit varsayılan olarak 500 iletiyi tutar ve bu sayıyı aşan en eski iletileri periyodik olarak siler. MP_MAX_MESSAGES: 0 otomatik silme işlemini tamamen devre dışı bırakır; bir catch-all yapılandırmasının kimse fark etmeden diski doldurmasının nedeni tam olarak bu değişikliktir. MP_MAX_AGE bir zaman sınırı ekler ve bu süre saat veya gün cinsinden, 36h veya 14d şeklinde yazılır.

MP_DATABASE tüm bu verilerin kalıcı olup olmayacağına karar verir. Bu ayar olmadan Mailpit, süreç sonlandığında silinen geçici bir dosyaya yazar; bu nedenle her yeniden başlatma gelen kutusunu boşaltır. Bu ayar etkinleştirildiğinde ise postalar yeniden başlatmalardan sonra da korunur ve dosya büyümeye devam eder.

Alanı tüketen temel unsur ek dosyalardır. Her gece 300 test adresine 2 MB boyutunda PDF raporu gönderen bir iş, gecelik 600 MB veri demektir ve yalnızca ileti sayısı sınırı bu büyümeye zamanında müdahale edemez. Bu büyümeyi, aynı birimi paylaşan diğer servislerle birlikte değerlendirin; çünkü PhotoPrism veya Immich gibi medya yoğunluklu bir komşu, küçük bir VPS diskinin büyük kısmını zaten kullanıyor olacaktır.

du -h ~/mailpit/data/mailpit.db
df -h /

Sınırın tetiklenmesini beklemek yerine, CI çalıştırmaları arasında depolama alanını boşaltın:

curl -s -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messages

Inbucket aynı sorunu INBUCKET_STORAGE_RETENTIONPERIOD (imajda 72 saat) ve INBUCKET_STORAGE_MAILBOXMSGCAP (300) ile yönetir. Hangi aracı kullanırsanız kullanın, ilk test paketi yönlendirmesini yapmadan önce sınırları belirleyin.

Test paketinizden gelen kutusunu okuma

GET /api/v1/messages depolanan öğeleri listeler, GET /api/v1/message/{ID} bir iletiyi parçaları ve başlıklarıyla birlikte döndürür, GET /api/v1/search filtreleme yapar ve DELETE /api/v1/messages depoyu temizler. Çalıştırdığınız sürüme ait etkileşimli dokümantasyon http://127.0.0.1:8025/api/v1/ adresinde sunulmaktadır.

Faydalı bir test; bir ileti gönderir, ileti görünene kadar yoklama (poll) yapar, konu başlığını ve içindeki bağlantıyı kontrol eder, ardından her şeyi siler. Tek bir istek yerine kısa bir yeniden deneme döngüsü içinde yoklama yapın; çünkü postayı arka plan işleyicisinde kuyruğa alan bir uygulama, Mailpit iletiyi almadan önce gönderim çağrısından döner. Aynı model, genellikle üretim ortamına asla dokunmayan bir hazırlık (staging) ortamının diğer yarısını oluşturan self-hosted API test ve mock araçları içinde de görülür.

FAQ

Self-hosted geçici e-posta kutusu bir open relay midir?

Relay özelliği kapalı olduğu sürece değildir. Mailpit mesajları depolar ve siz MP_SMTP_RELAY_CONFIG ile bir relay yapılandırması belirtmediğiniz sürece iletmez; bu nedenle 1025 numaralı porta erişen bir yabancı, sunucunuz üzerinden e-posta gönderemez. Yine de depolama alanınızı doldurabilirler, bu yüzden SMTP portunu yalnızca uygulamanızın erişebileceği bir adrese bağlayın. Compose dosyasında 1025:1025 olarak yayınlamak tüm ana bilgisayar adreslerini bağlar ve sudo ufw deny 1025/tcp bunu kapatmayacaktır, çünkü Docker'ın kendi nat kuralları önceliklidir.

Test alan adım için MX kaydına ihtiyacım var mı?

Yalnızca internetten e-posta gelmesini istiyorsanız gereklidir. MX kaydı olmadan gönderici sunucuların teslimat yapacak bir yeri yoktur, bu nedenle gelen kutusu yalnızca kendi uygulamalarınızın SMTP üzerinden gönderdiklerini tutar. Kaydı yayınlayıp 25 numaralı portu açarsanız, herkese açık bir catch-all sunucusu çalıştırmış olursunuz: günler içinde spam, her deneme için bir mesaj depolayan sözlük saldırıları ve filtrelenmemiş yabancı ekleri diskinizde birikir.

Mesaj listesi neden sadece sayfayı yenilediğimde güncelleniyor?

Mailpit, yeni postaları açık bir sayfaya WebSocket üzerinden iletir. proxy_http_version 1.1 ile Upgrade ve Connection başlıklarını içermeyen bir nginx location bloğu bu bağlantıyı yükseltemez, bu yüzden sayfa normal şekilde yüklenir ancak donar. Postalar yine de ulaşır ve API bunları döndürür, bu yüzden gelen kutusu bozuk değil, güncel değilmiş gibi görünür. İlgili satırları ekleyin, nginx'i yeniden yükleyin ve ardından sayfayı yenileyin.

Gelen kutusunun diski doldurmasını nasıl engellerim?

MP_MAX_MESSAGES değerini gerçek bir sayıda tutun ve MP_MAX_AGE ekleyin. Varsayılan sınır 500 mesajdır ve bunu 0 olarak ayarlamak silme işlemini tamamen devre dışı bırakır; ekli bir catch-all sunucusunun sessizce büyüme nedeni budur. MP_MAX_AGE, 36h veya 14d gibi saat veya gün cinsinden değerleri kabul eder. CI temizleme aşamasında depoyu curl -X DELETE http://127.0.0.1:8025/api/v1/messages ile temizleyin. Inbucket aynı işi INBUCKET_STORAGE_RETENTIONPERIOD (72s) ve INBUCKET_STORAGE_MAILBOXMSGCAP (300) ile yapar.

Mailpit, Inbucket veya MailHog arasından hangisini kullanmalıyım?

Ağustos 2026 itibarıyla yeni projeler için Mailpit tercih edilmelidir. MailHog hala çalışmaktadır ancak varsayılan dalı Ağustos 2022'den beri commit almamıştır, bu nedenle yamalanmamış bağımlılıklar içerir. Inbucket aktif olarak korunmaktadır (3.1.1, Aralık 2025) ve testleriniz POP3 gerektiriyorsa daha iyi bir seçimdir; çünkü Mailpit'in POP3 sunucusu yalnızca bir parola dosyası sağladığınızda başlar. Mailpit, MailHog ile aynı portları (1025 ve 8025) kullanır, bu nedenle MailHog'u değiştirmek Compose dosyanızda sadece bir imaj adını değiştirmek kadar kolaydır.