Gmail rechaza los correos electrónicos. Openspf.net falla las pruebas

Tengo un problema con Gmail.

Comenzó después de que una de nuestras PC infectadas con troyanos envió spam durante un día desde nuestra dirección IP.

Hemos solucionado el problema, pero nos metimos en 3 listas negras. También lo hemos arreglado. Pero aún así cada vez que enviamos un correo electrónico a Gmail, el mensaje es rechazado:

Así que revisé la guía de Google Bulk Sender una vez más y encontré un error en nuestro registro SPF y lo solucioné. Google dice que todo debería estar bien después de un tiempo, pero esto no sucede. Ya pasaron 3 semanas pero aún no podemos enviar correos electrónicos a Gmail.

Nuestra configuración MX es un poco compleja, pero no demasiado: tenemos un nombre de dominio delo-company.com, tiene su propio correo @ delo-company.com (este está bien, pero los problemas están con el nombre del subdominio corp.delo-company.com).

El dominio Delo-company.com tiene varios registros DNS para el subdominio:

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" 

(Configuré ~ todo solo para fines de prueba, fue -todos antes de eso)

Estos registros son para nuestro servidor corporativo Exchange 2003 en 82.209.198.147. Su nombre de LAN es s2.corp.delo-company.com, por lo que sus saludos HELO / EHLO también son s2.corp.delo-company.com.

Para pasar la verificación EHLO también hemos creado algunos registros en el DNS de delo-company.com:

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

Según tengo entendido, las verificaciones SPF deben pasarse de esta manera: El servidor de salida s2 se conecta al MX del receptor (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX dice Ok, y realiza la verificación SPF de HELO / EHLO Hace NSlookup para s2.corp.delo-company.com y obtiene los registros DNS anteriores. TXT records dice que s2.corp.delo-company.com debe ser solo de IP 82.209.198.147. Por lo tanto, debe ser aprobado.

Entonces nuestro servidor s2 dice RCPT FROM: el servidor Rcp.MX también lo comprueba. Los valores son los mismos, por lo que también deberían ser positivos.

Tal vez también haya una verificación de rDNS, pero no estoy seguro de qué se verificó HELO o RCPT FROM.

Nuestro registro PTR para 82.209.198.147 es:

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

Para mí, todo parece estar bien, pero de todos modos Gmail rechaza todos los correos electrónicos.

Entonces, revisé MXtoolbox.com: dice que todo está bien, pasé http://www.kitterman.com/spf/validate.html Verificación de Python, hice la prueba de correo electrónico 25port.com. También está bien:

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

También verifiqué con [email protected], pero FALLA todo el tiempo, sin importar qué registros SPF haga:

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

He llenado el formulario de Gmail dos veces, pero no pasa nada.

No enviamos spam, solo correos electrónicos para nuestros clientes. 2 o 3 veces enviamos correos electrónicos masivos (como saludos de Año Nuevo y promociones de ventas) desde las direcciones de corp.delo-company.com, pero todos cumplían con la Guía del remitente masivo de Gmail (me refiero a SPF, relés abiertos, precedencia: masivo y cancelar suscripción) etiquetas). Entonces, esto no debería ser un problema.

Por favor, ayúdame. ¿Qué estoy haciendo mal?

UPD: También probé la prueba Unlocktheinbox.com y el servidor también falla esta prueba. Aquí está el resultado; Aquí hay uno más.

También intenté enviar correos electrónicos desde ese servidor manualmente a través de Telnet y todo está bien. Esto es lo que escribo:

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

Y esto es lo que obtengo:

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

Microsoft tiene un buen wizzard. Tal vez puede sugerir algunos cambios?

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

Después de 50 días de intentar buscar una solución en Google, Gmail comenzó a aceptar nuestros correos electrónicos. Pasan a la bandeja de entrada de forma normal (no están etiquetados como spam).

No hice ningún cambio ni ningún otro intento durante los últimos 15 días. No sé si es burocracia o algunos algoritmos que tardan tanto, pero en mi opinión, tardó 10 veces más de lo que debería. Una penalización de 5 días para nuestra débil seguridad es suficiente.

Por cierto, unlocktheinbox.com ahora pasa la prueba, la prueba openspf.org todavía informa un error. Parece que mi situación es demasiado compleja para la prueba. Solucionaría mis nombres PTR y HELO para que coincidan con el nombre de dominio.

Sin embargo, tardó ya una semana después de que le pedimos a nuestro ISP que cambiara el PTR y aún permanece sin cambios ... Una cuestión más de burocracia.

Gracias por la ayuda de todos.

¿podría ser porque está usando solo registros TXT, sin un registro de tipo SPF?

para citar RFC 4408:

Se reconoce que la práctica actual (usando un registro TXT)
no es óptima, pero es necesaria porque hay una serie de
implementaciones de servidor DNS y de resolución de uso común que no pueden manejar
el nuevo tipo RR. El esquema de dos tipos de registro proporciona una ruta
hacia la mejor solución de usar un tipo RR reservado para este propósito.

Un nombre de dominio compatible con SPF DEBE tener registros SPF de ambos
tipos de RR . Un nombre de dominio compatible DEBE tener un registro de al menos un
tipo. Si un dominio tiene registros de ambos tipos, DEBEN tener
contenido idéntico.