Gmail rifiuta le email. Openspf.net non supera i test


11

Ho un problema con Gmail.

È iniziato dopo che uno dei nostri PC infetti da trojan ha inviato spam per un giorno dal nostro indirizzo IP.

Abbiamo risolto il problema, ma siamo entrati in 3 liste nere. Abbiamo risolto anche questo. Ma ogni volta che inviamo un'email a Gmail il messaggio viene rifiutato:

Quindi ho ricontrollato la guida di Google Bulk Sender, ho trovato un errore nel nostro record SPF e l'ho risolto. Google dice che tutto dovrebbe andare bene dopo qualche tempo, ma ciò non accade. Sono già trascorse 3 settimane ma non possiamo ancora inviare e-mail a Gmail.

La nostra configurazione MX è un po 'complessa, ma non troppo: abbiamo un nome di dominio delo-company.com, ha la sua mail @ delo-company.com (questa va bene, ma i problemi sono con il nome del sottodominio corp.delo-company.com).

Il dominio Delo-company.com ha diversi record DNS per il sottodominio:

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" 

(Ho impostato ~ tutto solo a scopo di test, prima di allora)

Questi record sono per il nostro server Exchange 2003 aziendale al 82.209.198.147. Il suo nome LAN è s2.corp.delo-company.com, quindi i suoi saluti HELO / EHLO sono anche s2.corp.delo-company.com.

Per passare il controllo EHLO abbiamo anche creato alcuni record nel DNS di delo-company.com:

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

A quanto ho capito, le verifiche SPF devono essere passate in questo modo: Out server s2 si collega a MX del destinatario (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX dice Ok e fa il controllo SPF di HELO / EHLO. Fa NSlookup per s2.corp.delo-company.com e ottiene i record DNS sopra. I record TXT indicano che s2.corp.delo-company.com dovrebbe essere solo dall'IP 82.209.198.147. Quindi dovrebbe essere passato.

Quindi il nostro server s2 dice RCPT FROM: anche il server Rcp.MX` lo controlla. I valori sono gli stessi, quindi dovrebbero anche essere positivi.

Forse c'è anche un controllo rDNS, ma non sono sicuro di cosa sia stato verificato HELO o RCPT FROM.

Il nostro record PTR per 82.209.198.147 è:

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

Per me tutto sembra a posto, ma comunque tutte le e-mail vengono rifiutate da Gmail.

Quindi, ho controllato MXtoolbox.com - dice che tutto va bene, ho superato http://www.kitterman.com/spf/validate.html Controllo Python, ho fatto il test e-mail di 25port.com. Va anche bene:

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>

Ho anche controllato con spf-test@openspf.net, ma FAIL continuamente, indipendentemente dai record SPF che faccio:

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

Ho compilato due volte il modulo Gmail, ma non succede nulla.

Non inviamo spam, solo e-mail per i nostri clienti. 2 o 3 volte abbiamo inviato e-mail di massa (come i saluti di Capodanno e le promozioni di vendita) dagli indirizzi corp.delo-company.com, ma tutte conformi alla Guida del mittente di Gmail Bulk (intendo SPF, Open Relays, Precedence: Bulk e Unsubscribe tag). Quindi, questo non dovrebbe essere un problema.

Mi aiuti per favore. Che cosa sto facendo di sbagliato?

UPD: Ho anche provato il test Unlocktheinbox.com e anche il server ha fallito questo test. Ecco il risultato; eccone uno in più.

Ho anche provato a inviare e-mail da quel server manualmente tramite telnet e tutto va bene. Ecco cosa scrivo:

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

E questo è quello che ottengo:

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

Hai provato a cambiare il record TXT da ip4:82.209.198.147a mx? Come te, non riesco a vedere un errore, ma potrebbe valere la pena provarlo.
James O'Gorman,

Provato mx per corp: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: indirizzo del destinatario rifiutato: test SPF: Mail-From Result = "permerror" : Mail From = "supruniuk-p@corp.delo-company.com" HELO name = "s2.corp.delo-company.com" HELO Result = "softfail" IP remoto = "82.209.198.147">
pablomedok

E mx per s2.corp. <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: indirizzo del destinatario rifiutato: test SPF: Mail-From Result = "softfail": Mail From = " supruniuk-p@corp.delo-company.com "HELO name =" s2.corp.delo-company.com "HELO Result =" softfail "IP remoto =" 82.209.198.147 "> Entrambi sono Softfail.
pablomedok,

Hai un DSN (Notifica sullo stato della consegna) per un messaggio rimbalzato? Puoi pubblicarlo? Non dici se sai con certezza che SPF è il motivo per cui Gmail sta rifiutando la tua email.
kls

Posso dartelo, ma è in russo: Сообщение не было получено одним или несколькими получателями. Тема: Test 22 Отправлено: 03.03.2012 00:07 Сообщение не получили следующие получатели: pablomedok@gmail.com на 03.03.2012 00:08 Ошибка связи с сервером электронной почты получателя по протоколу SMTP. Обратитесь к системному администратору. <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] Il nostro sistema ha rilevato una frequenza insolita di> Il messaggio si interrompe dopo la prima riga. Ho visto i registri, dopo di che c'è QUIT
pablomedok

Risposte:



2

Dopo 50 giorni di tentativi e ricerche su Google per una soluzione, Gmail ha iniziato ad accettare le nostre e-mail. Passano alla posta in arrivo in modo normale (non sono contrassegnati come spam).

Non ho apportato modifiche o altri tentativi negli ultimi 15 giorni. Non so se è la burocrazia o alcuni algoritmi che impiegano così tanto tempo, ma a mio avviso ci sono voluti 10 volte di più di quanto dovrebbe. Una penalità di 5 giorni per la nostra debole sicurezza è sufficiente.

A proposito, unlocktheinbox.com ora supera il test, il test openspf.org sta ancora segnalando un errore. Sembra che la mia situazione sia troppo complessa per il test. Vorrei correggere i miei nomi PTR e HELO in modo che corrispondessero al nome di dominio.

Tuttavia, ci è voluta già una settimana dopo che abbiamo chiesto al nostro ISP di cambiare PTR ed è rimasto invariato ... Ancora un problema di burocrazia.

Grazie per l'aiuto di tutti.


1

potrebbe essere perché stai utilizzando solo record TXT, senza un record di tipo SPF?

per citare RFC 4408:

È noto che la pratica corrente (utilizzando un record TXT)
non è ottimale, ma è necessaria perché ci sono un certo numero di
implementazioni di server DNS e resolver di uso comune che non sono in grado di gestire
il nuovo tipo RR. Lo schema a due record fornisce un percorso diretto
alla soluzione migliore dell'utilizzo di un tipo RR riservato a questo scopo.

Un nome di dominio conforme a SPF DOVREBBE avere record SPF di entrambi i
tipi RR . Un nome di dominio conforme DEVE avere un record di almeno un
tipo. Se un dominio ha record di entrambi i tipi, DEVE avere
un contenuto identico.


Il nostro pannello di controllo dell'hosting non supporta il tipo di record SPF (solo a, aaaa, cname, ns, mx, srv, txt). Ma questo non era un problema prima. Non riesco proprio a capire perché alcuni servizi passano e altri falliscono. E perché l'invio manuale di messaggi tramite Telnet è riuscito dallo stesso server? Sembra che ci sia qualcosa di sbagliato nelle impostazioni di Exchange.
pablomedok

1
Per chiunque legga questo ora, tieni presente che l'uso del SPFtipo RR è stato deprecato nel 2014. use TXT. Vedi RFC 7208 per i dettagli.
MC0e
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.