Incluso con solo un breve vistazo al protocolo SMTP, notará que además del HELO habitual, también está EHLO, lo que hace que Extendido El servidor SMTP anuncia sus capacidades más allá del estándar original. Uno de estos es DSN. DSN? ¿El ADN y el DDT no son suficientes?
Para argumentar que el correo electrónico no es confiable, que alguien debería " … alimentar a su servidor mejor; se comió mi correo … "no es infrecuente. Sin embargo, no hay muchas razones para apoyar estas sospechas.
Entrega S tatus norte La otificación 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 la entrega, será responsable de ello. Si por alguna razón no puede comunicárselo al destinatario, debe enviarlo de vuelta con la notificación del error al remitente original. Esto dio lugar a algún correo electrónico oscuro.
Aparte de eso, esta antigua convención significaba que recibías un mensaje de error o recibías nada en cuyo caso 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. A medida que el correo electrónico es 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 a los comandos MAIL y RCPT.
No EHLO, No Fun
Primero, debemos asegurarnos de que el servidor admita DSN. Por eso, tenemos que decirle EHLO y escuchar con atención. Si responde con DSN en algún lugar de la lista de características, podemos asumir que podrá atender nuestras solicitudes. Si no, entonces no: podemos probar otro servidor o simplemente retroceder al correo electrónico sin DSN. Por ejemplo:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Domingo, 24 de agosto de 1997 18:23:22 +0200EHLO localhost250-larose.magnet.at Hola localhost 127.0.0.1, encantado de conocerte250-EXPN250-VERBO250-8BITMIME250-TAMAÑO250-DSN250-ONEX250-ETRN250-XUSR250 AYUDA Por suerte, entre otras cosas encontramos DSN. El siguiente comando normalmente 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ó de forma bastante arbitraria en el comando MAIL, pero encaja aquí como lo haría en cualquier otro lugar. El propósito es especificar cuánto de su mensaje original debe devolverse en caso de una falla en la 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 identificación se deja básicamente a la imaginación del remitente. No usaremos ENVID en nuestro ejemplo: CORREO DESDE: [email protected] RET = HDRS250 [email protected] … remitente ok Aparentemente, solo queremos recuperar los encabezados en nuestro DSN. El RCPT TO: obtiene su parte justa de extensiones también: NOTIFY y ORCPT. NOTIFY es el verdadero corazón de DSN. Le dice al servidor cuando para enviar una notificación de estado de entrega. El primer valor posible NUNCA es lo que significa que en ningún caso se debe devolver un DSN al remitente. Esto no era posible sin DSN. Luego está el ÉXITO, que le notificará cuando su correo llegue a su destino. El FALLO es la contraparte de SUCCESS: un DSN llegará si se produce 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 compensan un equipo bastante fuerte, contándoles en (casi) cualquier caso lo que sucedió con su correo. El propósito de ORCPT es preservar la original destinatario 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 PARA: [email protected] NOTIFY = FAILURE, DELAY ORCPT = rfc822; [email protected]250 [email protected] … Recipient ok (se pondrá en cola) A esto le siguen los DATOS tal como los conocemos y, eventualmente, esperamos, una notificación de estado de entrega que le notifique un éxito. Por supuesto, toda esta belleza y solo funcionará si los agentes de transporte de correo desde el remitente hasta el destinatario admiten DSN. Algún día lo harán. Extensiones DSN Sender
Extensiones de destinatario DSN
¿Funciona DSN?
