Autor: Matt Connor
Własna tymczasowa skrzynka e-mail na VPS z Mailpit
Konfiguracja serwera SMTP typu catch-all przy użyciu Mailpit i Docker Compose. Instrukcja bezpiecznego przechwytywania wiadomości testowych na własnym VPS bez ryzyka wysyłki.
Czym jest tymczasowa skrzynka odbiorcza
Tymczasowa skrzynka odbiorcza to niewielki serwer SMTP (Simple Mail Transfer Protocol), który akceptuje pocztę dla dowolnego adresu, lecz nie dostarcza jej do adresatów. Aplikacja w środowisku testowym wysyła wiadomości do tego serwera zamiast do rzeczywistego dostawcy poczty, a każda wiadomość zostaje w nim zatrzymana. Treść przychodzących wiadomości odczytuje się przez interfejs WWW, dzięki czemu błędna lista odbiorców lub uszkodzony szablon nie generują kosztów ani ryzyka, ponieważ poczta nigdy nie opuszcza skrzynki.
Niniejszy przewodnik opisuje budowę takiego rozwiązania na pojedynczym VPS przy użyciu Docker Compose. Mailpit pełni rolę uniwersalnego odbiornika (catch-all sink). Jego nasłuch SMTP jest powiązany z adresem dostępnym wyłącznie dla aplikacji, interfejs WWW znajduje się za nginx z włączonym TLS (Transport Layer Security) oraz ochroną hasłem, a limit retencji zapobiega zapełnieniu dysku przez skrzynkę. Jeśli Docker Compose jest nowym narzędziem, podstawy Compose dla VPS wyjaśniają układ plików przyjęty w tym przewodniku.
Efektem końcowym jest narzędzie testowe, a nie serwer pocztowy. Nie posiada ono kont użytkowników, mechanizmów dostarczania ani filtrowania spamu. Rzeczywiste skrzynki pocztowe dla użytkowników to pełnoprawny serwer pocztowy, taki jak Mailcow, co stanowi znacznie bardziej złożone zadanie.
Mailpit kontra Inbucket kontra MailHog: który serwer typu sink wybrać
Trzy narzędzia realizują to zadanie. Różnice między nimi wynikają ze statusu utrzymania, portów, na których nasłuchują, oraz możliwości przetwarzania wiadomości po ich odebraniu. Wersje wymienione poniżej sprawdzono w październiku 2026 roku.
MailHog (mailhog/mailhog) nasłuchuje na porcie 1025 dla protokołu SMTP i udostępnia interfejs na porcie 8025. Narzędzie nadal działa. Główna gałąź repozytorium nie otrzymała żadnego commita od sierpnia 2022 roku, a system śledzenia błędów zawiera ponad 200 otwartych zgłoszeń, co oznacza pracę na niezałatanych zależnościach w środowisku testowym. Nie należy rozpoczynać nowych wdrożeń z użyciem tego narzędzia.
Inbucket (inbucket/inbucket) nasłuchuje na porcie 2500 dla SMTP, 9000 dla interfejsu webowego oraz 1100 dla POP3 (post office protocol version 3). Wersja 3.2.0 została wydana 10 października 2026 roku. Przechowuje wiadomości jako pliki w lokalizacji /storage i samodzielnie zarządza ich usuwaniem: obraz ustawia parametry INBUCKET_STORAGE_RETENTIONPERIOD=72h oraz INBUCKET_STORAGE_MAILBOXMSGCAP=300. Należy wybrać to rozwiązanie, gdy test wymaga pobierania poczty za pomocą biblioteki klienta POP3 zamiast wywołania HTTP.
Mailpit (axllent/mailpit) korzysta z tych samych portów co MailHog, czyli 1025 i 8025, dzięki czemu zastępuje MailHog bez konieczności modyfikacji konfiguracji aplikacji. Wersja 1.31.6 została wydana 15 października 2026 roku; linia 1.30 zakończyła się na wersji 1.30.7 w sierpniu. Narzędzie zawiera wewnątrz pliku binarnego funkcje wymagane przez ten przewodnik: obsługę pliku haseł dla interfejsu webowego i API (application programming interface), limit liczby wiadomości, limit wieku wiadomości oraz filtr odbiorców. Dalsza część tego przewodnika wykorzystuje Mailpit.
Jak działa mechanizm catch-all i dlaczego DNS nie bierze w tym udziału
Aplikacja nie sprawdza, dokąd dostarczyć wiadomość. Przekazuje hosta oraz port, otwiera połączenie TCP i ogłasza RCPT TO:<anyone@example.test>. Mailpit akceptuje każdego odbiorcę, niezależnie od treści, zapisuje wiadomość i nie przesyła jej dalej. Domena nie jest rozwiązywana, dlatego example.test działa, mimo że .test jest nazwą zarezerwowaną, która nie istnieje w systemie nazw domenowych (DNS).
To cały mechanizm i właśnie dlatego skrzynka odbiorcza jest domyślnie bezpieczna. Nie jest wymagany rekord MX (mail exchanger), nie podejmuje się prób dostarczenia i żadna wiadomość nie może trafić do rzeczywistego adresata.
Skierowanie aplikacji testowej na serwer przechwytujący
Ustaw host SMTP aplikacji na mailpit, gdy aplikacja działa jako kontener w tym samym projekcie Compose, lub na 127.0.0.1, gdy działa bezpośrednio na hoście. Ustaw port na 1025, wyłącz TLS oraz pozostaw nazwę użytkownika i hasło puste. Mailpit akceptuje pocztę anonimową.
Niektóre frameworki odmawiają wysyłki bez poświadczeń. MP_SMTP_AUTH_ACCEPT_ANY=1 sprawia, że Mailpit akceptuje dowolną nazwę użytkownika i hasło, a MP_SMTP_AUTH_ALLOW_INSECURE=1 zezwala na mechanizmy PLAIN oraz LOGIN przy nieszyfrowanym połączeniu. Te dwa ustawienia są tutaj bezpieczne tylko dlatego, że serwer nasłuchujący jest niedostępny z Internetu, co wymusza poniższa konfiguracja wdrożeniowa.
MP_SMTP_ALLOWED_RECIPIENTS warto ustawić od samego początku. Przyjmuje ono wyrażenie regularne i odrzuca każdego odbiorcę, który do niego nie pasuje. Skieruj je na swoją domenę testową, dzięki czemu baza danych środowiska testowego, która wciąż zawiera rzeczywiste adresy klientów, wywoła widoczny błąd w logach aplikacji zamiast wiadomości, która po cichu trafi do serwera przechwytującego.
Plik Docker Compose
Najpierw utwórz katalog oraz plik z hasłem dla interfejsu WWW. htpasswd -B zapisuje skrót bcrypt, a Mailpit odczytuje zarówno bcrypt, jak i tekst jawny.
mkdir -p ~/mailpit/data
cd ~/mailpit
sudo apt update && sudo apt install -y apache2-utils
htpasswd -B -c data/ui-auth qaZapisz compose.yaml:
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$$'Podwójny znak dolara nie jest błędem. Compose interpretuje pojedynczy $ jako początek zmiennej do rozwinięcia, więc $$ jest sposobem na przekazanie dosłownego znaku dolara do kontenera. Wyrażenie regularne dociera do Mailpit jako @example\.test$.
Uruchom usługę i sprawdź stan jej kondycji (health state):
docker compose up -d
docker compose psKolumna STATUS powinna wskazywać Up ... (healthy). Obraz zawiera własny mechanizm healthcheck, który uruchamia /mailpit readyz co 15 sekund, więc kontener, który pozostaje w stanie starting lub zmienia się na unhealthy, zazwyczaj nie obsługuje ruchu na porcie 8025 wewnątrz kontenera. Kontrola pobiera ustawienia ze zmiennych środowiskowych MP_, ale nie z flag wiersza poleceń; jest to powód, dla którego niniejszy przewodnik konfiguruje wszystko w sekcji environment:. Przekazanie opcji jako flag może spowodować, że kontrola zgłosi unhealthy, podczas gdy Mailpit będzie działał poprawnie. Przeczytaj docker compose logs mailpit przed wprowadzeniem jakichkolwiek innych zmian.
Oba opublikowane porty zawierają adres, który stanowi kontrolę bezpieczeństwa. Wewnątrz kontenera Mailpit nasłuchuje na 0.0.0.0, co jest poprawne, ponieważ kontener posiada własną przestrzeń nazw sieciowych. Lewa strona mapowania decyduje o tym, kto uzyskuje dostęp z zewnątrz. Zapis 8025:8025 powoduje, że Docker wiąże się z każdym adresem na hoście, w tym z adresem publicznym.
Jeśli aplikacja testowa (staging) jest usługą w tym samym pliku, usuń całkowicie mapowanie 1025 i skieruj aplikację na nazwę hosta mailpit na porcie 1025. Kontenery w tej samej sieci Compose komunikują się bezpośrednio, więc port SMTP w ogóle nie jest wystawiany na hoście. Jak sieci Compose rozwiązują nazwy usług omawia ten mechanizm.
Wysłanie pojedynczej wiadomości i weryfikacja jej dostarczenia
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)
EOFSkrypt nie wyświetla żadnych komunikatów w przypadku powodzenia. Należy potwierdzić zapisanie wiadomości za pomocą API:
curl -s -u qa:yourpassword http://127.0.0.1:8025/api/v1/messagesPolecenie to zwraca obiekt JSON z listą zapisanych wiadomości. Usunięcie flagi -u spowoduje odrzucenie żądania, ponieważ MP_UI_AUTH_FILE chroni jednocześnie API oraz interfejs WWW. Każdy test odczytujący skrzynkę odbiorczą musi przesyłać te dane uwierzytelniające.
Błąd ConnectionRefusedError w skrypcie Python oznacza, że na porcie 127.0.0.1:1025 nie nasłuchuje żadna usługa. Jest to oczekiwany rezultat w przypadku usunięcia mapowania SMTP; w takiej sytuacji test musi zostać uruchomiony z poziomu kontenera działającego w tej samej sieci Compose.
Udostępnianie interfejsu WWW przez nginx z hasłem
Interfejs obecnie odpowiada wyłącznie na adresie loopback. nginx dokonuje terminacji TLS i wymaga podania hasła, zanim jakikolwiek ruch dotrze do usługi.
sudo htpasswd -B -c /etc/nginx/mailpit.htpasswd qaserver {
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;
}
}Przeładuj konfigurację po sprawdzeniu składni za pomocą sudo nginx -t && sudo systemctl reload nginx. Warto zapoznać się z artykułem Działanie poszczególnych dyrektyw w bloku reverse proxy, jeśli jest to pierwsza konfiguracja proxy.
Użyj tej samej nazwy użytkownika i hasła w pliku nginx oraz w data/ui-auth. nginx przekazuje nagłówek Authorization przeglądarki do backendu, więc zgodne dane uwierzytelniające pozwalają na przejście obu kontroli po jednokrotnym wpisaniu danych. Różne dane uwierzytelniające spowodują, że przeglądarka prześle zestaw, który druga kontrola odrzuci.
Nagłówki Upgrade oraz Connection nie są opcjonalne. Mailpit przesyła nową pocztę do otwartej strony za pośrednictwem WebSocket, a proxy działające w trybie HTTP/1.1 bez tych nagłówków nie może dokonać aktualizacji połączenia. Strona w takim przypadku ładuje się poprawnie, ale nie aktualizuje: poczta dociera, API ją widzi, jednak lista pozostaje statyczna do momentu przeładowania strony.
Zachowaj obie blokady. Hasło w nginx chroni adres publiczny, a MP_UI_AUTH_FILE chroni sam port 8025. Jest to istotne, ponieważ każdy link do resetowania hasła wygenerowany przez aplikację testową, tak długo jak jest przechowywany, jest możliwy do odczytania w tym interfejsie.
Nigdy nie dopuszczaj do powstania otwartego przekaźnika (open relay)
Otwarty przekaźnik to serwer SMTP, który przyjmuje wiadomość od dowolnego nadawcy i przekazuje ją do dowolnego odbiorcy. Spamerzy nieustannie skanują sieć w poszukiwaniu takich serwerów, a znalezienie jednego pod Twoim adresem kończy się zgłoszeniami o nadużyciach i zawieszeniem konta.
Mailpit nie jest otwartym przekaźnikiem w konfiguracji domyślnej, ponieważ standardowo nie przekazuje żadnych wiadomości dalej. Posiada dwie funkcje wychodzące, z których obie pozostają wyłączone do momentu ich skonfigurowania. MP_SMTP_RELAY_CONFIG wskazuje plik konfiguracyjny przekaźnika i aktywuje w interfejsie funkcję wysyłki, która przesyła wybraną wiadomość przez wskazany serwer; automatyczne przekazywanie wymaga dodatkowego przełącznika, MP_SMTP_RELAY_ALL (domyślnie false) lub MP_SMTP_RELAY_MATCHING. Przekierowywanie, ustawiane za pomocą MP_SMTP_FORWARD_CONFIG lub zmiennych MP_SMTP_FORWARD_*, kopiuje każdą przychodzącą wiadomość na wskazane adresy. Pozostawienie tych opcji nieustawionych jest celowym działaniem.
Istnieją dwa sposoby na utratę tego zabezpieczenia. Włączenie MP_SMTP_RELAY_ALL, które przesyła każdą przychodzącą wiadomość do jej oryginalnych odbiorców i ignoruje MP_SMTP_ALLOWED_RECIPIENTS, a następnie wystawienie portu SMTP na świat, tworzy działający otwarty przekaźnik. MP_SMTP_RELAY_MATCHING robi to samo dla każdego odbiorcy pasującego do wzorca. Wystawienie portu bez przekaźnika uniemożliwia obcym wysyłanie poczty przez Twój serwer, ale pozwala im zapełnić pamięć masową i umieścić treść w interfejsie, któremu ufa Twój zespół. Przy włączonym przekierowywaniu, ich wiadomości trafiają również do skrzynek odbiorczych, które otrzymują kopie.
Pułapką na hoście Docker jest firewall. Publikacja portu powoduje, że Docker dopisuje własne reguły do tabeli nat, a ruch kierowany do kontenera jest dopasowywany tam, zanim reguły ufw (uncomplicated firewall) zostaną uwzględnione. sudo ufw deny 1025/tcp zgłasza sukces i niczego nie zmienia. Dlaczego Docker publikuje porty z pominięciem ufw wyjaśnia kolejność łańcuchów.
Rozwiązaniem jest adres w mapowaniu, a nie reguła firewalla. Sprawdź, co jest faktycznie powiązane:
sudo ss -ltnp | grep -E ':(1025|8025)'Prawidłowy wynik pokazuje 127.0.0.1:1025 oraz 127.0.0.1:8025. Linia o treści 0.0.0.0:1025 oznacza, że mapowanie utraciło adres i sink nasłuchuje na interfejsie publicznym. Z innej maszyny polecenie nc -vz mail-test.example.com 1025 powinno zwrócić błąd przekroczenia czasu lub odmowy połączenia.
Jeśli aplikacja znajduje się na innym serwerze, nie otwieraj portu 1025 w celu połączenia obu maszyn. Umieść oba serwery w sieci prywatnej lub tunelu VPN i powiąż mapowanie z adresem tego interfejsu.
Publikuj rekordy MX tylko wtedy, gdy oczekujesz rzeczywistej poczty przychodzącej
Rekord MX (mail exchanger) informuje inne serwery pocztowe, który host przyjmuje wiadomości dla danej domeny. Jego brak nie zamyka automatycznie dostępu: gdy domena nie posiada rekordu MX, serwery nadawcze próbują połączyć się z jej rekordem adresowym (A lub AAAA), zgodnie z sekcją 5.1 RFC 5321, a nazwa hosta wskazująca na ten serwer w celu obsługi interfejsu WWW taki rekord posiada. Przed pocztą internetową chroni fakt, że na serwerze nic nie nasłuchuje na porcie 25. Skrzynka odbiorcza zawiera tylko to, co przesłały własne aplikacje, do czego służy skrzynka testowa.
Odbieranie rzeczywistej poczty wymaga rekordu DNS kierującego serwery nadawcze na ten serwer (rekord MX lub rekord adresowy, na który następuje fallback), uruchomionego Mailpit na porcie 25 (MP_SMTP_BIND_ADDR=0.0.0.0:25) oraz otwartego tego portu. W tym momencie uruchamiasz publiczny serwer typu catch-all dla każdego adresu w domenie. Należy mieć świadomość konsekwencji:
- Spam pojawia się w ciągu kilku dni od opublikowania rekordu, ponieważ boty skanują DNS. Ataki słownikowe sprawdzają popularne nazwy i zapisują wiadomość dla każdej próby.
- Załączniki od nieznanych nadawców trafiają na dysk i pozostają tam. Brak filtrów powoduje, że archiwum od nieznanego nadawcy znajduje się obok własnej poczty testowej.
- Każdy, kto pozna domenę, może zarejestrować się w zewnętrznych serwisach przy użyciu adresu w tej domenie, a mail potwierdzający zostanie dostarczony na Twój serwer. Jeśli zabezpieczenia hasłem zawiodą, te konta należą do osoby mającej dostęp do skrzynki odbiorczej.
- Limity retencji przestają być kwestią porządkową, a stają się kluczowe dla wydajności, ponieważ wolumen poczty przestaje być pod kontrolą użytkownika.
Jeśli potrzebujesz rzeczywistej poczty przychodzącej do testów dostarczalności, użyj dedykowanej subdomeny, utrzymuj MP_MAX_AGE na krótkim poziomie i traktuj całą zawartość jako publiczną. Jeśli potrzebujesz skrzynek pocztowych, na których polegają użytkownicy, uruchom pełnoprawny serwer pocztowy z filtrowaniem i kopiami zapasowymi.
Retencja: jak nieograniczony catch-all zapełnia dysk
Mailpit domyślnie przechowuje 500 wiadomości i okresowo usuwa najstarsze po przekroczeniu tego limitu. Flaga MP_MAX_MESSAGES: 0 wyłącza ten limit, a bez ustawionej wartości MP_MAX_AGE żadna wiadomość nie jest usuwana automatycznie, co sprawia, że skrzynka typu catch-all zapełnia dysk bez wiedzy administratora. Parametr MP_MAX_AGE dodaje limit czasowy, działa samodzielnie lub w połączeniu z limitem liczby wiadomości i przyjmuje wartości w godzinach lub dniach, zapisywane jako 36h lub 14d.
Flaga MP_DATABASE decyduje o trwałości danych. Bez niej Mailpit zapisuje dane do pliku tymczasowego, który jest usuwany po zakończeniu procesu, więc każdy restart czyści skrzynkę odbiorczą. Z tą flagą poczta przetrwa restarty, a plik będzie stale rosnąć.
To załączniki zużywają przestrzeń dyskową. Nocne zadanie wysyłające raport PDF o rozmiarze 2 MB na 300 adresów testowych generuje 600 MB danych każdej nocy, a sam limit liczby wiadomości nie zareaguje wystarczająco szybko. Należy uwzględnić ten przyrost w planowaniu zasobów, zwłaszcza jeśli wolumen jest współdzielony z innymi usługami, ponieważ sąsiednie aplikacje multimedialne, takie jak PhotoPrism lub Immich, mogą już zajmować większość miejsca na dysku małego serwera VPS.
du -h ~/mailpit/data/mailpit.db
df -h /Należy czyścić magazyn między uruchomieniami CI, zamiast czekać na zadziałanie limitu:
curl -s -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messagesInbucket rozwiązuje ten sam problem za pomocą INBUCKET_STORAGE_RETENTIONPERIOD (domyślnie 72h w obrazie) oraz INBUCKET_STORAGE_MAILBOXMSGCAP (300). Niezależnie od wybranego narzędzia, limit należy ustalić przed skierowaniem na nie pierwszego zestawu testów.
Odczytywanie skrzynki odbiorczej z zestawu testów
GET /api/v1/messages wyświetla listę przechowywanych elementów, GET /api/v1/message/{ID} zwraca pojedynczą wiadomość wraz z jej częściami i nagłówkami, GET /api/v1/search filtruje zawartość, a DELETE /api/v1/messages czyści magazyn. Interaktywna dokumentacja dla używanej wersji jest dostępna pod adresem http://127.0.0.1:8025/api/v1/.
Użyteczny test wysyła wiadomość, odpytuje o jej pojawienie się, sprawdza temat oraz zawarty w niej link, a następnie usuwa wszystkie dane. Należy stosować odpytywanie w krótkiej pętli ponowień zamiast pojedynczego żądania, ponieważ aplikacja kolejkująca pocztę w procesie działającym w tle zwraca odpowiedź z wywołania wysyłki, zanim Mailpit otrzyma wiadomość. Ten sam wzorzec pojawia się w narzędziach do testowania i mockowania API typu self-hosted, które zazwyczaj stanowią drugą połowę środowiska stagingowego, niemającego styczności z produkcją.
FAQ
Czy samodzielnie hostowana tymczasowa skrzynka odbiorcza jest otwartym przekaźnikiem (open relay)?
Nie, dopóki przekaźnik pozostaje wyłączony. Domyślnie Mailpit nie wysyła niczego dalej: MP_SMTP_RELAY_CONFIG umożliwia jedynie ręczne zwolnienie wybranych wiadomości, a automatyczne przesyłanie wymaga dodatkowo MP_SMTP_RELAY_ALL lub MP_SMTP_RELAY_MATCHING. Jeśli te opcje pozostaną nieustawione, osoba trzecia, która uzyska dostęp do portu 1025, nie będzie mogła wysłać poczty przez serwer. Może jednak zapełnić pamięć masową, dlatego należy powiązać port SMTP z adresem dostępnym wyłącznie dla aplikacji. Publikacja jako 1025:1025 w pliku Compose wiąże usługę ze wszystkimi adresami hosta, a sudo ufw deny 1025/tcp nie zamknie tego dostępu, ponieważ reguły nat w Dockerze są przetwarzane w pierwszej kolejności.
Czy potrzebuję rekordu MX dla domeny testowej?
Tylko jeśli poczta z Internetu ma docierać do serwera; brak rekordu MX nie stanowi samodzielnego zabezpieczenia. Bez rekordu MX serwery nadawcze próbują połączyć się z rekordem A lub AAAA domeny, więc faktyczną blokadą dla poczty z Internetu jest brak nasłuchiwania na porcie 25. Skrzynka przechowuje wtedy tylko to, co aplikacje przesyłają przez SMTP. Skierowanie DNS na serwer i otwarcie portu 25 oznacza uruchomienie publicznego serwera typu catch-all: w ciągu kilku dni pojawi się spam, ataki słownikowe zapisujące wiadomość dla każdej próby oraz załączniki od nieznajomych na dysku bez żadnego filtrowania.
Dlaczego lista wiadomości aktualizuje się tylko po odświeżeniu strony?
Mailpit przesyła nową pocztę do otwartej strony za pomocą protokołu WebSocket. Blok location w nginx, w którym brakuje proxy_http_version 1.1 oraz nagłówków Upgrade i Connection, nie może dokonać aktualizacji połączenia, więc strona ładuje się normalnie, a następnie przestaje reagować. Poczta nadal dociera, a API zwraca dane, dlatego skrzynka wygląda na nieaktualną, a nie na uszkodzoną. Należy dodać te linie, przeładować nginx i odświeżyć stronę.
Jak zapobiec zapełnieniu dysku przez skrzynkę odbiorczą?
Należy utrzymać MP_MAX_MESSAGES na konkretnej wartości i dodać MP_MAX_AGE. Domyślny limit to 500 wiadomości, a ustawienie 0 wyłącza usuwanie oparte na liczbie, więc jeśli MP_MAX_AGE nie jest ustawione, nic nie jest usuwane, co prowadzi do niekontrolowanego wzrostu rozmiaru skrzynki catch-all z załącznikami. MP_MAX_AGE akceptuje godziny lub dni, na przykład 36h lub 14d. Warto czyścić magazyn podczas zamykania środowiska CI za pomocą curl -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messages, ponieważ punkt końcowy usuwania wymaga tych samych poświadczeń co interfejs WWW. Tylko Send API (POST /api/v1/send) może otrzymać własne poświadczenia, co jest opcjonalne. Inbucket realizuje to samo zadanie za pomocą INBUCKET_STORAGE_RETENTIONPERIOD (72h) i INBUCKET_STORAGE_MAILBOXMSGCAP (300).
Czy wybrać Mailpit, Inbucket czy MailHog?
Dla nowych projektów, według stanu na październik 2026, należy wybrać Mailpit. MailHog nadal działa, ale jego główna gałąź nie otrzymała żadnego commita od sierpnia 2022 roku, przez co zawiera niezałatane zależności. Inbucket jest aktywnie rozwijany (wersja 3.2.0, październik 2026) i stanowi lepszy wybór, gdy testy wymagają POP3, ponieważ serwer POP3 w Mailpit uruchamia się dopiero po podaniu poświadczeń w pliku haseł lub w zmiennej MP_POP3_AUTH. Mailpit używa tych samych portów co MailHog, czyli 1025 i 8025, więc zastąpienie MailHog wymaga jedynie zmiany nazwy obrazu w pliku Compose.