Sign inGet Started

एजेंट मेलबॉक्स

एजेंट मेलबॉक्स एक पते वाला इनबॉक्स है, जिसे आपका कोड API के ज़रिए प्रबंधित करता है। IMAP सर्वर चलाए या कच्चे MIME को पार्स किए बिना इसके थ्रेड पढ़ें और फ़िल्टर करें, संदेशों का जवाब दें या नया मेल लिखें।

मेलबॉक्स साझा inbox.ai डोमेन पर या आपके अपने किसी भेजने वाले डोमेन पर रहता है। मेलबॉक्स बनाते ही उसका पता आपका हो जाता है और आपका ही रहता है। लोकल पार्ट आपके वर्कस्पेस के लिए आरक्षित रहता है और किसी और को कभी नहीं दिया जाता, मेलबॉक्स हटाने के बाद भी नहीं।

पते

हर मेलबॉक्स का एक पता होता है, {local_part}@inbox.ai। आप पता दो तरीकों से पाते हैं:

  • जनरेट किया गया: लोकल पार्ट न दें, और हम आपके लिए ऐसा लोकल पार्ट जनरेट करेंगे जो किसी और से न टकराए (a7f3k2@inbox.ai)। यह हमेशा उपलब्ध है।
  • कस्टम: कोई खास लोकल पार्ट माँगें (support@inbox.ai)। कस्टम हैंडल वैश्विक रूप से अद्वितीय होते हैं, पहले आओ पहले पाओ के आधार पर मिलते हैं और सशुल्क प्लान में शामिल होते हैं। मुफ़्त वर्कस्पेस जनरेट किए गए पते इस्तेमाल करता है।

पता बनने के बाद बदला नहीं जा सकता। उसे बदलने के लिए नया मेलबॉक्स बनाएँ और पुराना हटा दें। पुराना लोकल पार्ट 30 दिनों तक (उसकी रीस्टोर अवधि) रोका जाता है, उसके बाद ही उसे फिर से लिया जा सकता है, और वह आपके वर्कस्पेस के लिए आरक्षित रहता है।

अपने डोमेन पर, बनाते समय domain दें और कोई भी लोकल पार्ट चुनें, जैसे support@acme.com। मेल मेलबॉक्स तक कैसे पहुँचता है, यह डोमेन के सेटअप पर निर्भर करता है:

  • प्राप्ति चालू है: डोमेन के MX रिकॉर्ड हमारी ओर इंगित होते ही मेल सीधे पहुँचता है। ईमेल प्राप्त करना देखें।
  • रिसीविंग सक्षम नहीं है: डोमेन का स्वामित्व सत्यापित होना चाहिए, और आपके MX रिकॉर्ड जैसे हैं वैसे ही रहते हैं। मेलबॉक्स को एक forwarding_address मिलता है, जैसे k7q2mzxw4h6p5ra3@eu1.inbound.bird.com। अपने मौजूदा ईमेल प्रदाता पर support@acme.com के लिए एक फ़ॉरवर्डिंग नियम जोड़ें, जो उस पते की ओर इशारा करे। फ़ॉरवर्ड किया गया मेल मेलबॉक्स में आता है, और जवाब तथा नया मेल फिर भी support@acme.com से ही भेजे जाते हैं।

Gmail और Google Workspace किसी नए फ़ॉरवर्डिंग पते पर कुछ भी फ़ॉरवर्ड करने से पहले एक पुष्टि कोड भेजते हैं। पुष्टि संदेश मेलबॉक्स में आता है, इसलिए सेटअप पूरा करने के लिए मेलबॉक्स खोलें। replies_only या allowlist नीति में यह संदेश ब्लॉक किए गए मेल में मिलेगा। मेलबॉक्स हटाने और बहाल करने पर भी फ़ॉरवर्डिंग पता वही रहता है, इसलिए आपके प्रदाता पर बना नियम काम करता रहता है।

अगर आप बाद में डोमेन पर रिसीविंग सक्षम करते हैं, तो support@acme.com पर आने वाला मेल सीधे पहुँचता है, और फ़ॉरवर्डिंग पता भी काम करता रहता है। उस समय फ़ॉरवर्डिंग नियम बंद कर दें। वरना जो प्रदाता अब भी एक कॉपी भेजता है, जैसे Google Workspace की डुअल डिलीवरी, वह हर संदेश को मेलबॉक्स में दो बार डालेगा।

थ्रेड और संदेश

प्राप्त और भेजे गए मेल थ्रेड में समूहित होते हैं, हर बातचीत के लिए एक थ्रेड। थ्रेड में भाग लेने वाले पते, अपठित संदेशों की संख्या, उसके नवीनतम संदेश की दिशा (inbound या outbound) और उसकी सबसे हाल की गतिविधि का टाइमस्टैम्प होता है। जवाब उसी थ्रेड में जुड़ते हैं जिसका वे उत्तर देते हैं; नया संदेश लिखने पर नया थ्रेड शुरू होता है।

हर संदेश में हेडर, उद्धृत पुराने हिस्से हटाकर निकाला गया सादा टेक्स्ट, और अटैचमेंट उपलब्ध होते हैं। मूल बॉडी 30 दिनों तक उपलब्ध रहती है; raw MIME केवल प्राप्त संदेशों के लिए उपलब्ध है। संदेश ID के आगे दिशा के अनुसार उपसर्ग लगता है: प्राप्त संदेश के लिए rem_, और आपके भेजे संदेश के लिए em_।

कौन-सा मेल अंदर आए, यह तय करना

इनबॉक्स से पहले दो नियंत्रण लागू होते हैं:

  • रिसीव नीति: पूरे मेलबॉक्स पर लागू डिफ़ॉल्ट।
    • open ब्लॉक नियमों के बाद मेल स्वीकार करता है। SPF और DKIM के नतीजे इस प्रवेश नीति को नहीं बदलते।
    • replies_only केवल वही मेल स्वीकार करता है जो मेलबॉक्स में पहले से मौजूद किसी थ्रेड को आगे बढ़ाता है।
    • allowlist केवल उन प्रेषकों को स्वीकार करता है जिन्हें आपके नियम अनुमति देते हैं, साथ ही किसी मौजूदा थ्रेड के जवाबों को भी।
    • drop बिना किसी अपवाद के सारा मेल हटा देता है।
  • प्राप्ति नियम: हर प्रेषक के लिए अनुमति या ब्लॉक प्रविष्टियाँ, जो पूरे पते या डोमेन से मिलाई जाती हैं (डोमेन नियम उसके सबडोमेन से भी मेल खाता है)। ब्लॉक हमेशा अनुमति पर भारी पड़ता है।

ब्लॉक नियम एनवेलप प्रेषक या From: पते से मेल खाता है। अनुमति नियम एनवेलप प्रेषक से मेल खाता है, या From: पते से, जब संदेश पर उस पते के डोमेन का वैध DKIM हस्ताक्षर हो। From: हेडर को आसानी से जाली बनाया जा सकता है, इसलिए बिना हस्ताक्षर वाले From: को कभी अनुमति नहीं मिलती। यह फ़ॉरवर्ड किए गए मेल पर लागू होता है, जहाँ Gmail और Microsoft 365 एनवेलप प्रेषक को अपने पते से बदल देते हैं, और उन भेजने वाली सेवाओं के मेल पर भी जो अलग बाउंस पता इस्तेमाल करती हैं। जिस फ़ॉरवर्ड किए गए मेल में DKIM हस्ताक्षर बचा नहीं रहता, वह फिर भी फ़ॉरवर्डिंग सेवा के पते से मिलाया जाता है।

नियम द्वारा ब्लॉक किया गया मेल मेलबॉक्स में सहेजा जाता है और पढ़ा जा सकता है। उसे इनबॉक्स से बाहर रखा जाता है और उसके लिए कोई webhook नहीं भेजा जाता। एकमात्र अपवाद drop पर सेट मेलबॉक्स है, जो सारा मेल सहेजने के बजाय आते ही हटा देता है।

भेजना

मेलबॉक्स API के ज़रिए दो तरह से भेजता है: किसी संदेश का जवाब देकर (भेजा गया संदेश उसी थ्रेड में जुड़ जाता है) या नया संदेश लिखकर (जिससे नया थ्रेड शुरू होता है)। डैशबोर्ड में कोई संदेश खोलें और Forward चुनें, ताकि उसकी मूल बॉडी और अटैचमेंट नए प्राप्तकर्ताओं को भेजे जा सकें। यह मूल सामग्री की 30 दिन की अवधि के भीतर ही संभव है। मेल मेलबॉक्स के अपने पते से जाता है, उस पर आपके कॉन्फ़िगर किए गए डिस्प्ले नाम और डिफ़ॉल्ट Reply-To के साथ। डिलीवरी स्थिति भेजे गए संदेश पर वापस दर्ज होती है, इसलिए आप देख सकते हैं कि जवाब डिलीवर हुआ या बाउंस हुआ।

इवेंट

पोलिंग के बिना एजेंट चलाने के लिए email_mailbox.* webhook परिवार की सदस्यता लें: email_mailbox.message_received (आने वाला मेल इनबॉक्स में पहुँचा), email_mailbox.thread_created, और आपके भेजे संदेशों के डिलीवरी-स्थिति इवेंट। केवल इनबॉक्स मेल के लिए इवेंट भेजे जाते हैं; स्पैम और नियम से ब्लॉक किया गया मेल चुपचाप सहेजा जाता है, ताकि मेल से भरा मेलबॉक्स webhooks की बाढ़ न बन सके। इनबॉक्स मेल मानक email.received इवेंट भी भेजता है, इसलिए मौजूदा इनबाउंड इंटीग्रेशन काम करता रहता है। दोनों इवेंट में प्रमाणीकरण परिणाम होते हैं। स्वचालित रूटिंग से पहले इन फ़ील्ड की जाँच करें: केवल इनबॉक्स में पहुँचने का मतलब यह नहीं कि प्रेषक सत्यापित था।

रिटेंशन और मिटाना

मेलबॉक्स का रिटेंशन टियर तय करता है कि आप संदेश हेडर, निकाला गया टेक्स्ट और मेलबॉक्स अटैचमेंट कितने समय तक पढ़ सकते हैं। यह अवधि भेजने या प्राप्त होने के समय से गिनी जाती है। डिफ़ॉल्ट 30 दिन है। अगर आपके प्लान में 90 दिन या 365 दिन का रिटेंशन शामिल है, तो बनाते या अपडेट करते समय retention_tier सेट करें। आपके प्लान में शामिल न होने वाला टियर E17048 के साथ अस्वीकार कर दिया जाता है।

सामग्री या कार्रवाईरिटेंशन अवधि
संदेश हेडर, निकाला गया टेक्स्ट और मेलबॉक्स अटैचमेंटचुना गया टियर: 30, 90 या 365 दिन
मूल HTML और प्लेन-टेक्स्ट बॉडीहर टियर पर 30 दिन
प्राप्त संदेशों का रॉ MIMEहर टियर पर 30 दिन; भेजे गए संदेशों का रॉ MIME संग्रहीत नहीं होता
डैशबोर्ड में संदेश फ़ॉरवर्ड करनामूल सामग्री का उसकी 30-दिन की अवधि के भीतर होना ज़रूरी है
निकाला गया टेक्स्ट पढ़ना या नई सामग्री के साथ जवाब देनाजब तक संदेश रखा गया है, तब तक उपलब्ध

उदाहरण के लिए, 90-दिन वाले मेलबॉक्स में 40वें दिन किसी संदेश का निकाला गया टेक्स्ट अब भी पढ़ा और खोजा जा सकता है, और उसके अटैचमेंट भी रखे रहते हैं। आप नई सामग्री के साथ जवाब दे सकते हैं, लेकिन मूल बॉडी नहीं खोल सकते, उसका रॉ MIME डाउनलोड नहीं कर सकते और उसे फ़ॉरवर्ड नहीं कर सकते। निकाला गया टेक्स्ट प्रति संदेश 64 KiB तक सीमित है और उसमें मूल संदेश के कुछ हिस्से छूट सकते हैं। विस्तारित अटैचमेंट अवधि चालू होने से पहले संग्रहीत अटैचमेंट लगभग 31 दिन की अपनी मूल समाप्ति अवधि बनाए रखते हैं; टियर बदलने से वे स्थानांतरित नहीं होते। टियर बढ़ाने से पहले ही हटाई जा चुकी सामग्री वापस नहीं आती।

अवधि समाप्त होते ही संदेश API से लौटाए जाने बंद हो जाते हैं। हर घंटे चलने वाली एक प्रक्रिया बैकग्राउंड में उन्हें हटाती है; भौतिक सफ़ाई API समाप्ति से पीछे रह सकती है।

टियर घटाने का असर पढ़ने पर तुरंत होता है: नई कटऑफ़ से पुराना कोई भी संदेश उसी समय लौटना बंद हो जाता है। इसे पलटने के लिए आपके पास दस मिनट हैं, और केवल इन दस मिनटों की गारंटी है: उस अवधि के भीतर टियर फिर से बढ़ाएँ, तो कुछ भी नहीं खोता। उसके बाद छूटे हुए संदेश हटाए जाने योग्य हो जाते हैं और अगला घंटेवार स्वीप उन्हें हटा देता है, इसलिए बाद में टियर बढ़ाने पर केवल वही सामग्री वापस मिलती है जिस तक स्वीप नहीं पहुँचा है।

आपके प्लान में शामिल टियर तक बढ़ाना किसी भी समय स्वीकार किया जाता है, तब भी जब पिछला बदलाव अभी लागू हो रहा हो। बैकग्राउंड अपडेट दस मिनट की पलटने वाली अवधि से स्वतंत्र है। दूसरी बार घटाना तभी स्वीकार होता है जब पहला बदलाव हर संग्रहीत संदेश को अपडेट कर चुका हो। अपडेट हर दस मिनट में शुरू होता है और बड़े मेलबॉक्स के लिए इसमें घंटों लग सकते हैं। इसके पूरा होने तक API E17050 लौटाता है; बाद में फिर से प्रयास करें।

अगर आपका प्लान मेलबॉक्स स्टोरेज की सीमित मात्रा तय करता है, तो वह एक ही मात्रा हर सक्रिय या पुनर्स्थापित किए जा सकने वाले मेलबॉक्स में साझा होती है। हर मेलबॉक्स अपना हिस्सा size_bytes के रूप में बताता है। जिस प्लान में सीमित मात्रा नहीं है, उसमें मेलबॉक्स स्टोरेज असीमित है। जब सभी मेलबॉक्स मिलकर सीमित मात्रा तक पहुँच जाते हैं, तो भेजना E17049 के साथ अस्वीकार होता है, जब तक आप उनमें से किसी में जगह खाली नहीं करते।

मेलबॉक्स हटाने पर वह तुरंत मेल प्राप्त करना बंद कर देता है। मेलबॉक्स को 30 दिनों तक पुनर्स्थापित किया जा सकता है, और इस दौरान संदेशों की सामान्य रिटेंशन समाप्ति जारी रहती है। 30 दिनों के बाद स्थायी मिटाने की प्रक्रिया मेलबॉक्स और उसके बचे हुए संदेशों को हटा देती है। स्थायी मिटाना शुरू होने के बाद पुनर्स्थापना अस्वीकार होती है, भले ही सफ़ाई अभी जारी हो। पता आपके वर्कस्पेस के लिए आरक्षित रहता है।

अगले कदम

इस विषय के लिए दस्तावेज़, गाइड और उदाहरणों के साथ आगे बढ़ें।