11 votos

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

Tengo un problema con Gmail.

Comenzó después de que uno de nuestros PCs infectados con troyanos enviara spam durante un día desde nuestra dirección IP.

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

Así que he revisado la guía del remitente masivo de Google una vez más y he encontrado un error en nuestro registro SPF y lo he arreglado. Google dice que todo debería estar bien después de un tiempo, pero esto no sucede. Ya han pasado 3 semanas pero todavía 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-compañía.com, tiene su propio correo @delo-compañía.com (este está bien, pero los problemas son con el nombre de sub-dominio corp.delo-compañía.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" 

(Lo puse todo para propósitos de prueba solamente, fue -todo antes de eso)

Estos registros son para nuestro servidor corporativo de Exchange 2003 en el 82.209.198.147. Su nombre LAN es s2.corp.delo-compañía.com así que sus saludos HELO/EHLO son también s2.corp.delo-compañía.com.

Para pasar el control de 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 de SPF deben pasar de esta manera: Nuestro servidor s2 se conecta al MX del receptor (Rcp.MX): EHLO s2.corp.delo-compañía.com Rcp.MX dice Ok, y hace la verificación SPF de HELO/EHLO. Hace NSlookup para s2.corp.delo-compañía.com y obtiene los registros DNS anteriores. Los registros TXT dicen que s2.corp.delo-compañía.com debe ser sólo de IP 82.209.198.147. Así que debería ser pasado.

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

Tal vez también hay un chequeo de rDNS, pero no estoy seguro de qué se chequea HELO o RCPT.

Nuestro récord de 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 todos los correos electrónicos son rechazados por Gmail.

Así que, he revisado MXtoolbox.com - dice que todo está bien, pasé http://www.kitterman.com/spf/validate.html Comprobación de pitón, hice la prueba de correo electrónico de 25port.com. También está bien:

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>

También lo comprobé con spf-test@openspf.net, pero falla todo el tiempo, sin importar los registros de SPF que haga:

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

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

No enviamos spam, sólo correos electrónicos para nuestros clientes. 2 o 3 veces enviamos correos masivos (como felicitaciones de año nuevo y promociones de ventas) desde direcciones de corp.delo-company.com, pero todos ellos cumplían con la Guía del remitente de correo masivo de Gmail (me refiero a SPF, Open Relays, Precedence: Bulk y Unsubscribe tags). Por lo tanto, esto no debería ser un problema.

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

UPD: También intenté la prueba de Unlocktheinbox.com y el servidor también falla esta prueba. Aquí es el resultado; aquí es uno más.

También traté de enviar un correo electrónico desde ese servidor manualmente vía 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: <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

Y esto es lo que obtengo:

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

0 votos

¿Has probado a cambiar el registro TXT de ip4:82.209.198.147 a mx ? Al igual que tú, no veo ningún error, pero puede que valga la pena intentarlo.

0 votos

Probado mx para corp: <s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 spf-test@openspf.net: Dirección del destinatario rechazada: Pruebas 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">

0 votos

Y mx para s2.corp. <s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 spf-test@openspf.net: Dirección del destinatario rechazada: Pruebas 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"> Ambos son Softfail.

2voto

DerekC Puntos 96

Microsoft tiene un bonito wizzard. ¿Tal vez pueda sugerir algunos cambios?

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

2voto

pablomedok Puntos 63

Después de 50 días de intentos y de buscar una solución en Google, Gmail empezó a aceptar nuestros correos electrónicos. Pasan a la bandeja de entrada de forma normal (no se etiquetan como spam).

No he hecho ningún cambio ni ningún otro intento durante los últimos 15 días. No sé si es la burocracia o algunos algoritmos que tardan tanto, pero a mi parecer tardaron 10 veces más de lo debido. 5 días de penalización por nuestra débil seguridad es suficiente.

Por cierto, unlocktheinbox.com ahora pasa la prueba, la prueba de openspf.org sigue informando de un fallo. Parece que mi situación es demasiado compleja para la prueba. Yo arreglaría mis nombres PTR y HELO para que coincidan con el nombre del dominio.

Sin embargo, ya ha pasado una semana desde que pedimos a nuestro ISP que cambie el PTR y todavía no ha cambiado... Un problema más de burocracia.

Gracias por la ayuda de todos.

1voto

Waleed Hamra Puntos 408

¿podría ser porque está utilizando sólo registros TXT, sin un registro de tipo SPF?

para citar el RFC 4408:

Se reconoce que la práctica actual (utilizando un registro TXT) es
no es óptimo, pero es necesario porque hay una serie de DNS
implementaciones de servidores y resolutores de uso común que no pueden manejar
el nuevo tipo de RR. El esquema de dos tipos de recodificación proporciona una ruta de avance
a la mejor solución de utilizar un tipo de RR reservado para este fin.

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

0 votos

Nuestro panel de control de alojamiento no admite el tipo de registro SPF (sólo a, aaaa, cname, ns, mx, srv, txt). Pero eso no era un problema antes. No puedo entender, por qué algunos servicios pasan y otros fallan. ¿Y por qué el envío manual de mensajes a través de Telnet tuvo éxito desde el mismo servidor? Parece que hay algo mal en la configuración de Exchange.

1 votos

Para cualquiera que lea esto ahora, tenga en cuenta que el uso de la SPF El tipo RR quedó obsoleto en 2014. use TXT . Ver RFC 7208 para más detalles.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: