Gmail और Yahoo की 2024 इनबॉक्स सुरक्षा और उनके ईमेल प्रोग्राम्स पर अर्थ

मूल लेख ↗ Hacker News चर्चा ↗

Gmail और Yahoo 2024 के लिए inbox नियम कड़े कर रहे हैं, जिनमें bulk senders (जो Gmail को रोज़ 5,000 या उससे अधिक संदेश भेजते हैं) के लिए SPF, DKIM और DMARC का उपयोग, one-click unsubscribe, और 0.3% से कम spam शिकायतें रखना शामिल है। टिप्पणीकार बताते हैं कि गंभीर प्रेषक और कई self-hosters पहले से ही इन सुरक्षा उपायों का उपयोग करते हैं, लेकिन email forwarding, shared SMTP services, और password resets जैसे transactional संदेशों को marketing से अलग पहचानने जैसी edge cases को लेकर चिंता है। abusive marketing practices को रोकने के लिए व्यापक समर्थन है, हालांकि इस बात पर संदेह बना हुआ है कि बड़े providers email को कितनी सही तरह वर्गीकृत करेंगे और इससे spam वास्तव में कितना घटेगा बनाम प्रमुख email platforms और अधिक मज़बूत हो जाएँगी।

नई Gmail/Yahoo आवश्यकताओं का दायरा

  • बल्क प्रेषक (व्यक्तिगत Gmail पर प्रति दिन ≥ ~5,000 संदेश) को यह करना होगा:
    • SPF, DKIM, और DMARC का उपयोग करना।
    • उपयोगकर्ता-रिपोर्टेड स्पैम शिकायतें 0.3% से नीचे रखना।
    • RFC 8058 के अनुसार one-click unsubscribe का समर्थन करना और बॉडी में एक दिखाई देने वाला unsubscribe लिंक शामिल करना (मार्केटिंग/सब्सक्रिप्शन मेल के लिए)।
  • “Bulk sender” की परिभाषा 24 घंटे की अवधि में एक ही primary domain से भेजे गए संदेशों पर आधारित है; थ्रेशोल्ड एक बार पार करने पर आप स्थायी रूप से bulk माने जाते हैं।
  • Transactional mail (जैसे password reset, MFA) को unsubscribe से छूट मिलनी चाहिए, लेकिन कुछ लोगों के लिए यह स्पष्ट नहीं है कि Google transactional और marketing सामग्री के बीच विश्वसनीय रूप से कैसे अंतर करता है।

SPF, DKIM, DMARC: भूमिकाएँ, सीमाएँ, और किनारे के मामले

  • कई लोग SPF/DKIM/DMARC को “पुरानी बात” मानते हैं और अच्छे deliverability के लिए इन्हें लगभग पहले से ही आवश्यक समझते हैं।
  • SPF भेजने वाले IP को envelope-from के विरुद्ध प्रमाणित करता है; DKIM headers/content पर हस्ताक्षर करता है; DMARC रिसीवर्स को बताता है कि जब वे मेल नहीं खाते तो कैसे कार्रवाई करनी है।
  • कुछ लोगों का तर्क है कि सैद्धांतिक रूप से SPF अकेले पर्याप्त है; अन्य कहते हैं कि केवल SPF spoofing को आमंत्रित करता है और DKIM अधिक मजबूत है (keys बनाम बार-बार उपयोग होने वाले IPs)।
  • Forwarding से SPF टूट जाता है; DMARC के साथ ARC (RFC 8617) को इच्छित समाधान के रूप में उल्लेख किया गया है, लेकिन ARC पूरी तरह standardize नहीं है और mandatory DMARC के तहत व्यवहार को अस्पष्ट माना जाता है।
  • यह प्रश्न उठाया गया कि क्या “p=none” DMARC तकनीकी रूप से नई “DMARC required” शर्त को पूरा करता है।

One-Click Unsubscribe और UX/Security चिंताएँ

  • असली “नई” तकनीकी ज़िम्मेदारी RFC 8058 (List-Unsubscribe POST) का समर्थन है।
  • कुछ लोगों को चिंता है:
    • Link scanners और crawlers द्वारा unsubscribe अपने-आप ट्रिगर हो सकते हैं।
    • forwarded message पाने वाला कोई भी व्यक्ति मूल recipient को unsubscribe करा सकता है।
  • अन्य लोग जवाब देते हैं कि:
    • GET नहीं, POST, कुछ scanning समस्याओं को कम करता है।
    • false या prank unsubscribes, abusive retention की तुलना में, एक छोटी हानि हैं।
    • Confirmation या “oops, resubscribe me” flows और follow-up confirmation emails मदद कर सकते हैं।

Deliverability, छोटे प्रेषक, और Self-hosting

  • कई self-hosters बताते हैं कि यदि DNS, rDNS, DMARC alignment, और IP reputation मजबूत हों तो deliverability अच्छी रहती है; अन्य लोग सब कुछ “सही” करने के बावजूद प्रमुख providers द्वारा rejection की रिपोर्ट करते हैं।
  • Shared smarthosts (SendGrid, SES, आदि) चीज़ों को जटिल बनाते हैं; domain-based counting मदद करती है, लेकिन कुछ लोग misclassification और किसी उपाय के अभाव से डरते हैं।
  • IP warming और outbound SMTP की अनुमति देने वाले hosts ढूँढना, SPF/DKIM/DMARC सेट करने से अधिक कठिन बताया गया है।

DMARC Reporting Ecosystem

  • कई लोगों को DMARC aggregate reports (ZIPs में XML) सीधे उपयोगी नहीं लगते और वे dashboards/services पर निर्भर रहते हैं।
  • कई commercial और free tools का उल्लेख किया गया; कुछ लोग “DMARC SaaS industry” की आलोचना करते हैं कि साधारण XML parsing के लिए यह बहुत महँगा है और हल्के self-hosted विकल्प चाहते हैं।

Marketing Email और Spam के प्रति रुख

  • अनचाहे marketing, re-opt-ins, dark-pattern unsubscribes, और transactional के रूप में masquerade करने वाले “legal update” spam को लेकर तीखी निराशा।
  • कुछ लोग सिद्धांततः लगभग सभी commercial email को spam के रूप में चिह्नित करते हैं और आशा करते हैं कि 0.3% spam-rate cap साफ़-सुथरी practices को मजबूर करेगा।
  • अन्य लोग संदेह करते हैं कि बदलाव वास्तविक दुनिया के spam को सार्थक रूप से कम करेंगे, यह देखते हुए कि बहुत सा spam पहले से ही बड़े, पूरी तरह authenticated providers (Gmail/Yahoo स्वयं सहित) से आता है और false positives तथा inconsistent filtering अभी भी आम हैं।