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ç bulunmaktadır. Bunları birbirinden ayıran özellikler bakım durumları, dinledikleri portlar ve bir iletiyi kabul ettikten sonra onunla neler yapabildikleridir. Aşağıdaki sürümler Ekim 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ına Ağustos 2022'den beri hiçbir commit gönderilmemiştir ve takip sisteminde 200'den fazla açık sorun bulunmaktadır; bu nedenle test ortamınızda yamalanmamış bağımlılıklar çalıştırıyor olursunuz. Üzerinde yeni bir çalışmaya başlamayın.

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. 3.2.0 sürümü 10 Ekim 2026 tarihinde yayınlanmıştır. İletileri /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 posta toplaması gerektiğinde bu aracı seçin.

Mailpit (axllent/mailpit), MailHog ile aynı portları (1025 ve 8025) kullandığı için uygulama yapılandırmasına dokunmadan MailHog'un yerini alır. 1.31.6 sürümü 15 Ekim 2026 tarihinde yayınlanmıştır; 1.30 serisi ise Ağustos ayında 1.30.7 sürümü ile sona ermiştir. Bu rehberin 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ı, ileti sınırı, yaş sınırı ve alıcı filtresi. Bu rehberin 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.31
    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 okur; bu nedenle $$, tek bir gerçek dolar işaretini container içine 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 denetim mekanizmasına sahiptir. Bu nedenle starting durumunda kalan veya unhealthy değerine dönen bir container, genellikle container içindeki 8025 numaralı portta hizmet vermiyordur. Denetim mekanizması ayarları MP_ ortam değişkenlerinden alır ancak komut satırı bayraklarını dikkate almaz; bu rehberin her şeyi environment: altında tanımlamasının nedeni budur. Seçenekleri bayrak olarak geçerseniz, Mailpit normal şekilde hizmet verse bile denetim mekanizması unhealthy rapor edebilir. Başka bir değişiklik yapmadan önce docker compose logs mailpit belgesini okuyun.

Yayınlanan her iki port da bir adres taşır ve bu adres güvenlik kontrolünü sağlar. Mailpit, container içinde 0.0.0.0 adresini dinler; container kendi ağ ad alanına (network namespace) sahip 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 staging uygulamanız aynı dosya içindeki bir servis ise, 1025 eşleştirmesini tamamen silin ve uygulamayı 1025 numaralı port üzerindeki mailpit ana makine adına yönlendirin. Paylaşımlı bir Compose ağındaki container'lar birbirlerine doğrudan erişebilir; bu sayede SMTP portu ana makineye hiçbir şekilde temas etmez. Compose ağlarının servis adlarını nasıl çözümlediği konusu bu arama işlemini 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ı yapar ve herhangi bir veri kendisine ulaşmadan önce parola ister.

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ızsa, reverse proxy bloğundaki her yönergenin işlevi başlıklı dokümanı bir kez okumanız faydalı olacaktır.

nginx dosyasında ve data/ui-auth içerisinde aynı kullanıcı adını ve parolayı kullanın. nginx, tarayıcının Authorization başlığını upstream'e iletir; bu sayede eşleşen kimlik bilgileri her iki kontrolü de tek bir istemle karşılar. Farklı kimlik bilgileri kullanıldığında, tarayıcı bir set bilgiyi tutar ve ikinci kontrol bunu reddeder.

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. Bu durumda sayfa düzgün yüklenir ancak hiçbir zaman değişmez: 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ı, saklama süresi boyunca bu arayüz üzerinden okunabilir durumdadır.

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

Açık relay, herhangi birinden gelen mesajı kabul edip istenen herhangi bir hedefe ileten bir SMTP sunucusudur. İstenmeyen e-posta göndericileri (spammer) sürekli olarak bu tür sunucuları tarar; bir tane bulduklarında adresiniz kötüye kullanım raporlarına konu olur ve hesabınız askıya alınır.

Mailpit, varsayılan olarak hiçbir şeyi dışarıya iletmediği için kutudan çıktığı haliyle açık bir relay değildir. İki adet giden mesaj özelliği bulunur ve siz yapılandırana kadar her ikisi de kapalı kalır. MP_SMTP_RELAY_CONFIG, bir relay yapılandırma dosyasına işaret eder ve arayüzde, seçtiğiniz bir mesajı o sunucu üzerinden gönderen release eylemini etkinleştirir; otomatik relay işlemi için MP_SMTP_RELAY_ALL (varsayılan false) veya MP_SMTP_RELAY_MATCHING gibi ek bir anahtar gerekir. MP_SMTP_FORWARD_CONFIG veya MP_SMTP_FORWARD_* değişkenleri ile ayarlanan yönlendirme (forwarding), gelen her mesajın bir kopyasını seçtiğiniz sabit adreslere gönderir. Bunların hepsini yapılandırılmamış halde bırakmak bilinçli bir tercihtir.

Bu özelliği kaybetmenin iki yolu vardır. Gelen her mesajı orijinal alıcılarına gönderen ve MP_SMTP_ALLOWED_RECIPIENTS ayarını yok sayan MP_SMTP_RELAY_ALL seçeneğini açıp ardından SMTP portunu internete açarsanız, çalışan bir açık relay oluşturmuş olursunuz. MP_SMTP_RELAY_MATCHING, kendi deseniyle eşleşen her alıcı için aynı işlemi yapar. Portu herhangi bir relay ayarı 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. Yönlendirme açık olduğunda, bu mesajlar kopyaları alan her türlü gelen kutusuna da düşer.

Docker ana makinesindeki tuzak güvenlik duvarıdır. Bir portu yayınlamak, Docker'ın kendi kurallarını nat tablosuna yazmasına neden olur ve 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 başlıklı yazı, zincir sırasını detaylandırır.

Çözüm, güvenlik duvarı kuralı değil, eşlemedeki 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, ikisi arasında köprü kurmak 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 o 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. Bu kaydı eklememek tek başına kapıyı kapatmaz: Bir alan adının MX kaydı olmadığında, gönderen sunucular RFC 5321 bölüm 5.1'de belirtildiği üzere adres (A veya AAAA) kaydına geri döner ve web arayüzü için bu sunucuya işaret ettiğiniz ana bilgisayar adının bir adresi vardır. İnternet postasını dışarıda tutan şey, sunucuda 25 numaralı portu dinleyen hiçbir şeyin olmamasıdır. Gelen kutusu yalnızca kendi uygulamalarınızın gönderdiklerini tutar; test posta kutusunun amacı da budur.

Gerçek posta almak, gönderen sunucuları sunucuya yönlendiren bir DNS kaydı (bir MX kaydı veya geri döndükleri adres kaydı), Mailpit'in 25 numaralı portu dinlemesi (MP_SMTP_BIND_ADDR=0.0.0.0:25) 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" (her şeyi yakala) sistemi çalıştırıyor olursunuz. Bundan sonra yaşanacakların farkında olun.

• Kayıt göründükten sonraki günler içinde spam başlar, çünkü harvesters (adres toplayıcılar) DNS kayıtlarını okur. Sözlük saldırıları yaygın isimleri dener ve her deneme için bir ileti saklar.
• Yabancılardan gelen ekler diskinize iner ve orada kalır. Bunları filtreleyen bir mekanizma 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 noktada zayıflarsa, bu hesaplar gelen kutusunu okuyan kişinin eline geçer.
• Saklama sınırları artık bir temizlik işlemi olmaktan çıkıp yük yönetimi haline gelir, çünkü hacim artık sizin kontrolünüzde değildir.

Teslim edilebilirlik kontrolü için gerçek gelen postaya ihtiyacınız varsa, buna özel bir alt alan adı 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 özellikleri olan 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 bu sınırı devre dışı bırakır; herhangi bir MP_MAX_AGE ayarlanmadığında ise hiçbir ileti otomatik olarak silinmez. Bir catch-all adresinin kimse fark etmeden diski doldurma yöntemi budur. MP_MAX_AGE bir zaman sınırı ekler; ileti sınırı ile birlikte veya onun yerine çalışır ve 36h ya da 14d biçiminde yazılan saat veya gün değerlerini kabul eder.

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

Alanı tüketen asıl 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 hıza yetişemez. Bu büyüme miktarını, aynı birimi paylaşan diğer servislerle kıyaslayarak bütçelendirin; çünkü PhotoPrism veya Immich gibi medya yoğunluklu bir komşu, küçük bir VPS diskinin büyük kısmını zaten işgal etmiş olacaktır.

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

Bir sınırın tetiklenmesini beklemek yerine CI çalıştırmaları arasında depoyu 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ı tutulduğu sürece değildir. Mailpit varsayılan olarak hiçbir şeyi iletmez: MP_SMTP_RELAY_CONFIG yalnızca seçtiğiniz iletilerin manuel olarak serbest bırakılmasını sağlar; otomatik iletim için ise MP_SMTP_RELAY_ALL veya MP_SMTP_RELAY_MATCHING gereklidir. Bu ayarları boş bırakırsanız, 1025 numaralı porta erişen bir yabancı sunucunuz üzerinden e-posta gönderemez. Ancak depolama alanınızı doldurabilirler; bu nedenle 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 makine 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ını eklememek başlı başına bir güvenlik önlemi değildir. MX kaydı olmadığında, gönderen sunucular alan adının A veya AAAA kaydına geri döner. İnternet trafiğini engelleyen asıl unsur, 25 numaralı portta hiçbir servisin dinleme yapmıyor olmasıdır. Bu durumda gelen kutusu yalnızca kendi uygulamalarınızın SMTP üzerinden gönderdiklerini tutar. DNS'i sunucuya yönlendirip 25 numaralı portu açarsanız, herkese açık bir catch-all servisi çalıştırmış olursunuz: günler içinde spam, her deneme için bir mesaj kaydeden sözlük saldırıları ve filtrelenmemiş yabancı ekler diskinizi doldurur.

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

Mailpit, yeni e-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 nedenle sayfa normal şekilde yüklenir ancak güncellenmez. E-postalar ulaşmaya ve API üzerinden dönmeye devam eder, bu yüzden gelen kutusu bozuk değil, güncel değilmiş gibi görünür. İlgili satırları ekleyin, nginx servisini yeniden yükleyin ve sayfayı yenileyin.

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

MP_MAX_MESSAGES değerini gerçek bir sayı olarak tutun ve MP_MAX_AGE ayarını ekleyin. Varsayılan sınır 500 mesajdır; bu değeri 0 yapmak sayı tabanlı silme işlemini devre dışı bırakır. Dolayısıyla MP_MAX_AGE ayarlanmadığı sürece hiçbir şey temizlenmez; ekli dosyalar içeren bir catch-all kutusu bu şekilde sessizce büyür. MP_MAX_AGE saat veya gün cinsinden değer kabul eder; örneğin 36h veya 14d gibi. CI süreçlerinin sonunda depolama alanını curl -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messages ile temizleyin, çünkü silme uç noktası web arayüzü ile aynı kimlik bilgilerini kullanır. Yalnızca Send API (POST /api/v1/send) için ayrı kimlik bilgileri tanımlanabilir, bu da isteğe bağlıdır. Inbucket aynı işi INBUCKET_STORAGE_RETENTIONPERIOD (72h) ve INBUCKET_STORAGE_MAILBOXMSGCAP (300) ile yapar.

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

Ekim 2026 itibarıyla yeni projeler için Mailpit tercih edilmelidir. MailHog hala çalışmaktadır ancak varsayılan dalına Ağustos 2022'den beri commit yapılmamıştır, bu nedenle yamalanmamış bağımlılıklar içerir. Inbucket aktif olarak korunmaktadır (3.2.0, Ekim 2026) ve testleriniz POP3 gerektiriyorsa daha iyi bir seçimdir. Mailpit'in POP3 sunucusu, bir parola dosyasında veya MP_POP3_AUTH değişkeninde kimlik bilgileri tanımlanana kadar başlamaz. Mailpit, MailHog ile aynı portları (1025 ve 8025) kullanır; bu nedenle MailHog'u değiştirmek, Compose dosyanızda yalnızca bir imaj adını güncellemenizi gerektirir.