Gmail отклоняет электронные письма. Openspf.net не проходит тесты

У меня проблема с Gmail.

Это началось после того, как один из наших зараженных трояном компьютеров отправил спам на один день с нашего IP-адреса.

Мы исправили проблему, но попали в 3 черных списка. Мы это тоже исправили. Но, тем не менее, каждый раз, когда мы отправляем письмо в Gmail, сообщение отклоняется:

Поэтому я еще раз проверил руководство Google Bulk Sender и нашел ошибку в нашей записи SPF и исправил ее. Google говорит, что через некоторое время все должно стать хорошо, но этого не происходит. Уже прошло 3 недели, но мы все еще не можем отправлять письма в Gmail.

Наши настройки MX немного сложны, но не слишком сложны: у нас есть доменное имя delo-company.com, у него есть свой собственный mail @ 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" 

(Я установил ~ все только для целей тестирования, это было до этого)

Эти записи предназначены для нашего корпоративного сервера Exchange 2003 по адресу 82.209.198.147. Его имя в локальной сети s2.corp.delo-company.com, поэтому приветствия HELO / EHLO также s2.corp.delo-company.com.

Чтобы пройти проверку EHLO, мы также создали несколько записей в DNS delo-company.com:

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

Как я понимаю, SPF-проверки должны проходить следующим образом: наш сервер s2 подключается к MX получателя (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX говорит «ОК» и выполняет проверку SPF для HELO / EHLO. Это делает NSlookup для s2.corp.delo-company.com и получает вышеупомянутые DNS-записи. Записи TXT говорят, что s2.corp.delo-company.com должен быть только с IP 82.209.198.147. Так что это должно быть принято.

Затем наш сервер s2 сообщает RCPT FROM: Сервер Rcp.MX` тоже проверяет это. Значения одинаковы, поэтому они также должны быть положительными.

Может быть, есть также проверка rDNS, но я не уверен, что проверяется HELO или RCPT FROM.

Наш рекорд PTR для 82.209.198.147:

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

Для меня все выглядит хорошо, но в любом случае Gmail отклоняет все электронные письма.

Итак, я проверил MXtoolbox.com - он говорит, что все в порядке, я прошел http://www.kitterman.com/spf/validate.html Проверка Python, я сделал тест электронной почты 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, но он постоянно СДЕЛАН, независимо от того, какие записи SPF я делаю:

<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">

Я заполнил форму Gmail дважды, но ничего не происходит.

Мы не рассылаем спам, только электронные письма нашим клиентам. 2 или 3 раза мы делали массовые электронные письма (например, новогодние поздравления и рекламные акции) с адресов corp.delo-company.com, но все они соответствовали Руководству для массовых отправителей Gmail (я имею в виду SPF, открытые ретрансляции, приоритет: массовые и отписаться) теги). Таким образом, это не должно быть проблемой.

Пожалуйста, помогите мне. Что я делаю неправильно?

UPD: Я также пробовал тест Unlocktheinbox.com, и сервер также не проходит этот тест. Вот результат; вот еще один.

Я также пытался отправить электронную почту с этого сервера вручную через telnet, и все в порядке. Вот что я печатаю:

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

У Microsoft хороший волшебник. Может быть, это может предложить некоторые изменения?

http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

После 50 дней поисков решения Gmail начал принимать наши электронные письма. Они проходят в папку «Входящие» обычным способом (они не помечаются как спам).

Я не делал никаких изменений или каких-либо других попыток в течение последних 15 дней. Я не знаю, это бюрократия или некоторые алгоритмы, которые занимают так много времени, но, на мой взгляд, это заняло в 10 раз больше времени, чем следовало бы. Для нашей слабой безопасности достаточно 5 дней штрафа.

Кстати, unlocktheinbox.com сейчас проходит тест, тест openspf.org по-прежнему сообщает об ошибке. Похоже, моя ситуация слишком сложна для теста. Я бы исправил свои имена PTR и HELO, чтобы они соответствовали доменному имени.

Однако прошло уже неделю после того, как мы попросили нашего интернет-провайдера изменить PTR, и это все еще остается неизменным ... Еще один вопрос бюрократии.

Спасибо всем за помощь.

Может ли это быть потому, что вы используете только записи TXT, без записи типа SPF?

процитировать RFC 4408:

Признано, что текущая практика (с использованием записи TXT)
не является оптимальной, но это необходимо, поскольку существует ряд распространенных реализаций DNS-
сервера и преобразователя, которые не могут обрабатывать
новый тип RR. Схема с двумя записями обеспечивает прямой путь
к лучшему решению использования типа RR, зарезервированного для этой цели.

SPF-совместимое доменное имя ДОЛЖНО иметь SPF-записи обоих
типов RR . Совместимое доменное имя ДОЛЖНО иметь запись как минимум одного
типа. Если в домене есть записи обоих типов, они ДОЛЖНЫ иметь
идентичный контент.