Estás aquí porque, probablemente, te llegó un mensaje de correo electrónico como el siguiente:
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/delivery-report-decoding.html
La traducción literal del mensaje es la siguiente:
Esta es una colección de reportes acerca del proceso
de envío de correo electrónico, relativa a un mensaje
que fue originado por ti.
Algunas explicaciones/traducciones de estos reportes
se pueden encontrar en:
http://www.zmailer.org/reports-es.html
El software Agente de Transporte de Mensajes (MTA: Message Transfer Agent) ZMailer produce variados reportes a causa de mensajes que pasan a través de él, dependiendo de qué sucede con dicho mensaje y lo que el usuario haya solicitado de ser informado al respecto.
Algunas veces, la gente que mantiene los sistemas que utilizan este software reciben preguntas del tipo: "¿Qué significa este (reporte) en el idioma XYZ?
Lamentablemente los creadores del entorno original de Correo Electrónico [1][2] hablaban todos inlgés (norteamericano) y, por lo tanto, todos los textos suplementarios utilizados por los sistemas se crearon sólo en inglés. (Y en ese entonces, las cuestiones idiomáticas no eran algo de qué preocuparse).
Ahora que la población usuaria creció, inclusive la mayoría de los angloparlantes no pueden enteder las explicaciones en jerga técnica, generalmente demasiado concisa, utilizada para diagnósticos dados en los entornos clásicos de transferencia de correo electrónico SMTP[1], y se ha hecho necesario aumentar la información con algunos detalles adicionales. También se hizo necesario posibilitar la creación de Agentes de Correo Electrónico del Usuario (MUA: Mail User Agent) que pudieran presentar las secciones formales (inteligibles para la computadora) en un idioma[3] que el usuario elija ver.
Estos mensajes de Reporte de Envío (Delivery Report) están estructurados según la especificación RFC1894 [5], y tienen las siguientes partes:
El proposito de esta estructura formal es dar soporte al software MUA para que pueda decodificar y presentar los códigos numéricos en la parte formal en el lenguaje escogido.
Si tu software MUA (el cliente de correo electrónico) no tiene la habilidad para hacer dicha presentación, deberías solicitar al proveedor de dicho software que te informe cuándo proveerá una versión que lo haga.
La parte formal contiene elementos de acción ("Action:") que llevan una de las siguientes etiquetas
¡Esto no significa que el receptor haya leído el mensaje!
(La dirección destino puede llegar a producir otro tipo de reportes, pero no DELIVERED.)
To: sender@domain
From: The Post Office <postmaster@local.server>
Subject: Delivery reports about your email [FAILED(1)]
Date: Wed, 1 Mar 2000 15:20:53 +0200
[-- Anexo N°1 --]
[-- Tipo: text/plain, Codificación: 7bit, Tamaño: 1.7K --]
This is a collection of reports about email delivery
process concerning a message you originated.
Some explanations/translations for these reports
can be found at:
http://www.zmailer.org/reports.html
FAILED:
<smtp some.server.dom user.name@some.server.dom 99>: ...\
expired after 3 days, problem was:
smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Connection refused)
FAILED:
<smtp other.server.dom user@other.server.dom 60000>: ...\
<<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom
->> 550 <user@other.server.dom>... Relaying denied
FAILED:
<smtp other.server.dom user@other.server.dom 60000>: ...\
<<- RCPT To:<user@other.server.dom> ORCPT=rfc822;user@other.server.dom
->> 552 <user@other.server.dom>... Unknown User
[ Se borró el segundo y tercer anexo de este. ]
[-- Anexo N°2 --]
[-- Tipo: message/delivery-status, Codificación: 7bit, Tamaño: 0.5K --]
Reporting-MTA: dns; local.server
Arrival-Date: Wed, 1 Mar 2000 15:19:53 +0200
Local-Spool-ID: S92519AbQCANTx
Original-Recipient: rfc822;user.name@some.server.dom
Final-Recipient: RFC822;user.name@some.server.dom
Action: failed
Status: 5.4.1 (TCP/IP-connection failure)
Diagnostic-Code: smtp; 500 (connect to some.server.dom [11.22.33.44|25|55.66.77.88|1879]: Connection refused)
Remote-MTA: dns; somemx.server.dom (11.22.33.44|25|55.66.77.88|1879)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
Original-Recipient: rfc822;user@other.server.dom
Final-Recipient: RFC822;user@other.server.dom
Action: failed
Status: 5.1.1 (bad destination mailbox)
Diagnostic-Code: smtp; 550 (<user@other.server.dom>... Relaying denied)
Remote-MTA: dns; mx.third.dom (22.33.44.55|25|55.66.77.88|2345)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
Original-Recipient: rfc822;user@other.server.dom
Final-Recipient: RFC822;user@other.server.dom
Action: failed
Status: 5.1.1 (bad destination mailbox)
Diagnostic-Code: smtp; 550 (<user@other.server.dom>... Unknown User)
Remote-MTA: dns; mx.third.dom (22.33.44.55|25|55.66.77.88|2345)
Last-Attempt-Date: Wed, 1 Mar 2000 15:20:53 +0200
[-- Anexo N°3 --]
[-- Tipo: message/rfc822, Codificación: 7bit, Tamaño: 0.2K --]
From: Sender <sender@domain>
To: user.name@some.server.dom
Cc: user@other.server.dom
Subject: demo
Date: Wed, 1 Mar 2000 15:19:53 +0200
demo
Esto puede ser radicalmente distinto de "Original-Recipient" en algunos casos, lo que puede hacer que la identificación de la dirección original se muy difícil sin la facilidad ORCPT de DSN.
Dice qué pasó con el mensaje:
¡Esto no significa que el receptor haya leído el mensaje!
(La dirección destino puede llegar a producir otro tipo de reportes, pero no DELIVERED.)
El Agentes de Correo Electrónico del Usuario (MUA) debería utilizar este código para explicar al usuario en el idioma elegido por este, cuál fue el tratamiento dado al mensaje.
Si el report tiene "Action: DELAYED", otros reportes podrían aparecer más tarde.
Usualmente esto indica problemas en los servidores remtos.
Esto es un error de configuración en algún lado, ya sea en el servicio DNS del dominio destino o en la configuración de los servidores de reenvío.
Los códigos de estado numéricos están definidos en RFC 1893 [4].
Como todas las codificaciones, estas no son adecuadas para todos los usos, pero al menos son mejores que las originales de SMTP [1], que utilizaban muy pocos códigos para indicar simplemente que había ocurrido un error sin dar un código numérico explícito sobre cuál había sido realmente el error.
Los códigos se ven como los siguientes:
2.2.0 4.5.3 5.7.1
Esto es, tres dígitos decimales con puntos entre ellos.
Este provee una clasificación general en los códigos:
Éxito especifica que la DSN está reportando una acción de envio positiva. Los sub-códigos de detalle pueden proveer notificación de transformaciones que fueron requeridas para el envío.
Una falla transitoria persistente es aquella en la cual el mensaje tal cual se envió es válido pero algún evento temporario impide que se envíe exitosamente. Un envío en el futuro podría ser exitoso.
Una falla permanente es aquella que posiblemente no se resuelva reenviando el mensaje del mismo modo. Algún cambio al mensaje o al destino se debe realizar para poder enviarlo exitosamente.
No hay información adicional disponible.
El estado de direccionamiento reporta acerca de la dirección de origen o de destino. Puede incluir sintaxis o validez en la dirección. Estos errores generalmente pueden ser corregidos y reintentados por el remitente.
El estado de la casilla de mensajes indica que algo relacionado con dicha casilla causó esta DSN. Se asume que los problemas relacionados con las casillas están bajo el control general del receptor del mensaje.
El estado del sistema de correo indica que algo relativo al sistema destino causó la DSN. Se asume que los problemas del sistema están bajo el control general del administrador del sistema destino.
Los códigos relativos a la red o el ruteo informan sobre el sistema de envío en sí. Estos componentes incluyen cualquier infraestructura necesaria como ser servicios de directorio y de ruteo. Se asume que los problemas de la red están bajo el control de los administradores del sistema destino o de los sistemas intermedios.
Los códigos de estado del protocolo de envío de correo reportan fallas relativas al protocolo de envío de mensajes. Estas fallas incluyen todos los problemas resultantes de errores de implementación o una conexión no confiable. Los problemas de protocolo de envío de mensajes pueden ser controlados por muchas partes, incluyendo los administradores del sistema de origen, del sistema de destino o de los sistemas intermedios.
Los códigos de estado del contenido del mensaje o estado del medio informan fallas relacionadas con el contenido del mensaje. Estos codigos informan fallas debido a traducción, transcodificación o algún otro tipo de medio no soportado en el mensaje. Los temas relativos al contenido del mensaje o al medio están bajo el control del remitente y el destinatario y ambos deben tener soporte para un conjunto de tipos de contentenido (content-types) en común.
Los códigos de estado de seguridad o de políticas informan fallas relacionadas a políticas como ser filtrado por receptor o por equipo y operaciones criptográficas. Se asume que los temas relativos a la seguridad y a las políticas estan bajo el control del remitente, del receptor o de ambos. Tanto el remitente como el receptor deben permitir el intercambio de mensajes y acordar el intercambio de las claves y certificados necesarios para las operaciones criptográficas.
El tercer dígito (x.x.N) sólo es significativo en conexión con el dígito del medio. La lista es larga y por ello no se incluye aquí.
Todos los detalles están disponibles en inglés: Ver la parte 3 deRFC 1893 [4].
Ningún (equipo de) programador(es) puede crear software con la habilidad de dar mensajes de texto significativos en todos esos idiomas, especialmente cuando los protocolos que llevan otra información no comienzan los intercambios de protocolo con intercambio de información de idiomas y conjuntos de caracteres...