संक्षेप में: वैध ईमेल रद्दी फ़ोल्डर में ईओपी (एक्सचेंज ऑनलाइन प्रोटेक्शन) के रूप में ईमेल संदेशों को रद्दी (एससीएल 5) और एसपीएफ-असफल के रूप में उतार रहे हैं। यह सभी बाहरी डोमेन (जैसे gmail.com/hp.com/microsoft.com) पर क्लाइंट के डोमेन (contoso.com) के साथ होता है।
पृष्ठभूमि की जानकारी:
हम मेलबॉक्स को Office 365 (Exchange Online) पर माइग्रेट करने की शुरुआत में हैं। यह हाइब्रिड परिनियोजन / रिच-सह-अस्तित्व कॉन्फ़िगरेशन है, जहां:
- ऑन-प्रिमाइसेस = एक्सचेंज 2003 (लिगेसी) और 2010 (हाइब्रिड परिनियोजन के लिए स्थापित)
- ऑफ-प्रिमाइसेस = ऑफिस 365 (ऑनलाइन एक्सचेंज)
- EOP को SPF जाँच के लिए कॉन्फ़िगर किया गया है।
- एमएक्स रिकॉर्ड ऑन-प्रिमाइसेस को इंगित कर रहे हैं क्योंकि हमने ऑन-प्रिमाइसेस से एक्सचेंज ऑनलाइन तक सभी मेलबॉक्सों को माइग्रेट करने का काम पूरा नहीं किया है।
समस्या तब होती है जब बाहरी उपयोगकर्ता संगठन में Office 365 मेलबॉक्स को ईमेल भेजता है (मेल प्रवाह: बाहरी -> मेल गेटवे -> ऑन-प्रिमाइसेस मेल सर्वर -> EOP -> Office 365), EOP एक SPF लुकअप और हार्ड / सॉफ्ट कार्य करता है मेल गेटवे के बाहरी सामना करने वाले आईपी पते के साथ संदेशों को विफल करना जहां से उसे मेल प्राप्त हुआ।
(ऑन-प्रिमाइसेस मेलबॉक्स इस समस्या को नहीं दिखाते हैं, केवल मेलबॉक्स Office 365 में माइग्रेट करते हैं।)
एक उदाहरण:
उदाहरण 1: Microsoft से O365 तक
Authentication-Results: spf=fail (sender IP is 23.1.4.9)
smtp.mailfrom=microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.outlook.com; client-ip=23.1.4.9;
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5
उदाहरण 2: HP से O365 तक
Authentication-Results: spf=none (sender IP is 23.1.4.9)
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none
(message not signed) header.d=none; Received-SPF: None
(protection.outlook.com: hp.com does not designate permitted sender hosts)
X-MS-Exchange-Organization-SCL: 5
उदाहरण 3: Gmail से O365 तक
Authentication-Results: spf=softfail (sender IP is 23.1.4.9)
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com;
dkim=fail (signature did not verify) header.d=gmail.com;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
gmail.com discourages use of 23.1.4.9 as permitted sender)
X-MS-Exchange-Organization-SCL: 5
X-Forefront-Antispam-Report वाले संदेश शीर्षलेखों के लिए, http://pastebin.com/sgjQETzM देखें
नोट: 23.1.4.9 ऑन-प्रिमाइसेस हाइब्रिड Exchange 2010 सर्वर कनेक्टर का सार्वजनिक IP पता Exchange Online करने के लिए है।
हाइब्रिड परिनियोजन के सह-अस्तित्व चरण के दौरान ईओपी द्वारा कबाड़ के रूप में चिह्नित किए जाने से हम बाहरी ईमेलों को कैसे रोकते हैं?
[2015-12-12 अपडेट]
यह समस्या Office 365 समर्थन (एस्केलेटेड / बैकेंड टीम) द्वारा तय की गई थी क्योंकि इसका हमारी सेटिंग्स से कोई लेना-देना नहीं है।
हमें निम्नलिखित सुझाव दिए गए थे:
- ईओपी अनुमति सूची में सार्वजनिक आईपी को श्वेत सूची दें (कोशिश की गई। इससे कोई फायदा नहीं हुआ।)
- हमारे डोमेन के लिए SPF रिकॉर्ड जोड़ें: "v = spf1 ip4: XXX.XXX.XXX.XXX ip4: YYY.YYY.YYY.YYY में शामिल हैं: spf.protection.outlook.com -all" (यह सुझाव मान्य नहीं है) जैसा कि EOP को हमारे SMTP IP पते के खिलाफ gmail.com की जाँच नहीं करनी चाहिए क्योंकि यह gmail.com के SPF रिकॉर्ड में निर्दिष्ट नहीं है। ऐसा नहीं लगता है कि SPF काम करता है।)
- सुनिश्चित करें कि टीएलएस सक्षम है (नीचे देखें)
मुख्य भाग तीसरा बिंदु है। "अगर टीएलएस सक्षम नहीं है, तो स्थानीय एक्सचेंज से आने वाले ईमेल को आंतरिक / विश्वास ईमेल के रूप में चिह्नित नहीं किया जाएगा, और ईओपी सभी रिकॉर्डों की जांच करेगा।"
समर्थन ने हमारे मेल हेडर से एक टीएलएस अंक निर्धारित किया है:
- एक्स-एमएस-एक्सचेंज-ऑर्गेनाइज़ेशन-ऑथर्स: बेनामी
यह इंगित करता है कि ईएलओ को ईमेल मिलने पर टीएलएस सक्षम नहीं था। ईओपी ने आने वाले ईमेल को विश्वास ईमेल के रूप में नहीं माना। सही एक जैसा होना चाहिए:
- एक्स-एमएस-एक्सचेंज-ऑर्गनाइजेशन-ऑथर्स: इंटरनल
हालाँकि, यह हमारी सेटिंग के कारण नहीं था; समर्थन व्यक्ति ने हमें यह सुनिश्चित करने में मदद की कि हमारे एक्सचेंज 2010 हाइब्रिड सर्वर से क्रिया SMTP लॉग की पुष्टि करके हमारी सेटिंग्स सही थीं।
लगभग उसी समय, उनकी बैकएंड टीम ने हमें यह बताए बिना समस्या तय की कि वास्तव में इसका क्या कारण है (दुर्भाग्य से)।
उन्होंने इसे ठीक करने के बाद, हमने पाया कि संदेश शीर्षकों में नीचे के रूप में कुछ महत्वपूर्ण बदलाव थे।
Exchange 2003 से Office 365 तक आंतरिक-उत्पत्ति वाले मेल के लिए:
एक्स-एमएस-एक्सचेंज-ऑर्गेनाइज़ेशन-ऑथर्स: इंटरनल (यह "बेनामी" था)
SCL = -1 (यह SCL = 5 था)
- प्राप्त-एसपीएफ: सॉफ्टफेल (यह वही था)
और बाहरी मेल (जैसे gmail.com) से ऑफिस 365 तक:
एक्स-एमएस-एक्सचेंज-ऑर्गनाइजेशन-ऑथर्स: एनॉनिमस (यह वही था)
SCL = 1 (यह SCL = 5 था)
प्राप्त-एसपीएफ: सॉफ्टफेल (यह वही था)
हालाँकि SPF चेक अभी भी gmail.com (बाहरी) से लेकर ऑफिस 365 तक के लिए सॉफ्ट-फेल है, समर्थन व्यक्ति ने कहा कि यह ठीक है, और सभी मेल्स जंक फ़ोल्डर के बजाय इनबॉक्स में जाएंगे।
एक साइड नोट के रूप में, समस्या निवारण के दौरान, बैकएंड टीम को एक प्रतीत होता है कि मामूली विन्यास समस्या थी - हमारे पास हमारे इनबाउंड कनेक्टर (यानी सार्वजनिक रूप से एक्सचेंज 2010 हाइब्रिड सर्वर का सार्वजनिक आईपी) से हमारे आईपी अनुमति सूची में परिभाषित किया गया था (किसी अन्य Office 365 समर्थन द्वारा सुझाया गया) समस्या निवारण कदम के रूप में व्यक्ति)। वे जानते हैं कि हमें ऐसा करने की आवश्यकता नहीं है और वास्तव में ऐसा करने से रूटिंग के मुद्दे पैदा हो सकते हैं। उन्होंने टिप्पणी की कि प्रारंभिक पास पर ईमेल को स्पैम के रूप में चिह्नित नहीं किया जा रहा था, इसलिए यहां एक संभावित मुद्दा भी था। फिर हमने IP अनुमति सूची से IP को हटा दिया। (हालाँकि, IP अनुमति सूची सेटिंग होने से पहले स्पैम समस्या मौजूद थी। हमें नहीं लगता था कि अनुमति सूची का कारण था।)
निष्कर्ष में, "यह ईओपी तंत्र होना चाहिए," समर्थन व्यक्ति ने कहा। इसलिए, पूरी बात उनके तंत्र के कारण होनी चाहिए।
रुचि रखने वाले किसी व्यक्ति के लिए, उनके किसी सहायक व्यक्ति के साथ समस्या निवारण धागा यहाँ देखा जा सकता है: https://community.office365.com/en-us/f/156/t/403396