El esquema de reescritura del remitente (SRS) es un esquema para eludir los métodos del marco de políticas del remitente (SPF) para prevenir direcciones de remitente falsificadas. La falsificación de una dirección de remitente también se conoce como suplantación de correo electrónico .
En varios casos, incluido el cambio de dirección de correo electrónico y listas de correo, un agente de transferencia de mensajes (MTA) acepta un mensaje de correo electrónico que no está destinado a un buzón local pero que debe reenviarse. En tales casos, surge la pregunta de quién merece recibir cualquier mensaje de rebote relacionado . En general, se trata del autor o de una persona u otra entidad que administra el envío. [1] Enviar devoluciones al autor es administrativamente más sencillo y solía realizarse simplemente conservando el remitente del sobre original. Sin embargo, si la dirección del autor está sujeta a una política SPF estricta ( -all) y el MTA de destino la aplica, la transacción de reenvío puede rechazarse.
Como solución alternativa, es posible sintetizar una dirección de rebote temporal sobre la marcha que dirigirá cualquier rebote al MTA actual. El esquema proporciona una forma de recuperar la dirección del sobre original para que, si llega un rebote, se pueda reenviar por la ruta inversa, pero esta vez con un remitente con un sobre vacío.
Si bien existen otras soluciones, SRS es bastante general. Su noción de invertir la ruta se asemeja a las disposiciones de enrutamiento originales para el correo electrónico, ver más abajo.
Tenga en cuenta: el uso del protocolo SRS no supera la verificación de alineación SPF para su registro DMARC , y es por diseño. Su registro DMARC aún puede pasar con una verificación DKIM.
SRS es una forma de ruta de retorno de sobre variable (VERP), ya que codifica el remitente del sobre original en la parte local de la dirección reescrita. [2] Considere ejemplo.com reenviar un mensaje originalmente destinado a [email protected] a su nueva dirección <[email protected]> :
Remitente del sobre ORIGINAL : [email protected] destinatario del sobre : [email protected]
Remitente del sobre REESCRITO : [email protected] destinatario del sobre : [email protected]
El ejemplo anterior está adaptado de Shevek. [3] Con respecto a VERP, la parte local ( alice ) se mueve después de su nombre de dominio ( example.org ), agregando además un prefijo ( ), un hash ( HHH ) y una marca de tiempo ( TT ). Eso refleja una diferencia operativa: los eventuales rebotes a una dirección VERP se manejan dentro del dominio de reescritura, y los mensajes falsificados pueden, como máximo, cancelar la suscripción de algunos usuarios, un tipo de abuso que no ha visto explotaciones significativas en las últimas décadas. En cambio, SRS tiene como objetivo volver a enviar un posible rebote a Alice , de modo que los rebotes falsificados puedan convertirse en una técnica atractiva para inyectar spam que aparentemente se origina en el remitente que reescribe.SRS0
SRS proporciona otro prefijo, que se utilizará para reescribir una dirección ya reescrita, en un escenario de múltiples saltos. Si example.net tiene que reenviar el mensaje a su vez, puede agregar otra marca de tiempo y repetir la parte local original ( alice ). Es decir, cada nuevo reenviador agrega solo su propio hash ( HHH ) y el nombre de dominio del reenviador anterior:SRS1
REESCRITO ADICIONAL del remitente del sobre : [email protected] destinatario del sobre : bob@más.ejemplo
El uso de una base de datos puede controlar el crecimiento de direcciones reescritas, ya que basta con poner una clave única en la parte local reescrita. También permite cierto grado de anonimato en el proceso de reenvío, si así se desea. Sin embargo, una base de datos requiere centralización y es un único punto de falla. [4]
Otra posibilidad es almacenar la dirección larga reescrita en algún lugar del encabezado del mensaje. La etiqueta i = de una firma DKIM puede ser un buen lugar, ya que dicha elección mejora considerablemente la seguridad. Esta técnica acaba de ser observada. [5] A menos que exista un mecanismo de respaldo, solo puede funcionar si el mensaje devuelto está en un formato estándar. [6]
Históricamente, todos los agentes de transferencia de correo (MTA) agregaban su nombre de host a la ruta inversa . En el Protocolo simple de transferencia de correo (SMTP), esta ruta inversa también se conoce como MAIL FROM , pero las rutas también se usaban antes y fuera de SMTP, por ejemplo, como rutas bang en UUCP y Usenet (Net-News). Todos los artículos de noticias todavía contienen un encabezado de ruta , ejemplo:
Camino :noticias.servidor.ejemplo!otro.ejemplo!no-para-correo
La misma información en un sobre de correo electrónico RFC 5321 (es decir, la información SMTP como MAIL FROM ) sería:
El primer paso refleja al remitente, el segundo paso al siguiente MTA, etc. En este ejemplo, supongamos que el segundo MTA reenvía el correo a un tercer MTA, donde finalmente se entrega. El MTA final también se conoce como agente de entrega de correo (MDA), y coloca el correo en el buzón del destinatario. El MDA transforma la ruta inversa en el campo de encabezado conocido de Return-Path :
Vía de retorno :<@servidor.de.noticias.ejemplo:[email protected]>
SMTP utiliza registros MX para su enrutamiento directo. Rutas de origen explícitas como en...
RCPT A :<@noticias.servidor.ejemplo:[email protected]>
...enrutar el correo desde otro.ejemplo a través de MTA news.server.example al destino MDA.ejemplo eran engorrosos. Para empeorar las cosas, a veces el nuevo estilo de direcciones (1982) se mezclaba con antiguas rutas de explosión UUCP en construcciones como...
[email protected] [email protected]
...y varias otras pifias. Los registros SMTP y MX hicieron que todo esto fuera esencialmente inútil. Por lo tanto, el enrutamiento de origen quedó obsoleto en 1989 en RFC 1123.
Un caso especial en RFC 1123 son las puertas de enlace desde o hacia otras redes como UUCP y NetNews, donde el primer MTA emisor no puede llegar al receptor final directamente con TCP . Se resuelve mediante registros MX y, si es necesario, reescribiendo direcciones extranjeras en la puerta de enlace. MX es un acrónimo de Mail eXchanger .
Otro caso especial son las listas de correo , donde el servidor de listas reescribe todas las rutas inversas a su propia dirección de manejo de errores para los rebotes (mensajes de error) de los destinatarios. El servidor de listas podría cancelar automáticamente la suscripción de los destinatarios que rebotan. Este tipo de reescritura de direcciones se conoce desde RFC 821 y todavía se utiliza en la actualidad (RFC 5321, así como RFC 2821, actualizaron el capítulo SMTP en RFC 1123).
Por último, pero no menos importante, el reenvío a otra dirección siempre funcionó reescribiendo la dirección en la ruta de reenvío también conocida como RCPT TO , si y solo si el MTA de reenvío aceptó la responsabilidad de reenviar el correo y devolver posibles mensajes rebotados al remitente. RFC 821 y todas las especificaciones SMTP posteriores ofrecen dos códigos de resultado para esta situación:
Por razones de privacidad, estos códigos de resultados rara vez se utilizan hoy en día; ellos incluyen elreenviado a (251)ono reenviado a la dirección (551). Pero el significado y el efecto de la transmisión a terceros es idéntico paracódigo de resultado 250ycódigo de error 550respectivamente.
Como se señaló, RFC 1123 desaprobó el enrutamiento de origen, que implícitamente también desaprobó el enrutamiento inverso de rebotes. En 1989 era una Internet relativamente pequeña, los administradores de correo (postmasters) a menudo se conocían y solucionaban problemas sobre la marcha. Enrutar los mensajes devueltos a través de cualquier reenviador era una pérdida de tiempo y ancho de banda si el MTA que detectaba un problema (por ejemplo, un rechazo con un código de error 5xx) podía enviar el mensaje de error directamente al MX del remitente.
Desde RFC 1123, los reenviadores a terceros aún reescribieron la dirección RCPT TO , pero mantuvieron el MAIL FROM como está. Como efecto secundario, los MTA que desean aceptar correo de reenviadores generalmente aceptan cualquier dirección CORREO DESDE .
Más de una década después, los spammers comenzaron a abusar de esta falla en el SMTP posterior a 1123; hoy en día, la mayoría de los correos son spam y la mayoría de las rutas inversas son falsificadas. Tenga en cuenta que los spammers suelen falsificar rutas inversas y muchos MTA rechazan el correo si la verificación de devolución de llamada u otras comprobaciones de plausibilidad fallan en la ruta inversa .
RFC 5321, así como RFC 2821, establecen que los informes de no entrega ( rebotes ) deben enviarse al originador como se indica en la ruta inversa después de que un MTA aceptó la responsabilidad de la entrega. Sin embargo, el mensaje devuelto puede suprimirse cuando el contenido original es hostil (por ejemplo, correo no deseado o virus) o el mensaje es falsificado (RFC 5321, Sección 6). Tenga en cuenta que todos los métodos actuales de detección de falsificaciones requieren que el propietario del buzón proporcione información para que funcionen. No proporcionar los criterios no debería hacer que ningún mensaje devuelto se pueda clasificar como retrodispersión , aunque algunas personas piensan erróneamente que así debería ser.
Los retransmisores abiertos y los reenviadores se encuentran en una posición desafortunada con respecto a este problema, generalmente no pueden garantizar que la dirección MAIL FROM indique el originador y tampoco pueden garantizar que la entrega final se realice correctamente.
Este problema de SMTP causado como efecto secundario del RFC 1123 se aborda mediante SPF , y el resumen ejecutivo es que SPF interrumpe el reenvío ; en realidad, ese no es el caso.FALLO DEL FPSsolo pide a los receptores que verifiquen el SPF en su MTA fronterizo, no más tarde.
Los receptores pueden organizar su reenvío de una manera que funcione con SPF con, básicamente, tres estrategias:
El esquema de reescritura del remitente (SRS) es una forma de aplicar la tercera estrategia.
Cuando un mensaje se entrega o reenvía a cada dirección de un formulario de lista ampliada, la dirección del remitente en el sobre ("CORREO DE:") DEBE cambiarse para que sea la dirección de una persona u otra entidad que administra la lista.
El SRS puede verse como una forma de VERP.