1984 की तरह अपना खुद का ईमेल सर्वर चलाना
(maxadamski.com)- अपना खुद का ईमेल सर्वर चलाने से कम लागत में automation tasks और mailing list management किया जा सकता है
- delivery reliability की समस्या व्यवहारिक रूप से मौजूद है, इसलिए बड़े services के साथ मेल भेजने-प्राप्त करने में विफलता हो सकती है
- सिर्फ Postfix और OpenDKIM configuration से बुनियादी SMTP और authenticated mail sending system बनाया जा सकता है
- SSL certificate, DKIM, SPF, DMARC सेट करने से मेल की विश्वसनीयता और transmission security बेहतर की जा सकती है
- PTR (reverse DNS) record भी सेट कर दिया जाए तो बड़े mail services तक delivery rate बढ़ने की उम्मीद की जा सकती है
परिचय
अपना खुद का ईमेल सर्वर चलाना mailing list, newsletter, email verification API जैसी automation tasks के लिए उपयोगी है
लेकिन सबसे बड़ी व्यावहारिक चुनौती mail delivery reliability है, क्योंकि मेल ठीक से न पहुँचे या प्राप्ति विफल हो जाए, ऐसा जोखिम मौजूद रहता है
संचालक इस जोखिम को स्वीकार करने की शर्त पर इस तरीके को personal projects में लागू कर रहा है
खुद संचालन करने का फायदा यह है कि लगभग कोई अतिरिक्त लागत नहीं आती; मौजूदा वेबसाइट पर सिर्फ software install करना होता है, और storage या energy consumption भी बहुत कम होता है
लेखक को लगा था कि ईमेल सर्वर चलाना बहुत कठिन होगा, लेकिन वास्तव में यह SaaS-type email service सेटअप से बहुत अलग नहीं है
सेटअप को आसान और सरल रखने के लिए webmail, multi-user environment को फिलहाल छोड़ दिया गया है, ताकि user account, database, और web interface configuration की ज़रूरत न पड़े
यह सेटअप single account operation के लिए उपयुक्त है, और ज़रूरत पड़ने पर SSH तथा mailx, sendmail, mutt के जरिए मेल भेजे और प्राप्त किए जा सकते हैं
आगे आवश्यकता के अनुसार इसे बढ़ाया जा सकता है और webmail भी जोड़ा जा सकता है
Postfix
मूल रूप से port 25 खोलकर, Postfix और OpenDKIM को install तथा configure करने भर से एक basic SMTP server बनाया जा सकता है
ज़्यादातर mail services (जैसे Gmail) तक मेल reliably पहुँचाने के लिए OpenDKIM (mail authentication) की ज़रूरत होती है
लेखक ने master.cf को default पर ही रखा, और main configuration (main.cf) के उदाहरण में TLS encryption, DKIM integration जैसी मुख्य settings ही दिखाई गई हैं
POP3/IMAP configure नहीं किया गया; इसके बजाय इसे सरल रखने के लिए ज़रूरत पड़ने पर SSH से सीधे सर्वर में लॉग इन कर mailx जैसी commands से मेल भेजने-प्राप्त करने की व्यवस्था रखी गई है
TLS (transmission encryption)
SSL certificate SMTP server के साथ data transmission को encrypt करने के लिए आवश्यक है
हर domain के लिए certificate जारी करने की ज़रूरत नहीं; जिस single host पर mail server स्थित है (MX record के लिए), उसी के लिए certificate होना पर्याप्त है
उदाहरण के लिए, यदि MX record mx.example.com है, तो सिर्फ उसी domain के लिए Let’s Encrypt से free certificate लेकर लागू किया जा सकता है
TLS केवल servers के बीच भेजने-प्राप्त करने वाले हिस्से को encrypt करता है, और यह वास्तविक sender domain name authentication से अलग है
इसलिए email address के From header में चाहें तो कोई भी मान स्वतंत्र रूप से सेट किया जा सकता है
DKIM, SPF, DMARC
DKIM का उपयोग यह साबित करने के लिए किया जाता है कि मेल वास्तव में आपके domain से आया है, जिससे मेल की विश्वसनीयता बढ़ती है
OpenDKIM से हर domain के लिए key pair बनाया जाता है, और public key को DNS TXT record के रूप में दर्ज किया जाता है
keys अपने आप expire नहीं होतीं, लेकिन उन्हें समय-समय पर rotate करना recommended है
SPF, DMARC TXT records भी DNS में जोड़कर यह तय किया जाता है कि कौन-से hosts मेल भेज सकते हैं, और DMARC policy (जैसे authentication विफल होने पर reject) क्या होगी
उदाहरण configuration files (opendkim.conf, KeyTable, SigningTable, TrustedHosts) में हर item को सेट करने का तरीका साफ़ तौर पर देखा जा सकता है
DNS में सिर्फ MX, SPF, DKIM, DMARC से संबंधित records जोड़ने होते हैं
reverse DNS (PTR)
PTR record (reverse DNS) mail server की विश्वसनीयता बढ़ाता है, जिससे Gmail जैसे बड़े services द्वारा मेल block किए जाने की संभावना कम होती है
इसके लिए ISP से संपर्क कर mail server के PTR record की setting करवाने का अनुरोध करना पड़ता है
वास्तविक deployment environment में PTR record न होने पर भी Gmail, GMX, Outlook आदि में मेल सामान्य रूप से प्राप्त हुए, और mail-tester.com पर 10/10 score मिला
PTR सेट न होने के कारण कुछ points कटे, लेकिन "trusted relay" के कारण अतिरिक्त points भी मिले
यह IP किसी blacklist में भी दर्ज नहीं था, इसलिए sender IP की reputation भी अच्छी रही
Gmail delivery test
sendmail command से Gmail पर test mail (HTML message) भेजा गया
Gmail में मेल तुरंत पहुँचा, और TLS encryption की पुष्टि हुई
"Show original" में मूल मेल देखने पर SPF, DKIM, DMARC authentication pass मिला
mailx का उपयोग करके local (server) पर प्राप्त मेल की सामग्री भी देखी जा सकती है
अगर configuration में समस्या हो, तो DNS, certificate, DKIM key access permissions आदि दोबारा जाँचने चाहिए; खासकर OpenDKIM की configuration files typos के प्रति संवेदनशील होती हैं
अगले कदम
अगले लेख में Python से email application बनाने का तरीका बताया जाएगा
प्रश्न या राय हो तो max@idx.cy पर संपर्क किया जा सकता है
1 टिप्पणियां
Hacker News राय
मुझे 20 साल से भी ज़्यादा समय तक अपना ईमेल खुद होस्ट करने पर गर्व है, और आगे भी ऐसा ही करने का इरादा है। विडंबना यह है कि सरकारें और संबंधित विभाग खुद अपने ईमेल सिस्टम नहीं चला पाते, सिर्फ राष्ट्रीय सुरक्षा विभाग ही सीधे होस्टिंग करते हैं। शायद किस्मत अच्छी रही कि मेल भेजने में लगभग कभी समस्या नहीं हुई। हाल की एक घटना याद है जब Microsoft ने मेरी मेल निगल ली थी, लेकिन वह पुराने exim और outlook की TLS authentication गड़बड़ी की वजह से था। एक setting बदलकर ठीक हो गया। maintenance भी खास मेहनत नहीं मांगता, इसलिए जब भी कुछ छेड़ता हूं तो उसे कुछ नया सीखने का मौका मानता हूं। इस साल Debian jessie से Arch Linux पर गया और cron jobs को पूरी तरह systemd timers में शिफ्ट कर दिया। जब भी कोई महत्वपूर्ण मेल भेजता हूं, server logs ज़रूर देखता हूं, और मुझे लगता है कि logs खुद देखना भी एक अच्छी आदत है। सलाह बस इतनी है कि self-hosting को hobby की तरह लें और उसका मज़ा लेना सीखें। और अंत में, Debian पर Exim configuration डिज़ाइन करने वाले व्यक्ति ने बहुत लोगों का समय बर्बाद कराया है। अगर Debian पर Exim सेट कर रहे हैं, तो आधिकारिक Upstream configuration पर स्विच करके उसे अपनी ज़रूरत के हिसाब से customize करना ही सही रास्ता है
आजकल के SNS “decentralization” और “open” होने की बहुत बात करते हैं, लेकिन सच यह है कि हमारे पास पहले से ही ऐसे tools हैं जिनसे हम पूरी तरह स्वतंत्र और आत्मनिर्भर हो सकते हैं। UX सुधारने की बात करते-करते लोग यह भूल जाते हैं कि उसी प्रक्रिया में users का नियंत्रण ही गायब हो रहा है। आखिरकार, अगर हम जरूरत से ज्यादा simplified systems के आदी हो जाएं, तो भविष्य में ऐसी दुनिया आ सकती है जहां किसी दूर बैठे व्यक्ति की “अनुमति” के बिना आप एक app तक install न कर सकें
मैंने कॉलेज के दिनों में, WWW से पहले, पहली बार ईमेल इस्तेमाल किया था। बाद में ISP account मिला जिसमें storage बहुत सीमित थी और सिर्फ POP support था, इसलिए अपना mail server चलाने लगा। उस समय मैं हमेशा internet से जुड़ा नहीं रहता था, इसलिए relay और dynamic DNS के ज़रिए मेल receive करता था। अब VPS के ज़रिए घर के server पर मेल receive और store करता हूं। वर्षों में कभी-कभी Outlook जैसी बड़ी mail services से IP या domain delist कराने का अनुरोध करना पड़ा, लेकिन ऐसा बहुत बार नहीं हुआ। मैं ऐसी दुनिया में नहीं रहना चाहता जहां सिर्फ दो-तीन कंपनियां पूरी दुनिया के ईमेल पर राज करें, इसलिए self-hosting मुझे एक छोटे प्रतिरोध की तरह लगती है
काश 20 साल पहले वाली motivation का 1% भी आज बाकी होता। अब full-time job और परिवार, यानी पत्नी और बच्चे, की वजह से ऐसे कामों के लिए समय ही नहीं बचता
मैं भी एक समय self-hosting से दूर हो गया था, लेकिन अब सोच रहा हूं कि समय/लागत का संतुलन बदलने के बाद शायद फिर से करना ठीक रहेगा। ईमेल होस्टिंग में मेरी सबसे बड़ी चिंता spam management है। आजकल हालात कैसे हैं, और अगर किसी के पास tips हों तो साझा करें
मेरे लिए ईमेल बहुत महत्वपूर्ण service है। 15 साल self-hosting करने के बाद मैंने इसे छोड़ा क्योंकि 1) नियमित backup/restore और monitoring ठीक से नहीं हो पा रही थी, 2) disaster recovery plan न होने की वजह से इसका खर्च दूसरी services से ज़्यादा पड़ रहा था, और 3) security पर हमेशा पर्याप्त ध्यान नहीं दे पाता था। एक दोस्त का server ransomware का शिकार होकर पूरा data खो बैठा, लेकिन मैं FreeBSD पर था इसलिए बच गया, शायद क्योंकि वह attack target ही नहीं था। आम तौर पर maintenance बहुत जटिल नहीं होती, लेकिन एक बार चीज़ें उलझ जाएं तो बहुत बुरी तरह फंसा सकती हैं, और नतीजा गंभीर भी हो सकता है
मैं पहले अपना ईमेल खुद होस्ट करता था, लेकिन मैंने reputation की वजह से नहीं छोड़ा; असली वजह यह थी कि 100% uptime से बचा नहीं जा सकता, और इससे mail loss या blacklist में जाने का जोखिम बनता है। सिद्धांत रूप में ईमेल protocol downtime सहने के लिए बना है, लेकिन व्यवहार में बड़े ईमेल providers एक बार समस्या देखते ही मेल reject कर देते हैं और दोबारा कोशिश भी नहीं करते। पहले GitHub भी ऐसा ही करता था: एक bounce होते ही address को “undeliverable” मार्क कर देता और बाद में मेल भेजना ही बंद कर देता था। अब शायद बेहतर है, लेकिन आधुनिक ईमेल सिस्टम “always online” मानकर बनाए जा रहे हैं
मेरा mail server जानबूझकर पहली बार आने वाली मेल को reject करने वाली greylisting feature इस्तेमाल करता है। मैंने बहुत बड़ी संख्या में मेल receive की हैं, लेकिन किसी वैध मेल के न पहुंचने का एक भी मामला नहीं देखा। retry तो email standard में पहले से built-in है, इसलिए अगर चिंता हो तो backup incoming mail server जोड़कर LMTP से backhaul कर सकते हैं। ईमेल सिस्टम मूल रूप से ऐसे समय के लिए डिज़ाइन किया गया था जब 24 घंटे लगातार connected रहना सामान्य बात नहीं थी
यह बात बढ़ा-चढ़ाकर कही गई है। मेरे मामले में, अगर कोई मेल नहीं पहुंचती थी तो वह कुछ घंटों या एक दिन बाद फिर आ जाती थी, और आम तौर पर यह पता करने का कोई तरीका नहीं होता था कि गड़बड़ी कहां हुई। अगर authentication सही से किया हो, जैसे dkim और spf, तो self-hosting में भी 99% से ज़्यादा deliverability मिल सकती है। complexity से डरने की ज़रूरत नहीं है। बोनस के तौर पर caldav भी निजी तौर पर इस्तेमाल किया जा सकता है
अगर server कुछ घंटे down हो जाए तो “mail loss” की इतनी चिंता क्यों होती है, यह समझ नहीं आता। मेरा server 219 दिनों से लगातार चल रहा है। हम रोज़मर्रा में जो काम करते हैं, उनकी तुलना में ईमेल server चलाना सचमुच बहुत आसान है
सच कहूं तो आज के ईमेल सिस्टम को देखकर वही एहसास होता है: “मेरे बेटे के साथ तुम लोगों ने क्या कर दिया?”
जो लोग अपना ईमेल खुद होस्ट करना शुरू करना चाहते हैं, उनके लिए मेरी सलाह: पहले इसे सिर्फ account sign-up के लिए इस्तेमाल करके देखें। शुरुआत से ही इसे निजी संपर्क के लिए इस्तेमाल करना ज़रूरी नहीं है। “Mail-in-a-box” का उपयोग करें https://mailinabox.email./ — सिर्फ installation guide follow करके कुछ घंटों में setup हो जाएगा और अच्छा चलता है। 1-2 साल इस्तेमाल करके जब आप पर्याप्त सहज हो जाएं, तब निजी संपर्क भी उस पर शिफ्ट करें
मैं Stalwart https://github.com/stalwartlabs/stalwart की सिफारिश करता हूं। यह एक single-binary, fully self-contained mail service है, इसलिए dependencies नहीं के बराबर हैं और install/update करना बेहद आसान है। मैंने कई दूसरे projects आज़माए हैं, लेकिन Stalwart सबसे सरल रहा और बिना किसी समस्या के चलता है
मैं वर्षों से cloud में MIAB चला रहा हूं। अगर IP reputation साफ़ हो तो outgoing mail में समस्या नहीं होती, लेकिन जब Outlook की तरफ मेल नहीं जाती तो Microsoft postmaster को सीधे मेल भेजकर हल करता हूं। DKIM/SPF/DMARC जैसी settings सीखने को मिलती हैं, इसलिए सीखने के लिए यह अच्छा है और मैं इसकी सिफारिश करता हूं। लेकिन sign-up emails receive करना वाकई मुश्किल है। MIAB की greylisting पहली बार वाले senders को reject करती है और retry का इंतज़ार करती है, लेकिन कई वैध sites भी दोबारा कोशिश नहीं करतीं। verification या 2FA code वाले emails आने में बहुत देर लगती है, और spam filter को थोड़ी देर के लिए बंद करने का भी कोई आसान तरीका नहीं है
आजकल ISP द्वारा दिए गए ईमेल, यहां तक कि Google Gmail, में भी spam filtering जैसी चीज़ों में अक्सर दिक्कत आती है। उदाहरण के लिए, अगर Shopify के ज़रिए order करें, तो shopify mail लगातार Gmail में spam में चली जाती है। DMARC, SPF, DKIM सब pass होने के बाद भी क्यों फंसती है, यह समझ नहीं आता। ईमेल भेजना और पाना तकनीकी रूप से बहुत मुश्किल नहीं है, और कोई भी service 100% परफेक्ट नहीं है। malicious users, यानी spammers, इतने ज़्यादा हैं कि यह सिस्टम जितना ठीक चल रहा है, वही आश्चर्य की बात है
DMARC, SPF, DKIM जैसी चीज़ें सिर्फ authentication settings हैं, spam होने या न होने से उनका सीधा संबंध नहीं है। properly authenticated junk mail भी होती है, और unauthenticated लेकिन शानदार mail भी हो सकती है
Shopify mail के spam में जाने की वजह यह है कि Shopify को बहुत से लोग spam के रूप में mark करते हैं, या उसके shared mail servers पर कोई खराब reputation वाला user है। मैं बार-बार “not spam” मार्क करूं तब भी, अगर sender की overall reputation बहुत खराब है तो वह spam folder से बाहर नहीं निकल पाती
मैं करीब 20 साल से अपना ईमेल खुद होस्ट कर रहा हूं। 10-15 साल तक सारे मेल Gmail पर forward करता था, लेकिन spam filter से तंग आकर, जो महत्वपूर्ण मेल तक गायब कर देता था, मैंने खुद imapd चलाना शुरू किया। SPF वगैरह सही से सेट कर लें तो self-hosting कहीं बेहतर लगती है
असली समस्या तो यही filtering policies हैं। अगर आप खुद होस्ट करते हैं या कोई छोटा ईमेल service इस्तेमाल करते हैं, तो अक्सर मेल block होने की संभावना, खासकर Gmail जैसी सख्त filtering की तुलना में, कम होती है। Google के पास खुद Gmail users में spam के बड़े स्रोत हैं, फिर भी वह आक्रामक filtering policies पर अड़ा रहता है
आजकल Gmail का spam filter marketing mails पर जरूरत से ज़्यादा संवेदनशील है। 10 साल पहले समस्या उलटी थी, लेकिन अब तो इतने मेल spam में चले जाते हैं कि झुंझलाहट होने लगती है। बल्कि आज के spam का बड़ा हिस्सा छोटे और नए mail addresses से आने वाले cold emails हैं। Gmail में marketing mails के लिए “unsubscribe” feature अच्छी तरह काम करता है, लेकिन ऐसे cold mails पर इसका कोई असर नहीं होता
अगर आप एक पूरी तरह से सेटअप होने वाला IMAP server चाहते हैं जो अलग-अलग clients के साथ भी ठीक से काम करे, तो https://workaround.org/ispmail-bookworm/ guide ज़्यादा उपयुक्त है। मैं खुद database की जगह plain text files से इसे सरल तरीके से चला रहा हूं। अगर user सिर्फ आप हैं, तो यह तरीका ठीक है, और ऊपर वाली guide बड़े enterprise setup तक के लिए भी पर्याप्त रूप से scalable है
स्वयं-प्रचार: हम Hyvor Relay https://github.com/hyvor/relay नाम का self-hosted alternative beta test कर रहे हैं। हमारा ध्यान visibility पर है, जैसे DKIM/SPF monitoring और DNS automation। सिर्फ एक
Docker compose upसे इसे चलाया जा सकता है https://relay.hyvor.com/hosting/deploy-easyमैं 10-15 साल से सस्ते kimsufi box पर opensmtp, dovecot, rspamd के साथ अपना ईमेल खुद होस्ट कर रहा हूं। कोई खास समस्या नहीं हुई। एक बार telekom.de ने server block कर दिया था, लेकिन मैंने औपचारिक mail से समझाया तो तुरंत whitelist कर दिया। शायद इसलिए भी कि IP लंबे समय से मेरे पास है, मुझे वे समस्याएं कभी महसूस नहीं हुईं जिनकी बाकी लोग बात करते हैं। हालांकि, server और IP दोनों मेरे नाम पर हैं
Debian trixie आधारित self-hosted email पर एक जर्मन लेख https://krei.se/Doc पर साझा कर रहा हूं। अगर इसे सही तरह से सेट करें तो यह सचमुच आनंद देता है। automatic updates और reboot के साथ, customized systemd से मुझे रोज़ ईमेल में status report मिलती है। 2-3 साल, और trixie हो तो शायद 5 साल तक, बिना हाथ लगाए स्थिरता से चल सकता है। ईमेल server software अब काफी mature है। मैं self-hosting की सिफारिश करता हूं। autonomy, शांति और सीधा नियंत्रण वाकई बहुत मूल्यवान हैं
मैं 10 साल से भी ज़्यादा समय से अपना ईमेल खुद चला रहा हूं, और पहले के HN comments भी कभी-कभी link किए हैं, जैसे 39891262, 38471262। Digital Ocean के IPs को खराब reputation मिलने लगी, इसलिए outgoing mail के लिए Amazon SES इस्तेमाल करने लगा, और Gmail को free spam training tool की तरह उपयोग करके अपने filters बेहतर कर रहा हूं (38843288)। जैसा कई लोगों ने कहा, greylisting बहुत मदद करती है। वैध mail servers retry ज़रूर करते हैं, इसलिए 2FA जैसी चीज़ों में भले असुविधा हो, लेकिन सिस्टम के लिहाज़ से यह भरोसेमंद है। कई दिनों का downtime भी बड़ी चिंता नहीं है, और incoming तथा storage servers अलग करके backup भी आसान हो जाता है (38512732)। 2FA mails के लिए मैं साथ में https://github.com/stevejenkins/postwhite भी इस्तेमाल करता हूं, लेकिन सच कहूं तो 2FA के लिए ईमेल की सिफारिश नहीं करूंगा; वह एक अलग चर्चा का विषय है
हाल ही में Amazon SES से भेजा गया एक महत्वपूर्ण मेल मुझे नहीं मिला क्योंकि वह spam block list (bl.spamcop.net) में फंस गया। Amazon ने कई IPs से retry किया, greylisting से टकराया, और अंततः एक प्रयास reject हो गया। बड़े providers के बीच, यानी MX से MX, शायद यह बहुत बड़ी समस्या न हो, लेकिन यह संरचना भी 100% परफेक्ट समाधान नहीं है
आखिर इतनी लंबी चर्चा के बाद नतीजा शायद यही लगता है कि बस Gmail जैसी बड़ी email service इस्तेमाल करना बेहतर है
UUCP कहां है, addresses bang path क्यों नहीं हैं, और sendmail.cf कहां गया — यही जिज्ञासा है
सही कहा। अगर कोई सचमुच 1984-स्टाइल, यानी पुराने email तरीके से self-hosting करना चाहे, तो वह open relay बन जाएगा जो सबकी mail forward करेगा, और तरह-तरह की vulnerabilities के लिए खुला रहेगा
उस दौर की बात करें तो, यूनिवर्सिटी लैब में 6 Unix workstations के बीच एक server से दूसरे server पर email जाते समय disk की आवाज़ से मेल की आवाजाही महसूस होती थी — वह याद आज भी है
मैंने भी title देखकर bang path और “killer!jolet!” address सोचा था। क्या शानदार दौर था
सहमत हूं। मैं ‘1984’ title देखकर उत्साहित होकर आया था, लेकिन यहां तो बस ‘postfix configuration’ की बात निकली, इसलिए थोड़ा निराश हुआ