API

डिस्पोजेबल इनबॉक्स

ऐसे व्यक्ति के लिए काम करता पता जिसके पास कोई नहीं है: न खाता, न कुंजी, और उसी दिन ख़त्म।

डिस्पोजेबल इनबॉक्स क्या है

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

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

ये वही कॉल हैं जो इस साइट पर मौजूद मुफ़्त टूल करता है, इसलिए जो पेज कर सकता है वह आपका कोड भी कर सकता है। API उस स्थिति के लिए है जहाँ पेज नहीं है: ऐसा टेस्ट सूट जिसे हर run पर ताज़ा पता चाहिए।

पता ही क्रेडेंशियल नहीं है

डिस्पोजेबल पता जारी होते ही किसी साइनअप फ़ॉर्म में टाइप कर दिया जाता है। वहाँ से वह To: header में यात्रा करता है, भेजने वाले के लॉग से होकर, और उस CRM तक जो दूसरे सिरे पर बैठा है। अगर पता जान लेना ही मेल पढ़ने के लिए काफ़ी होता, तो यह टूल डिज़ाइन से ही हर जारी किया इनबॉक्स लीक कर देता — और ठीक उसी पक्ष को, जिसे कॉल करने वाला दूर रख रहा था।

इसलिए इनबॉक्स बनाना एक दूसरा मान भी लौटाता है: एक token, 32 यादृच्छिक bytes, oe_inbox_ और 43 base64url अक्षरों के रूप में। वह उसी एक रिस्पॉन्स पर दिखता है और किसी दूसरे पर नहीं। row उसका केवल keyed hash रखती है, इसलिए उसे कुछ भी वापस नहीं ला सकता — न कोई सपोर्ट अनुरोध और न डेटाबेस डंप। टोकन खोया तो इनबॉक्स गया, और किसी की मेल पढ़ने वाले क्रेडेंशियल के लिए यही सही नतीजा है।

पूरा फ़्लो

# 1. Mint one. This is the only response that carries a token.curl -s -X POST "$OE/temp-mail/inboxes" -H "Content-Type: application/json" -d '{}' # 2. Keep it, and read with it.export INBOX="Authorization: Bearer oe_inbox_kQ8v…"curl -s "$OE/temp-mail/inboxes/tinb_9c2f…/messages" -H "$INBOX"

इनमें से किसी route पर oe_live_ या oe_test_ API कुंजी भेजें और उसे सपाट 401 के बजाय invalid_credential_type के रूप में मना किया जाता है। यहाँ दो तरह के क्रेडेंशियल एक ही होस्ट और एक ही header साझा करते हैं, और "अनधिकृत" आपको यह अनुमान लगाने पर छोड़ देता कि आपका कौन-सा गलत था।

लीज़, और उसे बढ़ाना

एक घंटा, न कि वे दस मिनट जिनके नाम पर यह शैली जानी जाती है। दस पुष्टि कोड के लिए काफ़ी हैं और उस दूसरे आधे उपयोग के लिए नाकाफ़ी: ऐसा ट्रायल जो अगली सुबह फिर ईमेल करता है, ऐसा फ़ॉर्म जो दो बार भरा गया क्योंकि पहली कोशिश टाइम आउट हो गई। create पर ttlMinutes कुछ और माँगता है, 1 से 1440 तक; उस दायरे के बाहर की संख्या चुपचाप समायोजित करने के बजाय 422 से मना की जाती है, क्योंकि जो समाप्ति आपने माँगी नहीं वह वैसी है जिसकी योजना आप पहले ही बना चुके हैं।

POST /temp-mail/inboxes/{id}/extend समाप्ति में एक घंटा जोड़ता है, अभी में नहीं, इसलिए जल्दी बढ़ाने से आपका बचा हुआ समय बर्बाद नहीं होता। यह 23 बार काम करता है, और इनबॉक्स बनने के क्षण से गिना गया दिन दोनों सीमाओं में कठिन है: जो लीज़ पहले से वहाँ तक चलती है उसके पास खरीदने को कुछ बचा ही नहीं, चाहे कितनी भी कम extensions खर्च हुई हों। हर इनबॉक्स रिस्पॉन्स पर extensionsLeft दोनों गिनता है, ताकि क्लाइंट बटन धूसर कर सके; शून्य पर कॉल 409 extension_limit देती है।

समाप्त हुआ इनबॉक्स समाप्त होते ही प्रमाणीकरण बंद कर देता है: उसका टोकन sweep का इंतज़ार किए बिना 404 देता है। sweep वही है जो मेल हटाता है, और वह प्रति घंटा cron पर चलता है; DELETE /temp-mail/inboxes/{id} वही हटाना माँग पर है।

सीमाएँ

ये सब दर-सीमक नहीं, गिनी जाने वाली rows हैं। इस कोडबेस में इस्तेमाल करने लायक कोई सीमक है ही नहीं, और यह कह देना ऐसी सुरक्षा का संकेत देने से ज़्यादा उपयोगी है जो मौजूद नहीं। वे वहाँ रखी गई हैं जहाँ नुकसान होता: बनाने पर, और भंडारण पर।

सीमा	मान	वहाँ पहुँचने पर क्या होता है
लीज़	60 मिनट, 24 घंटे तक बढ़ाई जा सकती है	409 `conflict_error` / `extension_limit`
प्रति इनबॉक्स संदेश	50	आगे की मेल दरवाज़े पर ही गिरा दी जाती है। कोई bounce नहीं लिखा जाता, कुछ कतार में नहीं लगता, और संदेश हटाने से स्लॉट वापस नहीं मिलता।
बनाए गए इनबॉक्स	प्रति कॉलर 6 प्रति घंटा, 30 प्रति दिन	429 `rate_limit_error` / `too_many_inboxes`
संग्रहित बॉडी	2 MB	संदेश पर `truncated: true`; बाकी हिस्सा चला गया।
अटैचमेंट bytes	प्रत्येक 8 MB	`content` null होता है और मेटाडेटा रखा जाता है, जो खाली फ़ाइल के बराबर नहीं है।

बनाने की सीमा क्लाइंट IP के keyed hash के विरुद्ध गिनी जाती है, और नष्ट किया गया इनबॉक्स भी गिना जाता है, इसलिए एक को फेंक देना दूसरा पाने का तरीका नहीं है। किसी और की प्रॉक्सी के पीछे forwarded header नकली बनाया जा सकता है, जो क्रेडेंशियल में छेद नहीं बल्कि इस सीमा की ज्ञात कमज़ोरी है: यहाँ कुछ भी उस मान पर अधिकृत नहीं करता।

यहाँ क्या नहीं है

अभी जारी नहीं हुआ

आज़माकर पता लगाना, बता दिए जाने से बुरा है:

किसी भी रूप में भेजना नहीं। डिस्पोजेबल इनबॉक्स के पास भेजने के लिए कोई कनेक्शन नहीं है, और उसे जोड़ना एक अनाम, अप्रमाणित एंडपॉइंट को खुला relay बना देता।
नाम बदलना नहीं। अपना पता बदलने का मतलब है दूसरा इनबॉक्स बनाना: जगह पर नाम बदलना क्लिक करते ही पुराना local-part छोड़ देता, और रास्ते में चल रही कोई पुष्टि फिर उसे डिलीवर हो जाती जिसे वह अगला जारी हुआ।
कोई नियम, फ़िल्टर, forwarding, webhooks या AI नहीं। spam संदेश पर एक फ़्लैग है और उस पर किसी ने कोई कार्रवाई नहीं की। कुछ भी फ़ाइल करके नहीं रखा गया, और यहाँ कुछ भी सारांशित या embed नहीं होता।
कोई bounce नहीं। pooled डोमेन पर आई ऐसी मेल जो न किसी जीवित डिस्पोजेबल इनबॉक्स का नाम लेती है और न ऑपरेटर के बनाए पते का, जानबूझकर चुपचाप गिरा दी जाती है: सार्वजनिक पता-जनरेटर शब्दकोश हमलों को खींचता है, और हमला जिस भी return path का दावा करे उस पर डिलीवरी रिपोर्ट लिखना इस इंस्टॉल को backscatter का स्रोत बना देता।
कोई डोमेन कॉन्फ़िगर नहीं तो कोई सेवा नहीं। जब TEMP_MAIL_DOMAINS खाली हो, GET /temp-mail/domains खाली सूची देता है और इनबॉक्स बनाना 503 temp_mail_unavailable देता है। pooled डोमेन पर इनबाउंड डिलीवरी किसी जीवित डोमेन पर एक सिरे से दूसरे सिरे तक देखी नहीं गई है।

डोमेन कॉन्फ़िगर करना, अगर इंस्टॉल आप चलाते हैं

यह सूची कॉन्फ़िगरेशन है: TEMP_MAIL_DOMAINS जिनका नाम लेता है वही बाँटे जाते हैं। DNS कुछ भी स्वचालित नहीं करता, इसलिए इन पाँच में से चार चरण रजिस्ट्रार पर बैठा कोई व्यक्ति ही करता है।

इसके लिए एक डोमेन पंजीकृत करें। ऐसा चुनें जिसे अजनबियों को बाँटने देने में आपको कोई आपत्ति न हो। उस पर मौजूद हर पता उसकी प्रतिष्ठा साझा करता है, और इसीलिए picker नए इनबॉक्स पहले डोमेन को भरने के बजाय पूरे pool में यादृच्छिक रूप से फैलाता है।
उसे ऐप में Settings → Domains के नीचे जोड़ें। इससे भेजने वाली पहचान बनती है और प्रकाशित करने लायक DNS रिकॉर्ड छप जाते हैं।
रजिस्ट्रार पर MX, SPF, DKIM और _openemail-challenge TXT रिकॉर्ड प्रकाशित करें। सत्यापन जीवित DNS पढ़ता है और cron पर दोबारा जाँचा जाता है; केवल सत्यापित डोमेन ही कभी पेश किया जाता है।
सत्यापित डोमेन को सर्वर पर TEMP_MAIL_DOMAINS में जोड़ें, अल्पविराम से अलग करके। जब तक वह सूचीबद्ध न हो, वह वर्कस्पेस का एक सामान्य डोमेन है।
catch-all चालू रहने दें। यही वह चीज़ है जिससे डिस्पोजेबल पता बनाए बिना अस्तित्व में आता है, क्योंकि किसी भी local part पर आई मेल स्वीकार की जाती है और सामान्य प्राप्तकर्ता-खोज से पहले पढ़ ली जाती है, इसलिए pooled डोमेन के लिए कोई पता-row कभी नहीं लिखी जाती; catch-all चालू छोड़ना फेंकने लायक मेल को किसी असली मेलबॉक्स में फ़ाइल करना शुरू कर देता।

आरक्षित local-parts (postmaster, abuse, security और RFC 2142 के बाकी) कभी डिस्पोजेबल नहीं हो सकते और इसके बजाय सामान्य मेलबॉक्स तक चले जाते हैं। जो pooled डोमेन अपनी ही abuse रिपोर्टें निगल जाता है, वह डोमेन कहीं भी डिलीवर करने की क्षमता खो देता है। pooled डोमेन पर आपका खुद बनाया पता, जैसे legal@ या privacy@, भी वैसा ही व्यवहार करता है: उस पर आई मेल आपके मेलबॉक्स में आती है, और उसे किसी को डिस्पोजेबल पते के रूप में जारी नहीं किया जा सकता।

इस सेक्शन में

pooled डोमेन सूचीबद्ध करेंयह इंस्टॉल किन पर पता जारी करेगा।इनबॉक्स बनाएँपता, और वह इकलौता रिस्पॉन्स जिस पर टोकन होता है।इनबॉक्स प्राप्त करेंलीज़, गिनती, और कितने extensions बचे हैं।लीज़ बढ़ाएँएक और घंटा, उस दिन तक जिस पर वह सीमित है।इनबॉक्स नष्ट करेंमेल अभी, पता एक हफ़्ते में।संदेश सूचीबद्ध करेंवह कॉल जिसे आप poll करते हैं। केवल मेटाडेटा।संदेश प्राप्त करेंएक संदेश उसकी बॉडी के साथ, और क्या रेंडर करना है।संदेश हटाएँएक संदेश और उसके bytes, आपके अनुरोध पर।अटैचमेंट सूचीबद्ध करेंbytes, base64, और वे कब गायब होते हैं।SDK सेवही नौ कॉल जैसे `tempMail.*`, हर एक की एक row।