Para un agente de transferencia de correo (MTA) RFC 5321 , el Esquema de reescritura del remitente (SRS) es un esquema para reescribir la dirección del remitente del sobre de un mensaje de correo electrónico, con el fin de reenviarlo. En este contexto, reenvío es una especie de reenvío de correo electrónico . SRS fue diseñado para reenviar correo electrónico sin romper el Marco de políticas del remitente (SPF), en 2003. [1]
Fondo
En varios casos, incluido el cambio de dirección de correo electrónico y listas de correo, un MTA acepta un mensaje de correo electrónico que no está destinado a un buzón de correo local, pero debe reenviarse. En tales casos, surge la pregunta de quién merece recibir cualquier mensaje de rebote relacionado . En general, es el autor o una persona u otra entidad que administra el reenvío en sí. [2] Enviar rebotes al autor es administrativamente más simple y solía lograrse 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 sobre la marcha una dirección de rebote temporal que dirigirá cualquier rebote al MTA actual. El esquema prevé la recuperación de la dirección del sobre original, de modo que si llega un rebote, se puede reenviar por la ruta inversa, con un remitente de sobre vacío esta vez.
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 .
El esquema de reescritura
SRS es una forma de ruta de retorno de sobre variable (VERP) en la medida en que codifica el remitente del sobre original en la parte local de la dirección reescrita. [1] Considere example.com reenviar un mensaje originalmente destinado a [email protected] a su nueva dirección
Remitente del sobre ORIGINAL : [email protected] destinatario del sobre : [email protected]
Reescrito 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 ( SRS0), un hash ( HHH ) y una marca de tiempo ( TT ). Eso refleja una diferencia operativa: los rebotes eventuales 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 exploits significativos en las últimas décadas. En cambio, SRS tiene como objetivo 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 lo reescribe.
- La parte local , en este caso Alice , se mueve porque puede contener signos de igual (=), por lo que colocarla en un extremo de la parte local reescrita hace que esta última sea analizable.
- La marca de tiempo ( TT ) tiene una resolución de un día para invalidar la dirección después de unos días. Calculado como tiempo Unix ⁄ (60 × 60 × 24) mod 2 10 , se puede almacenar como dos caracteres base32 , con un período de reciclaje de aproximadamente 3,5 años.
- El código de autenticación de mensajes basado en hash ( HHH ) se calcula contra un secreto local, pero solo se utiliza una parte; por ejemplo, almacenar los primeros 4 caracteres de una representación base64 proporciona 24 bits de seguridad . El hash es verificado por el dominio que lo generó, en caso de que llegue un rebote.
- El prefijo , SRS0está destinado a eliminar la ambigüedad de las direcciones regulares de las reescritas; Depende de example.com asegurarse de que ninguno de sus usuarios tenga una dirección de correo electrónico que empiece por SRS0=.
SRS proporciona otro prefijo, SRS1que se utilizará para reescribir una dirección ya reescrita, en un escenario de varios saltos. Si example.net tiene que reenviar el mensaje a su vez, puede ahorrar agregar otra marca de tiempo y repetir la parte local original ( alice ). Es decir, cada reenviador nuevo agrega solo su propio hash ( HHH ) y el nombre de dominio del reenviador anterior:
REESCRIBO ADEMÁS Remitente del sobre : [email protected] destinatario del sobre : [email protected]
Alternativa de base de datos
Definitivamente, el uso de una base de datos puede controlar el crecimiento de las 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 se desea. Sin embargo, una base de datos requiere centralización y es un único punto de falla. [4]
Alternativa de campo de encabezado
Otra posibilidad es almacenar la dirección reescrita larga 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 se acaba de observar. [5] A menos que haya un mecanismo de respaldo, solo puede funcionar si el mensaje de devolución está en un formato estándar. [6]
Antecedentes históricos
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 (NetNews). Todos los artículos de noticias todavía contienen un encabezado de ruta , por ejemplo:
Camino :news.server.example! other.example! not-for-mail
La misma información en un sobre de correo electrónico RFC 5321 , que es la información SMTP como MAIL FROM , sería:
- CORREO DESDE :
@other.example> - CORREO DESDE :<@ news.server.example: [email protected]>
El primer paso refleja el remitente, el segundo paso el 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), que coloca el correo en el buzón del destinatario. El MDA transforma la ruta inversa en el campo de encabezado de ruta de retorno conocido :
Ruta de retorno :<@ news.server.example: [email protected]>
SMTP utiliza registros MX para su enrutamiento directo. Rutas de origen explícitas como en ...
RCPT PARA :<@ news.server.example: [email protected]>
... para enrutar el correo desde otro.Ejemplo a través de MTA news.server.example a MDA destination.example fueron engorrosos. Para empeorar las cosas, a veces el nuevo estilo de direcciones (1982) se mezcló con las viejas rutas de bang UUCP en construcciones como ...
[email protected] [email protected]
... y varios otros kludges. 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 que envía 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 usa 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 funcionaba 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 aceptaba la responsabilidad tanto de reenviar el correo como de devolver posibles mensajes de rebote al remitente. RFC 821 y todas las especificaciones SMTP posteriores ofrecen dos códigos de resultado para esta situación:
- 251 usuario no local (intento de reenvío)
- 551 usuario no local (correo rechazado)
Por razones de privacidad, estos códigos de resultado se utilizan hoy en día con poca frecuencia; ellos incluyen elreenviado a (251) o no reenviado a la dirección (551). Pero el significado y el efecto del reenvío a terceros es idéntico paracódigo de resultado 250 y código de error 550 respectivamente.
Como se señaló, RFC 1123 desaprobó el enrutamiento de origen, que implícitamente también desaprobó el enrutamiento inverso de rebotes. Era una Internet relativamente pequeña en 1989, los administradores de correo (administradores de correos) a menudo se conocían y solucionaban problemas sobre la marcha. Enrutar mensajes de rebote a través de reenviadores era una pérdida de tiempo y ancho de banda si el MTA notando 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 deseen aceptar correo de reenviadores generalmente aceptan cualquier dirección MAIL FROM .
Más de una década después, los spammers comenzaron a abusar de esta falla en el SMTP posterior a 1123, hoy la mayoría de los correos son spam y la mayoría de las rutas inversas están falsificadas. Tenga en cuenta que los spammers suelen forjar rutas inversas que funcionan , muchos MTA rechazan el correo si la verificación de devolución de llamada u otras comprobaciones de plausibilidad fallan para la ruta inversa .
RFC 5321, así como RFC 2821, establece 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 de rebote puede suprimirse cuando el contenido original es hostil (cf. correo no deseado o correo con virus) o el mensaje es falso (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 de rebote se clasifique como retrodispersión , aunque algunas personas piensan erróneamente que debería hacerlo.
Los relés abiertos y los reenviadores se encuentran en una posición desafortunada con respecto a este problema, por lo general, 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 de RFC 1123 es abordado por SPF , y el resumen ejecutivo es SPF rompe el reenvío ; en realidad, ese no es el caso,FALLO SPF solo 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, en esencia, tres estrategias:
- no verificar SPF detrás de su borde, por ejemplo, reenviadores de listas blancas
- solo rechaza FALLO SPF, lo que resulta en un rebote (Error 550 de SMTP)
- reescriba el MAIL FROM en el reenviador (como lo hacen las listas de correo)
Sender Rewriting Scheme (SRS) es una forma de la tercera estrategia.
Ver también
- Marco de políticas del remitente (SPF)
- Mensaje de devolución (informe de no entrega SMTP)
- Validación de etiquetas de direcciones de rebote (BATV)
- Protocolo simple de transferencia de correo (SMTP)
Referencias
- ↑ a b Meng Weng Wong (junio de 2003). "Esquema de reescritura del remitente para reenviadores y revendedores para reescribir las direcciones del remitente" . OpenSPF.org . Consultado el 5 de julio de 2013 .
SRS puede verse como una forma de VERP.
- ^ "Listas de correo y alias" . Protocolo simple de transferencia de correo . IETF . Octubre de 2008. sec. 3.9. doi : 10.17487 / RFC5321 . RFC 5321 .
Cuando se entrega o reenvía un mensaje a cada dirección de un formulario de lista expandida, la dirección de retorno en el sobre ("CORREO DE:") DEBE cambiarse para que sea la dirección de una persona u otra entidad que administre la lista.
- ^ Shevek (junio de 2004). "El esquema de reescritura del remitente" (PDF) . Anarres.org . Consultado el 5 de julio de 2013 .
- ^ Meng Weng Wong (enero de 2004). "Requisitos SRS" . lista de correo spf-discusion . Monharc.org . Consultado el 5 de julio de 2013 .
- ^ Laura Atkins (junio de 2013). "I raro = en el correo del cliente" . lista de correo ietf-dkim . Mipassoc.org . Consultado el 5 de julio de 2013 .
- ^ Michael Deutschmann (julio de 2013). "Ese extraño i = probablemente sea EDSP" . lista de correo ietf-dkim . Mipassoc.org . Consultado el 5 de julio de 2013 .
enlaces externos
- página de inicio de libsrs2
- Documento sobre SRS (PDF)
- Borrador histórico de SRS por Meng Weng Wong (2003)
- parche de qmail SRS
- Página de inicio de PostSRSd (demonio que maneja SRS para Postfix)