संदेश-आकार की अस्वीकृतियाँ बनाम प्रमाणीकरण अस्वीकृतियाँ

प्राप्तकर्ता सर्वर द्वारा सभी संदेश प्रमाणीकरण का मूल्यांकन करने से पहले एक संदेश-आकार अस्वीकृति हो सकती है। यह तब भी प्रकट हो सकता है जब अपस्ट्रीम सर्वर एक संदेश स्वीकार कर लेता है और बाद में हॉप एक छोटी सीमा लागू करता है। प्रत्येक स्थायी अस्वीकृति को एक के रूप में मानने के बजाय अस्वीकार हॉप पर आकार की स्थिति का निदान करें SPF, DKIM या DMARC दोष.

पॉलिसी और भंडारण से आकार में अंतर बताएं

RFC 3463 X.3.4 को एक संदेश के रूप में परिभाषित करता है जो प्राप्तकर्ता प्रणाली के लिए बहुत बड़ा है और X.2.3 को एक संदेश की लंबाई के रूप में परिभाषित करता है जो मेलबॉक्स के लिए एक प्रशासनिक सीमा से अधिक है। ये X.2.2 मेलबॉक्स से भिन्न हैं। संपूर्ण निदान पढ़ें क्योंकि उत्पाद अपनी सीमाएं, इकाइयां और व्याख्यात्मक शब्द जोड़ सकते हैं। केवल एक सामान्य "552" लेबल सटीक कॉन्फ़िगर प्रतिबंध स्थापित नहीं करता है। RFC 3463 अनुभाग 3.3 और 3.4.

प्रमाणीकरण विफलताएं संदेश ऑक्टेट की संख्या के बजाय पहचान, हस्ताक्षर या नीति से संबंधित हैं। आकार कम करना DKIM मरम्मत नहीं है; हस्ताक्षरित सामग्री को बदलने से हस्ताक्षर स्वयं ही अमान्य हो सकता है, इसलिए एक अधिकृत प्रतिस्थापन को सामान्य हस्ताक्षर कार्यप्रवाह से गुजरना होगा। इसके विपरीत, SPF में किसी अन्य आईपी को अधिकृत करने से प्राप्तकर्ता के अनुमत संदेश आकार में वृद्धि नहीं होती है। जब तक स्वतंत्र साक्ष्य यह न दिखाए कि दोनों विफल हो रहे हैं, तब तक दोनों जांचों को अलग-अलग रखें।

विज्ञापित आकार क्षमता को सही ढंग से पढ़ें

SMTP SIZE एक्सटेंशन एक सर्वर को समर्थन और वैकल्पिक रूप से अधिकतम संदेश आकार का विज्ञापन करने देता है EHLO प्रतिक्रिया। एक सहायक ग्राहक अनुमानित आकार की आपूर्ति कर सकता है मेल प्रेषक, संपूर्ण संदेश प्रसारित करने से पहले अस्वीकृति की अनुमति देता है। संख्या के बिना आकार कोई निश्चित-अधिकतम जानकारी नहीं देता है; आकार 0 स्पष्ट रूप से इंगित करता है कि कोई निश्चित अधिकतम सीमा लागू नहीं है। न ही स्वीकृति की गारंटी देता है। बाद में प्रसंस्करण और अन्य हॉप्स अभी भी बाधाएं लगा सकते हैं। RFC 1870 धारा 3 और 4.

RFC 1870 आकार के लिए, सीआरएलएफ लाइन एंडिंग्स, हेडर, MIME संरचना और एन्कोडेड सामग्री सहित संदेश ऑक्टेट की गणना करें, लेकिन डेटा टर्मिनेटिंग डॉट और अतिरिक्त डॉट-स्टफिंग बाइट्स को बाहर रखें। केवल अनुलग्नक फ़ाइल की गिनती न करें. बेस64 एन्कोडिंग बाइनरी डेटा का विस्तार करती है, और लाइन ब्रेक और आसपास के संदेश भाग अधिक बाइट्स जोड़ते हैं। देखना RFC 2045 अनुभाग 6.8. प्रदाता इंटरफ़ेस गोलाकार इकाइयों को अलग-अलग प्रदर्शित कर सकता है। दो अस्पष्टीकृत "एमबी" लेबलों की तुलना करने के बजाय मापे गए ऑक्टेट और सटीक विज्ञापित या दस्तावेजित सीमा को रिकॉर्ड करें।

नियंत्रित वेरिएंट की तुलना करें

दो अधिकृत वेरिएंट बनाएं जो केवल आकार-प्रासंगिक सामग्री में भिन्न हों। प्रत्येक परिणाम के छोटे और बड़े क्रमबद्ध आकार और SMTP चरण को सुरक्षित रखें। एक उदाहरणात्मक जोड़ी में वही संक्षिप्त व्याख्यात्मक पाठ हो सकता है, जिसमें एक बड़े अनुलग्नक को एक अनुमोदित एक्सेस-नियंत्रित फ़ाइल लिंक द्वारा प्रतिस्थापित किया जा सकता है। यह न मानें कि फ़ाइल लिंक गोपनीय सामग्री के लिए उपयुक्त है या प्राप्तकर्ता के पास पहुंच है।

RFC 5321 अनुभाग 4.5.3.1 .7 को हेडर सहित कम से कम 64K ऑक्टेट के संदेश आकार के लिए समर्थन की आवश्यकता होती है। निम्नलिखित 100,000-ऑक्टेट सीमा उस प्रोटोकॉल न्यूनतम से ऊपर है, अनुशंसित प्रदाता सेटिंग नहीं।

एक काल्पनिक अंकगणितीय जाँच के लिए, मान लीजिए कि वही समापन बिंदु आकार 100000 का विज्ञापन करता है। एक अनुमानित 115,900-ऑक्टेट संदेश उस सीमा से 15,900 ऑक्टेट से अधिक है; अनुमानित 20,100-ऑक्टेट प्रतिस्थापन इसके नीचे 79,900 ऑक्टेट है। पहले को MAIL FROM पर अस्वीकार किया जा सकता है; दूसरा आगे की प्रक्रिया के लिए पात्र है लेकिन इसकी स्वीकृति की गारंटी नहीं है। इन संख्याओं का आविष्कार किया गया है, माप या निष्पादित SMTP परिणाम नहीं। वे किसी भी प्रदाता की अनुलग्नक सीमा का वर्णन नहीं करते हैं।

सबसे संकीर्ण प्रासंगिक बाधा को सुधारें

अस्वीकार करने वाले सिस्टम के मालिक से पूछें कि क्या आकार एक जानबूझकर सेवा सीमा है या संगठन-नियंत्रित सेटिंग है। यदि व्यावसायिक आवश्यकता को छोटी फ़ाइल से पूरा किया जा सकता है, तो संपूर्ण मेल सिस्टम पर सीमाएं बढ़ाने के बजाय उस मार्ग का उपयोग करें। यदि कोई सीमा परिवर्तन अधिकृत है, तो इसे लागू करने से पहले संसाधन खपत, मैलवेयर स्कैनिंग और डाउनस्ट्रीम संगतता पर विचार करें।

उसी स्थायी रूप से अस्वीकृत सामग्री को अपरिवर्तित रखते हुए पुनः प्रयास न करें। पुष्टि करें कि मूल को किसी अन्य हॉप पर या किसी अन्य प्राप्तकर्ता के लिए स्वीकार नहीं किया गया था, फिर पहले के प्रयास के स्पष्ट संबंध के साथ अनुमोदित प्रतिस्थापन सबमिट करें। अपना स्वयं का संदेश और कतार पहचानकर्ता सुरक्षित रखें। एक नया संदेश एक नया डिलीवरी इवेंट है, भले ही उपयोगकर्ता इसे उसी अनुलग्नक के रूप में मानता हो।

मापा संदेश आकार के साथ बंद करें, सही प्रयास की अस्वीकार सीमा और परिणाम की पहचान की गई। इनबॉक्स प्लेसमेंट और लिंक की गई सामग्री तक प्राप्तकर्ता की पहुंच को अलग-अलग जांच के रूप में छोड़ दें।

सीमा को वर्कअराउंड से अलग करें

• माप: केवल अनुलग्नक ही नहीं, बल्कि SIZE परिभाषा का उपयोग करके संपूर्ण क्रमबद्ध संदेश की गणना करें।
• पता लगाएँ: रिजेक्टिंग हॉप, कमांड स्टेज, डायग्नोस्टिक और लागू सीमा को कैप्चर करें।
• मरम्मत: एक स्वीकृत छोटा संदेश या एक्सेस-नियंत्रित वितरण विधि चुनें।
• दोबारा जांचें: प्रतिस्थापन आकार और प्रति प्राप्तकर्ता परिणाम रिकॉर्ड करें; यह न मानें कि प्रत्येक डाउनस्ट्रीम सीमा मेल खाती है।
• बंद करें: SMTP स्वीकृति से अलग से प्राप्तकर्ता की पहुंच की पुष्टि करें।