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


11

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: <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 verifiqué con spf-test@openspf.net, pero FALLA todo el tiempo, sin importar qué registros SPF 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 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: <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

¿Has intentado cambiar el registro TXT de ip4:82.209.198.147a mx? Como tú, no puedo ver un error, pero vale la pena intentarlo.
James O'Gorman

Intenté 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: Resultado del correo = "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

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: Resultado de envío de correo = "softfail": Correo de = " supruniuk-p@corp.delo-company.com "HELO name =" s2.corp.delo-company.com "HELO Resultado =" softfail "Remote IP =" 82.209.198.147 "> Ambos son Softfail.
pablomedok

¿Tiene un DSN (Notificación de estado de entrega) para un mensaje devuelto? ¿Puedes publicarlo? No dice si sabe con certeza que SPF es la razón por la que Gmail rechaza su correo electrónico.
kls

Puedo dártelo, pero está en ruso: Сообщение не было получено одним или несколькими получателями. Тема: prueba de 22 Отправлено: 03.03.2012 0: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] Nuestro sistema ha detectado una tasa inusual de> El mensaje se rompe después de la primera línea. Vi los registros, después de que hay QUIT
pablomedok

Respuestas:



2

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.


1

¿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.


Nuestro panel de control de hosting no admite el tipo de registro SPF (solo a, aaaa, cname, ns, mx, srv, txt). Pero eso no fue un problema antes. Simplemente 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 fue exitoso desde el mismo servidor? Parece que hay algo mal con la configuración de Exchange.
pablomedok

1
Para cualquiera que lea esto ahora, tenga en cuenta que el uso del SPFtipo RR fue obsoleto en 2014. uso TXT. Ver RFC 7208 para más detalles.
mc0e
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.