जीमेल ईमेल खारिज कर देता है। Openspf.net परीक्षण विफल करता है


11

मुझे जीमेल की समस्या है।

यह हमारे ट्रोजन संक्रमित पीसी में से एक के बाद हमारे आईपी पते से एक दिन के लिए स्पैम भेजे जाने के बाद शुरू हुआ।

हमने समस्या को ठीक कर दिया है, लेकिन हम 3 ब्लैक लिस्ट में शामिल हो गए हैं। हमने वह भी तय कर लिया है। लेकिन फिर भी हर बार जब हम जीमेल पर एक ईमेल भेजते हैं तो संदेश अस्वीकृत हो जाता है:

इसलिए मैंने एक बार फिर से Google Bulk Sender की मार्गदर्शिका की जाँच की और हमारे SPF रिकॉर्ड में त्रुटि पाई और उसे ठीक कर दिया। Google का कहना है कि कुछ समय बाद सब कुछ ठीक हो जाना चाहिए, लेकिन ऐसा नहीं होता है। 3 सप्ताह पहले ही बीत चुके हैं लेकिन हम अभी भी जीमेल पर ईमेल नहीं भेज सकते हैं।

हमारा MX सेटअप थोड़ा जटिल है, लेकिन बहुत अधिक नहीं: हमारे पास एक डोमेन नाम delo-company.com है, इसका अपना मेल @ delo-company.com है (यह एक ठीक है, लेकिन समस्याएं उप-डोमेन नाम के साथ हैं corp.delo-company.com)।

Delo-company.com डोमेन में उपडोमेन के लिए कई DNS रिकॉर्ड हैं:

corp                     A     82.209.198.147
corp                     MX    20 corp.delo-company.com
corp.delo-company.com    TXT   "v=spf1 ip4:82.209.198.147 ~all" 

(मैं परीक्षण के प्रयोजनों के लिए ~ सब सेट करता हूं, यह उससे पहले ही था)

ये रिकॉर्ड हमारे कॉर्पोरेट एक्सचेंज 2003 सर्वर के लिए 82.209.198.147 पर हैं। इसका LAN नाम s2.corp.delo-company.com है, इसलिए इसका HELO / EHLO अभिवादन भी s2.corp.delo-company.com है।

EHLO चेक को पास करने के लिए हमने delo-company.com के DNS में कुछ रिकॉर्ड भी बनाए हैं:

s2.corp                  A     82.209.198.147
s2.corp.delo-company.com TXT   "v=spf1 ip4:82.209.198.147 ~all" 

जैसा कि मैं समझता हूं कि एसपीएफ़ सत्यापन इस तरह से पारित किया जाना चाहिए: आउट सर्वर s2 रिसीवर के MX (Rcp.MX) से जुड़ता है: EHLO s2.corp.delo-company.com Rcp.MX ठीक कहता है, और SPF को HELO / का चेक बनाता है। EHLO। यह s2.corp.delo-company.com के लिए NSlookup करता है और उपरोक्त DNS-रिकॉर्ड प्राप्त करता है। TXT रिकॉर्ड कहता है कि s2.corp.delo-company.com केवल IP 82.209.198.147 से होना चाहिए। इसलिए इसे पारित किया जाना चाहिए।

तब हमारे s2 सर्वर का कहना है कि RCPT FROM: Rcp.MX` सर्वर इसे भी चेक करता है। मूल्य समान हैं इसलिए उन्हें भी सकारात्मक होना चाहिए।

शायद वहाँ भी एक rDNS चेक है, लेकिन मुझे यकीन नहीं है कि हेलो या RCPT FROM की जाँच क्या है।

82.209.198.147 के लिए हमारा PTR रिकॉर्ड है:

147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.

मेरे लिए सब कुछ ठीक लग रहा है, लेकिन वैसे भी सभी ईमेल जीमेल द्वारा खारिज कर दिए जाते हैं।

तो, मैंने MXtoolbox.com की जाँच की है - यह कहता है कि सब कुछ ठीक है, मैंने http://www.kitterman.com/spf/validate.html अजगर जांच की, मैंने 25port.com ईमेल परीक्षण किया। यह ठीक है, भी:

Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <check-auth@verifier.port25.com>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <supruniuk-p@corp.delo-company.com>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass header.From=supruniuk-p@corp.delo-company.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_001_01CCF89E.BE02A069"
Subject: test
Date: Fri, 2 Mar 2012 21:03:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <4C9EB1DB67831A428B2E14052F4A418707E1FF@s2.corp.delo-company.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <supruniuk-p@corp.delo-company.com>
To: <check-auth@verifier.port25.com>

मैंने spf-test@openspf.net के साथ भी जांच की, लेकिन यह हर समय विफल रहता है, कोई फर्क नहीं पड़ता कि एसपीएफ रिकॉर्ड क्या बनाते हैं:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <spf-test@openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p@corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

मैंने दो बार जीमेल फॉर्म भरा है, लेकिन कुछ नहीं होता है।

हम अपने ग्राहकों के लिए केवल ईमेल नहीं भेजते हैं। Corp.delo-company.com पतों से 2 या 3 बार हमने बड़े पैमाने पर ईमेल (जैसे न्यू ईयर ग्रीटिंग्स और सेल्स प्रोमो) किए, लेकिन वे सभी जहां जीमेल बल्क सेंडर के गाइड (मेरा मतलब एसपीएफ, ओपन रिले, प्रीडेन्स, बल्क और अनसब्सक्राइब) का अनुपालन करते हैं टैग)। तो, यह एक समस्या नहीं होनी चाहिए।

कृपया मेरी मदद करें। मैं क्या गलत कर रहा हूं?

UPD: मैंने Unlocktheinbox.com परीक्षण की भी कोशिश की और सर्वर भी इस परीक्षण को विफल करता है। यहाँ परिणाम है; यहाँ एक और है।

मैंने उस सर्वर से मैन्युअल रूप से टेलनेट के माध्यम से ईमेल भेजने की कोशिश की और सब कुछ ठीक है। यहाँ मैं टाइप कर रहा हूँ:

220 mx.google.com ESMTP g15si4811326anb.170
HELO s2.corp.delo-company.com
250 mx.google.com at your service
MAIL FROM: <supruniuk-p@corp.delo-company.com>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <pablomedok@gmail.com>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test
.
250 2.0.0 OK 1330795021 g15si4811326anb.170
QUIT
221 2.0.0 closing connection g15si4811326anb.170

और यही मुझे मिलता है:

Delivered-To: pablomedok@gmail.com
Received: by 10.227.132.73 with SMTP id a9csp96864wbt;
        Sat, 3 Mar 2012 09:17:02 -0800 (PST)
Received: by 10.101.128.12 with SMTP id f12mr4837125ann.49.1330795021572;
        Sat, 03 Mar 2012 09:17:01 -0800 (PST)
Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (s2.corp.delo-company.com. [82.209.198.147])
        by mx.google.com with SMTP id g15si4811326anb.170.2012.03.03.09.15.59;
        Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Received-SPF: pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) client-ip=82.209.198.147;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) smtp.mail=supruniuk-p@corp.delo-company.com
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <4f52520c.0f53640a.77bf.5626SMTPIN_ADDED@mx.google.com>
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test

क्या आपने TXT रिकॉर्ड को बदलने की कोशिश की ip4:82.209.198.147है mx? आपकी तरह, मुझे कोई त्रुटि दिखाई नहीं दे रही है, लेकिन वह कोशिश करने लायक हो सकती है।
जेम्स ओ'गॉर्मन

कॉर्प के लिए कोशिश की mx: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: प्राप्तकर्ता का पता अस्वीकृत: SPF टेस्ट: मेल-रिजल्ट = "permerror" : Mail From = "supruniuk-p@corp.delo-company.com" HELO नाम = "s2.corp.delo-company.com" HELO परिणाम = "softfail" दूरस्थ IP = "82.209.198.147">
pablomedok

और s2.corp के लिए एमएक्स। <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: प्राप्तकर्ता का पता अस्वीकृत: SPF टेस्ट: मेल-रिजल्ट से = "softfail": मेल से = " supruniuk-p@corp.delo-company.com "हेलो नाम =" s2.corp.delo-company.com "हेलो परिणाम =" सॉफ्टफेल "रिमोट आईपी =" 82.209.198.147 "> दोनों सॉफ्टफेल हैं।
पेल्बोमेडोक

क्या आपके पास बाउंस किए गए संदेश के लिए DSN (डिलीवरी स्टेटस नोटिफिकेशन) है? क्या आप इसे पोस्ट कर सकते हैं? आप यह नहीं कहते कि क्या आप जानते हैं कि SPF यही कारण है कि Gmail आपके ईमेल को अस्वीकार कर रहा है।
मार्लस

मैं इसे आपको दे सकता हूं, लेकिन यह रूसी में है: Сообниение не было получено одним или несколькими получателями। Тема: test 22 Отправлено: 03.03.2012 0:07 Сообщение не получили следующие получатели: pablomitok@gmail.com पर: 03.03.2012 0:08 Ошибка связи с сведом। Обратитесь к системному администратору। <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] हमारी प्रणाली ने पहली पंक्ति के बाद संदेश के टूटने की असामान्य दर का पता लगाया है। मैंने लॉग देखे, इसके बाद QUIT
pablomedok

जवाबों:



2

50 दिनों की कोशिश और समाधान के लिए जाने के बाद, जीमेल ने हमारे ईमेल स्वीकार करना शुरू कर दिया। वे सामान्य तरीके से इनबॉक्स पास करते हैं (उन्हें स्पैम के रूप में टैग नहीं किया जाता है)।

मैंने पिछले 15 दिनों के दौरान कोई बदलाव या कोई अन्य प्रयास नहीं किया। मुझे नहीं पता कि यह नौकरशाही या कुछ एल्गोरिदम है जो इतने लंबे समय तक ले जाते हैं, लेकिन मेरे दिमाग में इसे जितना होना चाहिए उससे 10 गुना अधिक समय लगा। हमारी कमजोर सुरक्षा के लिए 5 दिन की सजा पर्याप्त है।

वैसे, अब unlocktheinbox.com टेस्ट पास करता है, Openpf.org टेस्ट अभी भी एक विफलता की रिपोर्ट कर रहा है। ऐसा लगता है कि परीक्षण के लिए मेरी स्थिति बहुत जटिल है। मैं डोमेन नाम से मिलान करने के लिए अपने पीटीआर और हेलो नामों को ठीक करूंगा।

हालाँकि, हमें अपने ISP द्वारा PTR को बदलने के लिए कहने के एक सप्ताह बाद ही शुरू हो गया था और यह अभी भी अपरिवर्तित है ... एक और नौकरशाही का मुद्दा।

सभी की मदद के लिए धन्यवाद।


1

ऐसा इसलिए हो सकता है क्योंकि आप एसपीएफ प्रकार के रिकॉर्ड के बिना केवल TXT रिकॉर्ड का उपयोग कर रहे हैं?

RFC 4408 उद्धृत करने के लिए:

यह माना जाता है कि वर्तमान अभ्यास (एक TXT रिकॉर्ड का उपयोग करना)
इष्टतम नहीं है, लेकिन यह आवश्यक है क्योंकि
सामान्य उपयोग में कई DNS सर्वर और रिज़ॉल्वर कार्यान्वयन हैं जो
नए आरआर प्रकार को संभाल नहीं सकते हैं । दो-रिकॉर्ड-प्रकार योजना
इस उद्देश्य के लिए आरक्षित आरआर प्रकार का उपयोग करने के बेहतर समाधान के लिए एक आगे का रास्ता प्रदान करती है ।

एक SPF- अनुरूप डोमेन नाम SHOULD में दोनों RR
प्रकार के SPF रिकॉर्ड होते हैं। आज्ञाकारी डोमेन नाम MUST में कम से कम एक
प्रकार का रिकॉर्ड होना चाहिए । यदि किसी डोमेन में दोनों प्रकार के रिकॉर्ड हैं, तो उनके पास
समान सामग्री होनी चाहिए ।


हमारा होस्टिंग कंट्रोल पैनल SPF रिकॉर्ड प्रकार (केवल a, aaaa, cname, ns, mx, srv, txt) का समर्थन नहीं करता है। लेकिन वह पहले कोई समस्या नहीं थी। मैं अभी समझ नहीं पा रहा हूं, कुछ सेवाएं क्यों गुजरती हैं और कुछ अन्य विफल हो जाती हैं। और टेलनेट के माध्यम से भेजने वाला मैनुअल संदेश उसी सर्वर से सफल क्यों था? लगता है कि एक्सचेंज सेटिंग्स में कुछ गड़बड़ है।
पेल्बोमेडोक

1
इसे पढ़ने वाले किसी भी व्यक्ति के लिए, इस बात का ध्यान रखें कि SPF2014 में RR प्रकार का उपयोग किया गया था TXT। देखें आरएफसी 7208 जानकारी के लिए।
mc0e
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.