VPS पर disposable email inbox कैसे सेटअप करें

Disposable email inbox क्या है

Disposable email inbox एक छोटा SMTP (simple mail transfer protocol) सर्वर होता है जो हर पते के लिए मेल स्वीकार तो करता है, लेकिन उसे कहीं भेजता नहीं है। आपका staging application किसी वास्तविक मेल प्रदाता के बजाय इसे मेल भेजता है, और हर संदेश वहीं रुक जाता है। आप वेब इंटरफेस में देखते हैं कि क्या पहुँचा है, इसलिए गलत recipient list या खराब template से कोई नुकसान नहीं होता, क्योंकि मेल कभी भी उस बॉक्स से बाहर नहीं जाता।

यह गाइड Docker Compose का उपयोग करके एक सिंगल VPS पर इसे बनाना सिखाती है। Mailpit एक catch-all sink है। इसका SMTP listener वहाँ bind होता है जहाँ केवल आपका application ही पहुँच सकता है, इसका वेब इंटरफेस nginx के पीछे transport layer security (TLS) और पासवर्ड के साथ सुरक्षित रहता है, और एक retention limit मेलबॉक्स को डिस्क भरने से रोकती है। यदि आप Compose के लिए नए हैं, तो VPS के लिए Compose की बुनियादी जानकारी उस file layout को कवर करती है जिसे यह गाइड मानकर चलती है।

इसका परिणाम एक test tool है, न कि मेल सर्वर। इसमें कोई account नहीं होता, कोई delivery नहीं होती और न ही कोई spam filtering होती है। वास्तविक लोगों के लिए वास्तविक मेलबॉक्स Mailcow जैसे पूर्ण मेल सर्वर होते हैं और यह एक बहुत बड़ा कार्य है।

Mailpit बनाम Inbucket बनाम MailHog: कौन सा sink चलाएं

यह कार्य तीन टूल्स द्वारा किया जाता है। इनके बीच का अंतर इनके मेंटेनेंस स्टेटस, इनके द्वारा उपयोग किए जाने वाले ports और संदेश प्राप्त करने के बाद ये क्या कर सकते हैं, इस पर निर्भर करता है। नीचे दिए गए वर्ज़न अक्टूबर 2026 में चेक किए गए थे।

MailHog (mailhog/mailhog) SMTP के लिए 1025 पर listen करता है और अपना इंटरफ़ेस 8025 पर सर्व करता है। यह अभी भी काम करता है। इसकी डिफ़ॉल्ट ब्रांच में अगस्त 2022 से कोई commit नहीं हुआ है और ट्रैकर में 200 से अधिक open issues हैं, इसलिए आप अपने टेस्ट पाथ में unpatched dependencies चला रहे होंगे। इस पर कोई नया काम शुरू न करें।

Inbucket (inbucket/inbucket) SMTP के लिए 2500, वेब इंटरफ़ेस के लिए 9000 और POP3 (post office protocol version 3) के लिए 1100 पर listen करता है। वर्ज़न 3.2.0 को 10 अक्टूबर 2026 को रिलीज़ किया गया था। यह संदेशों को /storage के अंतर्गत फ़ाइलों के रूप में स्टोर करता है और उन्हें स्वयं हटा देता है: इमेज INBUCKET_STORAGE_RETENTIONPERIOD=72h और INBUCKET_STORAGE_MAILBOXMSGCAP=300 सेट करती है। इसे तब चुनें जब किसी टेस्ट को HTTP कॉल के बजाय POP3 क्लाइंट लाइब्रेरी के साथ मेल कलेक्ट करने की आवश्यकता हो।

Mailpit (axllent/mailpit) MailHog वाले ही ports, 1025 और 8025 का उपयोग करता है, इसलिए यह एप्लिकेशन कॉन्फ़िगरेशन को बदले बिना MailHog की जगह ले लेता है। वर्ज़न 1.31.5 को 11 अक्टूबर 2026 को रिलीज़ किया गया था; 1.30 लाइन अगस्त में 1.30.7 पर समाप्त हो गई थी। इसमें वह सब कुछ शामिल है जिसकी इस गाइड को आवश्यकता है: वेब इंटरफ़ेस और API (application programming interface) के लिए एक पासवर्ड फ़ाइल, एक संदेश सीमा, एक समय सीमा और एक प्राप्तकर्ता फ़िल्टर। इस गाइड का शेष भाग Mailpit का उपयोग करता है।

Catch-all कैसे काम करता है, और DNS इसमें शामिल क्यों नहीं है

आपका application यहाँ यह नहीं देखता कि संदेश कहाँ पहुँचाना है। आप इसे एक host और एक port देते हैं, यह एक TCP connection खोलता है, और यह RCPT TO:<anyone@example.test> की घोषणा करता है। Mailpit उस recipient को स्वीकार कर लेता है, चाहे वह कुछ भी कहे, संदेश को store करता है, और कुछ भी forward नहीं करता है। domain को कभी resolve नहीं किया जाता है, इसलिए example.test काम करता है, भले ही .test एक reserved नाम हो जो domain name system (DNS) में कहीं मौजूद नहीं है।

यह पूरी प्रक्रिया है, और यही कारण है कि inbox डिफ़ॉल्ट रूप से सुरक्षित है। इसमें कोई MX (mail exchanger) record शामिल नहीं होता, कोई delivery का प्रयास नहीं किया जाता, और कोई भी संदेश किसी वास्तविक व्यक्ति तक नहीं पहुँच सकता।

Staging app को sink की ओर point करें

जब application एक ही Compose project में container के रूप में चलती है, तो application के SMTP host को mailpit पर सेट करें, या जब यह host पर चलती है तो इसे 127.0.0.1 पर सेट करें। Port को 1025 पर सेट करें, TLS को बंद (off) करें, और username तथा password को खाली छोड़ दें। Mailpit anonymous mail स्वीकार करता है।

कुछ frameworks credentials के बिना mail भेजने से मना कर देते हैं। MP_SMTP_AUTH_ALLOW_INSECURE=1 unencrypted connection पर PLAIN और LOGIN mechanisms की अनुमति देता है, जबकि MP_SMTP_AUTH_ACCEPT_ANY=1 Mailpit को किसी भी username और password को स्वीकार करने के लिए बाध्य करता है। ये दोनों settings यहाँ केवल इसलिए सुरक्षित हैं क्योंकि listener internet से पहुँच के बाहर है, जिसे नीचे दी गई deployment सुनिश्चित करती है।

MP_SMTP_ALLOWED_RECIPIENTS को पहले दिन से ही सेट करना उचित है। यह एक regular expression लेता है और उन सभी प्राप्तकर्ताओं (recipients) को अस्वीकार कर देता है जो इससे मेल नहीं खाते। इसे अपने test domain पर point करें। इससे यदि staging database में कोई वास्तविक customer address रह जाता है, तो वह चुपचाप sink में जाने के बजाय आपके application log में एक स्पष्ट failure के रूप में दिखाई देगा।

Docker Compose फ़ाइल

सबसे पहले वेब इंटरफ़ेस के लिए डायरेक्टरी और पासवर्ड फ़ाइल बनाएँ। htpasswd -B एक bcrypt हैश लिखता है, और Mailpit bcrypt के साथ-साथ प्लेन टेक्स्ट को भी पढ़ सकता है।

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

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$$'

दोहरा डॉलर चिह्न कोई टाइपिंग त्रुटि नहीं है। Compose एक एकल $ को वेरिएबल के विस्तार की शुरुआत के रूप में पढ़ता है, इसलिए $$ वह तरीका है जिससे आप एक लिटरल डॉलर को कंटेनर तक पहुँचाते हैं। यह regex Mailpit तक @example\.test$ के रूप में पहुँचता है।

इसे स्टार्ट करें और हेल्थ स्टेट की जाँच करें:

docker compose up -d
docker compose ps

STATUS कॉलम में Up ... (healthy) लिखा होना चाहिए। इमेज अपना खुद का हेल्थचेक शिप करती है जो हर 15 सेकंड में /mailpit readyz चलाता है, इसलिए जो कंटेनर starting पर रहता है या unhealthy हो जाता है, वह आमतौर पर कंटेनर के अंदर 8025 पर सर्विस नहीं दे रहा होता है। यह चेक MP_ एनवायरनमेंट वेरिएबल्स से सेटिंग्स उठाता है, न कि कमांड-लाइन फ्लैग्स से, यही कारण है कि यह गाइड सब कुछ environment: के तहत सेट करती है। यदि आप विकल्पों को फ्लैग के रूप में पास करते हैं, तो चेक unhealthy रिपोर्ट कर सकता है जबकि Mailpit सामान्य रूप से काम कर रहा हो। कुछ भी और बदलने से पहले docker compose logs mailpit पढ़ें।

दोनों पब्लिश किए गए पोर्ट्स में एक एड्रेस होता है, और वह एड्रेस ही सुरक्षा नियंत्रण है। कंटेनर के अंदर Mailpit 0.0.0.0 पर लिसन करता है, जो कि ठीक है, क्योंकि कंटेनर का अपना नेटवर्क नेमस्पेस होता है। मैपिंग का बायां हिस्सा यह तय करता है कि बाहर से इसे कौन एक्सेस कर सकता है। 8025:8025 लिखें और Docker होस्ट के हर एड्रेस को बाइंड कर देगा, जिसमें पब्लिक एड्रेस भी शामिल है।

यदि आपका स्टेजिंग ऐप इसी फ़ाइल में एक सर्विस है, तो 1025 मैपिंग को पूरी तरह से हटा दें और ऐप को पोर्ट 1025 पर mailpit होस्टनेम की ओर पॉइंट करें। एक साझा Compose नेटवर्क पर कंटेनर सीधे एक-दूसरे तक पहुँच सकते हैं, इसलिए SMTP पोर्ट कभी भी होस्ट को टच नहीं करता है। Compose नेटवर्क सर्विस नामों को कैसे रिज़ॉल्व करते हैं में इस लुकअप के बारे में विस्तार से बताया गया है।

एक संदेश भेजें और जाँचें कि वह पहुँच गया है

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

सफलता मिलने पर script कुछ भी print नहीं करती है। API के माध्यम से पुष्टि करें कि संदेश store हो गया है:

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

यह store किए गए संदेशों की सूची वाला JSON लौटाता है। -u flag को हटा दें और वही request अस्वीकार कर दी जाएगी, क्योंकि MP_UI_AUTH_FILE API और web interface दोनों की सुरक्षा करता है। inbox को पढ़ने वाले किसी भी test को वे credentials भी भेजने होंगे।

Python script से ConnectionRefusedError का मतलब है कि 127.0.0.1:1025 पर कोई service listening मोड में नहीं है। यदि आपने SMTP mapping हटा दी है, तो यही अपेक्षित परिणाम है, और ऐसी स्थिति में check को उसी Compose network पर स्थित किसी container से चलना चाहिए।

nginx के माध्यम से वेब इंटरफेस को पासवर्ड के साथ प्रकाशित करना

इंटरफेस वर्तमान में केवल loopback address पर ही प्रतिक्रिया देता है। nginx TLS को terminate करता है और कुछ भी पहुँचने से पहले पासवर्ड मांगता है।

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;
    }
}

सिंटैक्स की जाँच करने के बाद sudo nginx -t && sudo systemctl reload nginx के साथ reload करें। यदि आप पहली बार proxy का उपयोग कर रहे हैं, तो reverse proxy ब्लॉक में प्रत्येक directive क्या करती है इसे पढ़ना उपयोगी है।

nginx फ़ाइल और data/ui-auth में एक ही username और password का उपयोग करें। nginx ब्राउज़र के Authorization हेडर को upstream तक भेजता है, इसलिए मेल खाते क्रेडेंशियल्स एक ही प्रॉम्प्ट के साथ दोनों जाँचों को पूरा कर देते हैं। अलग-अलग क्रेडेंशियल्स का उपयोग करने पर ब्राउज़र के पास एक सेट रह जाता है जिसे दूसरी जाँच अस्वीकार कर देती है।

Upgrade और Connection हेडर केवल सजावट नहीं हैं। Mailpit एक खुले पेज पर WebSocket के माध्यम से नए मेल भेजता है, और बिना उन हेडर्स के HTTP/1.1 पर चलने वाला proxy कनेक्शन को अपग्रेड नहीं कर सकता है। ऐसी स्थिति में पेज सही ढंग से लोड तो हो जाता है लेकिन कभी अपडेट नहीं होता: मेल आता है, API उसे दिखाता है, लेकिन जब तक आप पेज reload नहीं करते, सूची स्थिर रहती है।

दोनों सुरक्षा स्तरों को बनाए रखें। nginx पासवर्ड public address की सुरक्षा करता है, और MP_UI_AUTH_FILE स्वयं 8025 पोर्ट की सुरक्षा करता है। यह महत्वपूर्ण है क्योंकि आपके staging app द्वारा जनरेट किया गया प्रत्येक पासवर्ड रीसेट लिंक, जब तक retention उसे रखता है, उस इंटरफेस में पढ़ा जा सकता है।

सिंक को कभी भी ओपन रिले न बनने दें

ओपन रिले एक ऐसा SMTP सर्वर है जो किसी से भी संदेश स्वीकार करता है और उसे किसी भी गंतव्य पर भेज देता है। स्पैमर्स लगातार इनकी तलाश में रहते हैं, और यदि उन्हें आपके पते पर एक भी ओपन रिले मिल जाए, तो परिणाम स्वरूप आपको एब्यूज रिपोर्ट मिल सकती है और आपका अकाउंट सस्पेंड हो सकता है।

Mailpit डिफ़ॉल्ट रूप से ओपन रिले नहीं है, क्योंकि यह अपने आप कुछ भी आगे नहीं भेजता है। इसमें दो आउटबाउंड फीचर्स हैं, और जब तक आप उन्हें कॉन्फ़िगर नहीं करते, वे बंद रहते हैं। MP_SMTP_RELAY_CONFIG एक रिले कॉन्फ़िगरेशन फ़ाइल को इंगित करता है और इंटरफ़ेस में रिलीज़ एक्शन को सक्षम करता है, जो आपके द्वारा चुने गए संदेश को उस सर्वर के माध्यम से भेजता है; स्वचालित रिलेइंग के लिए एक अतिरिक्त स्विच, MP_SMTP_RELAY_ALL (डिफ़ॉल्ट false) या MP_SMTP_RELAY_MATCHING की आवश्यकता होती है। फॉरवर्डिंग, जिसे MP_SMTP_FORWARD_CONFIG या MP_SMTP_FORWARD_* वेरिएबल्स के साथ सेट किया जाता है, प्रत्येक आने वाले संदेश की एक कॉपी आपके द्वारा चुने गए निश्चित पतों पर भेज देता है। इन सभी को अनसेट छोड़ना एक जानबूझकर लिया गया निर्णय है।

इस सुरक्षा को खोने के दो तरीके हैं। MP_SMTP_RELAY_ALL को चालू करें, जो प्रत्येक आने वाले संदेश को उसके मूल प्राप्तकर्ताओं को भेज देता है और MP_SMTP_ALLOWED_RECIPIENTS को अनदेखा कर देता है, फिर SMTP पोर्ट को इंटरनेट के लिए एक्सपोज़ कर दें, और आपने एक सक्रिय ओपन रिले बना लिया है। MP_SMTP_RELAY_MATCHING किसी भी ऐसे प्राप्तकर्ता के लिए यही काम करता है जिसका पैटर्न मेल खाता है। बिना रिले के पोर्ट को एक्सपोज़ करने पर, बाहरी लोग आपके माध्यम से मेल तो नहीं भेज पाएंगे, लेकिन वे आपके स्टोरेज को भर सकते हैं और उस इंटरफ़ेस में सामग्री डाल सकते हैं जिस पर आपकी टीम भरोसा करती है। फॉरवर्डिंग चालू होने पर, उनके संदेश उन इनबॉक्स में भी पहुँच जाते हैं जहाँ कॉपी भेजी जाती है।

Docker होस्ट पर सबसे बड़ा खतरा फ़ायरवॉल है। पोर्ट पब्लिश करने से Docker nat टेबल में अपने स्वयं के नियम लिख देता है, और कंटेनर के लिए आने वाला ट्रैफ़िक ufw (uncomplicated firewall) नियमों के लागू होने से पहले ही वहाँ मैच हो जाता है। sudo ufw deny 1025/tcp सफलता की रिपोर्ट देता है लेकिन कुछ भी नहीं बदलता है। Docker पोर्ट्स को ufw के पार सीधे पब्लिश क्यों करता है लेख में चेन ऑर्डर के बारे में विस्तार से बताया गया है।

इसका समाधान मैपिंग में पता (address) सेट करना है, न कि फ़ायरवॉल नियम। जाँचें कि वास्तव में क्या बाइंड है:

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

स्वस्थ आउटपुट में 127.0.0.1:1025 और 127.0.0.1:8025 दिखाई देना चाहिए। यदि कोई लाइन 0.0.0.0:1025 पढ़ती है, तो इसका मतलब है कि मैपिंग ने अपना पता खो दिया है और सिंक इंटरनेट पर लिसन कर रहा है। किसी अन्य मशीन से, nc -vz mail-test.example.com 1025 को टाइम आउट हो जाना चाहिए या रिफ्यूज हो जाना चाहिए।

जब एप्लिकेशन किसी अलग सर्वर पर हो, तो दोनों को जोड़ने के लिए 1025 पोर्ट न खोलें। दोनों मशीनों को एक प्राइवेट नेटवर्क या VPN टनल पर रखें, और मैपिंग को उस इंटरफ़ेस एड्रेस पर बाइंड करें।

केवल तभी MX records प्रकाशित करें जब आप वास्तव में inbound mail प्राप्त करना चाहते हों

एक MX (mail exchanger) record अन्य mail servers को यह बताता है कि किसी domain के लिए mail कौन सा host स्वीकार करता है। इसे न रखने से ही दरवाजा बंद नहीं हो जाता: जब किसी domain का कोई MX record नहीं होता, तो भेजने वाले servers उसके address (A या AAAA) record पर वापस चले जाते हैं, जैसा कि RFC 5321 section 5.1 में निर्दिष्ट है, और जिस hostname को आप web interface के लिए इस box पर point करते हैं, उसका एक record होता है। internet mail को बाहर रखने वाली बात यह है कि box पर port 25 पर कोई भी service listen नहीं कर रही होती। inbox में केवल वही mail होता है जिसे आपके अपने applications ने submit किया है, जो कि एक test mailbox का उद्देश्य है।

वास्तविक mail प्राप्त करने का अर्थ है एक ऐसा DNS record जो भेजने वाले servers को box तक ले जाए (एक MX record, या वह address record जिस पर वे वापस जाते हैं), Mailpit का port 25 (MP_SMTP_BIND_ADDR=0.0.0.0:25) पर listen करना, और उस port का खुला होना। उस क्षण आप domain के प्रत्येक address के लिए एक public catch-all चला रहे होते हैं। इसके परिणामों के प्रति स्पष्ट रहें।

• record के दिखाई देने के कुछ ही दिनों के भीतर spam शुरू हो जाता है, क्योंकि harvesters DNS को पढ़ते हैं। Dictionary attacks फिर सामान्य नामों के माध्यम से चलते हैं और हर प्रयास के लिए एक message store करते हैं।
• अजनबियों के attachments आपकी disk पर आते हैं और वहीं रहते हैं। उन्हें filter करने वाला कोई नहीं है, इसलिए एक अज्ञात sender की archive आपकी अपनी test mail के बगल में स्थित होती है।
• जो कोई भी domain के बारे में जान जाता है, वह उस पर मौजूद किसी address के साथ third party services के लिए sign up कर सकता है, और confirmation mail आपके server पर deliver हो जाती है। यदि password gate कभी चूक जाता है, तो वे accounts उस व्यक्ति के हो जाते हैं जो inbox पढ़ रहा है।
• Retention limits केवल housekeeping नहीं रह जातीं, बल्कि load bearing बन जाती हैं, क्योंकि volume अब आपके नियंत्रण में नहीं रहता।

यदि आपको deliverability check के लिए वास्तविक inbound mail की आवश्यकता है, तो इसे एक dedicated subdomain दें, MP_MAX_AGE को छोटा रखें, और इसमें मौजूद हर चीज़ को public मानें। यदि आपको ऐसे mailboxes की आवश्यकता है जिन पर लोग भरोसा कर सकें, तो इसके बजाय filtering और backups के साथ एक वास्तविक mail server चलाएं।

Retention: unbounded catch-all डिस्क को कैसे भरता है

Mailpit डिफ़ॉल्ट रूप से 500 संदेश रखता है और उसके बाद सबसे पुराने संदेशों को समय-समय पर हटा देता है। MP_MAX_MESSAGES: 0 इस सीमा को हटा देता है, और यदि कोई MP_MAX_AGE सेट न हो तो कुछ भी स्वचालित रूप से डिलीट नहीं होता है, जिससे catch-all डिस्क को भर देता है और किसी को पता भी नहीं चलता। MP_MAX_AGE एक समय सीमा जोड़ता है, जो संदेश सीमा के साथ या उसके स्थान पर काम करता है, और इसे घंटों या दिनों में, 36h या 14d के रूप में लिखा जाता है।

MP_DATABASE यह तय करता है कि इसमें से कुछ भी सुरक्षित रहता है या नहीं। इसके बिना, Mailpit एक अस्थायी फ़ाइल में लिखता है जिसे प्रोसेस बंद होने पर हटा दिया जाता है, इसलिए हर रीस्टार्ट पर इनबॉक्स खाली हो जाता है। इसके साथ, मेल रीस्टार्ट के बाद भी सुरक्षित रहता है और फ़ाइल का आकार बढ़ता रहता है।

अटैचमेंट ही वह चीज़ है जो जगह घेरती है। एक nightly job जो 300 टेस्ट एड्रेस पर 2 MB की PDF रिपोर्ट मेल करती है, वह प्रति रात 600 MB डेटा बनाती है, और केवल संदेशों की संख्या की सीमा समय पर काम नहीं करेगी। उस वृद्धि का बजट उस वॉल्यूम के अन्य डेटा के साथ संतुलित करें, क्योंकि PhotoPrism या Immich जैसा मीडिया-हैवी पड़ोसी पहले ही एक छोटी VPS डिस्क का अधिकांश हिस्सा ले चुका होगा।

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

कैप ट्रिगर होने का इंतज़ार करने के बजाय CI रन के बीच स्टोर को खाली करें:

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

Inbucket इसी समस्या को INBUCKET_STORAGE_RETENTIONPERIOD (इमेज में 72h) और INBUCKET_STORAGE_MAILBOXMSGCAP (300) के साथ संभालता है। आप जो भी रन करें, पहली टेस्ट सुइट को पॉइंट करने से पहले ही सीमा निर्धारित कर लें।

अपने टेस्ट सूट से इनबॉक्स पढ़ना

GET /api/v1/messages यह सूचीबद्ध करता है कि क्या स्टोर किया गया है, GET /api/v1/message/{ID} एक संदेश को उसके हिस्सों और हेडर के साथ लौटाता है, GET /api/v1/search फिल्टर करता है, और DELETE /api/v1/messages स्टोर को खाली कर देता है। आपके द्वारा चलाए जा रहे संस्करण के लिए इंटरैक्टिव डॉक्यूमेंटेशन http://127.0.0.1:8025/api/v1/ पर उपलब्ध है।

एक उपयोगी टेस्ट एक संदेश भेजता है, उसके आने तक पोल (poll) करता है, विषय और उसके अंदर के लिंक की जाँच करता है, और फिर सब कुछ डिलीट कर देता है। एक सिंगल रिक्वेस्ट के बजाय एक छोटे रिट्राई लूप में पोल करें, क्योंकि जो एप्लिकेशन बैकग्राउंड वर्कर में मेल को कतारबद्ध (queue) करती है, वह Mailpit के पास संदेश पहुँचने से पहले ही सेंड कॉल से वापस आ जाती है। यही पैटर्न सेल्फ-होस्टेड API टेस्टिंग और मॉकिंग टूल्स में दिखाई देता है, जो आमतौर पर एक स्टेजिंग एनवायरनमेंट का दूसरा हिस्सा होता है जो कभी भी प्रोडक्शन को प्रभावित नहीं करता है।

FAQ

क्या self-hosted disposable email inbox एक open relay है?

नहीं, जब तक relaying बंद है। डिफ़ॉल्ट रूप से Mailpit कुछ भी आगे नहीं भेजता: MP_SMTP_RELAY_CONFIG केवल आपके द्वारा चुने गए संदेशों को मैन्युअल रूप से भेजने की अनुमति देता है, और स्वचालित relaying के लिए MP_SMTP_RELAY_ALL या MP_SMTP_RELAY_MATCHING की आवश्यकता होती है। इन्हें unset रहने दें, तो port 1025 तक पहुँचने वाला कोई भी बाहरी व्यक्ति आपके सर्वर के माध्यम से मेल नहीं भेज पाएगा। वे अभी भी आपके स्टोरेज को भर सकते हैं, इसलिए SMTP port को केवल उस address पर bind करें जिसे केवल आपका application ही access कर सके। इसे Compose में 1025:1025 के रूप में publish करने पर यह हर host address पर bind हो जाता है, और sudo ufw deny 1025/tcp इसे बंद नहीं करेगा, क्योंकि Docker के अपने nat rules पहले match होते हैं।

क्या मुझे अपने test domain के लिए MX record की आवश्यकता है?

केवल तभी जब आप चाहते हैं कि internet से मेल आए, और इसे न रखना अपने आप में कोई सुरक्षा नहीं है। MX record के बिना, भेजने वाले सर्वर domain के A या AAAA record पर वापस चले जाते हैं, इसलिए जो चीज़ वास्तव में internet mail को बाहर रखती है, वह यह है कि port 25 पर कोई service listening नहीं है। तब inbox में केवल वही मेल होते हैं जिन्हें आपके अपने applications SMTP के माध्यम से submit करते हैं। DNS को box की ओर point करें और port 25 खोलें, तो आप एक public catch-all चला रहे होंगे: कुछ ही दिनों में spam, dictionary attacks जो हर प्रयास के लिए एक संदेश store करते हैं, और बिना किसी फ़िल्टरिंग के अजनबियों द्वारा भेजे गए attachments आपकी disk पर जमा हो जाएंगे।

संदेश सूची केवल page reload करने पर ही update क्यों होती है?

Mailpit एक खुले page पर WebSocket के माध्यम से नया मेल push करता है। यदि nginx location block में proxy_http_version 1.1 और Upgrade तथा Connection headers गायब हैं, तो वह connection upgrade नहीं हो पाता, इसलिए page सामान्य रूप से load होता है और फिर रुक जाता है। मेल अभी भी आता है और API अभी भी उसे return करता है, यही कारण है कि inbox टूटा हुआ नहीं बल्कि पुराना (stale) दिखता है। उन lines को जोड़ें, nginx को reload करें, और फिर page को reload करें।

मैं inbox को disk भरने से कैसे रोकूँ?

MP_MAX_MESSAGES को एक वास्तविक संख्या पर रखें और MP_MAX_AGE जोड़ें। डिफ़ॉल्ट सीमा 500 संदेशों की है, और इसे 0 पर सेट करने से count-based deletion अक्षम हो जाता है, इसलिए जब तक MP_MAX_AGE सेट न हो, कुछ भी prune नहीं होता, और इसी तरह attachments वाला catch-all चुपचाप बढ़ता रहता है। MP_MAX_AGE घंटों या दिनों को स्वीकार करता है, जैसे कि 36h या 14d। CI teardown में curl -u qa:yourpassword -X DELETE http://127.0.0.1:8025/api/v1/messages के साथ store को साफ़ करें, क्योंकि API वही credentials मांगता है जो web interface के लिए उपयोग होते हैं। Inbucket भी INBUCKET_STORAGE_RETENTIONPERIOD (72h) और INBUCKET_STORAGE_MAILBOXMSGCAP (300) के साथ यही काम करता है।

क्या मुझे Mailpit, Inbucket या MailHog चलाना चाहिए?

अक्टूबर 2026 तक, नए काम के लिए Mailpit का उपयोग करें। MailHog अभी भी चलता है, लेकिन इसकी default branch में अगस्त 2022 के बाद से कोई commit नहीं हुआ है, इसलिए यह unpatched dependencies के साथ आता है। Inbucket सक्रिय रूप से maintained है (3.2.0, अक्टूबर 2026) और जब test के लिए POP3 की आवश्यकता हो तो यह बेहतर विकल्प है, क्योंकि Mailpit का POP3 सर्वर केवल तभी शुरू होता है जब आप उसे credentials देते हैं, या तो password file में या MP_POP3_AUTH variable में। Mailpit, MailHog वाले ही ports (1025 और 8025) का उपयोग करता है, इसलिए MailHog को बदलने के लिए आपके Compose file में केवल एक image name बदलना पर्याप्त है।