Mailcow के साथ अपना ईमेल सर्वर कैसे होस्ट करें

आप क्या बना रहे हैं

अपने स्वयं के सर्वर पर एक पूर्ण मेल सर्वर: भेजने और प्राप्त करने के लिए SMTP, आपके फोन और लैपटॉप को सिंक में रखने के लिए IMAP, एक वेबमेल क्लाइंट, और एक स्पैम फिल्टर जो दोनों दिशाओं में प्रत्येक संदेश को स्कोर करता है। mailcow-dockerized एक ही Docker Compose स्टैक में Postfix, Dovecot, Rspamd, SOGo वेबमेल, MariaDB, Redis और एक ACME क्लाइंट को बंडल करता है, इसलिए सॉफ्टवेयर का हिस्सा कठिन नहीं है। आप इसे आधे घंटे में चला लेंगे।

कठिन हिस्सा इसके आसपास की हर चीज है। ईमेल वह सेवा है जहाँ बाकी इंटरनेट सक्रिय रूप से एक बिल्कुल नए सर्वर पर अविश्वास करता है, और "यह काम करता है" तथा "Gmail चुपचाप हर संदेश को खा जाता है" के बीच का अंतर चार DNS रिकॉर्ड और एक IP-reputation सेटिंग पर निर्भर करता है जिसे आप पूरी तरह से नियंत्रित नहीं कर सकते हैं। कुछ भी किराए पर लेने से पहले नीचे दी गई पूर्व-आवश्यकताओं को पढ़ें। यदि उन्हें पढ़ने के बाद, आप यह तय करते हैं कि reputation बनाए रखने की मेहनत इसके लायक नहीं है, तो यह एक वैध निर्णय है, 2026 में वास्तव में क्या self-host करने योग्य है, इसका हमारा विवरण ईमेल को ठीक इन्हीं कारणों से "केवल तभी जब आप इसे गंभीरता से लें" श्रेणी में रखता है।

प्रिरिक्विजिट्स (prerequisites) ही प्रोजेक्ट हैं

इनमें से किसी एक को भी छोड़ने पर आपकी भेजी गई ईमेल कभी नहीं पहुँचेगी। यहाँ उन चीजों का क्रम दिया गया है जो अक्सर लोगों के काम को विफल कर देती हैं:

आउटबाउंड पोर्ट 25 खुला होना चाहिए। आपका सर्वर TCP पोर्ट 25 के माध्यम से Gmail और Microsoft को मेल डिलीवर करता है। स्पैम रोकने के लिए अधिकांश VPS और क्लाउड प्रदाता डिफ़ॉल्ट रूप से आउटबाउंड 25 को ब्लॉक कर देते हैं। यह ब्लॉक साइलेंट होता है, बूट के समय कोई एरर नहीं आता, सब कुछ सही दिखता है, और मेल हमेशा के लिए क्यू (queue) में पड़ा रहता है। कुछ भी इंस्टॉल करने से पहले इसे टेस्ट करें। यदि यह ब्लॉक है, तो एकमात्र समाधान अपने प्रदाता को सपोर्ट टिकट भेजकर इसे खुलवाना है; कुछ प्रदाता पुराने अकाउंट्स के लिए ऐसा कर देते हैं, जबकि कुछ कभी नहीं करते।

उपयोगी प्रतिष्ठा (reputation) वाला एक क्लीन IP। रीसायकल किए गए VPS IP अक्सर पिछले उपयोगकर्ता द्वारा स्पैम फैलाने के कारण पहले से ही ब्लॉकलिस्ट में होते हैं। प्रतिबद्ध होने से पहले Spamhaus lookup या mxtoolbox जैसी सर्विस पर अपना IP चेक करें। लिस्टेड IP का मतलब है ऐसे रिजेक्शन जिन्हें आप कोडिंग से ठीक नहीं कर सकते।

DNS का नियंत्रण और एक सही PTR रिकॉर्ड। आपको अपने डोमेन के ज़ोन में रिकॉर्ड जोड़ने होंगे, और आपको अपने सर्वर के IP के लिए रिवर्स DNS (PTR) की आवश्यकता होगी जो आपके मेल होस्टनेम की ओर इशारा करे। PTR आमतौर पर आपके DNS पैनल में सेट नहीं होता है, यह उस संस्था के पास होता है जिसके पास IP का स्वामित्व है, इसलिए इसे आपके VPS प्रदाता के कंट्रोल पैनल में या टिकट के माध्यम से सेट किया जाता है।

6 GiB RAM और 2 vCPU एक आरामदायक न्यूनतम आवश्यकता है। एक निजी इंस्टॉलेशन के लिए mailcow की न्यूनतम आवश्यकता 6 GiB RAM और 1 GiB स्वैप है, और जब कुछ उपयोगकर्ता इस पर निर्भर हो जाएं तो 8 GiB की सलाह दी जाती है। लगभग 2.5 GiB से नीचे, generate_config.sh ClamAV वायरस स्कैनर को डिसेबल करने का विकल्प देता है ताकि कर्नल कंटेनर्स को बंद (kill) न करे। शुरुआत के लिए इसे 20 GB SSD दें।

एक DNS नाम, न कि केवल एक IP। mail.example.com जैसा एक होस्टनेम चुनें। यही एकमात्र नाम आपका MAILCOW_HOSTNAME, आपका TLS सर्टिफिकेट सब्जेक्ट, आपका PTR टारगेट और आपका SMTP बैनर बन जाता है। इसे हर जगह एक समान रखें।

चरण 1, साबित करें कि outbound port 25 खुला है

सबसे पहले यह करें। यदि यह विफल रहता है, तो बाकी सब कुछ व्यर्थ है। नए VPS से, एक वास्तविक mail server के साथ SMTP conversation शुरू करने का प्रयास करें:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25

एक सफल परिणाम तुरंत मिलता है:

Connection to gmail-smtp-in.l.google.com (142.250.x.x) 25 port [tcp/smtp] succeeded!

एक blocked port पूरे पांच सेकंड के लिए hang हो जाता है, और फिर विफल हो जाता है:

nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) timed out: Operation now in progress

वह timeout ही block है। यह provider-side network filter है, न कि आपका firewall, इसलिए कोई भी local बदलाव इसे ठीक नहीं करेगा। एक ticket खोलें: "कृपया मेरे VPS के लिए <IP> पर outbound TCP port 25 सक्षम करें; मैं एक वैध mail server चला रहा हूँ।" जब तक यह "succeeded" न हो जाए, तब तक mailcow इंस्टॉल न करें। ध्यान दें कि inbound 25 (अन्य सर्वर जो आप तक पहुँचते हैं) एक अलग मार्ग है और आमतौर पर खुला रहता है, यह outbound पक्ष है जिसे providers सीमित (throttle) करते हैं।

चरण 2, अभी DNS रिकॉर्ड सेट करें

DNS परिवर्तनों को propagate होने में समय लगता है, इसलिए इंस्टॉलेशन से पहले ही सब कुछ पब्लिश कर दें। मान लें कि आपका डोमेन example.com है, आपका मेल होस्ट mail.example.com है, और IP 10.0.0.10 है। अपने ज़ोन में, निम्नलिखित बनाएँ:

mail.example.com.        A      10.0.0.10
mail.example.com.        AAAA   2001:db8::10          ; only if you have IPv6
example.com.             MX  10 mail.example.com.
example.com.             TXT    "v=spf1 mx -all"
_dmarc.example.com.      TXT    "v=DMARC1; p=none; rua=mailto:postmaster@example.com"

SPF रिकॉर्ड का अर्थ है "केवल मेरा MX इस डोमेन के लिए मेल भेज सकता है, बाकी को अस्वीकार करें"। DMARC को p=none पर शुरू करें ताकि आप अपने मेल को रिजेक्ट किए बिना रिपोर्ट्स की निगरानी कर सकें; एक बार अलाइनमेंट सिद्ध हो जाने पर इसे p=quarantine और फिर p=reject पर सख्त करें। दो रिकॉर्ड जानबूझकर अभी भी गायब हैं: DKIM, जिसे mailcow आपके लिए चरण 6 में जनरेट करेगा, और PTR, जिसे आप अभी अपने प्रोवाइडर के पैनल में सेट करते हैं।

10.0.0.10 के लिए PTR (रिवर्स DNS) को mail.example.com पर सेट करें, जो MAILCOW_HOSTNAME का सटीक मान है। यह वह एकमात्र रिकॉर्ड है जिसे अधिकांश लोग भूल जाते हैं, और बड़े प्रोवाइडर्स इसी के आधार पर मेल रिजेक्ट कर देते हैं। यदि आपके पैनल में rDNS फ़ील्ड नहीं है, तो एक टिकट रेज़ करें।

चरण 3, Docker इंस्टॉल करें

mailcow को Compose v2 प्लगइन के साथ Docker Engine की आवश्यकता होती है। Ubuntu के docker.io पैकेज के बजाय Docker की आधिकारिक सुविधा स्क्रिप्ट (convenience script) का उपयोग करें, क्योंकि उस पैकेज में कोई Compose प्लगइन नहीं होता है:

curl -fsSL https://get.docker.com | sudo sh
sudo docker compose version

आपको एक Docker Compose version v2.x लाइन दिखाई देनी चाहिए। यदि docker compose version कमांड docker: 'compose' is not a docker command आउटपुट देता है, तो इसका मतलब है कि Docker Engine इंस्टॉल है लेकिन Compose प्लगइन नहीं है। Docker के रिपॉजिटरी से प्लगइन इंस्टॉल करें, ऊपर दी गई स्क्रिप्ट को फिर से चलाएं, या हमारी Docker Compose बेसिक्स गाइड का पालन करें, जो Docker की अपनी apt रिपॉजिटरी से दोनों को सेटअप करती है।

चरण 4, mailcow को clone करें और config generate करें

cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
umask
sudo ./generate_config.sh

जाँचें कि umask, 0022 प्रिंट करता है या नहीं। mailcow गलत file mask के साथ build होने से मना कर देता है, और एक fresh Ubuntu 24.04 root shell आपको पहले से ही 0022 देता है। इसके बाद script आपसे सबसे महत्वपूर्ण जानकारी मांगती है: fully qualified hostname। mail.example.com दर्ज करें, यह मान आपके A record और PTR से बिल्कुल मेल खाना चाहिए। यह mailcow.conf लिखता है, जो कि वह एकमात्र environment file है जिसे पूरा stack पढ़ता है। यदि आपको web ports (HTTP_PORT, HTTPS_PORT) बदलने हैं या छोटे सर्वर पर ClamAV को disable करना है, तो इसे खोलें:

MAILCOW_HOSTNAME=mail.example.com
HTTP_PORT=80
HTTPS_PORT=443
SKIP_CLAMD=n          # set to y to drop the virus scanner on a <2.5 GiB box

कम RAM वाले सर्वर पर SKIP_FTS=y दूसरा महत्वपूर्ण विकल्प है: full-text search mailcow के docs के अनुसार दूसरी सबसे ज्यादा memory लेने वाली सेवा है, और इसे छोड़ने का मतलब केवल webmail में body-text search की सुविधा खोना है।

HTTP_PORT=80 और HTTPS_PORT=443 को तब तक न बदलें जब तक कि host पर कोई अन्य सेवा इनका उपयोग न कर रही हो। certificate प्राप्त करने के लिए mailcow के built-in ACME client को internet से port 80 तक पहुँच की आवश्यकता होती है। यही कारण है कि आप एक ही box पर अलग nginx-plus-Certbot setup नहीं चलाते हैं; mailcow अपने TLS को आंतरिक रूप से जारी और renew करता है, और 80/443 पर कोई दूसरी सेवा इसे बाधित कर देगी। यही बात किसी भी अन्य सेवा पर लागू होती है जिसे public web front end चाहिए, इसलिए Jellyfin library को 90 के दशक के वीडियो स्टोर के रूप में reskin करने जैसा build, जिसे 443 पर अपने स्वयं के reverse proxy की आवश्यकता होती है, किसी अलग host पर होना चाहिए। इसका अपवाद वह सेवा है जो कभी भी public web port नहीं मांगती है: एक self-hosted RustDesk relay केवल अपनी 21115 से 21119 की range पर listen करता है, इसलिए यदि आपके पास पर्याप्त bandwidth उपलब्ध है तो यह एक ही box पर चल सकता है।

चरण 5, स्टैक को स्टार्ट करें और लॉग इन करें

sudo docker compose pull
sudo docker compose up -d
sudo docker compose ps

Pull करने पर लगभग दो दर्जन images डाउनलोड होती हैं; इसमें कुछ मिनट का समय लग सकता है। जब docker compose ps हर container को running (या healthy) के रूप में दिखाए, तो ब्राउज़र में https://mail.example.com खोलें। डिफ़ॉल्ट एडमिन लॉगिन username admin और password moohoo है। एडमिन UI में Access → Administrators के अंतर्गत इस पासवर्ड को तुरंत बदलें। यदि ब्राउज़र NET::ERR_CERT_AUTHORITY_INVALID की चेतावनी देता है, तो इसका मतलब है कि ACME certificate अभी जारी नहीं हुआ है। इसे खराब मानने से पहले नीचे दी गई ACME विफलता (failure) देखें; पहले एक या दो मिनट के लिए self-signed placeholder का दिखना सामान्य है।

चरण 6, एक डोमेन और मेलबॉक्स जोड़ें, और DKIM प्रकाशित करें

Admin UI में, Mail Setup पेज (Configuration → Mail Setup) खोलें, और Domains टैब के अंतर्गत Add domain पर क्लिक करें और example.com दर्ज करें। फिर, Mailboxes के अंतर्गत, एक पासवर्ड के साथ you@example.com बनाने के लिए Add mailbox पर क्लिक करें। यह एक कार्यशील मेलबॉक्स है जो पहले से ही IMAP के माध्यम से एक्सेस किया जा सकता है।

अब DKIM key की बारी है। Configuration → ARC/DKIM keys पर जाएं; हो सकता है कि डोमेन जोड़ते समय mailcow ने पहले ही एक key जनरेट कर ली हो, यदि नहीं, तो वहां एक key जनरेट करें, डोमेन चुनें, selector को dkim रखें, 2048-bit चुनें, और Add पर क्लिक करें। यह जो लंबा TXT मान दिखाता है उसे कॉपी करें और इसे इस प्रकार प्रकाशित करें:

dkim._domainkey.example.com.  TXT  "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqh...long-key...QAB"

mailcow के Domains पेज पर एक DNS बटन है जो उन सभी रिकॉर्ड्स की सूची दिखाता है जिनकी उसे अपेक्षा है और जो वास्तव में प्रकाशित हैं उनके सामने हरा टिक या लाल क्रॉस दिखाता है। इसे अपनी चेकलिस्ट के रूप में उपयोग करें, और deliverability का परीक्षण करने से पहले हर पंक्ति को हरा करें। प्रकाशित करने के बाद DKIM पंक्ति का लाल होना आमतौर पर यह दर्शाता है कि key को TXT के टुकड़ों में गलत तरीके से विभाजित किया गया था; एक 2048-bit key एक एकल TXT स्ट्रिंग के लिए 255-वर्णों की सीमा से अधिक लंबी होती है, इसलिए इसे एक तार्किक मान के रूप में पेस्ट करें और अपने DNS होस्ट को इसे आपके लिए टुकड़ों में विभाजित करने दें।

चरण 7, deliverability का परीक्षण करें और 10/10 स्कोर प्राप्त करें

mail-tester.com पर जाएं, वहां दिखाए गए रैंडम पते को कॉपी करें, और अपने नए मेलबॉक्स से उस पर एक संदेश भेजें। इसके लिए https://mail.example.com/SOGo पर SOGo वेबमेल में लॉग इन करें और वहां से ईमेल भेजें। इसके बाद "Then check your score" पर क्लिक करें।

आपका लक्ष्य 10/10 स्कोर प्राप्त करना है। सामान्य कटौती और उनके कारण इस प्रकार हैं:

• SPF aligned नहीं है, आपका MX/SPF रिकॉर्ड गायब है या भेजने वाला IP इसमें शामिल नहीं है। अपने SPF TXT रिकॉर्ड की दोबारा जांच करें।
• DKIM signature सत्यापित नहीं हो रहा है, dkim._domainkey TXT रिकॉर्ड गायब है, अभी भी propagate हो रहा है, या गलत तरीके से कॉन्फ़िगर है। यह सबसे आम गलती है।
• PTR नहीं है / PTR मेल नहीं खाता, reverse DNS mail.example.com पर resolve नहीं हो रहा है। इसे अपने प्रदाता (provider) के पास ठीक करें।
• ब्लॉकलिस्ट में सूचीबद्ध है, यह आपके IP की पिछली प्रतिष्ठा के कारण है। delisting का अनुरोध करें या एक क्लीन IP की मांग करें।

जब तक स्कोर 10/10 न हो जाए, तब तक Gmail या Outlook पर वास्तविक मेल न भेजें। कम स्कोर और नया IP होने पर आपका डोमेन पहले ही दिन फ्लैग (flag) हो सकता है।

चरण 8, एक वास्तविक mail client को कनेक्ट करें

Thunderbird, Apple Mail, या अपने फोन को इन सेटिंग्स के साथ सर्वर पर पॉइंट करें। सभी के लिए सर्वर होस्ट mail.example.com है:

• IMAP: पोर्ट 993, SSL/TLS (या STARTTLS के साथ 143)
• SMTP submission: पोर्ट 465, SSL/TLS (या STARTTLS के साथ 587)
• Username: पूरा ईमेल पता, you@example.com
• Password: आपके द्वारा सेट किया गया मेलबॉक्स पासवर्ड

Client mail को कभी भी पोर्ट 25 पर न भेजें, वह पोर्ट केवल सर्वर-टू-सर्वर संचार के लिए है। mailcow वहां authenticated submission की सुविधा नहीं देता है, और उस पर पॉइंट किए गए किसी भी client को अस्वीकार कर दिया जाता है। यदि कोई client Relay access denied रिपोर्ट करता है, तो इसका मतलब है कि वह पोर्ट 25 पर या बिना authentication के भेजने का प्रयास कर रहा है; इसे अपने मेलबॉक्स क्रेडेंशियल्स के साथ 465 या 587 पर स्विच करें।

चरण 9, जो वास्तव में महत्वपूर्ण है उसका बैकअप लें

mailcow एक बैकअप स्क्रिप्ट के साथ आता है जो हर stateful volume का स्नैपशॉट लेती है। इसे किसी बाहरी डिस्क या माउंट की गई रिमोट लोकेशन पर चलाएं:

sudo MAILCOW_BACKUP_LOCATION=/opt/mailcow-backups \
  ./helper-scripts/backup_and_restore.sh backup all

all छह चीजों को कैप्चर करता है, और इनमें से किसी को भी खोने का मतलब है डेटा का नुकसान: vmail (वास्तविक मेलबॉक्स), crypt (वे कुंजियाँ जो vmail को डिक्रिप्ट करती हैं, इनके बिना vmail बेकार है), mysql (MariaDB जो डोमेन, उपयोगकर्ता, उपनाम और सेटिंग्स को होल्ड करता है), redis (कतार और कैश स्थिति), rspamd (सीखा गया स्पैम/हैम), और postfix (मेल कतार)। यह एक हेल्पर कंटेनर के अंदर चलता है जो कंप्रेस्ड आर्काइव लिखता है, इसलिए स्टैक के लाइव रहने के दौरान भी बैकअप सुसंगत (consistent) रहते हैं। इसे एक nightly cron job के साथ स्वचालित करें, और पुराने सेट को हटाने के लिए --delete-days 14 जोड़ें। जो cron job काम करना बंद कर देती है वह चुपचाप विफल हो जाती है, इसलिए स्क्रिप्ट के exit status को कहीं ऐसी जगह भेजें जहाँ आप उसे वास्तव में देख सकें; एक self-hosted ntfy server उसी cron entry से एक-लाइन का curl लेता है और विफलता होने वाली रात ही आपके फोन पर सूचना भेज देता है। रिस्टोर करने के लिए उसी स्क्रिप्ट का restore के साथ उपयोग करें, जो स्नैपशॉट की सूची दिखाता है और आपको यह चुनने देता है कि क्या वापस लाना है। जिस बैकअप को आपने कभी रिस्टोर करके टेस्ट नहीं किया है, वह केवल एक उम्मीद है, बैकअप नहीं; एक बार किसी स्क्रैच VPS पर इसका ड्राई रन जरूर करें।

चरण 10, निर्धारित समय पर अपडेट करना

mailcow अपने स्वयं के script के माध्यम से अपडेट होता है, जो नया code pull करता है, mailcow.conf को migrate करता है, images को prefetch करता है और containers को इस क्रम में restart करता है:

cd /opt/mailcow-dockerized
sudo ./update.sh --check   # reports whether an update exists, changes nothing
sudo ./update.sh           # applies it

सबसे पहले backup लें (चरण 9), क्योंकि schema migration को वापस पलटना कठिन होता है। अपडेट अक्सर आते रहते हैं और इनमें internet-facing daemons के लिए security fixes शामिल होते हैं, इसलिए mail server को महीनों तक पुराना न रहने दें। यदि कोई अपडेट किसी container को unhealthy छोड़ देता है, तो sudo docker compose logs --tail=50 <service>-mailcow उस daemon का नाम बताता है जो वापस start होने में विफल रहा।

Hardening पर एक नोट

mailcow अपनी खुद की netfilter service (netfilter-mailcow) चलाता है जो mail और webmail ports पर हमला करने वाले IPs को ban कर देती है, इसलिए mail का पक्ष पहले से ही सुरक्षित है। यह host पर मौजूद SSH को कवर नहीं करता है, जो अभी भी exposed है और उस पर brute-force हमले होते रहते हैं। इस build को SSH auth log को monitor करने वाले Fail2ban और केवल key-based login के साथ उपयोग करें। mailcow admin UI को एक मजबूत password के पीछे रखें और आदर्श रूप से, इसे public internet से दूर या VPN के पीछे रखें।

विफलता के प्रकार, सटीक स्ट्रिंग्स के साथ

मेल कतार में है लेकिन डिलीवर नहीं हो रहा है। sudo docker compose exec postfix-mailcow postqueue -p चलाएं, या एडमिन UI की मेल कतार देखें; प्रविष्टियाँ इस त्रुटि के साथ deferred स्थिति में हैं:

status=deferred (connect to gmail-smtp-in.l.google.com[142.250.x.x]:25: Connection timed out)

इसका अर्थ है कि आपके प्रदाता द्वारा आउटबाउंड पोर्ट 25 ब्लॉक कर दिया गया है (चरण 1)। कोई भी कॉन्फ़िगरेशन इसे ठीक नहीं करेगा, एक सपोर्ट टिकट खोलें। यह DNS या TLS की समस्या नहीं है; इसका संकेत पोर्ट 25 पर रिमोट MX के विरुद्ध timed out शब्द है।

Gmail हर चीज़ को स्पैम के रूप में चिह्नित करता है, या उसे वापस भेज देता है। Gmail में संदेश खोलें, "Show original" पर क्लिक करें, और ऑथेंटिकेशन परिणाम पढ़ें। dkim=fail या dkim=none का अर्थ है कि आपका dkim._domainkey TXT रिकॉर्ड गायब है, गलत है, या अभी तक प्रोपेगेट नहीं हुआ है। ARC/DKIM पेज पर जो दिखाया गया है उसे ठीक वैसा ही पुनः प्रकाशित करें और TTL समाप्त होने तक प्रतीक्षा करें। spf=fail का अर्थ है कि SPF/MX रिकॉर्ड आपके IP को कवर नहीं करते हैं। अलाइनमेंट सबसे महत्वपूर्ण है; एक भी विफल चेक आपको स्पैम में डालने के लिए पर्याप्त है।

कनेक्ट करने पर बड़े प्रदाता अस्वीकार कर देते हैं। बाउंस संदेश या Postfix लॉग में Gmail का PTR रिजेक्शन दिखाई देता है:

550-5.7.25 [10.0.0.10] The IP address sending this message does not have a PTR
550-5.7.25 record setup, or the corresponding forward DNS entry does not match
550 5.7.25 the sending IP. As a policy, Gmail does not accept messages from IPs
550 5.7.25 with missing PTR records.

550 5.7.25 कोड का अर्थ है कि रिवर्स DNS गायब है या मेल नहीं खाता है। प्रदाता के पास अपने IP के लिए PTR को mail.example.com पर सेट करें (चरण 2)। फॉरवर्ड (A) और रिवर्स (PTR) रिकॉर्ड का मेल होना अनिवार्य है, और दोनों को उसी होस्ट का नाम देना चाहिए जिसके रूप में mailcow अन्य सर्वरों को अपना परिचय देता है।

ब्राउज़र एक सर्टिफिकेट चेतावनी दिखाता है जो कभी नहीं हटती। acme-mailcow कंटेनर वास्तविक सर्टिफिकेट प्राप्त करने में विफल रहा। इसका लॉग देखें:

sudo docker compose logs acme-mailcow | tail -n 40

Cannot validate any hostnames, skipping Let's Encrypt for 1 hour. जैसी लाइन या चैलेंज विफलता का अर्थ है कि इंटरनेट से पोर्ट 80 तक नहीं पहुँचा जा सकता है, या A रिकॉर्ड इस सर्वर की ओर इशारा नहीं कर रहा है। पुष्टि करें कि mail.example.com इस बॉक्स पर रिज़ॉल्व होता है, किसी भी होस्ट फ़ायरवॉल के माध्यम से 80 और 443 पोर्ट खोलें, और सुनिश्चित करें कि कोई अन्य सेवा उन पोर्ट्स का उपयोग नहीं कर रही है। कारण ठीक करने के बाद, एक घंटे के बैक-ऑफ की प्रतीक्षा करने के बजाय sudo docker compose restart acme-mailcow के साथ क्लाइंट को रीस्टार्ट करें।

FAQ

क्या खुद का ईमेल सर्वर होस्ट करना वास्तव में फायदेमंद है?

यदि आप डेटा पर अपना स्वामित्व, असीमित aliases और पूर्ण नियंत्रण चाहते हैं, तो हाँ, mailcow आपको एक VPS की कीमत पर एक प्रोफेशनल स्टैक प्रदान करता है। लेकिन ईमेल की deliverability एक निरंतर चलने वाला काम है: IP reputation, DNS alignment और blocklist monitoring का काम कभी पूरी तरह खत्म नहीं होता। किसी ऐसे mission-critical व्यावसायिक पते के लिए, जहाँ किसी के spam folder में एक दिन भी ईमेल का जाना नुकसानदेह हो, एक managed provider का उपयोग करना ही व्यावहारिक विकल्प है। Self-host तब करें जब आप सुविधा से अधिक नियंत्रण को महत्व देते हैं और वास्तव में उसका रखरखाव करेंगे। यदि आप वास्तव में केवल अपना डेटा किसी और के सर्वर से हटाना चाहते हैं, न कि विशेष रूप से ईमेल के लिए, तो ऐसी सेवा से शुरुआत करें जिसमें किसी और का हस्तक्षेप न हो: एक photo library में deliverability की कोई समस्या नहीं होती है, और हमारा PhotoPrism और Immich तुलनात्मक लेख उसी तरह के VPS पर इसके लिए आवश्यक RAM और backup commands की जानकारी देता है।

मुझे कैसे पता चलेगा कि outbound port 25 ब्लॉक है?

सर्वर से nc -vz -w 5 gmail-smtp-in.l.google.com 25 चलाएँ। "succeeded!" का अर्थ है कि यह खुला है; पॉज़ के बाद timed out का मतलब है कि आपका प्रदाता इसे ब्लॉक करता है। यह सबसे आम कारण है कि एक self-hosted सर्वर ईमेल प्राप्त तो कर सकता है लेकिन भेज नहीं सकता, और इसका एकमात्र समाधान आपके प्रदाता द्वारा पोर्ट को खुलवाना है, कोई भी local setting इसे नहीं बदल सकती।

मेरा ईमेल Gmail के spam folder में क्यों जाता है?

इसका कारण लगभग हमेशा एक टूटी हुई authentication chain होती है। Gmail में "Show original" का उपयोग करें और spf=pass, dkim=pass, और dmarc=pass की जाँच करें। एक dkim=fail का मतलब है कि dkim._domainkey TXT record गायब है या गलत है; PTR mismatch या बिना किसी sending history वाला नया IP भी नुकसान पहुँचाता है। पहले mail-tester.com पर 10/10 स्कोर प्राप्त करें, फिर IP को धीरे-धीरे warm up करें, पहले दिन ही भारी मात्रा में ईमेल भेजने के बजाय प्रतिदिन कुछ संदेशों से शुरुआत करें।

मुझे वास्तव में किसका बैकअप लेने की आवश्यकता है?

backup_and_restore.sh backup all चलाएँ और पूरे सेट को सर्वर से बाहर रखें। यह vmail (मेलबॉक्स), crypt (उन्हें डिक्रिप्ट करने वाली कुंजियाँ), MariaDB डेटाबेस (domains, users, aliases, settings), Redis, Rspamd का सीखा हुआ डेटा और Postfix queue को कैप्चर करता है। crypt volume वह है जिसे लोग अक्सर अनदेखा कर देते हैं, इसके बिना vmail बैकअप केवल अपठनीय ciphertext है। कम से कम एक बार किसी अन्य सर्वर पर restore का परीक्षण जरूर करें।

क्या मैं 2 GB VPS पर mailcow चला सकता हूँ?

आराम से नहीं। generate_config.sh लगभग 2.5 GiB से कम RAM होने पर ClamAV को disable करने का विकल्प देता है, और तब भी Rspamd, ClamAV, Dovecot और MariaDB मेमोरी के लिए संघर्ष करते हैं, जिससे किसी भी वास्तविक लोड के तहत आप swap और OOM kills का सामना करेंगे। एक स्थिर single-user install के लिए 6 GiB RAM और 1 GiB swap को न्यूनतम आधार मानें, और जैसे ही एक-दो से अधिक लोग इस पर निर्भर हों, इसे 8 GiB पर ले जाएँ।