DSN: Notificación de estado de entrega para correo electrónico SMTP

Incluso un breve vistazo al protocolo SMTP le hará notar que además del HELO habitual, también existe EHLO, que hace que el servidor SMTP Extendido anuncie sus capacidades más allá del estándar original.

Incluso un breve vistazo al protocolo SMTP le hará notar que además del HELO habitual, también existe EHLO, que hace que el servidor SMTP Extendido anuncie sus capacidades más allá del estándar original. Uno de estos es DSN. DSN? ¿El ADN y el DDT no son suficientes?

Argumentar que el correo electrónico no es confiable, que alguien debería « … alimentar mejor a su servidor; se comió mi correo … » no es raro. Sin embargo, no hay muchas razones para apoyar estas sospechas.

La Notificación del estado de entrega ha existido desde RFC 821 (desde 1982). Tan pronto como la parte de DATOS del protocolo SMTP haya finalizado y el servidor haya aceptado el correo electrónico para su entrega, es responsable de ello. Si por algún motivo no puede transmitirlo al destinatario, debe enviarlo de vuelta con la notificación del error al remitente original. Esto resultó en algunos correos oscuros.

Aparte de eso, esta antigua convención significaba que recibías un mensaje de error o recibías nada en cuyo caso no sabías nada : el correo electrónico puede haber llegado o no. Los mensajes de error en muchos casos fueron tan útiles como ningún mensaje de error. Con el correo electrónico cada vez más importante, esto ya no es satisfactorio (como si fuera antes).

Extensiones DSN a SMTP

RFC 1891 propone algunas extensiones al protocolo SMTP que deberían dar como resultado un sistema DSN más confiable y más utilizable. Es un conjunto de extensiones para los comandos MAIL y RCPT.

Sin EHLO, sin diversión

Primero, debemos asegurarnos de que el servidor sea compatible con DSN. Por lo tanto, tenemos que decirle EHLO y escuchar con atención. Si responde con DSN en algún lugar de la lista de funciones, podemos suponer que podrá atender nuestras solicitudes. Si no, entonces no: podemos probar con otro servidor o simplemente recurrir al correo electrónico sin DSN. Por ejemplo:

 220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6; Dom, 24 de agosto de 1997 18:23:22 +0200 
EHLO localhost
250-larose.magnet.at Hola localhost [127.0.0.1], encantado de conocerte
250-EXPN
250-VERBO
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 AYUDA

Afortunadamente, entre otras cosas encontramos DSN.

Extensiones de remitente DSN

El siguiente comando generalmente es MAIL FROM. Con DSN, esto no es diferente. Pero hay dos opciones adicionales que puede emitir: RET y ENVID.

La opción RET se colocó arbitrariamente en el comando MAIL, pero se ajusta aquí tan bien como en cualquier otro lugar. El propósito es especificar qué cantidad de su mensaje original debe devolverse en caso de una falla de entrega. Los argumentos válidos son FULL y HDRS. Lo primero significa que el mensaje completo debe incluirse en el mensaje de error, HDRS le indica al servidor que solo devuelva los encabezados del correo fallido. Si no se especifica RET, depende del servidor qué hacer. En la mayoría de los casos, HDRS será el valor predeterminado.

ENVID realmente pertenece al remitente ya que ella o (más bien) su cliente de correo electrónico será el único que haga uso de este identificador de sobre . Su propósito es decirle al remitente a qué correo electrónico corresponde un mensaje de error posiblemente emitido. El formato de esta ID se deja básicamente a la imaginación del remitente. No usaremos ENVID en nuestro ejemplo:

 CORREO DE: sender@example.com RET = HDRS 
250 sender@example.com ... Remitente ok

Aparentemente, solo queremos recuperar los encabezados en nuestro DSN.

Extensiones de destinatario DSN

El RCPT TO: obtiene su parte justa de extensiones también: NOTIFICAR y ORCPT.

NOTIFY es el verdadero corazón de DSN. Le dice al servidor cuándo enviar una notificación de estado de entrega. El primer valor posible es NUNCA, lo que significa que bajo ninguna circunstancia debe devolverse un DSN al remitente. Esto no fue posible sin DSN. Luego está el ÉXITO, que le notificará cuando su correo haya llegado a su destino. FALLA es la contraparte del ÉXITO: ​​un DSN llegará si se produjo un error durante la entrega. La última opción es RETARDO: se le notificará si hay un retraso inusual en la entrega, pero el resultado real de la entrega (éxito o fracaso) aún no se ha decidido. NUNCA debe ser el único argumento si se especifica, los otros tres pueden aparecer en una lista, delimitada por una coma. El ÉXITO y el FALLO conforman un equipo bastante fuerte juntos, diciéndole (en casi cualquier caso) lo que sucedió con su correo.

El propósito de ORCPT es preservar el destinatario original de un mensaje de correo electrónico, por ejemplo, si se reenvía a otra dirección. El argumento de esta opción es la dirección de correo electrónico del destinatario original junto con el tipo de dirección. El tipo de dirección viene primero, seguido de un punto y coma y finalmente la dirección. Por ejemplo:

 RCPT A: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822; support@example.com 
250 support@example.com ...Destinatario ok (hará cola)

Esto es seguido por los DATOS tal como los conocemos y, eventualmente, con suerte, una notificación de estado de entrega que le notifica un éxito.

¿DSN funciona?

Por supuesto, toda esta belleza y solo funcionará si los agentes de transporte de correo del remitente al destinatario admiten DSN. Algún día lo harán.

Rate article
labsfabs.com
Add a comment