Gmail तीसरे पक्ष के पतों जैसे @yahoo.com के लिए "Send as" समर्थन समाप्त करेगा
Google Gmail के “Send as” समर्थन को तीसरे पक्ष के पतों (जैसे Yahoo, Outlook, और Google पर होस्ट न किए गए custom domains) के लिए समाप्त कर रहा है, जबकि Google Workspace aliases और अन्य Gmail-managed identities के लिए इसे बनाए रखेगा। कई उपयोगकर्ता जो Gmail को कई non-Google पतों के लिए एक केंद्रीय hub की तरह इस्तेमाल करते थे, इसे paid Workspace plans या Fastmail, Proton, Apple का iCloud+ mail hosting, या self-hosted समाधानों जैसे alternative providers की ओर धकेलने के रूप में देख रहे हैं। टिप्पणीकार इस कदम को Gmail के power-user features से धीरे-धीरे दूर जाने, anti-abuse measures (DMARC/SPF/DKIM) और maintenance costs कम करने तथा email से और अधिक monetization की Google की इच्छा के हिस्से के रूप में भी देखते हैं.
क्या बदल रहा है और यह क्यों महत्वपूर्ण है
- Gmail तीसरे पक्ष/गैर-Google पतों (जैसे yahoo.com, outlook.com, और Google पर होस्ट न किए गए कस्टम डोमेन) के लिए “Send as” समर्थन हटा देगा।
- Google-होस्टेड पहचानों (अन्य Gmail पते, Workspace aliases) के लिए “Send as” जारी रहेगा।
- कई टिप्पणीकार कहते हैं कि यह सुविधा ऐतिहासिक रूप से या तो इस तरह लागू की गई थी:
- Gmail Google के SMTP से सीधे मेल भेजता था (SPF/DKIM उचित रूप से सेट करके), या
- Gmail एक नियमित मेल क्लाइंट की तरह तीसरे पक्ष के प्रदाता के SMTP का उपयोग करता था।
- कई उपयोगकर्ताओं ने वर्षों तक इसका उपयोग एक निजी/कस्टम डोमेन बनाए रखने के लिए किया, जबकि Gmail को अपने एकमात्र इंटरफ़ेस के रूप में इस्तेमाल किया।
अस्पष्टताएँ और भ्रम
- यह स्पष्ट नहीं है कि ठीक-ठीक “Google-होस्टेड identity” में क्या शामिल है, खासकर उन कस्टम डोमेन के लिए जो outbound SMTP के लिए Google का उपयोग करते हैं लेकिन inbound के लिए किसी अन्य प्रदाता (या forwarding) का।
- कुछ सहायता दस्तावेज़ Gmail mobile app और third-party access का उल्लेख करते हैं, जिससे यह भ्रम पैदा होता है कि app/IMAP बनाम web के माध्यम से क्या अभी भी काम करता है।
- कई लोग इस बात को लेकर अनिश्चित हैं कि क्या personal Gmail accounts अभी भी Workspace-hosted कस्टम डोमेन के लिए “Send as” कर सकते हैं।
प्रेरणाएँ और व्याख्याएँ
- एक पक्ष: यह DMARC/SPF/DKIM को मजबूत करने और abuse कम करने से प्रेरित है; third-party relaying नाज़ुक है और एक attack vector है।
- दूसरा पक्ष: यह मुख्यतः monetization और cost-cutting है—उपयोगकर्ताओं को paid Workspace की ओर धकेलना या maintenance-heavy edge features का बोझ कम करना।
- कुछ का तर्क है कि इस सुविधा का उपयोग शायद बहुत कम है और यह Gmail के लिए “suicide” नहीं है; अन्य लोग अनुमान लगाते हैं कि इससे काफ़ी लोग दूर हो जाएंगे।
उपयोगकर्ता प्रभाव और प्रतिक्रियाएँ
- प्रभावित उपयोगकर्ताओं में शामिल हैं:
- वे व्यक्ति और छोटे व्यवसाय जो कहीं और होस्ट किए गए custom-domain mail के लिए Gmail को UI की तरह उपयोग करते हैं।
- वे लोग जो कई पतों को एक Gmail inbox में एकत्र करते हैं और उन पतों से “from” करके reply करते हैं।
- कुछ के लिए, यह “last straw” है जो Gmail/Workspace से migration को प्रेरित कर रहा है।
- अन्य इसे अपने email का पूरा स्वामित्व लेने की एक प्रेरणा के रूप में देखते हैं (अपने domain और non-Google provider के माध्यम से)।
विकल्प और migration रणनीतियाँ
- अक्सर उल्लेखित प्रदाता: Fastmail, Proton, Apple का iCloud Mail with custom domains, Migadu, MXRoute, mailbox.org, posteo, Tuta, Runbox।
- बताए गए tradeoffs:
- Fastmail: आम तौर पर सकारात्मक (domains/aliases के साथ अच्छा, कुछ UI शिकायतें, storage limits प्रबंधनीय)।
- Apple iCloud+: multiple custom domains के साथ सस्ती family hosting के लिए प्रशंसित।
- Migadu: multiple domains के लिए लचीला, calendar कमजोर।
- Tuta/Tutanota: मजबूत E2EE लेकिन IMAP/SMTP नहीं, जिसे कुछ लोग deal-breaker कहते हैं।
- सामान्य सलाह:
- अपने स्वयं के domain पर जाएँ, फिर MX changes के माध्यम से providers बदले जा सकते हैं।
- forwarding के साथ धीरे-धीरे account updates करें; पूरी तरह migrate होने तक Gmail को legacy “catch-all” के रूप में रखें।