Incluso un breve vistazo al protocolo SMTP le hará notar que además del habitual HELO, también existe EHLO, que hace que el Extended SMTP server anuncie sus capacidades más allá del estándar original. Uno de ellos es el DSN. ¿DSN? ¿No son suficientes el ADN y el DDT?
Argumentar que el correo electrónico no es fiable, que alguien debería » …alimentar mejor a su servidor; se comió mi correo…» no es infrecuente. Sin embargo, no hay muchas razones para apoyar estas sospechas.
Entrega Status Notificación existe desde el RFC 821 (desde 1982). Tan pronto como la parte DATA del protocolo SMTP esté terminada y el servidor haya aceptado el correo electrónico para su entrega, será responsable de ello. Si por alguna razón no puede hacerla llegar al destinatario, debe devolverla junto con la notificación del error al remitente original. Esto resultó en un correo electrónico oscuro.
Aparte de eso, esta vieja convención significaba que o bien recibías un mensaje de error o bien recibías nada en cuyo caso sabías nada: el correo electrónico podía haber llegado o no. Los mensajes de error en muchos casos fueron tan útiles como la ausencia de mensajes de error. Con el correo electrónico cada vez más importante, esto ya no es satisfactorio (como si lo fuera antes).
Índice de contenidos
Extensiones de DSN a SMTP
El RFC 1891 propone algunas extensiones al protocolo SMTP que deberían resultar en un sistema DSN más fiable y utilizable. Es un conjunto de extensiones de los comandos MAIL y RCPT.
No EHLO, No Fun
Primero, tenemos que asegurarnos de que el servidor soporta DSN. Por lo tanto, tenemos que decirle EHLO y escucharle atentamente. Si responde con DSN en algún lugar de la lista de características podemos asumir que será capaz de servir nuestras peticiones. Si no, entonces no: podemos probar otro servidor o simplemente volver al correo electrónico sin DSN. Por ejemplo:
220 larose.magnet.at ESMTP Sendmail 8.8.6/8.8.6.6; Dom, 24 Ago 1997 18:23:22 +0200
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.EHLO localhost
250-larose.magnet.at Hello localhost[127.0.0.0.1], encantado de conocerte
250-EXPN
250-VERB
250-8BITMIME
250 TAMAÑO
> TAMAÑO250-DSN
br250-ONEX
250-ETRN
250-XUSR
250 AYUDA
> AYUDA
Por suerte, entre otras cosas encontramos el DSN.
Extensiones del remitente de DSN
El siguiente comando típicamente es MAIL FROM. Con DSN, esto no es diferente. Pero hay dos opciones adicionales que usted puede emitir: RET y ENVID.
La opción RET fue colocada arbitrariamente en el comando MAIL, pero encaja aquí tan bien como en cualquier otro lugar. El propósito es especificar qué cantidad de su mensaje original debe ser devuelta en caso de fallo en la entrega. Los argumentos válidos son FULL y HDRS. La primera significa que el mensaje completo debe ser incluido en el mensaje de error, HDRS instruye al servidor para que sólo devuelva las cabeceras del correo fallido. Si no se especifica RET, depende del servidor qué hacer. En la mayoría de los casos, el 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 envolvente. Su objetivo es indicar al remitente a qué correo electrónico corresponde un posible mensaje de error. El formato de este ID se deja básicamente a la imaginación del remitente. No usaremos ENVID en nuestro ejemplo:
MAIL FROM: sender@example.com250 sender@example.com… Emisor ok
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Aparentemente, sólo queremos que las cabeceras vuelvan a nuestro DSN.
Extensiones de destinatarios de DSN
La RCPT TO: también recibe su parte justa de extensiones: NOTIFICAR y ORCPT.
NOTIFY es el verdadero corazón de DSN. Indica al servidor cuando que envíe una notificación de estado de entrega. El primer valor posible NUNCA es NUNCA, lo que significa que bajo ninguna circunstancia se debe devolver un DSN al remitente. Esto no era posible sin DSN. Luego está el ÉXITO, que le notificará cuando su correo haya llegado a su destino. FAILURE es la contraparte de SUCCESS: un DSN llegará si se produce un error durante la entrega. La última opción es la DEMORA: 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, delimitados por una coma. El ÉXITO y el FALLO compensan a un equipo bastante fuerte, diciéndole en (casi) cualquier caso lo que le pasó a 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 es el primero, seguido de un punto y coma y, por último, la dirección. Por ejemplo:
250 support@example.com… Destinatario ok (cola)
> (se pondrá en la cola)
A esto le siguen los DATOS tal y como los conocemos y, con suerte, una notificación del estado de la entrega que le notifica el éxito.
¿Funciona el DSN?
Por supuesto, toda esta belleza y sólo funcionará si los agentes de transporte de correo desde el remitente hasta el destinatario son compatibles con DSN. Algún día lo harán.
