¿La reescritura de SRS es absolutamente necesaria para un servidor de reenvío de correo?


14

Estoy operando un servidor de correo electrónico Postfix para mi dominio, por ejemplo, midominio.com. Principalmente actúa como un servidor de reenvío de correo electrónico: los usuarios reciben una dirección de correo electrónico @ midominio.com, pero generalmente eligen reenviar su dirección a una bandeja de entrada externa (Gmail, Yahoo, etc.). Se reenvían algunos miles de direcciones, por lo que el servidor maneja un volumen bastante significativo de tráfico de correo.

En el pasado, el servidor no usaba la reescritura de SRS. Por supuesto, esto significaba que el correo reenviado no pasaría las verificaciones SPF, ya que mi dirección IP no está técnicamente autorizada para enviar correos electrónicos en nombre del dominio del remitente original. Sin embargo, por lo que puedo ver, no parece estar causando ningún problema significativo. En general, ninguna queja de usuarios como Gmail, Yahoo, etc. parece ser lo suficientemente inteligente como para ignorar las fallas de SPF y entregar los mensajes de todos modos.

Con esto en mente, ¿es realmente necesario habilitar la reescritura de SRS? Estoy considerando habilitarlo, pero mi principal preocupación es que mi dominio quede en la lista negra por enviar spam cuando el spam inevitablemente se oculte. ¿La reescritura no lo haría aparecer como si yo fuera el creador del spam? (Al menos, esto es lo que entiendo al leer las Mejores prácticas de Gmail para reenviar servidores de correo ).

De acuerdo, ya estoy tomando algunas de las precauciones recomendadas, como usar SpamAssassin para agregar "SPAM" a la línea de asunto de spam sospechoso antes de reenviar, no reenviar spam de alta confianza (puntaje 15+) y usar la lista de bloqueo de spamhaus, pero estas medidas no son No es perfecto y el spam aún puede pasar sin marcar.

¿Vale la pena habilitar la reescritura de SRS si aumenta el riesgo de ser marcado erróneamente como spammer? ¿O sería más seguro dejarlo como está e ignorar las fallas de SPF?


Sé por experiencia que algunos ISP en el Reino Unido rechazarán el correo electrónico entrante que dice ser de sus propios clientes, pero que no ha sido enviado desde sus propios correos. Lo mismo también puede ser cierto para Gmail, Yahoo y AOL. Tales situaciones solo pueden resolverse reescribiendo la dirección del remitente.
Roaima

Respuestas:


8

Me parece que su pregunta se reduce a " ¿cuántos servidores de correo comprueban los registros SPF en el correo electrónico entrante? ". Si es la mayoría de ellos, SRS es un requisito absoluto para un servidor de reenvío; Si no es ninguno de ellos, no necesita SRS.

Desafortunadamente, no puedo poner inmediatamente mis manos en ningún trabajo académico sobre esto. Pero como verifico SPF en el correo electrónico entrante, puedo decir con certeza que algunos servidores de correo lo comprueban. Cualquiera de sus clientes que tengan su servidor reenviado a cuentas en mi servidor perderá el correo electrónico enviado por los remitentes que anuncian un SPF que finaliza (como todos deberían) -all, a menos que use SRS. Entonces puedo decir con certeza que sin SRS, algunos de los correos electrónicos de sus clientes no serán entregados .

Le pido disculpas a Marc porque no puedo leer alemán, por lo que no puedo decir si el PDF que cita presenta argumentos convincentes, pero puedo reiterar que sin SRS, una fracción del correo electrónico de sus clientes no se entregará. No puedo decir cuál es esa fracción, pero no es cero, y dado eso, no creo que tenga otra alternativa que ejecutar SRS.

Estoy de acuerdo en que su servidor no se ayudará a sí mismo mediante el reenvío de SPAM, pero en mi experiencia, la mayor parte del daño a la reputación se hace a su dirección IP, no al dominio de sobre-De; Esto se hará independientemente del uso de SRS.

La respuesta más profunda a su pregunta es que, entre SPF y su seguimiento DMARC (mal considerado y que rompe Internet), me parece que los servicios de reenvío de correo han tenido su día. Ya he requerido que todos mis usuarios, excepto uno, tengan la entrega final en mi servidor, y ese usuario tendrá que cambiar o abandonar en 2016. Hoy en día, muchos sistemas de correo web permitirán la integración en varios buzones mediante la recopilación de correo fuera del servidor usando IMAP o POP, y muchos clientes de correo permiten que varias cuentas IMAP o POP se presenten como una sola INBOX integrada, por lo que el reenvío no es una bendición para la lectura centralizada que solía ser.

En resumen, yo diría que necesita SRS a corto plazo y un nuevo modelo de negocio a largo plazo.


La cuestión es que SRS es una solución para remediar los problemas de reenvío de SPF. SRS reescribe, por ejemplo, usuario @ A a A = usuario @ B y los registros SPF de B están a cargo. Problema: ¡B todavía puede falsificar direcciones! Por lo tanto, algunos agregan hash de cifrado y marcas de tiempo a la dirección reescrita. Para que esto funcione a gran escala, necesita una adopción global que no existe. También solo funciona si algo se reenvía una vez, pero no más. También las respuestas son un problema. También tenga en cuenta que SPF es una técnica para proteger su propio dominio de abuso, nada más.
Marc Stürmer el

@ MarcStürmer " SRS es una solución para remediar los problemas de reenvío de SPF ": sí, eso es exactamente lo que es. Se sabe que SPF rompe el reenvío simplista; Si no cree que SRS sea un precio que valga la pena pagar, no anuncie un registro SPF. " Problema: B todavía puede falsificar direcciones ": no al dominio de A, ni a ningún otro dominio protegido por un registro SPF decente, o el correo será rechazado bajo SPF; pero aparte de eso, sí, puede, y no lo veo como un problema. " SPF es una técnica para proteger su propio dominio de abuso, nada más ": estoy de acuerdo.
MadHatter

@ MarcStürmer: "También solo funciona si algo se reenvía una vez, pero no más". Está Mal. SRS funciona completamente bien en varios servidores de reenvío. Solo sufre si hay un servidor sin etiquetado en la línea. Pero este es el mismo problema que con cualquier servidor sin etiquetado en general, ya sea un primer o más adelante salto hacia adelante. En un mundo SPF, no necesita SRS, solo necesita hacerse cargo de la responsabilidad del correo reenviado y asegurarse de que puede entregar un posible rebote. SRS es solo una técnica que hace esto, google, por ejemplo, usa algo diferente.
Adrian Zaugg

El problema es que el uso de SRS rompe la verificación de alineación de DMARC (es decir, el remitente del sobre! = From:-Header) y hará que Gmail rechace los mensajes si el dominio en el From:encabezado tiene p=rejectsu política DMARC. Si reescribe From:también, el correo se verificará de acuerdo con las reglas de su propio dominio. Pero una verificación DKIM fallará y el remitente que se muestra en el cliente de correo está destrozado.
mbirth

@mbirth afaik, tienes razón. Pero personalmente considero que DMARC es un desastre completo, sobre todo porque rompió unilateralmente las listas de correo y (en mi calidad de administrador de una gran lista comunitaria) simplemente aconsejo a las personas que no usen ningún ISP que publique una p=rejectpolítica. Si SRS rompe DMARC, bueno, eso es difícil para DMARC.
MadHatter

8

SRS parece ser una buena idea en el papel, pero no funciona muy bien en la práctica de acuerdo con la gente de Heinlein Support (están ejecutando un servicio de correo de tamaño mediano con más de 100000 cuentas).

Los detalles están en su charla, aunque en alemán, por qué: https://www.heinlein-support.de/sites/default/files/SPF-DKIM-Greylisting_FrOSCon_2012.pdf

La razón principal es que SRS es un pequeño parche para problemas serios de implementar SPF en realidad, porque SPF no cubre muy bien algunos casos de uso común de correo electrónico. Para que SRS tenga sentido, aunque debe implementarse en una gran base de servidores, lo que es poco probable que ocurra. Entonces, hasta que se implemente en esa gran base de servidores, no tiene mucho sentido en absoluto.

Sin embargo, el problema con los grandes proveedores de correo es que hoy en día tienen una base de usuarios realmente grande y están implementando más y más técnicas (el sucesor de DMARC ya está en proceso), lo que hace que sea cada vez más difícil para un cliente normal. configuración del servidor de correo para enviarles correos de una manera confiable.

Si desea que su correo se entregue mejor a los grandes proveedores de correo como Gmail, Hotmail, etc., debe implementar al menos DKIM y DMARC, pero también configurarlo en el mejor de los casos, y tal vez implementar algunos mecanismos de limitación de velocidad en la entrega de correo haría maravillas para ti.

Este problema con los grandes proveedores es la razón por la cual actualmente existen servicios como Mailchimp, Mandrill o Returnpath. Esos proveedores pagan dinero a Google & Co. Para una mejor calidad de entrega.


1
El problema aquí es SPF no SRS. Siempre que algunos ISP utilicen SPF, debe implementar SRS (o algo similar) para que el reenvío funcione con todos ellos. El problema con las listas grises es diferente, debe "desempaquetar" las direcciones de remitente etiquetadas con SRS para las listas grises (así como los correos etiquetados con BATV).
Adrian Zaugg

3

Estoy de acuerdo con cada palabra de @MadHatter, ¡PERO hecho importante sobre Google!

Si proporciona un servicio de reenvío a gmail, existe una buena posibilidad de que también proporcione acceso SMTP para que sus usuarios de gmail puedan enviar correos desde gmail en nombre de la dirección almacenada por usted.

En ese caso, gmail sabe que usted es un reenviador de este correo electrónico y no marca sus reenvíos como spam a pesar de que no se verifica SPF.

Puede enviar correos electrónicos a sus clientes desde bill@microsoft.com. ¡El mensaje llegará a su bandeja de entrada sin previo aviso! (Microsoft tiene -all en el registro spf)

Comprobado y verificado. Ejemplo adjunto.

Este mensaje fue a la bandeja de entrada.gmail Show Original

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.