ऐप पासवर्ड, खाते का पासवर्ड और API कुंजी में क्या अंतर है?
ईमेल ऐप पासवर्ड (app password) किसी बाहरी ऐप को आपके खाते से जोड़ने के लिए प्रदाता से मिलने वाला अलग पासवर्ड है। इसे मेल ऐप खोलने पर लगने वाले लॉक या ब्राउज़र में सहेजे गए पासवर्ड से न मिलाएँ। यहाँ काम है मेलबॉक्स तक पहुँच देना, फ़ोन के ऐप पर ताला लगाना नहीं।
Mailera आपके मौजूदा मेलबॉक्स को REST, MCP और webhooks के ज़रिए ऐप या AI एजेंट से जोड़ता है। इसमें पहुँच के लिए दो अलग कनेक्शन हैं: प्रदाता से Mailera का और Mailera से एजेंट का। दोनों के लिए एक ही पासवर्ड इस्तेमाल नहीं करना चाहिए।
| प्रमाण-पत्र या अनुमति | कौन देता है | कहाँ इस्तेमाल होता है | पहुँच बंद करने का नियंत्रण |
|---|---|---|---|
| खाते का मुख्य पासवर्ड | ईमेल प्रदाता का खाता | खाते में सामान्य साइन-इन | प्रदाता की खाता सुरक्षा सेटिंग; असर प्रदाता के अनुसार अलग होता है (आगे तालिका देखें) |
| ऐप पासवर्ड | ईमेल प्रदाता | समर्थित बाहरी ऐप का कनेक्शन | प्रदाता का ऐप पासवर्ड प्रबंधन |
| OAuth अनुमति | प्रदाता की सहमति प्रक्रिया | Mailera का Microsoft कनेक्शन | एजेंट की API कुंजी अलग है; उसे Mailera में रद्द करें |
| Mailera API कुंजी | Mailera | एजेंट की REST या MCP पहुँच | Mailera में कुंजी रद्द करना |
ऐप पासवर्ड अपने-आप केवल पढ़ने की अनुमति वाला नहीं होता; यह प्रदाता और सेवा पर निर्भर करता है। उदाहरण के लिए, Fastmail में ऐप पासवर्ड की पहुँच ईमेल, कैलेंडर या संपर्क डेटा तक सीमित की जा सकती है, पर यह पढ़ने/लिखने का भेद नहीं है। एजेंट के लिए पढ़ने-लिखने का भेद Mailera का अलग read अधिकार तय करता है। एजेंट के लिए Mailera का read अधिकार अलग नियंत्रण है।

आपके ईमेल प्रदाता के लिए कौन-सा तरीका सही है?
पहले कनेक्शन का तरीका चुनें, फिर पासवर्ड बनाएँ। खासकर Microsoft के लिए किसी सामान्य ऐप पासवर्ड सहायता पृष्ठ से शुरुआत न करें: Mailera में उसका रास्ता OAuth है।
| आपका प्रदाता | Mailera में तरीका | पहले क्या जाँचें | कनेक्शन की जानकारी |
|---|---|---|---|
| Gmail / Google Workspace | ऐप पासवर्ड | दो-चरणीय सत्यापन और खाते या संगठन में ऐप पासवर्ड की उपलब्धता | Gmail कनेक्शन |
| Outlook.com / Hotmail / Microsoft 365 | Microsoft Graph के ज़रिए OAuth | सही Microsoft खाते से साइन-इन करें | Microsoft कनेक्शन |
| Yahoo Mail | ऐप पासवर्ड | खाते में ऐप पासवर्ड बनाने की पात्रता | Yahoo कनेक्शन |
| iCloud Mail | ऐप-विशिष्ट पासवर्ड | Apple Account में दो-चरणीय सुरक्षा | iCloud कनेक्शन |
| AOL Mail | ऐप पासवर्ड | खाते के लिए ऐप पासवर्ड तैयार रखें | AOL कनेक्शन |
| Zoho Mail | ऐप पासवर्ड वाला कनेक्शन | योजना और संगठन में IMAP की अनुमति; IMAP सक्रिय होना | Zoho कनेक्शन |
| Fastmail | ऐप पासवर्ड | योजना में बाहरी मेल क्लाइंट की अनुमति | Fastmail कनेक्शन |
| निजी IMAP सर्वर / कंपनी डोमेन | कस्टम IMAP (private server / company domain) | व्यवस्थापक से साइन-इन विधि और सर्वर सेटिंग | कस्टम IMAP कनेक्शन |
Gmail के लिए दो-चरणीय सत्यापन आवश्यक है, लेकिन उसे चालू करने भर से ऐप पासवर्ड का विकल्प मिलना तय नहीं है। Google की ऐप पासवर्ड सहायता के अनुसार, केवल सुरक्षा कुंजियों वाला दो-चरणीय सत्यापन, संगठन का खाता या Advanced Protection इस विकल्प के न दिखने की वजह हो सकते हैं।
Google उन ऐप के लिए “Sign in with Google” की सलाह देता है जो यह विकल्प देते हैं, लेकिन Mailera जैसे तीसरे-पक्ष ऐप के लिए Gmail कनेक्शन ऐप पासवर्ड से ही होता है।
Apple के निर्देश ऐप-विशिष्ट पासवर्ड के लिए two-factor authentication आवश्यक बताते हैं। Yahoo के निर्देश खाते की पात्रता के अनुसार लागू होते हैं; Yahoo सहायता टीम भी ऐप पासवर्ड बनाने की पात्रता प्रक्रिया को बदल नहीं सकती।
Zoho में पहले IMAP सक्रिय होना चाहिए। संगठन की नीति इसे रोक सकती है, और नए Free योजना वाले खातों में IMAP उपलब्ध नहीं है। दो-चरणीय सत्यापन या संगठन में SAML इस्तेमाल होने पर बाहरी IMAP क्लाइंट के लिए ऐप-विशिष्ट पासवर्ड आवश्यक है। अपने खाते और डेटा सेंटर के सर्वर विवरण Zoho की IMAP सहायता के अनुसार लें।
Fastmail की ऐप पासवर्ड सहायता के अनुसार, हर बाहरी ऐप के लिए अलग ऐप पासवर्ड चाहिए। Basic योजना में बाहरी मेल क्लाइंट और ऐप पासवर्ड उपलब्ध नहीं हैं।
Microsoft के मामले में पासवर्ड बदलकर कोशिश करते रहना समाधान नहीं है। Exchange Online में IMAP के लिए Basic authentication हटा दिया गया है, और ऐप पासवर्ड उसे वापस नहीं लाता। इसका आधार Microsoft का Basic authentication दस्तावेज़ है। अन्य विकल्पों के लिए समर्थित प्रदाताओं की सूची देखें।
कनेक्शन शुरू करने से पहले क्या तैयार रखें?
अपने या अधिकृत परीक्षण मेलबॉक्स से शुरुआत करें। संगठन के खाते के लिए व्यवस्थापक से अनुमति और सुरक्षा नीति की पुष्टि लें। Mailera में मेलबॉक्स जोड़ने के लिए आपकी भूमिका Admin या Leader होनी चाहिए।
- ऊपर की तालिका से अपने प्रदाता का तरीका चुनें। निजी IMAP सर्वर के लिए हर बार ऐप पासवर्ड मानकर न चलें।
- जहाँ आवश्यक हो, दो-चरणीय सत्यापन, IMAP की अनुमति और खाते की योजना जाँचें।
- ऐप पासवर्ड वाला कनेक्शन हो तो प्रदाता की आधिकारिक खाता सुरक्षा प्रक्रिया से पासवर्ड बनाएँ। Microsoft हो तो OAuth वाला रास्ता लें।
- वह मेलबॉक्स समूह तय करें जिसकी पहुँच एजेंट को देनी है। API कुंजी का दायरा इसी समूह से जुड़ेगा।
- अपने परीक्षण मेलबॉक्स में पहचानने योग्य, गैर-संवेदनशील परीक्षण संदेश रखें। इससे कनेक्शन के बाद सही मेलबॉक्स खुलने की पुष्टि कर सकेंगे।
मुख्य पासवर्ड, ऐप पासवर्ड और API कुंजी को चैट, स्क्रीनशॉट या लॉग में न डालें। उदाहरण कोड में भी असली पासवर्ड या API कुंजी लिखने के बजाय उनके मान अपने सुरक्षित परिवेश से लें।
Mailera में मेलबॉक्स जोड़कर कनेक्शन कैसे जाँचें?
ऐप पासवर्ड वाले प्रदाता के लिए यह क्रम अपनाएँ:
- मेलबॉक्स → मेलबॉक्स जोड़ें → एक मेलबॉक्स खोलें।
- ईमेल पता भरें। Mailera पते से प्रदाता पहचानता है; परिणाम सही न हो तो या प्रदाता चुनें में सही विकल्प चुनें। फिर जारी रखें दबाएँ। निजी सर्वर के लिए कस्टम IMAP चुनें।
- ऐप पासवर्ड कैसे पाएँ और आपको क्या चाहिए पढ़ें। कनेक्शन विवरण के पासवर्ड फ़ील्ड में ऐप पासवर्ड भरें, सामान्य साइन-इन पासवर्ड नहीं। मेलबॉक्स समूह चुनें; ज़रूरत हो तो प्रदर्शित नाम भरें।
- जाँचें और कनेक्ट करें दबाएँ। इनकमिंग सर्वर साइन-इन, फ़ोल्डर की पहचान और, आउटगोइंग सर्वर होने पर, आउटगोइंग सर्वर साइन-इन का परिणाम देखें। जाँच में लाइव निगरानी की उपलब्धता भी दिखती है। यह प्रक्रिया कोई ईमेल नहीं भेजती।
- प्राप्त करने की जाँच सफल लेकिन भेजने की जाँच विफल हो तो केवल प्राप्ति मोड में सहेजें चुन सकते हैं। भेजना आवश्यक हो तो विवरण बदलें से सेटिंग सुधारें और फिर से जाँचें चलाएँ।
- सफल कनेक्शन के बाद मेलबॉक्स खोलें। शुरुआती लोडिंग में संदेश रखने की अवधि के भीतर आने वाले नए संदेश पहले लोड होते हैं। अपने परीक्षण संदेश को ढूँढ़कर उसकी पुष्टि करें।

कस्टम IMAP के लिए व्यवस्थापक से मिले इनकमिंग सर्वर (IMAP) विवरण भरें। भेजना भी चाहिए तो आउटगोइंग सर्वर (SMTP) विवरण दें। सेटिंग खोजें डोमेन की सार्वजनिक सेटिंग उपलब्ध होने पर उन्हें भर सकता है; निजी सर्वर की साइन-इन विधि और सेटिंग व्यवस्थापक से लें।
Microsoft के लिए प्रक्रिया अलग है: मेलबॉक्स जोड़ें → Microsoft से साइन इन करें चुनें और Microsoft पर OAuth सहमति पूरी करें। Outlook.com, Hotmail और Microsoft 365 को यहाँ ऐप पासवर्ड फ़ील्ड से नहीं जोड़ना है।

AI एजेंट के लिए सीमित API कुंजी कैसे बनाएँ?
मेलबॉक्स जुड़ने के बाद प्रदाता का ऐप पासवर्ड एजेंट को न दें। एजेंट के लिए अलग Mailera API कुंजी बनाएँ। इससे उसके अधिकार और उसका पहुँच-दायरा स्वतंत्र रूप से नियंत्रित कर सकेंगे।
- सेटिंग्स में API कुंजी वाला टैब खोलें और API key बनाएँ चुनें।
- पहचानने योग्य नाम भरें, ताकि बाद में पता रहे कि कुंजी किस एजेंट की है।
- मेलबॉक्स का दायरा में आवश्यक समूह चुनें। कुंजी का दायरा समूह है, किसी एक मेलबॉक्स का अलग चयन नहीं। Admin सभी समूह भी चुन सकते हैं, लेकिन केवल आवश्यक समूह चुनें।
- केवल पढ़ने वाले एजेंट को
readअनुमति दें। भेजने की आवश्यकता न हो तोsendन दें। - समाप्ति तय करें और आवश्यकता के अनुसार IP प्रतिबंध (वैकल्पिक) भरें।
- API key बन गई — अभी कॉपी करें दिखाई देने पर कुंजी सुरक्षित रखें। वह केवल एक बार दिखाई जाती है।

Claude, Cursor या VS Code के लिए उसी संवाद में MCP कॉन्फ़िग कॉपी करें इस्तेमाल करें। कॉन्फ़िगरेशन को भी गोपनीय मानें। Mailera का MCP विवरण समर्थित कनेक्शन बताता है। पहले list_mailboxes, फिर अपने परीक्षण मेलबॉक्स पर list_messages चलाएँ; दोनों के लिए read चाहिए।
REST से यही शुरुआती जाँच करने के लिए अपने सुरक्षित स्थानीय परिवेश में $MAILERA_API_KEY भरें:
curl --request GET 'https://mailera.app/api/public/v1/mailboxes?limit=1' \
--header "Authorization: Bearer $MAILERA_API_KEY"लौटी सूची के data में मेलबॉक्स का id, provider, status और last_sync_at देखें। limit=1 केवल उत्तर का आकार घटाता है; वह कुंजी की पहुँच सीमित नहीं करता। पहुँच चुने हुए समूह और कुंजी के अधिकारों से नियंत्रित होती है।
अपने परीक्षण मेलबॉक्स का id, $MAILBOX_ID में भरकर इनबॉक्स का संदेश देखें:
curl --request GET "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
--header "Authorization: Bearer $MAILERA_API_KEY"उत्तर में subject, folder और received_at से संदेश पहचानें। यदि संदेश मिल गया, तो Mailera में उस संदेश तक एजेंट की पढ़ने की पहुँच की पुष्टि हो गई। संदेश का पूरा निजी पाठ लॉग में डालना इस जाँच के लिए आवश्यक नहीं है।
कनेक्शन में कौन-सी आम गलतियाँ होती हैं?
एक ही पासवर्ड बार-बार डालने से पहले देखें कि विफलता किस चरण में हुई। प्रदाता का साइन-इन, भेजने की सेटिंग और API अनुमति अलग समस्याएँ हैं।
| समस्या | संभावित कारण | अगली जाँच |
|---|---|---|
| Gmail में ऐप पासवर्ड विकल्प नहीं दिखता | दो-चरणीय सत्यापन की स्थिति, संगठन की नीति या Advanced Protection | Google की ऐप पासवर्ड सहायता के अनुसार खाते की पात्रता देखें |
| ऐप पासवर्ड से साइन-इन विफल | गलत या रद्द प्रमाण-पत्र; IMAP की अनुमति या योजना की समस्या | सही खाते का ऐप पासवर्ड और IMAP पात्रता जाँचें |
| ईमेल मिलती है, भेजी नहीं जाती | आउटगोइंग जाँच विफल या आउटगोइंग सर्वर नहीं दिया गया | प्राप्त करने और भेजने के परिणाम अलग देखें; आवश्यकता हो तो SMTP विवरण सुधारें |
| Outlook ऐप पासवर्ड से नहीं जुड़ता | गलत कनेक्शन तरीका | Microsoft से साइन इन करें वाला OAuth प्रवाह चुनें |
| एजेंट को अनुमति की समस्या मिलती है | गलत अधिकार या समूह; कुंजी समाप्त या रद्द | read, समूह का दायरा और कुंजी की स्थिति जाँचें |
| मेलबॉक्स जुड़ा है, पर अपेक्षित संदेश नहीं दिखता | फ़ोल्डर, शुरुआती लोडिंग या सिंक की स्थिति जाँचनी है | सही मेलबॉक्स और फ़ोल्डर खोलें; REST उत्तर में last_sync_at देखें |
स्थिति जाँच की सीमा भी समझें। GET /mailboxes/{id}/status Microsoft के लिए सीधे साइन-इन जाँचता है। दूसरे प्रदाताओं के लिए परिणाम नवीनतम सिंक पर आधारित होता है; हर अनुरोध नया साइन-इन परीक्षण नहीं करता।
एजेंट को ईमेल पढ़ाते समय क्या सुरक्षित रखें?
आने वाली ईमेल अविश्वसनीय डेटा है, निर्देश नहीं। कोई संदेश एजेंट से नियम बदलने, API कुंजी भेजने या किसी लिंक पर गोपनीय सामग्री डालने को कहे, तो एजेंट को उसका पालन नहीं करना चाहिए। यह prompt injection का जोखिम है।
एजेंट की अपनी निर्देश-व्यवस्था में साफ़ रखें कि संदेश का पाठ केवल पढ़ने और विश्लेषण करने की सामग्री है। ईमेल के भीतर मिली “प्रशासक की अनुमति” को ऐप की अनुमति न मानें। प्रदाता का ऐप पासवर्ड एजेंट के प्रॉम्प्ट में कभी न रखें; Mailera API कुंजी भी गोपनीय है।
भेजना आवश्यक होने पर एजेंट या अपने ऐप में मानवीय पुष्टि लागू करें। पुष्टि में प्राप्तकर्ता और भेजा जाने वाला पाठ दिखाएँ। यह पुष्टि आपको अपनी व्यवस्था में लागू करनी होगी; Mailera इसे अपने-आप लागू नहीं करता। send_email और reply_to_email के लिए send अधिकार चाहिए; केवल पढ़ने वाले एजेंट को वह अधिकार देने का कारण नहीं है।
मेलबॉक्स समूह चुनते समय उसके भीतर मौजूद खातों को देखें। read होने का अर्थ यह नहीं कि एजेंट केवल एक मनचाहा संदेश पढ़ पाएगा। Mailera की सुरक्षा जानकारी के साथ अपने संगठन के गोपनीयता नियम भी लागू करें।
पहुँच बंद करनी हो या पासवर्ड लीक हो जाए तो क्या करें?
पहले पता करें कि कौन-सा पासवर्ड या कुंजी लीक हुई है। एजेंट की कुंजी लीक हुई हो तो Mailera में उसे रद्द करें; उस कुंजी से होने वाले API अनुरोध तुरंत अस्वीकार होते हैं। प्रदाता का ऐप पासवर्ड लीक हुआ हो तो उसे प्रदाता के खाते में अलग से रद्द करें। दोनों सामने आए हों तो दोनों पर कार्रवाई करें।
मुख्य खाते का पासवर्ड बदलने का असर प्रदाता के अनुसार अलग है:
| प्रदाता | ऐप पासवर्ड की पहुँच बंद करने का व्यवहार |
|---|---|
| मुख्य खाता पासवर्ड बदलने पर ऐप पासवर्ड रद्द होते हैं; किसी ऐप पासवर्ड को अलग से भी रद्द कर सकते हैं | |
| Yahoo | मुख्य पासवर्ड बदलने से ऐप पासवर्ड अमान्य नहीं होते; संबंधित ऐप पासवर्ड अलग से हटाना होता है |
| Apple | मुख्य पासवर्ड बदलने या रीसेट करने पर सभी ऐप-विशिष्ट पासवर्ड रद्द होते हैं; उन्हें अलग-अलग भी रद्द कर सकते हैं |
| Fastmail | ऐप पासवर्ड की पहुँच “Disable” से अस्थायी रूप से रोक सकते हैं या “Remove” से स्थायी रूप से हटा सकते हैं |
Microsoft का कनेक्शन OAuth से होता है। एजेंट की Mailera API कुंजी उससे अलग है और उसे Mailera में रद्द किया जा सकता है।
Mailera प्रदाता की ऐप पासवर्ड पात्रता, संगठन की सुरक्षा नीति या IMAP योजना की शर्तें नहीं बदल सकता। Proton Mail और Tuta समर्थित नहीं हैं। केवल प्राप्ति मोड में सहेजा गया कनेक्शन ईमेल भेजने की सुविधा नहीं देता।
2 मिनट में अपना पहला मेलबॉक्स कनेक्ट करें
Outlook, Gmail या IMAP मेलबॉक्स जोड़ें और ऐप में या API के ज़रिए ईमेल पढ़ें।
मेलबॉक्स कनेक्ट करें




