Gmail odrzuca e-maile. Openspf.net nie przejdzie testów


11

Mam problem z Gmailem.

Zaczęło się po tym, jak jeden z naszych zainfekowanych trojanem komputerów wysłał spam na jeden dzień z naszego adresu IP.

Rozwiązaliśmy problem, ale znaleźliśmy się na 3 czarnych listach. Naprawiliśmy to również. Ale nadal za każdym razem, gdy wysyłamy wiadomość e-mail do Gmaila, wiadomość jest odrzucana:

Po raz kolejny sprawdziłem przewodnik Google Bulk Sender i znalazłem błąd w naszym rekordzie SPF i naprawiłem go. Google twierdzi, że po jakimś czasie wszystko powinno być w porządku, ale tak się nie dzieje. Minęły już 3 tygodnie, ale nadal nie możemy wysyłać e-maili do Gmaila.

Nasza konfiguracja MX jest nieco złożona, ale nie za bardzo: mamy nazwę domeny delo-company.com, ma własną pocztę @ delo-company.com (ta jest w porządku, ale problemy dotyczą nazwy subdomeny corp.delo-company.com).

Domena Delo-company.com ma kilka rekordów DNS dla subdomeny:

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" 

(Ustawiłem ~ wszystko tylko do celów testowych, wcześniej było wszystko)

Te rekordy dotyczą naszego korporacyjnego serwera Exchange 2003 na 82.209.198.147. Jego nazwa LAN to s2.corp.delo-company.com, więc pozdrowienia HELO / EHLO są również s2.corp.delo-company.com.

Aby zdać test EHLO, utworzyliśmy również niektóre wpisy w DNS firmy delo-company.com:

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

Jak rozumiem, weryfikacje SPF powinny być przekazywane w ten sposób: nasz serwer s2 łączy się z MX odbiorcy (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX mówi Ok i sprawdza SPF w HELO / EHLO. Robi NSlookup dla s2.corp.delo-company.com i pobiera powyższe rekordy DNS. Rekordy TXT mówią, że s2.corp.delo-company.com powinna pochodzić tylko z IP 82.209.198.147. Więc to powinno zostać przekazane.

Następnie nasz serwer s2 mówi, że RCPT OD: serwer Rcp.MX również to sprawdza. Wartości są takie same, więc powinny być również dodatnie.

Może jest też sprawdzanie rDNS, ale nie jestem pewien, co jest sprawdzane HELO lub RCPT OD.

Nasz rekord PTR dla 82.209.198.147 to:

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

Dla mnie wszystko wygląda dobrze, ale i tak wszystkie e-maile są odrzucane przez Gmaila.

Więc sprawdziłem MXtoolbox.com - mówi, że wszystko jest w porządku, zdałem http://www.kitterman.com/spf/validate.html sprawdzenie w Pythonie, zrobiłem test poczty e-mail na 25port.com. Również w porządku:

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>

Sprawdziłem również za pomocą spf-test@openspf.net, ale ciągle się NIE udaje, bez względu na to, jakie rekordy SPF wykonuję:

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

Wypełniłem formularz Gmaila dwa razy, ale nic się nie dzieje.

Nie wysyłamy spamu, tylko e-maile dla naszych klientów. 2 lub 3 razy robiliśmy masowe wiadomości e-mail (takie jak życzenia noworoczne i promocje sprzedaży) z adresów corp.delo-company.com, ale wszystkie one były zgodne z Przewodnikiem masowego nadawcy Gmaila (mam na myśli SPF, przekaźniki otwarte, pierwszeństwo: luzem i rezygnacja z subskrypcji tagi). Nie powinno to stanowić problemu.

Proszę pomóż mi. Co ja robię źle?

UPD: Próbowałem również testu Unlocktheinbox.com i serwer również nie przejdzie tego testu. Oto wynik; oto jeszcze jeden.

Próbowałem również ręcznie wysłać wiadomość e-mail z tego serwera przez telnet i wszystko jest w porządku. Oto co piszę:

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

I to właśnie otrzymuję:

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

Czy próbowałeś zmienić rekord TXT z ip4:82.209.198.147na mx? Podobnie jak ty, nie widzę błędu, ale warto spróbować.
James O'Gorman

Próbowałem MX dla Corp: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: Adres odbiorcy odrzucony: Testy SPF: Mail-From Result = "permerror" : Mail From = "supruniuk-p@corp.delo-company.com" HELO name = "s2.corp.delo-company.com" HELO Result = "softfail" Remote IP = "82.209.198.147">
pablomedok

I MX dla s2.corp. <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: Adres odbiorcy odrzucony: Testy SPF: 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 ”> Oba są Softfail.
pablomedok

Czy masz DSN (powiadomienie o stanie dostawy) dla odesłanej wiadomości? Czy możesz to opublikować? Nie mówisz, czy wiesz na pewno, że SPF powoduje, że Gmail odrzuca Twój e-mail.
kls

Mogę ci to dać, ale jest po rosyjsku: Сообщение не было получено одним или несколькими получателями. Тема: test 22 Отправлено: 03.03.2012 00:07 Сообщение не получили следующие получатели: pablomedok@gmail.com на 03.03.2012 0:08 Ошибка связи с сервером электронной почты получателя ďî протоколу SMTP. Обратитесь к системному администратору. <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] Nasz system wykrył niezwykłą częstość> Wiadomość przerywa się po pierwszym wierszu. Widziałem dzienniki, potem jest
ZAKOŃCZENIE

Odpowiedzi:



2

Po 50 dniach próbowania i szukania rozwiązania Gmail zaczął akceptować nasze e-maile. Przechodzą do skrzynki odbiorczej w normalny sposób (nie są oznaczane jako spam).

W ciągu ostatnich 15 dni nie wprowadziłem żadnych zmian ani żadnych innych prób. Nie wiem, czy to biurokracja czy jakieś algorytmy, które trwają tak długo, ale moim zdaniem zajęło to 10 razy dłużej niż powinno. Wystarczy 5 dni kary za nasze słabe bezpieczeństwo.

Nawiasem mówiąc, unlocktheinbox.com przechodzi teraz test, test openspf.org wciąż zgłasza awarię. Wygląda na to, że moja sytuacja jest zbyt skomplikowana do testu. Naprawiłbym moje nazwy PTR i HELO, aby pasowały do ​​nazwy domeny.

Jednak minął już tydzień po tym, jak poprosiliśmy naszego dostawcę usług internetowych o zmianę PTR i nadal pozostaje on niezmieniony ... Jeszcze jedna kwestia biurokracji.

Dzięki za pomoc wszystkich.


1

może być tak, ponieważ używasz tylko rekordów TXT, bez rekordu typu SPF?

zacytować RFC 4408:

Uznaje się, że obecna praktyka (przy użyciu rekordu TXT)
nie jest optymalna, ale jest to konieczne, ponieważ istnieje wiele
implementacji serwera DNS i resolvera, które nie są w stanie obsłużyć
nowego typu RR. Schemat z dwoma rekordami zapewnia ścieżkę
do przodu w celu lepszego rozwiązania zastosowania typu RR zarezerwowanego do tego celu.

Nazwa domeny zgodna z SPF POWINNA mieć rekordy SPF obu
typów RR . Zgodna nazwa domeny MUSI mieć rekord co najmniej jednego
typu. Jeśli domena ma rekordy obu typów, MUSZĄ mieć
identyczną treść.


Nasz hostingowy panel sterowania nie obsługuje typu rekordu SPF (tylko a, aaaa, cname, ns, mx, srv, txt). Ale to nie był wcześniej problem. Po prostu nie rozumiem, dlaczego niektóre usługi przechodzą, a inne zawodzą. A dlaczego ręczne wysyłanie wiadomości za pośrednictwem Telnet było udane z tego samego serwera? Wygląda na to, że coś jest nie tak z ustawieniami Exchange.
pablomedok

1
Dla wszystkich, którzy czytają to teraz, należy pamiętać, że użycie SPFtypu RR zostało wycofane w 2014 r TXT. Use . Szczegółowe informacje można znaleźć w RFC 7208 .
mc0e
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.