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: <[email protected]>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <[email protected]>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <[email protected]>)
Authentication-Results: verifier.port25.com; spf=pass [email protected]
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) [email protected]
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass [email protected]
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: <[email protected]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <[email protected]>
To: <[email protected]>

Sprawdziłem również za pomocą [email protected], 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 <[email protected]>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="[email protected]" 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: <[email protected]>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <[email protected]>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: [email protected]
To: Pavel <[email protected]>
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: [email protected]
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: <[email protected]>
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 [email protected] 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 [email protected] designates 82.209.198.147 as permitted sender) [email protected]
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <[email protected]>
From: [email protected]
To: Pavel <[email protected]>
Subject: Test 28

This is telnet test
email spam gmail spf pablomedok
źródło
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 <[email protected]>: Adres odbiorcy odrzucony: Testy SPF: Mail-From Result = "permerror" : Mail From = "[email protected]" 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 <[email protected]>: Adres odbiorcy odrzucony: Testy SPF: Mail-From Result = "softfail": Mail From = " [email protected] „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 Сообщение не получили следующие получатели: [email protected] на 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.

pablomedok
źródło
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ść.

Waleed Hamra
źródło
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