लेखक: Matt Connor 2026-08-18 · अपडेट किया गया: 2026-08-21

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

Q: मैं inbox को डिस्क भरने से कैसे रोकूँ?

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

Mailpit का उपयोग करके अपने staging app के लिए एक सुरक्षित disposable email inbox बनाएँ। यह गाइड Docker Compose के जरिए सभी टेस्ट ईमेल को एक ही जगह रोकने का तरीका बताती है।

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, और संदेश प्राप्त करने के बाद ये क्या कर सकते हैं, इस पर निर्भर करता है। नीचे दी गई versions की जांच अगस्त 2026 में की गई थी।

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

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

Mailpit (axllent/mailpit) MailHog वाले ही ports, 1025 और 8025 का उपयोग करता है, इसलिए यह application config को बदले बिना MailHog की जगह ले लेता है। Version 1.30.7 को 8 अगस्त 2026 को release किया गया था। इसमें इस गाइड के लिए आवश्यक सभी चीजें binary के भीतर मौजूद हैं: वेब इंटरफ़ेस और API (application programming interface) के लिए password फ़ाइल, संदेशों की अधिकतम सीमा, समय सीमा, और recipient फ़िल्टर। इस गाइड का शेष भाग 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.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$$'

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

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

docker compose up -d
docker compose ps

STATUS कॉलम में Up ... (healthy) लिखा होना चाहिए। इमेज अपना खुद का हेल्थचेक शिप करती है जो हर 15 सेकंड में /mailpit readyz चलाता है, इसलिए जो कंटेनर starting पर रहता है या unhealthy हो जाता है, वह कंटेनर के अंदर 8025 पर सर्विस नहीं दे रहा है। कुछ भी और बदलने से पहले 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 स्वयं port 8025 की सुरक्षा करता है। यह महत्वपूर्ण है क्योंकि आपके staging ऐप द्वारा जनरेट किया गया हर पासवर्ड रीसेट लिंक उस इंटरफेस में पढ़ा जा सकता है।

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

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

Mailpit डिफ़ॉल्ट रूप से ओपन रिले नहीं है, क्योंकि यह कभी भी संदेशों को फॉरवर्ड नहीं करता है। रिले तब तक बंद रहता है जब तक आप MP_SMTP_RELAY_CONFIG को किसी रिले कॉन्फ़िगरेशन फ़ाइल पर पॉइंट नहीं करते, और जब तक आप ऐसा नहीं करते, इंटरफ़ेस में रिलीज़ एक्शन कुछ नहीं करता है। इसे अनसेट (unset) छोड़ना एक सोची-समझी रणनीति है।

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

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

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

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

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

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

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

एक MX (mail exchanger) record अन्य mail servers को यह बताता है कि किसी domain के लिए mail कौन सा host स्वीकार करता है। यदि आपके throwaway domain पर कोई MX record नहीं है, तो इंटरनेट से कोई भी मेल नहीं आ पाएगा, क्योंकि भेजने वाले servers के पास उसे deliver करने के लिए कोई गंतव्य नहीं होगा। inbox में केवल वही मेल होते हैं जिन्हें आपके अपने applications ने सबमिट किया है, और test mailbox का उद्देश्य यही होता है।

वास्तविक मेल प्राप्त करने का अर्थ है कि एक MX record उस box की ओर इशारा कर रहा हो, Mailpit port 25 (MP_SMTP_BIND_ADDR=0.0.0.0:25) पर listening मोड में हो, और वह 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 नहीं रह जातीं, बल्कि एक महत्वपूर्ण बोझ बन जाती हैं, क्योंकि volume अब आपके नियंत्रण में नहीं रहता।

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

Retention: अनबाउंडेड कैच-ऑल डिस्क को कैसे भरता है

Mailpit डिफ़ॉल्ट रूप से 500 संदेश रखता है और उसके बाद सबसे पुराने संदेशों को समय-समय पर हटा देता है। MP_MAX_MESSAGES: 0 स्वचालित विलोपन (automatic deletion) को पूरी तरह से बंद कर देता है, और यही वह बदलाव है जिसके कारण कैच-ऑल किसी के ध्यान में आए बिना डिस्क को भर देता है। MP_MAX_AGE एक समय सीमा जोड़ता है और इसे घंटों या दिनों में लिखा जाता है, जैसे कि 36h या 14d।

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

अटैचमेंट ही वह चीज़ है जो जगह घेरती है। एक नाइटली जॉब जो 300 टेस्ट एड्रेस पर 2 MB की PDF रिपोर्ट मेल करती है, वह प्रति रात 600 MB की खपत करती है, और केवल संदेशों की संख्या पर सीमा (message count cap) समय रहते प्रतिक्रिया नहीं देगी। उस वृद्धि का बजट उस वॉल्यूम के अनुसार रखें जो अन्य सेवाओं के साथ साझा किया गया है, क्योंकि 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 को relay configuration पर पॉइंट नहीं करते। इसलिए, port 1025 तक पहुँचने वाला कोई बाहरी व्यक्ति आपके सर्वर के माध्यम से मेल नहीं भेज सकता। वे अभी भी आपके स्टोरेज को भर सकते हैं, इसलिए SMTP port को केवल उस address पर bind करें जहाँ तक आपका application पहुँच सके। इसे Compose में 1025:1025 के रूप में publish करने से यह हर host address पर bind हो जाता है, और sudo ufw deny 1025/tcp इसे बंद नहीं करेगा, क्योंकि Docker के अपने nat rules पहले मैच होते हैं।

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

केवल तभी जब आप चाहते हैं कि internet से मेल आए। MX record के बिना, भेजने वाले सर्वर के पास deliver करने के लिए कोई जगह नहीं होती, इसलिए inbox में केवल वही रहता है जो आपके अपने applications SMTP के माध्यम से सबमिट करते हैं। record publish करें और port 25 खोलें, तो आप एक public catch-all चला रहे होंगे: कुछ ही दिनों में spam, dictionary attacks जो हर प्रयास पर एक संदेश स्टोर करते हैं, और बिना किसी फ़िल्टरिंग के आपकी डिस्क पर अजनबियों द्वारा भेजे गए attachments।

संदेश सूची केवल पेज रीलोड करने पर ही अपडेट क्यों होती है?

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

मैं inbox को डिस्क भरने से कैसे रोकूँ?

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

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

अगस्त 2026 तक, नए काम के लिए Mailpit का उपयोग करें। MailHog अभी भी चलता है, लेकिन इसकी डिफ़ॉल्ट शाखा में अगस्त 2022 से कोई commit नहीं हुआ है, इसलिए यह unpatched dependencies के साथ आता है। Inbucket सक्रिय रूप से बनाए रखा गया है (3.1.1, दिसंबर 2025) और जब किसी test को POP3 की आवश्यकता हो तो यह बेहतर विकल्प है, क्योंकि Mailpit का POP3 सर्वर केवल तभी शुरू होता है जब आप उसे password फ़ाइल देते हैं। Mailpit वही ports उपयोग करता है जो MailHog करता है, 1025 और 8025, इसलिए MailHog को बदलने के लिए आपके Compose फ़ाइल में केवल एक image नाम बदलना पड़ता है।

#email #testing#mailpit#inbucket#Docker #सेल्फ़-होस्टिंग