MXPA03000807A - Sistema y metodo para verificar la entrega e integridad de mensajes electronicos. - Google Patents

Abstract

Con el fin de proporcionar verificacion de una tercera parte, del contenido y entrega de un mensaje electronico tal como un correo electronico, un servidor recibe el correo electronico que se pretende sea enviado o encaminado hacia un destinatario especifico, y "etiqueta" el mensaje para indicar que este esta "registrado" con el proveedor del servicio. El servidor establece luego una conexion de red telefonica directa con el Agente de Usuario de Correo (MUA) del destinatario, y transmite el correo electronico etiquetado al MUA del destinatario, asi como a los MUAs de cualesquiera otros destinatarios. Despues de recibir las respuestas de los MUAs receptores, de que el mensaje fue exitosamente recibido, el servidor crea luego y envia al originador del mensaje un recibo electronico. El recibo incluye uno o mas y preferentemente todos de los siguientes: el mensaje original que incluye cualesquiera anexos originales; una tabla de exito/falla de la entrega que lista cuales MUAs de los destinatarios recibieron exitosamente el mensaje y a que hora, y para cuales MUAs existio una falla en la entrega; y una firma digital correspondiente al mensaje y a los anexos. Al recibir el recibo en una fecha posterior y verificar que la firma digital concuerda con el mensaje y la informacion relacionada, el operador del sistema puede proporcionar la verificacion independiente de tercera parte de que el recibo es un producto genuino de su sistema, y de que la informacion perteneciente al contenido y a la entrega del mensaje es correcta, sin la necesidad de archivar el mensaje original o el recibo.

Description

SISTEMA Y MÉTODO PARA VERIFICAR LA ENTREGA E INTEGRIDAD MENSAJES ELECTRÓNICOS ANTECEDENTES DE LA INVENCION II. CAMPO DE LA INVENCION Esta invención se refiere en general a un sistema y método para verificar la entrega y contenido de un mensaje electrónico y, más particularmente a un sistema y método de proporcionar al final la prueba respecto a la entrega y contenido de un mensaje de correo electrónico.

II. DESCRIPCION DE LA TECNICA RELACIONADA En años recientes, el correo electrónico se ha vuelto una herramienta mercantil indispensable. El correo electrónico ha reemplazado al "correo caracol" para muchas prácticas mercantiles debido a que es más rápido, y más barato y en general más confiable. Pero siguen existiendo algunas aplicaciones de correo donde la copia dura o el papel es todavía dominante, tal como el correo certificado y certificado. Por ejemplo, cuando una carga es enviada por correo certificado al remitente se le proporciona un acuse de recibo para probar que la carta fue enviada. Un recibo de REF: 144900 correo certificado, regresado, se agrega a la confirmación del servicio postal de que la carta fue exitosamente entregada al destinatario o al agente destinado por el destinatario. Adicionalmente , los correos privados tales como Federal Express® y United Parcel Service® (UPS) , proporcionan algún tipo de confirmación de entrega. Ya que cada pieza de paquete de correo es, en efecto, registrada es natural que los consumidores acudan a estos servicios cuando ellos desean la prueba de la entrega. Muchos sistemas existentes de correo electrónico y programas de correo electrónico proporcionan ya alguna forma de prueba de la entrega o entrega. Por ejemplo, algunos sistemas de correo electrónico hoy en día permiten que un remitente marque un mensaje con etiquetas de "petición para notificaciones" . Tales etiquetas permiten que un remitente pida la notificación de que el mensaje fue entregado y/o cuando el mensaje fue abierto. Cuando un remitente pide la notificación de la entrega, el sistema de correo electrónico de la Internet puede proporcionarle al remitente un acuse de recibo de correo electrónico de que el mensaje fue entregado al servidor de correo o al buzón electrónico del recipiente. El mensaje de recepción puede incluir el título del mensaje, la dirección de destino, y el tiempo de entrega o entrega. Este puede también incluir (dependiendo de los tipos de "banderas" que son proporcionadas y activadas en el software software de envío) , una lista de todas las "estaciones" de Internet de que el mensaje pasó a través de éstas en rutas hacia su destino. Esta forma de reportar está constituida en algunas de las reglas y protocolos que implementan el correo electrónico. Además, cuando un mensaje es enviado con una petición de "notif cación de lectura" el programa de correo electrónico del recipiente puede enviarle al remitente una notificación de correo electrónico de que el receptor abrió ese mensaje para su lectura. Muchos clientes de correo electrónico pueden y efectivamente apoyan este tipo de reporte; no obstante, los protocolos de Internet no hacen esto indispensable. No obstante, esto no significa que un correo electrónico enviado con una petición de notificación sea tan efectivo en todos sus aspectos como el correo registrado. Diversas personas certifican y registran las cartas debido a que ellos desean la prueba de la entrega, por ejemplo, la prueba que puede ser utilizada en un procedimiento civil o criminal, o la prueba que satisfará a un supervisor o a un cliente o una agencia gubernamental, de que un mensaje ha sido enviado, una labor ha sido realizada, una orden colocada, o un requerimiento de contrato satisfecho. Un recibo de registro del Servicio Postal de los Estados Unidos (USPS) constituye la prueba de la entrega debido a que el USPS está detrás de ésta. El recibo o acuse de recibo representa la confirmación de la Oficina Postal de que la carta o paquete en cuestión fue efectivamente entregada al destinatario o al representante autorizado. Por otra parte, con el acuse de recibo de correo electrónico existen diversos obstáculos para que un acuse de recibo de correo electrónico sea admitido y confiado como evidencia persuasiva en una corte legal, como una prueba de que el mensaje fue entregado. Después de todo, el acuse de recibo puede ser solo otro mensaje de correo electrónico que podría haber sido alterado o creado por cualquiera a cualquier tiempo . Existe una necesidad para un sistema de correo electrónico y/o un método que puede proporcionar prueba confiable del contenido y entrega de un mensaje de correo electrónico, con el fin de tener ventaja más completa de la conveniencia y bajo costo de la comunicación vía correo electrónico . Para cumplir esta necesidad, algunos sistemas han sido establecidos, mediante los cuales los remitentes pueden recibir una prueba de entrega de una tercera parte, enrolándose en servicio mediante los cuales: a) el remitente transmite un mensaje electrónico a una tercera parte junto con una lista de los receptores o destinatarios pretendidos del documento. b) la tercera parte envía una notificación a cada uno de los receptores pretendidos del mensaje, invitándoles a visitar el sitio de la red de la tercera parte, donde el mensaje puede ser observado. c) si el receptor pretendido visita el sitio de red de la tercera parte para observar el mensaje, la tercera parte registra esta visita de modo que el remitente puede saber que este mensaje ha sido leído por el receptor o destinatario . Los inconvenientes de tales sistemas son múltiples. En primer lugar, éstos confían esencialmente la cooperación del receptor del correo electrónico para recolectar sus mensajes del servicio de la tercera parte. Pero las circunstancias en las cuales un remitente puede desear la prueba de la entrega de un mensaje, son frecuentemente algunas en las cuales no se puede asumir que el receptor comprendido cooperará en la recepción del mensaje. En tales casos, por ejemplo, dónde el reconocimiento de recepción del mensaje podría colocar una carga financiera o legal al receptor, el receptor puede simplemente ignorar la notificación de que el correo está disponible para él, para recibirlo. Nótese que no existe nada en tal sistema para garantizar que el receptor pretendido haya recibido la notificación de correo en espera. En segundo lugar, tales sistemas son problemáticos y lentos para utilizarse en comparación al correo electrónico regular, en cuanto a que éste puede requerir que el remitente y el receptor se conecten a un sitio de la Red Mundial (World Wide Web) para enviar, recolectar y verificar la entrega o entrega de cada mensaje. Además, la transmisión de documentos mediante tales métodos puede requerir que el remitente y el receptor carguen y descarguen archivos hacia un sitio de la red. Finalmente, debido a que estos métodos requieren que la tercera parte conserve una copia de la totalidad de cada mensaje hasta un tiempo tal que, que éstos sean recolectados o hayan expirado, los métodos pueden requerir que su proveedor destina recursos computacionales sustanciales al almacenamiento de datos y al rastreo de datos en un periodo prolongado de tiempo. Como un método alternativo puede proporcionar prueba de la entrega, algunos sistemas proporcionan unidades enchufables de los clientes de correo electrónico del propietario o de buscadores (curioseadores) de la red que notificarán a los remitentes cuando un mensaje ha sido recibido, con la condición que un receptor utilice el mismo cliente de correo electrónico. La desventaja obvia de tales sistemas es que esto requieren que el remitente y el destinatario utilicen el mismo cliente de correo electrónico. Existe por lo tanto una necesidad para un sistema/método de correo electrónico que pueda proporcionar prueba confiable del contenido y entrega de los mensajes electrónicos que no requieren el cumplimiento u operación del receptor, que no requiere software de correo electrónico especial por parte del remitente o del destinatario, que opere con la misma o casi la misma conveniencia y velocidad de uso que el correo electrónico convencional, y el cual pueda ser operado económicamente por un proveedor de servicios .

BREVE DESCRIPCIÓN DE LA INVENCIÓN Un objetivo general de la presente invención es proporcionar un sistema y un método para verificar confiablemente, vía la documentación segura y a prueba de manipulaciones indebidas, el contenido y entrega de un mensaje electrónico tal como un correo electrónico. Idealmente, la invención le dará a un correo electrónico y a otros mensajes electrónicos una condición o estatus legal a la par con, sino es que superior a, aquel del correo certificado de los Estados Unidos. No obstante, no es necesario para la invención que sea acordada alguna condición legal particular a los mensajes enviados, de acuerdo a los métodos enseñados en la presente, ya que no obstante la invención proporciona información y verificación útiles. La presente invención incluye un sistema de mensajes electrónicos que crea y registra una firma digital de cada mensaje electrónico enviada a través del sistema. Un originador puede enviar una copia del mensaje electrónico al sistema o generar el mensaje electrónico dentro del sistema mismo. El sistema envía luego y entrega el mensaje electrónico a todo los receptores o destinatarios (o a los manej adores designados de los mensajes, asociados con los receptores) , incluyendo los destinatarios "hacia" y los destinatarios "ce" . Después de esto, el sistema devuelve un acuse de recibo de la entrega al originador o remitente del mensaje electrónico. El acuse de recibo incluye, entre otras cosas: el mensaje original, la firma digital del mensaje, y una historia de saludos y entregas incluyendo los tiempos de entrega hacia los destinatarios. Para verificar finalmente y autenticar la información contenida en el recibo, el originador o usuario envía una copia del recibo al sistema. El sistema verifica luego que la firma digital concuerde con el mensaje original y el resto del recibo. Si los dos concuerdan, entonces el sistema envía una carta o proporciona otra confirmación de autenticidad que verifica que el mensaje electrónico no ha sido alterado. El sistema puede ser una forma de servidor de correo electrónico conectado a la Internet, que puede ser utilizado de muchas maneras. Por ejemplo, los usuarios individuales pueden registrar sus mensajes electrónicos, tales como los correos electrónicos, mediante el envío de una "copia al carbón" (ce) al sistema o que componiendo el mensaje dentro del sistema mismo. Para usuarios corporativos o de comercio electrónico, estos usuarios pueden cambiar su servidor a un servidor que incorpore la presente invención y tenga todos sus mensajes electrónicos externos registrados, con la opción de tener el sistema que conserve y archive los recibos. El sistema puede aceptar y verificar mensajes electrónicos codificados y manejar los mensajes electrónicos dentro y/o fuera de una "pared de fuego". Para los usuarios basados en la red, por ejemplo, los individuos o corporaciones que utilizan correos electrónicos basados en la red, tales como el MSN Hotmail® y Yahoo Mail®, tales usuarios podrían verificar un buzón o casilla o de otro modo colocar una bandera dentro de sus programas de correo electrónico para seleccionar en una base caso por caso, a registrar los correos electrónicos y/o archivar los mensajes utilizando el presente sistema. La firma digital puede ser creada utilizando técnicas de firma digital conocidas, tales como mediante la realización de una función de comprobación aleatoria sobre el mensaje, para producir un compendio de mensajes y luego codificar el compendio de mensajes. Firmas digitales separables pueden ser creadas para el cuerpo del mensaje, cualesquiera anexos, y para el mensaje completo incluyendo el cuerpo, los anexos, y los compendios de mensajes individuales. El compendio de mensajes descodificados proporciona un tipo de código de autenti ficación o validación de mensajes, o documentación segura. Otros códigos de autenticación y/o validación de mensajes pueden ser también generados y utilizados. En un aspecto, la invención es un método para proporcionar prueba respecto a la entrega y contenido de un mensaje electrónico que comprende: la recepción desde de un remitente a través de una red de computadoras, de un mensaje electrónico, teniendo el mensaje una dirección de entrega asociada con éste; el cómputo de un compendio de mensajes de acuerdo al mensaje, la codificación del compendio de mensajes, el envío del mensaje electrónicamente hacia un destino correspondiente a la dirección de entrega; el registro del Protocolo de Transporte de Correo Simple (SMTP) o el diálogo SMTP extendido (ESMPT) el cual efectúa la entrega del mensaje; la recepción de la información de Notificación de Condición de Entrega, asociada con el mensaje y la dirección de entrega; la provisión al remitente de un acuse de recibo electrónico, el recibo comprende: una copia de mensaje, el compendio del mensaje codificado, los transcritos (E)SMTP, y al menos un subgrupo de información de notificación de Condición de Entrega, y, en una fecha futura, la recepción electrónicamente del recibo electrónico desde el remitente, verificando que el compendio de mensaje codificado corresponde al mensaje, y verificando que el mensaje fue recibido por un mane dor de mensajes electrónicos asociado con la dirección de entrega. En otro aspecto más, la invención es un método de verificar la entrega de un mensaje electrónico, que comprende: en un sistema de computadoras de red de área amplia, la recepción de un mensaje electrónico proveniente del remitente del mensaje, para encaminarse hacia un domicilio o dirección de destino; el establecimiento de la comunicación con un servidor de mensajes electrónicos asociado con la dirección de destino, definiendo el servidor un servidor de destino; la averiguación del servidor de destino para determinar si el servidor de destino apoya la funcionalidad de Notificación de Condición de Entrega (DSN) ; la recepción de una respuesta a la indagación, la indagación a la respuesta conjuntamente definen un diálogo SMTP; la petición de la información de notificación de Condición de Entrega desde el servidor de destino de acuerdo a los resultados del diálogo SMTP; la transmisión del mensaje electrónico hacia la dirección de destino; la recepción de la información DSN proveniente del servidor de destino con respecto a la entrega del mensaje electrónico; y la provisión hacia el remitente del mensaje, de al menos una porción del diálogo SMTP y al menos una porción de la información DSN. En otro aspecto más, la invención es un método para verificar el contenido de mensaje electrónico recibido, que comprende: la recepción del mensaje electrónico; la generación de una firma digital correspondiente al contenido del mensaje recibido; la provisión del mensaje y de la firma digital hacia un destinatario designado; y, a un tiempo posterior, la verificación de que la firma digital corresponda al mensaje. De acuerdo con otro aspecto más de la presente invención, el método incluye el establecimiento de si un mensaje fue electrónicamente recibido por un receptor o destinatario que comprende, la provisión de un mensaje que va a ser despachado electrónicamente junto con una dirección del receptor, proveniente de un remitente; la creación de una firma que se asocia con el mensaje el despacho del mensaje electrónicamente hacia la dirección del destinatario; el rastreo del mensaje para determinar una Condición de Entrega final del mensaje despachado al domicilio del destinatario; después de la recepción de la Condición de Entrega final del mensaje, la generación de un acuse de recibo, el recibo incluye una copia del mensaje, la firma y una Condición de Entrega final para el mensaje; y la provisión del acuse de recibo al remitente, para el establecimiento posterior de que el mensaje fue electrónicamente recibido por el destinatario. De acuerdo con otro aspecto más de la presente invención, se proporciona un método para proporcionar que un mensaje electrónico enviado a un destinatario, fue leído, que comprende: la provisión de un mensaje electrónico junto con una dirección del destinatario; el cálculo de una firma digital correspondiente al mensaje electrónico; el despacho del mensaje electrónico, electrónicamente hacia la dirección del destinatario; la petición de una notificación del Agente del Usuario de Correo ("lectura" del cliente de correo electrónico) proveniente del destinatario después de la recepción de la notificación de lectura, la generación de un recibo de lectura, el recibo de lectura incluye una copia del mensaje, la firma digital para el mensaje electrónico correspondiente, y una segunda firma digital para la recepción de lectura desde el destinatario, y la provisión del recibo de lectura para la verificación posterior de que el mensaje fue recibido por el destinatario. De acuerdo con otro aspecto de la presente invención, se proporciona un método para validar la integridad de una supuesta copia de un mensaje electrónico, que comprende: la recepción de la copia supuesta del mensaje electrónico, la copia supuesta incluye un compendio de mensajes codificados, asociados con ésta; la descodificación del compendio del mensaje la generación de un segundo compendio de mensaje basado en el contenido de la supuesta copia; y la validación de la supuesta copia mediante la comparación del compendio de mensaje descodificado y el segundo compendio de mensaje, para determinar si los dos compendios de mensaje concuerdan. De acuerdo con un aspecto adicional de la presente invención, se proporciona un método para validad un correo electrónico registrado, recibido, que comprende la recepción de un acuse de recibo electrónico, el recibo incluye un mensaje base y un compendio de mensaje codificado; la descodificación del compendio de mensaje codificado la generación de un segundo compendio de mensaje proveniente del mensaje base; y la validación del correo electrónico si el compendio de mensaje descodificado concuerda con el segundo compendio de mensaje. En otro aspecto más, la invención es de un sitio de la red al cual el usuario puede acudir para enviar y recibir mensajes seguros, con el anfitrión del sitio de red que actúa como una tercera parte independiente que enviará y recibirá los mensajes y proporcionará información segura respecto al contenido y a la entrega de los mensajes. Los objetivos anteriormente descritos de la presente invención, y otras características y beneficios de la presente invención, se volverán claros para aquellos expertos en la técnica, cuando sean leídos en conjunto con la siguiente descripción detallada de una modalidad ilustrativa preferida y observada en conjunto con los dibujos anexos en los cuales números similares se refieren a partes similares, y las reivindicaciones anexas.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La descripción detallada de la modalidad preferida de la invención será realizada con referencia a los dibujos anexos . La figura 1 es un diagrama de sistema de una primera modalidad de la presente invención, en la cual los mensajes de salida son registrados al ser transmitidos por un Agente de Transporte de Correo (MTA) especial . Las figuras 2A-2F constituyen un diagrama de flujo representativo para registrar un correo electrónico de salida de acuerdo a la modalidad de la figura 1. La figura 3 es un diagrama de sistema de una segunda modalidad de la presente invención, en la cual los remitentes pueden dirigirse a un Agente de Transporte de Correo para transmitir mensajes seleccionados a través de un MTA de registro, separado. La figura 4 es un diagrama de sistema de una tercera modalidad de la presente invención, en la cual son enviadas copias al carbón (cc's) de los mensajes de salida hacia un servidor especial para ser registrados. La figura 5 es un diagrama de sistema de una cuarta modalidad de la presente invención, en la cual los usuarios componen los mensajes de salida para ser registrados en un sitio de la red designado.

La figura 6 es un diagrama de sistema de una quinta modalidad de la presente invención, en la cual los usuarios pueden enviar mensajes electrónicos registrados y almacenar acuses de recibo desde dentro de un Agente de Usuario de Correo (MUA) basado en la red. La figura 7 es un diagrama de flujo para validar un recibo de correo electrónico registrado; La figura 8 es un diagrama de sistema de una modalidad de la presente invención, para registrar los mensajes de entrada; La figura 9 es un diagrama de flujo para registrar los mensajes de entrada; La figura 10 es un diagrama de flujo para validar los mensajes registrados, recibidos: La figura 11 es un diagrama de sistema que muestra un uso ejemplar de la presente invención, por un negocio electrónico para registrar y reconocer la entrada y salida de comunicaciones .

DESCRIPCIÓN DETALLA DE LA INVENCIÓN Esta descripción no tiene que ser tomada en un sentido limitante, sino que es realizada meramente para fines de ilustrar los principios generales de la invención. Los títulos de sección y la organización general de la presente descripción detallada, son para fines de conveniencia únicamente, y no se pretende que limiten la presente invención. En consecuencia, la invención será descrita con respecto a los sistemas de mensajería de correos electrónicos que utilizan la arquitectura e infraestructura de la red de Internet. Se debe entender que el tipo de mensaje particular y la arquitectura de la red descritos en la presente, son para ilustración únicamente; la invención también aplica a otros protocolos de mensajes electrónicos y tipos de mensaje utilizando otras arquitecturas de red de computadoras, incluyendo las redes alámbricas e inalámbricas. Para conveniencia de discusión, los mensajes que son procesados de acuerdo a la presente invención pueden ser denominados en la presente como mensajes "registrados". En la discusión siguiente, el término "RPost" se referirá en términos generales a una entidad de tercera parte que crea y/o opera el software (dotación lógica informática) y/o el hardware (equipo físico) que implementa la presente invención y/o actúa como un verificador de mensajes, tercera parte, desinteresado. El término es utilizado para conveniencia de la discusión ejemplar, y no debe ser entendido como limitante de la invención.

I . RPOST COMO MODALIDAD DEL SERVIDOR DE CORREO DE SALIDA La figura 1 es un diagrama del sistema de una primera modalidad de la presente invención, en donde los correos electrónicos de salida son registrados de acuerdo a la presente invención. En esta modalidad, el servidor 14 de registro de RPost sirve como un Agente de Transporte de Correo de salida, primario (MTA) para un Agente de Usuario de Correo (MUA) 13, del remitente del mensaje. Aunque el receptor 18 del mensaje es técnicamente el destinatario y es por lo tanto meramente el receptor pretendido o el destino pretendido en este punto en el tiempo, por simplicidad de discusión esta entidad será denominada en la presente como el receptor, destinatario o destino. Nótese que un mensaje simple puede tener muchos destinos diferentes y que cada uno de éstos pueden ser alcanzados a través de un MTA diferente. El método de envío de mensajes registrados puede ser dividido en tres partes: 1) Preprocesa iento: pasos que van a ser tomados antes de que un mensaje sea transmitido ; 2) Transmisión: el método de entrega o entrega de mensajes a los destinatarios; 3) Procesamiento Postal: procedimientos para obtener información respecto a los mensajes después de su entrega, la creación de acuses de recibo y la validación de los acuses de recibo. 1.1 PREPROCESAMIENTO A la recepción de un mensaje para la transmisión, el servidor RPost creará los registros en una base de datos para cada mensaje, que serán utilizados para almacenar tal información cómo: a) el tiempo en el cual la hora a la cual el mensaje fue recibido; b) los nombres de los anexos del mensaje; c) el número de destinatarios del mensaje; Para cada destino del mensaje, la base de datos registrará : a) el nombre del destino (si está disponible) ; b) la dirección de Internet del destino; c) la hora a la cual el mensaje fue entregado al servidor de correo de destino; d) la Condición de Entrega de este destino. Las Condiciones de Entrega de Destinatario utilizadas por el sistema, incluirán: NO ENVIADOS Esta condición indica que el mensaje no ha sido enviado .

ENTREGADO Y ESPERANDO PARA DSN Esta condición indica que el mensaje ha sido entregado a un MTA que cumple con un ESMTP, que apoya la Notificación de Condición de Entrega (DSN) de modo que puede ser esperado una notificación de éxito/falla. ENTREGADO Esta condición significa que la copia del mensaje enviado a este destinatario ha sido exitosamente entregado a un servidor que no apoya la DSN de ESMTP. ENTREGADO AL BUZÓN Esta condición significa que un mensaje DSN ha sido recibido, lo cual indica que la copia de mens e enviado a este destinatario fue entregada al buzón del destinatario. RETRAZADO Esta condición significa que una DNS del MTA ha sido recibida, lo cual indica que la copia del mensaje enviado a este destinatario, ha sido retrazada hacia adelante hacia otro servidor, NO ENTREGABLE Esta condición indica que después de intentos repetidos el RPost ha sido incapaz de conectarse a un MTA para entregar los mensajes a este destinatario. FALLIDO Esta condición significa que una DSN de MTA ha sido recibida, la cual indica una falla para entregar una copia del mensaje a este destinatario. A este tiempo, el sistema realizará también las funciones comprobación aleatoria sobre los contenidos del mensaj e . El servidor 14 de RPost emplea una función de comprobación aleatoria y un algoritmo de codificación. La función de comprobación aleatoria puede ser una de cualesquiera funciones de comprobación aleatoria bien conocidas, incluyendo MD2 , MD5, el Algoritmo de Comprobación Aleatoria Segura (SHA) y otras funciones de comprobación aleatoria que pueden ser desarrolladas en el futuro. Los algoritmos de comprobación aleatoria y los métodos son descritos en Bruce Schneider, Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons, Inc. (Nueva York) 1993; Federal Information Processing Standard Publication 180-1 (FIPS PUB 180-1) Secure Hash Standard, National Institute of Standards and Technology; y la Patente de los Estados Unidos No. 5,530,757 expedida a Krawcyk, titulada "Huellas Digitales Distribuidas para la verificación de la Integridad de la Información", que son incorporadas por referencia en la presente, por sus enseñanzas de las funciones de comprobación aleatoria, codificación y los métodos y sistemas para implementar esas funciones . Otros métodos conocidos o nuevos de detectar si los contenidos del mensaje han sido alterados, pueden también ser utilizados. Una buena función de comprobación aleatoria H es de una sola vía; es decir, ésta es difícil de invertir dónde "difícil de invertir" significa que dado un valor h de comprobación aleatoria, es computacionalmente no factible encontrar alguna entrada x tal que H(x) = h. Además, la función de comprobación aleatoria debe ser al menos débilmente libre de colisiones, lo cual significa que dado un mensaje x es computacionalmente no factible encontrar alguna entrada y tal que H(x) = H(y). La consecuencia de esto es que desde un supuesto falsificador quien conoce el algoritmo utilizado y el valor de comprobación aleatoria o el compendio de mensaje resultante, no obstante, no será capaz de crear un mensaje falso o falsificado que calculará la clave para el mismo número. El valor de comprobación aleatoria h regresado por una función de comprobación aleatoria es en general denominado corno un compendio de mensaje. El compendio de mensaje es alguna vez denominado como una "huella digital" del mensaje x. Actualmente, se recomienda que las funciones de comprobación aleatoria de una sola vía produzcan salidas que sean al menos de 128 bitios de longitud, con el fin de asegurar que los resultados sean seguros y no fal sificablea . Conforme avanza el sistema actual de la técnica, la longitud recomendada para las funciones de comprobación aleatorias seguras, puede incrementarse.

El servidor 14 de Post computa un compendio de mensaje para el cuerpo de mensaje, y un convenio de mensaje separado para cada uno de los anexos del mensaje, y almacena éstos de una manera en la cual éstos pueden ser posteriormente incluidos en un acuse de recibo para el mensaj e . Antes de que el mensaje sea alterado en las formas que requerirá el registro, una copia del mensaje original y sus anexos se almacenan de una manera en la cual éstos pueden ser posteriormente recuperados por el sistema. El servidor RPost puede alterar un mensaje en varias formas antes de la transmisión al MTA del destinatario . Aunque tal cosa no es necesaria para la práctica de la invención, el mensaje puede ser etiquetado para denotar el hecho de que el mensaje ha sido registrado, tal como la inserción de la palabra "Registrado" o al comienzo de la línea "sujeto u objetivo" del mensaje, mediante la anexión de una etiqueta tal co o: "Este mensaje ha sido registrado con RPost. Visitar nuestro sitio de la red en www . Post . com para información adicional" al final del mensaje adicional u otra etiqueta. Adicionalmente , la etiqueta puede contener instrucciones, destinatarios de la Red Mundial o conexiones o enlaces que invitan y que permiten que el destinatario envíe una respuesta registrada al mensaje, al conectarse a una página de la red desde la cual los mensajes registrados pueden ser compuestos y enviados . Aunque el etiquetamiento es opcional, el mensaje entregado en general será denominado en la presente como el mensaje etiquetado. Los protocolos de Internet proporcionan dos formas de acuse de recibo para los mensajes de correo electrónico.

NOTIFICACIONES MTA Estos son correos electrónicos que son enviados por un MTA del destinatario, que notifican al remitente nominal del mensaje, de que han ocurrido varios eventos. Los MTAs que se conforman al protocolo SMTP típicamente enviarán solo una notificación en el caso en que el portador de correo no pueda entregar un mensaje al buzón del destinatario (como puede suceder si la dirección no es válida o si el buzón del destinatario ha excedido su cuota de almacenamiento asignada) . Con la introducción del estándar SMTP Extendido se volvió posible para los MTAs de envío, el pedir avisos de éxito y de falla en la entrega de los mensajes. Estas Notificaciones de Condición de Entrega (DSNs) son correos electrónicos que son enviados por un MTA de recepción hacia el remitente nominal del mensaje, cuando ocurren ciertos eventos: por ejemplo, el mensaje ha sido exitosamente depositado en el buzón del destinatario; el mensaje no puede ser entregado al buzón del destinatario por la misma razón; el mensaje del destinatario ha sido confiado a otro servidor el cual no da acuses de recibo de DSN. Nótese que únicamente los servidores de correo electrónico que apoyan el protocolo SMTP Extendido (ESMTP) apoyan esta forma de DSN y que el apoyo para esta función es opcional para los servidores ESMTP, y depende de la configuración seleccionada por los administradores de servidor . Aunque DSN es un término que únicamente entró en uso con el advenimiento del ESMTP, en lo subsiguiente, se utilizarán "DSN" para referirse a cualquier mensaje generado por el MTA, con relación a la condición o estado de un mensaje recibido, ya sea que éste esté o no en conformidad con el protocolo ESMTP.

AVISOS DE MUA (NOTIFICACIONES DE LECTURA) Estos son correos electrónicos que son enviados al autor (nominal) de un mensaje por el Agente de Usuario de Correo del destinatario (MUA) (programa de correo electrónico) cuando ocurren ciertos eventos: por ejemplo el mensaje es abierto para lectura, o suprimido del sistema sin ser leído. Por convención de la Internet (RFC 1891) , ningún programa MUA puede ser forzado a generar tales notificaciones. Si un MUA generará estos acuses de recibo, esto dependeré de la configuración elegida por su usuario. El servidor 14 de RPost configurará y transmitirá el mensaje de una manera que intenta promover los DSNs de MTA y los avisos de MUA que cumplan los MTAs y MUAs . Con el fin de promover una Recepción de Lectura proveniente de los MUAs que cumplen, deben ser incluidos ciertos encabezados en la sección de encabezado de un mensaje de correo electrónico. Diferentes MUAs responden a diferentes encabezados; de aquí que el Servidor 14 agregará varios encabezados diferentes a cada mensaje, pidiendo una notificación de lectura en una forma reconocida por diversos MUAs. Estos encabezados tomarán todos la forma: Etiqueta del encabezado: nombre de usuario <dirección del usuario Por ejemplo: Disposición-notificación-para: john smith < j smith@adomain . com> Leer-notificación-para: john smith < smithSadomain . com> donde "john simth" es el nombre del usuario a quien va a ser enviada la notificación MUA y <j smith@adomain . com> es la dirección de Internet de ese usuario. Normalmente tales encabezados podrían referirse al autor del mensaje, pero en el caso del presente método, se requiere que la notificación sea regresada al RPost, de modo que la notificación pueda ser procesada por el RPost. Para asegurar que esto sea así, el Servidor 14 insertará encabezados que requieren que los acuses de recibo de MUA sean enviados a una dirección donde éstos puedan ser procesados por el servidor de RPost, por ejemplo: <readreceipt@RPost . com> . Esto dirigirá a cualesquiera MUAs cumplidores del destinatario, para enviar sus notificaciones a una dirección de RPost para el procesamiento . La tarea de procesar las notificaciones de MUA regresadas da origen a otro problema que debe ser enfrentado en esta etapa. No existen estándares que gobiernen el formato o el contenido de las modificaciones de MUA. Frecuentemente, éstos citarán el objetivo del mensaje original y la hora del evento (por ejemplo, "abierto para la lectura") que éstos están reportando. Pero incluso si esta información no es incluida en la notificación, es raramente suficiente el identificar de manera única el mensaje que lo impulsa, o identificar el autor de ese mensaje. Cuando el sistema recibe una notificación de MUA, éste debe ser capaz de identificar el mensaje que lo impulsa, para incluir la información de notificación en el recibo de que RPost generará para el remitente. Alternativamente, el sistema debe ser al menos capaz de identificar con iablemente al remitente del mensaje al cual se refiere la notificación de MUA, de modo que la información de notificación pueda ser pasada sobre el remitente en la forma de un acuse de recibo de lectura RPost (ver más adelante) . Para lograr la última meta, el sistema puede tomar ventaja del hecho de que las direcciones de Internet tienen dos componentes: un campo de nombre y un campo de dirección, donde el campo de dirección es puesto de relieve por dos corchetes angulados "< >" . La mayoría de los MUAs incluirán ambos campos en la dirección de destino de sus notificaciones de MUA. En la composición de sus peticiones para los acuses de recibo de MUA, el sistema RPost incluirá la dirección de manejo de recibo de lecturas del Servidor 14, como la dirección para la notificación pero utilizará la dirección del remitente original en el campo de nombre del encabezado. Por ejemplo, donde el remitente original del mensaje es el usuario John Smith con la dirección de Internet j smith@adomain . com, el servidor de RPost incluirá los encabezados de la forma: Disposición-notificación-para: j smithcaadomain . com <readreceipts@RPost . com> Esto típicamente dará como resultado el MUA cumplidor que envía una notificación a readreceipts@RPost . com dirigido como: j smith@adomain, com ;readreceipts@RPost . com> Después de la recepción de tal notificación en la dirección nreadreceipts@RPost . com" , el servidor puede, mediante análisis sintáctico del campo de destinatarios, determinar que la notificación se refiere a un mensaje originalmente enviado por j smith@adomai . com, incluso si esto no pudiera ser determinado mediante cualquier examen de los contenidos de la notificación. Con esta información a la mano, el servidor puede luego empaquetar los contenidos de la notificación en un recibo de lectura de RPost, digitalmente firmado, y enviar el recibo a la dirección j smith@adomain . com . El sistema de RPost se esforzará también en promover y recolectar los avisos DSN de MTA, generados por los MTAs del destinatario. Ya que tales notificaciones son siempre enviadas a la dirección listada en el campo "DE o PROVENIENTE DE" del encabezado de mensaje, el servidor 14 debe alterar cada encabezado de mensaje de modo que el mensaje es recibido como "DE o PROVENIENTE DE:" una dirección de RPost en la cual las DSNs pueden ser procesadas. No obstante, el problema de procesar las DSNs da origen a otro problema, que debe ser enfrentado en esta etapa. Las DSNs no tienen ningún contenido o formado estándar; frecuentemente es imposible determinar, meramente mediante el examen de los contenidos de estos correos electrónicos, de que mensaje están dando notificación sus contenidos. Se suponía que este problema había sido enfrentado para DSNs generadas en cumplimiento con el protocolo ESMTP mediante el uso de los números de identi icación de la envoltura de DSN (ver RFC 1869) . De acuerdo al protocolo, un MTA de transmisión puede incluir un número de referencia junto con su petición para una DSN. Este número podría ser citado en cualquier DSN de retorno, permitiendo que el remitente identifique el mensaje de objetivo de la DSN. No obstante, como un asunto de hecho, muchos MTAs que se reportan así mismos como apoyadores de la DSN de ESMTP no devuelven una ID de envoltura de la DSN o alguna otra información suficiente para identificar confiablemente el mensaje objetivo. Finalmente, incluso donde una DSN no devuelve la información suficiente para identificar el mensaje del que está dando aviso, éste recuentemente no contendrá información suficiente para identificar el destinatario específico del mensaje que ha impulsado la notificación. De este modo, un mensaje simple puede ser enviado a dos destinatarios en un dominio; uno puede ser exitosamente entregado al buzón del destinatario; el otro no. El MTA para el dominio puede reportar estos eventos en una DSN en formas que no proporcionan manera para que el destinatario de la DSN determine cuál destinatario fue exitosamente entregado y cual no lo fue (como puede suceder por ejemplo, si la DSN reporta las direcciones del receptor o destinatario en sus nombres de alias locales, en vez de por las direcciones contenidas en el mensaje original. La presente invención resuelve este problema en cuatro pasos: 1) Un número de identificación único es generado para cada mensaje de salida (por ejemplo, basado en un lapso de tiempo) . Este número es almacenado en una base de datos . 2) Los receptores o destinatarios de cada mensaje son enumerados y los números de identificación son almacenados en una base de datos . 3) El mensaje es enviado separadamente a cada MTA de destinatario pretendido (Incluso cuando dos destinatarios tienen un nombre de dominio común y MTA común, el servidor 14 transmitirá el mensaje a ese MTA en dos sesiones de red telefónica de SMTP, separadas) . 4) Cuando el Servidor 14 transmite el mensaje a un MTA del destinatario, éste aumenta el campo "DE o PROVENIENTE DE" del mensaje, para mostrar el mensaje como si hubiera sido enviado de una dirección que incorpora la identidad única del mensaje y el número de identificación del remitente. La dirección también contiene una subserie (por ejemplo "rcpt" ) que hace posible que el Servidor identifique los mensajes de retorno como de DSNs . De este modo, un mensaje simple denominado "mmyyddss" por el Servidor 14, proveniente del remitente nombrado John Smith, puede ser enviado a su primer destinatario pretendido (denominado "a" por el sistema) con la lectura de encabezados: De: John Smith <rcptmmddyyssa@Rpost . com> El mismo mensaje podría ser enviado al segundo destinatario con una lectura de encabezado: De: John Smith <rcptmmddyyssb@Rpost . com> Muchos MUAs de correo electrónico mostrarán únicamente el nombre del remitente de un mensaje y de este modo la dirección especial no será observada por la mayoría de los destinatarios. La conclusión de esta forma de envío, es que cuando los MTAs de destinatario emiten DSNs (ya sea que cumplan o no ESMTP) ellos dirigirán esas DSNs a diferentes destinatarios de RPost. Al recibir estas DSNs, el Servidor 14 puede identificarlas como mensajes de DSN por su prefijo "RCPT" y, al analizar sintácticamente los destinatarios, puede determinar cuál mensaje y cuál destinatario es el objetivo de la DSN. El sistema 14 alterará el campo "DE o PROVENIENTE DE" de cada mensaje para referirse a un destinatario del mensaje, cada vez que éste intenta transmitir el mensaje al MTA de ese destinatario. Para asegurar las respuestas del destinatario a los mensajes transmitidos sean dirigidas de manera apropiada, el sistema 14 agregará un encabezado de mensaje explícito "responder a", dentro del mensaje y listando el nombre del remitente original y la dirección de Internet. En el caso del presente ejemplo éste podría ser: Responder a: John Smith < smith©adomain . com> Esto conducirá a los MUAs del destinatario a enviar a las respuestas a un mensaje recibido a la dirección del remitente efectivo, en vez de la dirección RPost construida. 1.2 TRANSMISIÓN Como se anotó anteriormente, es parte del método que el servidor de RPost transmita una copia separada de un mensaje de salida a cada destinatario de ese mensaje. Además, RPost intentará realizar cada entrega tal a través de una conexión de SMTP directa con un intercambiador de correo (MX) de registro para cada destino. Nota: Cada dirección de correo electrónico de Internet, válida, incluye un nombre de dominio de Internet o dirección de IP. Cada nombre/dirección de dominio tiene asociado con éste uno o varios servidores de correo electrónico autorizados para recibir correo para las direcciones en ese dominio. Se notará que algunos dominios tienen más de un servidor. El Servidor de Nombre de Dominio, responsable para cada dominio, difunde la identidad de sus servidores de correo a través de la Internet . Eata información es públicamente disponible y es manejada y transmitida en modos que se conforman a las reglas y convenciones que gobiernan el correo electrónico de la Internet y el Servicio de Nombre de Dominio. Antes de transmitir una copia de un mensaje a cualquier destino, el servidor de RPost realizará una búsqueda de Servidor de Nombre de Internet para identificar un MTA asociado con el dominio de destino. Habiendo identificado el MTA responsable para recibir el correo a nombre de una dirección de destino, el sistema intentará abrir una conexión de telnet con el MTA local de destino. Es práctica común para los correos electrónicos de Internet que éstos sean relevados de MTA a MTA hasta que éstos lleguen a su destino final . El propósito primario para requerir una conexión directa entre el servidor de RPost y el MTA de destino es de modo que el servidor de RPost puede registrar la entrega del mensaje (este registro toma la forma de un diálogo de SMTP) con el servidor de correo electrónico que tiene responsabilidad de propietario de recibir el correo electrónico para el nombre de dominio del destinatario. La existencia de este registro proporciona evidencia de auxilio de que el mensaje fue entregado, con mucho de la misma manera que un acuse de recibo de correo certificado proporciona evidencia de la entrega. El correo certificado por USPS es tratado como verificablemente entregado si se puede probar que ha sido entregado al agente autorizado del destinatario (por ejemplo, una secretaria, o empleado del departamento de correos) . En- el caso de cualquier impugnación legal al mérito de evidencia de un acuse de recibo de entrega de RPost, se reconocerá que en la selección de un proveedor de servicio de correo electrónico de Internet, el destinatario ha autorizado que el proveedor recolecte los mensajes electrónicos en su nombre. A su vez, ese proveedor de servicio ha reconocido su condición como agente autorizado para los destinatarios de correo electrónico de ese nombre de dominio, al difundir la dirección de sus MTAs como los servidores de correo electrónico de recepción para ese dominio. En consecuencia, habiendo entregado los mensajes directamente al servidor de correo responsable para recibir el correo electrónico de los destinatarios, RPost habrá entregado el mensaje a un agente que el destinatario ha autorizado legalmente para recibir su correo. Al registrar la transacción de entrega (aquella transacción que toma la forma de un diálogo SMTP) el RPost puede reclamar la posición de prueba de la entrega al agente autorizado del destinatario . Nótese que mientras que el método descrito en la presente intenta recolectar otras formas de prueba de entrega a cada destino, si estos intentos tienen o no éxito, esto dependerá de factores que no estarán en control de RPost (por ejemplo, la forma del apoyo de SMTP desplegado en el servidor de correo del destinatario). Por otra parte, cada entrega exitosa directa a un servidor de correo del destinatario, generará siempre un registro en SMTP. La grabación de este registro permite que el RPost proporcione prueba de la entrega a cualquier destino de Internet válido que cumpla con los protocolos mínimos (SMTP) para el correo de Internet. Esto representa una ventaja importante del método actual sobre otros métodos que pueden intentar probar la entrega al confiar en la DSN de ESMTP . Habiendo identificado el MTA para un destino de un mensaje, el servidor de RPost intentará abrir una conexión de ESMTP con el MTA de destino, al enviar un saludo "EHLO" en cumplimiento con RFC 1869. Si el SERVIDOR 16 apoya el ESMTP, éste responderá al listar cuáles servicios de ESMTP éste apoya . Si el SERVIDOR 16 apoya ESMTP, el servidor de RPost primeramente determinará si el SERVIDOR 16 apoya el Servicio "VERIFICAR" de ESMTP . El servicio Verificar permite que un servidor de SMTP que llama determine, entre otras cosas, si una dirección en un dominio de MTA es genuina. Si el Servidor de RPost determina mediante estos medios que la dirección a la que éste está intentando entregar su mensaje, no es válida, éste terminará la conexión, dejará de intentar la entrega de un mensaje a este destinatario y registrará, en su base de datos, la condición de este destino de mensaje cómo NO ENTREGABLE. Cualquiera que sea el resultado, el Servidor de RPost registrará el diálogo VERIFICAR de ESMTP de un archivo, y lo almacenará de modo que éste puede posteriormente anexado a, o incluido en el Acuse de Recibo de Entrega para este mensaje. Se debe notar que, aparte del interés para la seguridad, pocos servidores ESMTP apoyan la función VERIFICAR. Si el sistema 16 no apoya el método VERIFICAR entonces el servidor de RPost intentará no obstante entregar el mensaje al sistema 16. Típicamente, un MTA aceptará mensajes para cualquier dirección nominalmente en su dominio, y posteriormente enviará una DSN si la dirección no es válida . El servidor de RPost intentará luego determinar si el servidor de destino apoya la DSN del servicio ESMTP. Si no lo hace, RPost transmitirá el mensaje con una petición de que el SERVIDOR 16 notifique al remitente del mensaje con una DSN de ESMTP si la entrega al destinatario tiene éxito o falla. Después de la transmisión exitosa del mensaje a este destino, el sistema registrará la Condición de Entrega de este destino como ENTREGADO- ESPERANDO- PARA-DSN . Si el Servidor 16 responde al saludo "EHLO" de una manera que indica que éste no apoya la ESMTP, el servidor RPost emitirá un mensaje "HELO" para iniciar una conexión de SMTP. Si esta conexión es lograda, el servidor de RPost transmitirá el mensaje en cumplimiento con el protocolo SMTP y registrará la condición de entrega del destino como ENTREGADO . Si la conexión es SMTP o ESMTP, el servidor de RPost registrará el diálogo de protocolo completo entre los dos servidores. Típicamente, este diálogo incluirá los mensajes de protocolo en los cuales, entre otras cosas el servidor de destino se identifica a sí mismo, otorga permiso para cargar un mensaje para un destinatario nombrado, y reconoce que el mensaje fue recibido. El RPost guardará el registro de esta transacción de una manera tal que éste puede ser posteriormente recuperado e incluido en o anexado al Recibo de Entrega de RPost para este mensaje. Por diversas razones, el RPost puede no ser capaz de lograr una conexión de SMTP con un MTA de un destinatario, o éste puede lograr tal conexión pero ser negado el permiso para transmitir el mensaje por el destinatario. En ese caso, si la búsqueda de DNS de Internet revela que la dirección de destino es servida por múltiples MTAs, el servidor de RPost intentará entregar su mensaje a cada uno de estos a su vez. RPost continuará intentando entregar a un MTA apropiado, tan frecuentemente como lo permitan los recursos del sistema. Si, después de un lapso de tiempo, RPost no puede entregar el mensaje a una dirección, éste marcará la condición de este destinatario de este mensaje como "NO ENTREGABLE" y deja de intentar enviar este mensaje a esta dirección de destino. Cuando el servidor de RPost tiene éxito en transmitir un mensaje a un Servidor de destino que apoya explícitamente la DSN de ESMTP, el RPost registrará la condición de este destinatario para este mensaje como "ENTREGADO-Y- ESPERANDO- POR-DS " . Cuando el servidor de RPost tiene éxito en transmitir un mensaje al Servidor de destino vía una conexión que no apoya explícitamente la DSN de ESMTP, el RPost registrará la condición de este destinatario para este mensaje como "ENTREGADO" . 1.3 POSTPROCESAMIENTO Procesamiento de D5N Las DSNs de MTA serán regresadas al Servidor de RPost dirigidas a direcciones ficticias en su dominio de propietario (por ejemplo, "RPost.com"), estas direcciones han sido construidas como se describió anteriormente. El servidor de RPost explorará todo el correo de entrada dirigido al dominio y detectará los mensajes de DSN por su sub-serie de identificación (por ejemplo, "rcpt"). Mediante el análisis sintáctico de estas direcciones en la manera descrita anteriormente, el sistema puede identificar el mensaje y el destinatario que ha promovido la notificación DSN. No existe formato estándar para los mensajes DSN; tampoco existe ningún diccionario en el cual ellos reporten sus resultados. Para evaluar una DSN recibida, el sistema debe buscar en la línea objetivo y el cuerpo de los mensajes DSN para las palabras y frases que expresan el significado de DSN. Por ejemplo, frases tales como "entrega exitosa" o "entregado al buzón" o "fue entregado" señalan normalmente que el mensaje al que se refiere DSN fue depositado al buzón del destino. Cuando éste detecta tales frases, el sistema cambiará la Condición de Entrega de este destino del mensaje a "ENTREGADO AL BUZÓN" . Las frases tales como "no pudo ser entregado" , "error fatal", "falla" y "no exitoso" típicamente señalan una DS que reporta una falla por el MTA para entregar el mensaje del destino. Cuando este detecta frases tales como éstas en la DSN, el sistema cambiará el registro de la Condición de Entrega del destinatario a "FALLIDO" . Aunque el sistema siempre entrega el correo a un MTA de propietario para el dominio de destino, estos MTAs algunas veces relevarán el mensaje a un diferente servidor (como pueda ser el caso, por ejemplo, si el MTA receptor envía correo detrás de una pared de fuego) . En este caso la DSN contendrá frases tales como "relevado" o "relevado hacia delante" . En tales casos el sistema cambiará la Condición de Entrega del destinatario a "RELEVADO" . Habiendo evaluado la DSN y actualizado la Condición de Entrega del destinatario, en consecuencia, el sistema guardará la DSN y cualesquiera anexos que ésta pueda contener de una manera tal que éste o varios mensajes puedan ser incluidos en y/o anexados a un Recibo de Entrega de RPost.

Manejo de Mensajes De cuando en cuando, el sistema explorará cada mensaje enviado y examinará la condición de cada destino de ese mensaje, con el fin de determinar si el sistema ha completado el procesamiento de esa entrega de destino. Los criterios para la terminación dependen de la Condición de Entrega de destino: ENTREGADO: Esta condición indica que una copia del mensaje para este destinatario ha sido entregada a un MTA que no apoya la DSN de ES TP . Tal MTA puede no obstante enviar una forma de Notificación de Condición de Entrega en el caso en que el mensaje pudiera no ser entregado al Buzón del destinatario, (como puede suceder, por ejemplo, si la dirección de destino no corresponde a una cuenta válida dentro del dominio) . En consecuencia, el sistema no intentará la entrega para cada destinatario como completada, hasta que haya transcurrido un periodo de tiempo desde la entrega a la MTA del destinatario. Este periodo de tiempo típicamente dos a veinticuatro horas - representa un estimado del tiempo máximo requerido para que una mayoría de los servidores devuelvan una notificación de una falla a la entrega, y pueda ser ajustado si el dominio de destino específico está remoto, o se sabe que es pronto o tardado en la producción de tales modificaciones . RELEVADO: Esta condición significa que una DSN ha sido recibida, la cual índica que la MTA del destinatario ha enviado el mensaje a otro MTA que no apoya la DSN de ESMTP . En este caso, es posible no obstante que el MTA al cual ha sido entregado el mensaje, enviará una notificación de falla para entregar en el curso debido. En consecuencia, los destinatarios con esta condición son tratados como completados bajo las mismas condiciones de los destinatarios con la condición ENTREGADO. ENTREGANDO-Y-ESPERANDO-PARA-DSN: Esta condición indica que el MTA del destinatario apoya la DSN de ESMTP y que una DSN ha sido solicitada pero todavía no ha sido recibida. Puede suceder algunas veces que aunque un MTA se identifique a sí mismo como apoyando este servicio, éste no obstante no proporcionará a las DSNs incluso en el caso de entrega exitosa. En consecuencia, el sistema considerará las entregas hacia un destino con esta condición como completadas incluso si no es recibida la DSN después de un intervalo de tiempo. Este intervalo -típicamente de seis a veinticuatro horas - representa un estimado del tiempo máximo típicamente requerido para un MTA cumplidor, para que devuelva una DSN. ENTREGADO-AL-BUZÓN: Esta condición indica que una DSN que indica la entrega exitosa ha sido recibida para este destinatario y por lo tanto la entrega del mensaje a este destino es completada.

FALLIDO , NO ENTREGABLE : Las entregas a los destinatarios con esta condición son siempre tratados como completos. Cuando el sistema encuentra que la entrega a todos los destinatarios de un mensaje ha sido completada, el sistema construirá un Recibo de Entrega para el mensaje.

Creación de Recibos de Entrega Los recibos de entrega son correos electrónicos enviados al remitente original del mensaje registrado. El recibo 20 puede contener: 1. un ident ificador para fines administrativos. Este identif icador puede o no incluir la referencia a la identidad del remitente y/o el valor de la ID del mensaje de Internet del mensaje del remitente como fue recibido por el sistema; 2. la fecha y la hora en la cual el recibo fue generado ; 3. el cuerpo citado del mensaje original, junto con las direcciones de correo electrónico de sus destinatarios pretendidos; 4. la fecha y la hora en la cual- el servidor de RPost recibió el mensaje; 5. una tabla para cada listado de destino: (i) la hora en la cual el MTA del destinatario recibió el mensaje y/o la hora en la cual el sistema recibió un reporte DSN proveniente del MTA del destinatario; (ii) una Condición de Entrega de mensaje para ese destino. La Condición de Entrega citada en un Recibo de Entrega está basada en el registro interno del sistema de la Condición de Entrega de destino. Estos pueden ser transcritos como sigue: • Entregas a destinos cuya condición es FALLIDA o NO ENTREGABLE, serán registradas en el recibo como "fallidas" . · Las entregas a destinos cuya condición es ENTREGADO o ENTREGADO- Y-ESPERANDO- PARA-DSN serán registradas en el recibo como "entregado al servidor de correo" . · Las entregas a destinatarios cuya condición es ENTREGADO-A-BUZÓN serán registradas en el recibo como "entregado al buzón" . El propósito de estos reportes es apreciar correctamente al lector de la forma de verificación de la entrega, que el sistema ha sido capaz de lograr. 6. una lista de los anexos originales del correo electrónico, junto con los compendios de mensajes separados de esos anexos ; 7. las copias de los anexos al mensaje original, estando incluido cada anexo original como un anexo al recibo ; 8. los transcritos, sumarios o abstracciones de los transcritos de todos los diálogos de SMTP involucrados en la entrega del mensaje a cada destino; 9. las citas provenientes de los cuerpos y los anexos de todos los reportes de DSN recibidos, incluyendo cualesquiera detalles de la entrega o disposición del mensaje que éstos puedan revelar; y 10. cualesquiera archivos que fueron devueltos al sistema como anexos a los reportes DSN. Todos estos elementos separados del recibo pueden tener sus propios compendios de mensaje o firmas digitales incluidas dentro del recibo. Adicionalmente , el recibo puede incluir un compendio de mensaje codificado, completo, simple o una firma digital computada y anexada como parte del recibo, proporcionando de este modo un código de autenticación de mensaje simple, el cual podría ser utilizado para autenticar toda la información contenida dentro del recibo. Ya que el recibo mismo y los diálogos de SMTP y los reportes de DSN dentro del recibo contiene lapsos de tiempo, el recibo incluye un registro no falsificable del o de los destinatarios de los mensajes, el contenido de los mensajes, y la hora y rutas de la entrega.

Procesamiento de Notificación de MUA Las notificaciones de MUA podrían ser recolectadas e incorporadas dentro de los recibos de entrega de RPost de la misma manera que las DSNs de MTA. No obstante, las notificaciones de MTA son típicamente emitidas por los MTA de recepción dentro de unas pocas horas de la entrega, mientras que las noti icaciones de MUA no serán generadas, sí las hay, hasta que el destinatario abra su correo electrónico de MUA y el cliente tome alguna acción con respecto al correo recibido. Por esta razón, en esta modalidad de la invención, las notificaciones MUA son recolectadas separadamente de las notificaciones MTA y reportadas en "Recibos de Lectura de RPos" separados de los recibos de Recibos de Entrega de RPost . Las notificaciones de MUA promovidas por los encabezados de mensaje, construidas de la manera descrita anteriormente, serán regresadas a la dirección de RPost común (por ejemplo ,vreadreceipts@RPos . com" ) y cada notificación contendrá -- en el campo de nombre de su dirección - la dirección del remitente original de este mensaje. Debido a que ésta es la única información requerida para generar un recibo de lectura de RPost de la manera descrita más adelante, el sistema puede tratar los avisos de MUA, siempre que estos puedan llegar y sin necesidad de haber almacenado alguna información respecto al mensaje original en sus bancos de datos . Los avisos de MUA pueden reportar, entre otras cosas, que un mensaje ha sido leído por un destinatario, que un mensaje ha sido mostrado visualmente sobre la terminal del destinatario (ya sea leído o no), que un mensaje ha sido suprimido sin haber sido abierto. No existe estándar gobernado por protocolo para el contenido o formato de los mensajes de MUA. El sistema podría ser configurado para examinar el texto de los MUAs para interpretar sus reportes de la misma manera que el sistema utiliza para las DSNs de MTA. No obstante, en la modalidad actual de la invención, los MUAs no son evaluados o interpretados por el servidor de RPost pero son, más bien pasados sobre el remitente para su propia evaluación en una forma que puede ser autenticada por el RPost. Para lograr esto, el sistema creará un mensaje de correo electrónico estilizado como un "Aviso de Lectura de RPost" el cual puede incluir, entre otros artículos: 1. la línea objetivo del aviso de MUA recibido; 2. el cuerpo del aviso de MUA recibido citado como el cuerpo del Aviso de Lectura; 3. el aviso de MUA recibido incluido como un anexo ; 4. cualesquiera anexos al aviso de MUA recibido, incluidos como uno o varios anexos; 5. los compendios de mensajes del aviso de MUA recibido y cualesquiera anexos a ese aviso; 6. una fecha y un reloj fechador; 7. una comprobación aleatoria codificada de al menos los incisos 5 y 6 proporcionando una firma digital estampada en la fecha, autenticable , para el documento y todos sus contenidos.

Disposición del Recibo En el caso de la modalidad actual de la invención, los recibos de Entrega de Post y Avisos ae Lectura son enviados al remitente original del mensaje registrado. Ya que estos recibos son digitalmente firmados con una comprobación aleatoria codificada, el RPost puede autenticar la información contenida en estos mensajes a cualquier tiempo que éstos sean presentados al RPost para este propósito, de la manera descrita más adelante. Esto significa que una vez que éste ha transmitido una copia del recibo a su remitente (con las instrucciones hacia el remitente para retener el recibo para sus registros) , RPost ya no tiene necesidad de retener cualesquiera datos concernientes al mensaje o a su entrega, y puede expulsar todos los registros tales de su sistema. De este modo, el RPost no necesita mantener alguna copia del mensaje original o del recibo. Esta economía de memoria de archivo da a la presente invención una ventaja sobre los diversos sistemas de autenticación de mensajes, de la técnica anterior, que requerían grandes cantidades de almacenamiento de datos en el lado de proveedor de servicios. En este caso, la carga de retener los datos de recibos recae en el remitente original del mensaje. Alternativa o adicionalmente , el RPost verificador de tercera parte puede, quizás por una cuota adicional, almacenar una copia permanente del recibo o de algunos o todos los datos del recibo. El recibo o parte o partes del mismo pueden ser mantenidos en cualquiera de los dispositivos de almacenamiento de archivos, adecuados, incluyendo cinta magnética, CD-ROM, u otros tipos de dispositivos de almacenamiento. Adicional o alternativamente, el RPost puede devolver los recibos o partes de los mismos a un sistema de almacenamiento abocado a este propósito dentro del control del remitente o de la organización del remitente. Como se describió anteriormente, la información del recibo del RPost incluye todos los datos provenientes del mensaje del remitente original y sus anexos. Existen circunstancias en las cuales los usuarios del sistema pueden no desear emprender la carga de retener los recibos en sus registros (por ejemplo, aparte del miedo de pérdida accidental de datos) sino que también puede no desear tener los contenidos de su mensaje en las manos de la tercera parte RPost . En consecuencia, el RPost puede desechar los contenidos de los mensajes, pero almacenar en su base de datos únicamente la información (por ejemplo, el remitente, la fecha de la composición, los compendios de los mensajes, los destinos y las Condiciones de Entrega) como pueda ser requerida para RPost para autenticar y verificar la entrega de un mensaje cuando se presenta con una copia del mensaje retenido por el remitente.

Verificación En el caso en que el originador de un mensaje requiera evidencia a una fecha posterior de que un correo electrónico fue enviado, entregado y/o leído, el originador presente el o los recibos para el mensaje a los operadores del sistema. Por ejemplo, con el fin de probar que un mensaje particular fue enviado del remitente 10 al destinatario 18, el remitente 10 envía al RPost una copia del recibo 20 con una petición para verificar la información contenida dentro del recibo. Esto podría ser realizado mediante el envío del recibo a un buzón predefinido en RPost, por ejemplo, verify@Rpost . com. El RPost determina luego si el recibo es o no un recibo válido. Un recibo es un recibo válido si la firma digital concuerda con el resto del recibo, y los compendios del mensaje concuerdan con las porciones correspondientes respectivas del mensaje original. Específicamente, el RPost realiza la función de comprobación aleatoria sobre las diversas porciones del mensaje, incluyendo el cuerpo del mensaje, los anexos, y el mensaje completo, incluyendo el diálogo SMTP y los reportes de DSN, para producir uno o más compendios de mensajes correspondientes a la copia de mensaje pretendida. El RPost compara los compendios de mensaje en la copia pretendida, incluyendo el compendio de mensaje completo, con los compendios de mensaje que el RPost a computado a partir de la copia de mensaje pretendida. El compendio de mensaje completo puede ser comparado ya sea mediante descodificación del compendio de mensaje completo recibido como la firma digital en el recibo pretendido, mediante la codificación del compendio de mensaje completo que fue calculado a partir de la copia de mensaje pretendida. Si los compendios de mensaje incluyen la concordancia de la firma digital, entonces el recibo es un recibo auténtico generado por RPost. Asumiendo que fue utilizada una buena función de comprobación aleatoria y que las claves utilizadas en la función de comprobación aleatoria criptográfica y el algoritmo de codificación de firma digital no han sido divulgados a otros, es virtualmente imposible que el recibo haya sido "falsificado" por la persona que presenta el recibo. Es decir, el recibo debe haber sido un recibo que fue generado por el RPost y por lo tanto el mensaje contenido en el recibo, la información hacia/proveniente de, la fecha y la hora de entrega, el hecho de la entrega exitosamente, la ruta mediante la cual el mensaje viajó, y cualquier información de DSN contenida dentro del recibo, debe ser una copia fiel de esa información y debe ser precisa. RPost puede luego proporcionar la autenticación, verificación y confirmación de la información contenida dentro del recibo. Esta confirmación puede tomar la forma de una confirmación de correo electrónico, testimonio jurado de los empleados de RPost familiarizados con los métodos utilizados por RPost, testimonio jurado activo en las deposiciones y en la corte, y otras formas de tes imonio. RPost puede cargar al remitente 10, al destinatario 18, o a cualquier otra entidad, las cuotas por los diversos servicios de confirmación respectiva. El RPost puede también proporcionar testimonio o cualquier otra información con respecto a la no autenticidad de un supuesto recibo. El testimonio puede ser proporcionado de acuerdo con las Reglas Federales de Evidencia 901(9), 901(10), 803(6), 803(7), 1001-1004, 1006, 702-706, las reglas estatales correspondientes de evidencia, y otras reglas aplicables. En resumen, el sistema proporciona la evidencia confiable basada en el testimonio de una tercera parte desinteresada de que un mensaje particular que tiene un contenido particular fue enviado, cuándo fue éste enviado, quién lo envío, quién lo recibió, cuándo fue abierto para la lectura, y cuándo fue éste borrado. Esta evidencia puede ser presentada a cualquier tiempo en que surja una disputa con respecto al contenido y a la entrega de los mensajes, como por ejemplo en la formación del contrato, la sincronización de la compra de acciones u órdenes de venta y muchas otras aplicaciones. Los operadores de sistema pueden atestiguar respecto a la precisión de la información contenida en el recibo mismo, sin la necesidad de que los operadores conserven cualquier registro o copia de la información contenida en el recibo. Una ventaja significativa del sistema es que éste puede ser utilizado por los UAs existentes sin ningún cambio a éstos. Debido a que toda la computación, codificación, interrogación de ESMTP y el diálogo, la recolección del reporte del DSN, y la recopilación de recibos, son realizados por el servidor de RPost, que es una tercera parte, ninguna de estas funciones necesitan ser implementadas dentro del equipo del usuario. De este modo, los usuarios pueden tomar ventaja del sistema rápidamente y de manera fácil. En la modalidad de la invención descrita anteriormente, el Servidor de RPost registra la entrega de todos los mensajes que pasan a través de éste. Alternativamente, un servidor de RPost puede registrar únicamente aquellos mensajes que tienen ciertos destinos (por ejemplo, externos a una organización) o provenientes de ciertos remitentes (por ejemplo, un grupo de relaciones de clientes) . Alternativamente o adicionalmente , el servidor de RPost puede registrar únicamente aquellos mensajes que tenían caracteres o series distintivas en el objetivo o cuerpo del mensaje. Por ejemplo, el servidor puede registrar únicamente los mensajes que el remitente haya incluido " (R) " en el objetivo del mensaje. Todos los otros mensajes pueden ser entregados por el Servidor de RPost o alguna otra función del servidor como un MTA de Internet, ordinario. En esta modalidad, el RPost puede obtener ingresos en una variedad de formas, por ejemplo: RPost puede cargar al remitente 10 el mensaje a su organización, una cuota en una base de pre -mensaj e , en una base por kilobyte, o en una base periódica de cuota establecida, tal como mensualmente , o en una combinación de los anteriores . RPost puede también cargar las cuotas para autenticación y verificación de un recibo, con un esquema de cargos dependiendo de si la verificación buscada es un correo electrónico de retorno, simple, una declaración jurada escrita, o una declaración, testimonio de hechos jurado en la comparecencia o en la corte, o un testimonio jurado de experto en la comparecencia o en la corte. Si los usuarios optan por hacer que el RPost conserve copias de los recibos, el RPost puede cargar por artículo y/o por kilobyte las cuotas de almacenamiento por mes .

II. DIAGRAMA DE FLUJO PARA REGISTRAR UN MENSAJE DE SALIDA Las Figuras 2A-2G constituyen un diagrama de flujo que muestran una operación ejemplar de la primera modalidad del sistema. La modificación de este diagrama de flujo para aplicarse a otras modalidades está dentro de la experiencia de alguien familiarizado con los protocolos de software y correo electrónico. La Figura 3A, el pre -procesamiento , ilustra los pasos tomados con un mensaje antes de que éste sea transmitido por el Servidor de Registro (el Sistema) . Para registrar un mensaje de correo electrónico, en el paso 201 un originador/remitente/usuario crea un mensaje de correo electrónico utilizando un Agente de Usuario de Correo de Internet (MUA) . Los posibles MUAs incluyen: (1) los programas de correo electrónico en el lado del cliente ; (2) los programas de correo electrónico basados en el servidor; (3) los servicios de correo electrónico basados en la red; y (4) las formas de HTML enviadas a través de las páginas de la red. El mensaje puede contener archivos anexos como se describe en las Peticiones para Comentarios (RFCs) 822, 2046, y 2047, que son incorporadas por referencia en la presente. Los RFCs son una serie de notas respecto a la Internet, que discuten muchos aspectos de la comunicación de la computadora, enfocándose sobre los protocolos, procedimientos, programas y conceptos de la red. En esta modalidad, el sistema funciona como el servidor de correo de salida del remitente, y por lo tanto el mensaje del remitente será directamente transferido al Servidor RPost por el MUA del remitente (paso 202) . En el paso 203, el sistema crea una copia del mensaje original para ser almacenada para el procesamiento poste ior . En el paso 204, el sistema crea un registro en una base de datos que puede incluir información tal como: la hora en la cual el mensaje fue recibido por el servidor, los nombres y el o los tamaños del o de los anexos del archivo del mensaje; el nombre (si es conocido) de cada destino del mensaje; la dirección de Internet de cada destino; la hora en la cual el mensaje fue entregado al MTA de destino ( inicialmente este valor es nulo) y una unidad que registra la Condición de Entrega de cada destino. En el paso 205, la Condición de Entrega de cada destino es ajustada a "NO ENVIADO" . En el paso 206, el sistema genera y almacena un compendio digital generado a partir del cuerpo del mensaje. En el paso 207, el sistema genera y almacena una comprobación aleatoria o compendio de mensaje para cada anexo incluido en el mensaje. En el paso 208, el sistema puede crear una copia modificada del mensaje original. En esta segunda copia (paso 209), la línea objetivo original del mensaje puede ser enmendada para indicar que esta copia está registrada (por ejemplo por el pre -pendiente "Registrado"). En el paso 210, un aviso de que el mensaje es registrado por el sistema, junto con las condiciones al sitio de la Red Mundial (Word Wide Web) del sistema puede ser anexado al cuerpo del mensaje. En el paso 211, los encabezados de correo electrónico pueden ser agregados requiriendo notificación de lectura en una variedad de formatos de encabezado, reconocidos por diversos MUAs . Las peticiones para la notificación dirigen la notificación de retorno a una dirección asociada con el sistema: por ejemplo, "readreceipt'S'RPost . com" . Estos encabezados incluirán también la dirección del remitente original del mensaje en el campo de nombre de la dirección a la cual debe ser enviada la notificación MUA.

Habiendo sido completado el pre-procesamiento, el sistema transmitirá ahora una copia del mensaje a cada uno de sus destinos, como se ilustra en la Figura 2B. La Figura 2B ilustra los pasos requeridos para transmitir un mensaje registrado. Como lo indica el paso 220, el proceso requiere una transmisión separada para cada destinatario del mensaje. En el paso 221, el sistema cambia el campo de encabezado de su copia de trabajo del mensaje, para mostrar el mensaje como "DESDE O PROVENIENTE": un remitente cuyo nombre es el remitente original del mensaje, pero cuya dirección es una dirección "RPost.com" construida a partir de; a) una serie utilizada para identificar las notificaciones MTA de retorno (por ejemplo "RCPT" ) ; b) una serie que identifica de manera única el mensaje que es enviado; c) una etiqueta que identifica de manera única el destino al que está siendo enviada esta copia del mensaje. En el paso 222, utilizando el nombre de dominio del destino al que está actualmente enviando, el sistema realiza una búsqueda de intercambio de Correo de Servidor de Nombre de Dominio para encontrar la dirección de los MTA(s) responsables de la recolección del correo para los destinatarios en este dominio. En el paso 223, el sistema intenta realizar una conexión de telnet directa al TA del destino. Si la conexión falla, el sistema intentará realizar la conexión nuevamente. Con la condición de que el sistema no haya excedido un número máximo de reintentos (227) para este destino, el sistema intentará realizar nuevamente la conexión utilizando quizás otro servidor X para el dominio de destino (228) . Si, después de un número máximo de reintentos, el sistema no puede conectarse a un MTA para este destino, el sistema, como en el paso 226, registrará esta Condición de Entrega del destino como "NO ENT EGABLE" y dejará de intentar entregar este mensaje a este destino. Al conectarse al MTA de destino, el sistema comenzará a realizar un registro de su diálogo (E)SMTP con el MTA (225) . En el paso 229, el sistema intenta iniciar un intercambio SMTP Extendido (ESMTP) con el MTA de destino mediante el envío de un saludo "EHLO" . Si el MTS de destino apoya el ESMTP , el sistema determinará entonces (230) si el MTA de destino apoya la función de SMTP, VERIFICAR. Si el MTA apoya VERIFICAR, el sistema intentará determinar si la dirección de destino es una dirección válida dentro del dominio (231) . Si la dirección no es válida, entonces, como en el paso 232, el sistema registrará la Condición de Entrega de este destino como "FALLA" y dejará de intentar entregar este mensaje a este destino. Si la dirección es válida o si el servidor de ESMTP no apoya VERIFICAR, el sistema entonces (233) determinará si el MTA de recepción apoya la DSN (notificación de Condición de Entrega) del servicio ESMTP. Si el MTA no apoya la DSN de ESMTP, el sistema transmitirá el mensaje con las peticiones de ESMTP para notificarle al remitente nominal del mensaje del éxito o falla de la entrega (234). Habiendo transmitido el mensaje, el sistema registrará la Condición de Entrega como "ENTREGADO-Y-ESPERANDO- POR DSN" (235) . Si el MTA receptor no apoya el SMTP Extendido, el sistema transmitirá el mensaje utilizando SMTP (236) y registrará la condición de destino como "ENTREGADO" (237. Habiendo entregado el mensaje, el sistema almacenará luego el diálogo (E)SMTP, registrando la entrega de una manera en la cual éste puede ser posteriormente recuperado (238) e intentará enviar el mensaje a otro dest ino . Habiendo transmitido un mensaje a su o sus destinos, el sistema debe realizar varias funciones con el fin de obtener la información respecto a la disposición del mensaje. La Figura 2C ilustra el proceso mediante el cual el sistema procesa las Notificaciones MTA regresadas por los MTAs del destinatario. Debido al formato utilizado en los encabezados de los mensajes enviados ilustrados en la Figura 2B paso 221, las notificaciones de mensaje MTA serán entregadas a una dirección local ficticia en el servidor. El sistema será capaz de detectar estas notificaciones por una serie (por ejemplo "rcpt" incrustada en sus destinatarios (241) . Al analizar gramaticalmente la dirección, como se ilustra en 242, el sistema puede determinar cuál mensaje a cuál destino impulsó la notificación recibida. En el paso 243, el sistema explora la línea objetivo y el cuerpo de los MTAs recibidos, para las frases que indican si el MTA está reportando una entrega exitosa, una entrega fallida, o que el mensaje ha sido relevado a otro servido . En el caso en que el proceso en el paso 243 revele que la notificación está reportando una entrega exitosa, el sistema, como se ilustra en el paso 245, cambiará la Condición de Entrega del destino relevante del mensaje relevante a "ENTREGADO AL BUZÓN" . Si el sistema determina que el aviso del MTA está reportando una falla de la entrega, el sistema (247) cambiará la Condición de Entrega del destino relevante del mensaje relevante a "FALLA" . En el caso en que el sistema determine que la notificación MTA indica que el mensaje fue relevado a otro servidor, el sistema, como se ilustra en el paso 249, cambiará la Condición de Entrega del destino relevante del mensaje relevante a "RELEVADO". Habiendo procesado la Notificación MTA, el sistema guardará este mensaje y todos sus anexos de una manera tal que éstos pueden ser posteriormente recuperados y utilizados en la construcción de un acuse de recibo para este destino (250) . De cuando en cuando, como se ilustra en la Figura 2D, el sistema examinará la condición de cada mensaje para determinar si el sistema ha recuperado todas las notificaciones MTA que probablemente esté por recibir en cada destino del mensaje y puede por lo tanto proceder a construir un recibo para el mensaje. El sistema examinará la Condición de Entrega de cada destino del mensaje. Si cualquier destino tiene la Condición de Entrega "NO ENVIADA", entonces el procesamiento del mensaje no está completo (252) . Si la Condición de Entrega de un destino es "ENTREGADO- Y -ESPERANDO-POR-DSN" entonces el sistema no considerará el procesamiento para este destino como completo a no ser que, como se ilustra en el paso 254, el tiempo desde que la entrega del mensaje ha excedido el periodo de entrega del sistema (por ejemplo 24 horas) . Si la Condición de Entrega de un destino está "ENTREGADA", (257) entonces el sistema considerará el procesamiento de este destino como completo con la condición de que (258) un periodo de tiempo haya transcurrido, el cual los operadores del sistema tratan como suficiente para haber recibido aviso de la falla de la entrega a partir del MTA de destino (por ejemplo 2 horas) . Cualquier otra Condición de Entrega de destino (por ejemplo "FALLIDO" , "NO ENTREGABLE" , "ENTREGADO AL BUZÓN") es tratado como que ha sido completado el procesamiento . Si el procesamiento de cualquier destino de mensaje no está completo, el sistema no toma acción, sino que se mueve para considerar otros mensajes en el sistema (paso 255) . No obstante, como se ilustra en el paso 259, si el procesamiento de cada destino del mensaje está completo, el sistema generará un Acuse de Recibo de Entrega para el mensaj e . Como se ilustra a manera de ejemplo en la Figura 2E, el recibo puede incluir: Un identificador para fines administrativos como en el bloque 271. Este identificador puede ser o puede incluir referencia a la identidad del remitente y/o el valor de la Identidad del Mensaje de Internet del mensaje del remitente, como fue recibido por el sistema. Como en el bloque 272, el cuerpo entre corchetes del mensaje original 12 conjuntamente con las direcciones de correo electrónico de sus destinatarios pretendidos, pueden también ser incluidos. Como en el bloque 273, una tabla para cada listado de destinatarios puede incluir: • el tiempo en el cual el MTA del destinatario recibió el mensaje y/o la hora en la cual el sistema recibió la DSN proveniente del MTA del destinatario; • el reporte de la Condición de Entrega del mensaje para ese destino, por ejemplo, "Entregado al Servidor de Correo" , "Entregado al Buzón", "Relevado", "Falla de la Entrega" , "No entregable" . Como en el bloque 274, una lista de los anexos originales del correo electrónico junto con sus valores de comprobación aleatoria separados o los compendios de mensaje. Como en el bloque 275, los transcritos o abstracciones de los transcritos de todos los diálogos SMTP involucrados en la entrega del mensaje a cada destino. Como en el bloque 276, las citas de los cuerpos y los anexos de todas las DSNs recibidas incluyendo cualesquiera detalles de entrega o disposición del mensaje que éstos puedan revelar. Como en el bloque 277, el sistema puede anexar al recibo copias de todos los anexos del mensaje original, y, como en el bloque 278, el sistema puede adicionalmente anexar archivos regresados al sistema como anexos a las DNSs. En el paso 279, habiendo generado el texto del recibo, el sistema genera luego una primera comprobación aleatoria para el mensaje de correo electrónico, y una o varias segundas comprobaciones aleatorias para cualesquiera anexos al cuerpo del recibo, y calcula una firma digital para cada una de las comprobaciones aleatorias, utilizando una clave de codificación conocida únicamente para los operadores del sistema. La codificación puede emplear, por ejemplo, el Estándar de Codificación de Datos descrito en la Publicación 4-2 de Estándares de Procesamiento de Información Federal (FIPS PUB 46-2), el Estándar de Codificación de Datos, Instituto Nacional de Estándares y Tecnología, que es incorporada por referencia en la presente. Alternativamente, otros métodos nuevos o conocidos de codificación del valor de comprobación aleatoria pueden ser también utilizados. En el paso 280, la comprobación aleatoria codificada es luego anexada al final del mensaje como la "firma digital del documento" . En el paso 281, el recibo 20, estando ahora completo, puede ser enviado por correo electrónico al remitente con el aviso de que éste es mantenido para los registros del remitente. En el paso 282, el sistema puede ahora suprimir todas las copias del mensaje original, anexos, y las DSNs . Alternativamente, en vez de enviar el recibo al remitente, el sistema puede almacenar el recibo, o el remitente y el sistema pueden almacenar el recibo. Debido a que las notificaciones de MUA son devueltas únicamente a la opción del destinatario y únicamente cuando el destinatario toma alguna acción con respecto al mensaje recibido, las modalidades del sistema pueden elegir tratar estos mensajes de retorno de manera diferente a las notificaciones de MTA. La Figura 2F ilustra cómo pueden ser tratadas estas notificaciones de MUA por el sistema. Las notificaciones de MUA son solicitadas por el sistema mediante la inclusión de diversos encabezados en los mensajes de salida en la manera mostrada en la Figura 2A, paso 211. Estos encabezados dirigen a los MUAs cumplidores a enviar las notificaciones a una dirección del sistema (por ejemplo "readreceipt@RPost.com") mantenidos aparte para este propósito. Los encabezados también utilizan, en el campo "nombre" de esta dirección de retorno, la dirección de correo electrónico del remitente original del mensaje. En consecuencia, en el paso 286, cuando las notificaciones de MUA son devueltas al readreceipt@RPost . com el sistema puede, al examinar la dirección de la notificación, determinar la dirección a la cual debe ser enviada la notificación de lectura . Después de la llegada de un recibo de lectura desde la MUA de un destino, el sistema, en el paso 287, genera un recibo de lectura que contiene el objetivo de las notificaciones de MUA recibidas, como su objetivo e incorpora, en su cuerpo del mensaje, el cuerpo de la Notificación de MUA recibida. En el paso 288, el sistema anexa al recibo cualesquiera archivos que puedan acompañar el recibo de MUA (típicamente, éstos pueden incluir detalles de la entrega o la disposición, y referencias de identificación al correo electrónico original). En el paso 289, el sistema genera una comprobación aleatoria para cualesquiera archivos anexados al recibo y registra esta comprobación aleatoria en el cuerpo del recibo. En el paso 290, el sistema genera una comprobación aleatoria para el cuerpo del recibo, y sus anexos, codifica esta comprobación aleatoria, y anexa el resultado al mensaje como una "firma digital del documento" .

En el paso 291, el sistema envía el recibo resultante al remitente del mensaje. En el paso 292, habiendo enviado este recibo, el sistema puede suprimir todos los registros internos de la transacción.

III. RPOST COMO MODALIDAD SECUNDARIA DEL SERVIDOR DE CORREO La Figura 3 es un diagrama de sistema de una segunda modalidad de la presente invención, en donde el servidor RPost no sirve como el MTA primario del usuario, sino más bien trabaja en combinación con otro MTA, En esta modalidad, el remitente puede elegir registrar un mensaje de salida particular mediante la inclusión de alguna forma de bandera en un mensaje de salida, objetivo de mensaje, o dirección de mensaje. Por ejemplo, si y solo si un remitente incluye el símbolo " (R) " en el objetivo del mensaje, el MTA del remitente dirigirá el mensaje para ser transmitido a través del servidor RPost, para generar un recibo. En esta modalidad, los operadores de RPost reciben ingresos del operador del MTA del remitente, por mensaje y/o por kilobytes transmitidos.

IV. CC PARA LA MODALIDAD DE RPOST La Figura 4 es un diagrama de sistema de una tercera modalidad en la cual es enviada una copia al carbón ("ce") al servidor de RPost. En esta modalidad, el usuario o el remitente 10 del mensaje puede utilizar un MUA estándar y el MTA estándar sin modificación. El remitente 10 del mensaje compone el correo electrónico que tiene un cuerpo de mensaje y cualquier número de anexos, y lo dirige al destinatario 18 del mensaje, junto con cualesquiera copias al carbón (ce' s) y copias al carbón ciegas (bcc's) como se desee. Adicionalmente , el remitente 10 del mensaje dirige una ce al RPost. El servidor 14 de RPost marca el mensaje como se describe anteriormente, y envía el mensaje etiquetado incluyendo los anexos al MTA 16 del destinatario, y cualesquiera cc's designadas. A la recepción de tal copia, el Servidor 14 de RPost puede enviar un acuse de recibo de correo electrónico de la copia. El destinatario 18 y otros destinos del mensaje recibirán ahora dos versiones del mismo mensaje: una primera versión del mensaje recibido directamente del remitente 10, y una segunda y etiquetada versión enviada desde el RPost. Una vez que el RPost recibe la confirmación del MTA 16 del destinatario, de que la versión etiquetada del mensaje fue exitosamente recibida por MTA 16 del destinatario, el servidor 14 de RPost compone el recibo 20 del mensaje como se describe anteriormente, y envía el recibo hacia el remitente 10 para su registro. Pueden ser generados los ingresos mediante el establecimiento de cuentas para los dominios de elaboración original de mensajes o los remitentes de mensaje individuales, y cargando a las cuentas del usuario por mensaje, por kilobyte, por mes o una combinación de éstos. Los ingresos pueden también ser generados para la colocación de anuncios en los recibos y a partir de los servicios de autenticación y verificación como se describió previamente.

V. MODALIDAD DEL SITIO DE LA RED La Figura 5 es un diagrama del sistema de una cuarta modalidad. En esta modalidad, el servidor 14 de RPost está asociado con un sitio de la red en el cual un usuario compone los mensajes. El remitente 10 del mensaje visita el Sitio de la Red RPost y compone su mensaje en el sitio de la red al introducir "para", "ce", "bec" , "Objetivo" y la información del texto del mensaje deseado. Los anexos pueden ser agregados mediante el uso de características disponibles sobre los buscadores estándares y los servidores de la red. En esta modalidad, el remitente debe proporcionar adicionalmente una dirección a la cual puede ser enviado el recibo del registro. El servidor 14 de RPost envía el recibo al remitente 10 a través del MTA del remitente. Los ingresos pueden ser generados mediante el establecimiento de cuentas para los dominios de origen de mensajes o los remitentes de mensajes individuales, y cargando a las cuentas de los usuarios por mensaje, por kilobyte, por mes, o una combinación de éstos. Los ingresos pueden también ser generados para la colocación de anuncios en los recibos y a partir de los servicios de autenticación y verificación como se describió previamente.

VI . MODALIDAD MUA BASADA EN LA RED La Figura 6 es un diagrama del sistema de una quinta modalidad. En esta modalidad, el servidor 14 de RPost está asociado con un Agente de Usuario de Correo, basado en la red. Además de permitir que los usuarios compongan el correo a través de un buscador de la red, tal MUA les proporciona a los suscriptores los buzones observables con el buscador que muestran los mensajes almacenados en el sitio del servidor de la Red. Los suscriptores a tal servicio tienen acceso a las cuentas de correo con los nombres de usuario y las palabras clave. En esta modalidad, el remitente 10 del mensaje visita el sitio de la red de RPost, accede a una cuenta de correo electrónico Basada en la Red al introducir un nombre de usuario y una clave, y compone su mensaje que es transportado para la entrega al servidor 14 de RPost. Los recibos generados por el servidor de RPost son devueltos a un buzón basado en la red, asociado con la cuenta del suscriptor. Además de las fuentes de ingresos disponibles en otras modalidades, en esta modalidad los operadores pueden cargar las cuotas de almacenamiento para los recibos mantenidos en el buzón basado en la red. En todas estas modalidades, el recibo puede servir como evidencia de que: (1) el originador envió un mensaje de correo electrónico ; 2) el mensaje fue enviado a una cierta hora; 3) el correo electrónico fue dirigido a ciertos destinatarios ; (4) el correo electrónico fue entregado al buzón de correo electrónico de cada uno de sus destinatarios pretendidos; (5) el correo electrónico fue entregado a una cierta hora; (6) el correo electrónico fue entregado por una cierta ruta de la red; y (7) el mensaje de correo electrónico y sus anexos tuvo el contenido especifico registrado en el recibo . Además, el sistema bajo ciertas circunstancias genera un recibo separado, el cual puede ser utilizado como evidencia de que: (1) el correo electrónico fue inspeccionado a través del Agente del Usuario de Correo (MUA) del destinatario; y (2) el destinatario tomó ciertas acciones en respuesta al mensaje, por ejemplo leyó o borró el correo electrónico, a una hora particular. Como con las otras modalidades, esta modalidad produce evidencia documentada que puede ser atestiguada y verificada por operadores desinteresados terceras partes, del sistema, de la entrega e integridad de un mensaje electrónico. En otras palabras, el sistema puede ser considerado como transformación del correo electrónico a un correo electrónico registrado que puede ser posteriormente utilizado para probar que un mensaje de correo electrónico particular fue enviado, que éste fue exitosamente entregado y cuándo y cómo . Si surge una disputa, la disputa puede ser resuelta a través del recibo generado por el sistema, debido a que el recibo está codificado de modo que los operadores del sistema pueden determinar la autenticidad del recibo como el producto del sistema. Después de esto, los operadores del sistema pueden atestiguar respecto a la precisión de la información contenida en un recibo auténtico, confiando únicamente en la información contenida en el recibo mismo y sin la necesidad de que los operadores preserven cualquier registro o copia de la información contenida en el recibo. Además de estos beneficios, los recibos generados por el sistema pueden también ser útiles como evidencia de la existencia y autoría de tales materiales, como puedan ser transmitidos a través del sistema. Además, el sistema es fácil de utilizar, ya que el sistema puede ser utilizado a partir de cualquier programa/ UA del cliente de correo electrónico de la Internet, de modo que no existe software adicional requerido.

DIAGRAMA DE FLUJO PARA LA VALIDACIÓN DE UN RECIBO La Figura 7 es un diagrama de flujo que ilustra un método ejemplar para validar un recibo. En el caso de que el remitente de un mensaje deba requerir evidencia de que un correo electrónico fue enviado y entregado (y/o leído) el remitente presenta el o los recibos correspondientes al mensaje, a los operadores del sistema en el paso 700. Los operadores del sistema entonces, en el paso 702, desprenden y descodifican la firma digital del documento anexo al recibo. En el paso 703, los operadores generan una comprobación aleatoria del balance del documento, incluyendo los anexos. En el paso 704, si el valor de comprobación aleatoria actual no concuerda con el valor de comprobación aleatoria descodificado, entonces el sistema genera un reporte que establece que el RPost no puede autenticar el recibo como un registro preciso de la entrega o los contenidos del mensaje descrito en el recibo. Si la comprobación aleatoria descodificada es equivalente a la comprobación aleatoria actual del mensaje, el sistema puede, como en el paso 706, garantizar que la información contenida en el cuerpo del mensaje permanezca sin cambio desde que el recibo pasó a través del sistema. Si el mensaje original no contenía anexos, el sistema puede ahora generar un reporte que garantice que el recibo es un registro preciso de los contenidos del mensaje y su entrega por el servidor de RPost . Si el recibo reporta que el mensaje original contenía anexos, entonces el recibo también registrará el nombre y el valor de la comprobación aleatoria de cada anexo. En la generación del recibo, todos los anexos del mensaje original son anexados sin cambio al recibo. En consecuencia, el sistema, para cada archivo anexo tal, generará una comprobación aleatoria del archivo anexo (708) y lo comparará al valor de la comprobación aleatoria registrado en el cuerpo del recibo (709) .

Si el valor de la comprobación aleatoria calculado de un archivo concuerda con el valor incluido en el recibo, el sistema puede garantizar que el archivo anexo al recibo es idéntico a aquel anexo al mensaje, como se entregó originalmente. Si las comprobaciones aleatorias no concuerdan, entonces el sistema reportará que éste no puede garantizar que el archivo anexo al recibo sea idéntico al archivo anexo al mensaje original. Habiendo realizado este cálculo para cada archivo anexo al mensaje original, el sistema prepara un reporte que reporta sobre la autenticidad del recibo y cada uno de sus archivos anexos (710) , o el cual reporta la falla de la validación (712) . Habiendo completado su evaluación, el sistema anexará entonces una copia del recibo y de todos sus anexos al reporte que éste ha generado, y lo enviará vía correo electrónico a la dirección de retorno del usuario quien envió el reporte para la validación.

VII. REGISTRO DE CORREOS ELECTRÓNICOS DE ENTRADA La Figura 8 es un diagrama de sistema que ilustra otra modalidad más de la invención, en la cual son registrados los correos electrónicos de entrada. En esta modalidad, un remitente 60 de mensajes envía un mensaje 70 de correo electrónico. El TA 62 del remitente envía el mensaje 70 sobre la Internet, como es usual. No obstante, en esta modalidad el RPost contrata con el suscriptor del servicio/destinatario 68 para registrar los correos electrónicos de entrada. De acuerdo al acuerdo, el RPost es designado con Network Solutions, Inc (NSI) u otra autoridad de nombre de dominio como el destinatario del correo (servidor MX) para el destinatario 68. Esto provoca que la petición de Servicio de Nombre de Dominio (DNS) realizada por el MTA 62 del remitente regrese a la dirección de IP del RPost como la dirección IP para el destinatario, que a su vez provoca que el MTA 62 del remitente envíe el mensaje de correo electrónico al servidor 64 de RPost. El servidor 64 de RPost actúa como un MTA de SMTP, POP, POP3 o IMAP (colectivamente, el "servidor de correo POP") para el destinatario 68. Los MTAs de SMTP, POP e IMAP son gobernados por RFC 821, el protocolo SMTP , el protocolo de Oficina Postal RFC 1939 Versión 3 (el cual obsoleció a RFC 1725) , y RFC 2069 IMAP (Protocolo de Acceso a Mensajes de Internet) Versión 4 rev 1 (el cual obsoleció a RFC 1730) , los cuales son incorporados por referencia en la presente. El Servidor 64 de .RPost prepara una versión registrada 74 del mensaje original 70, y coloca esta versión registrada 74 en la casilla del destinatario 68 en vez de, o en adición a, el mensaje original 70. La versión registrada puede tener todas las características de verificación y de información, y las opciones discutidas al principio en conexión con los recibos de los correos electrónicos. Esta información puede incluir, pero no está limitada a: compendios de mensajes individuales para cada uno del cuerpo y el texto del mensaje, la información hacia/desde, otra información de encabezado, cada anexo, un compendio de mensaje completo, y la firma digital, y la información de encaminamiento del mensaje y las etiquetas. La versión registrada 74 del mensaje 70 como se muestra en la Figura 6, incluye el cuerpo del mens je que incluye la información de encabezado, un anexo, compendios de mensajes separados para cada uno, y una firma digital o compendio de mensaje codificado. Las funciones de comprobación aleatoria y codificación son realizadas utilizando frases privadas o claves privadas conocidas únicamente para los operadores del sistema. La versión registrada 74 es hecha disponible al destinatario 68 para la inspección o la descarga a través del MUA del destinatario. El servidor de RPost puede enviar opcionalmente un correo electrónico 72 de confirmación al remitente 60 del mensaje. El mensaje de confirmación 72 puede ser un mensaje de texto simple que indica que un mensaje fue recibido y registrado. El mensaje de confirmación 72 podría también incluir un mensaje tal como, "Su mensaje de correo electrónico fue recibido el 24 de marzo del 2000 a las 2:05 p.m. La firma digital del mensaje era [firma digital de 128-bitios] . Para más información, visite nuestro sitio en la red en www.RPost.com". Alternativamente, o adicionalmente , el mensaje de confirmación 72 podría incluir toda la información contenida en la versión registrada 74. De este modo, el sistema puede proporcionar al destinatario 68 del mensaje un recibo 74 u otra confirmación verificable de que: (1) el destinatario recibió un mensaje de correo electrónico ; (2) el mensaje fue recibido a una cierta hora; (3) el correo electrónico fue dirigido desde un cierto remitente; (4) el mensaje parece ser entregado vía una cierta ruta en la red; y (5) el mensaje de correo electrónico y sus anexos tuvo un contenido específico. En consecuencia, el sistema proporciona evidencia, la cual puede ser atestiguada por los operadores del sistema, de que los mensajes electrónicos particulares y los documentos fueron entregados a los destinatarios, teniendo cierto contenido y representando por sí mismos como provenientes de ciertos remitentes. La Figura 9 es un diagrama de flujo que ilustra un ejemplo del registro de correo de entrada. En el paso 901, el servidor 64 de Post recibe un nuevo mensaje de correo electrónico. En el paso 902, el sistema genera una comprobación aleatoria/firma digital de los contenidos del mensaje, incluyendo los encabezados y los anexos del mensaje. Adicionalmente , el sistema puede generar una comprobación aleatoria separada para cada anexo de mensaje. En el paso 903, el sistema codifica la o las comprobaciones aleatorias utilizando una clave de codificación conocida únicamente para los operadores del sistema. En el paso 904, la o las comprobaciones aleatorias codificadas, resultantes, son luego anexadas al cuerpo del mensaje. Luego, en el paso 905, el mensaje modificado puede ser hecho disponible para la inspección o la descarga a través del MUA del destinatario. La Figura 10 es un diagrama de flujo de un ejemplo de validación de un mensaje de correo electrónico, registrado, recibido. En el paso 1000, en el caso en que el destinatario de un mensaje deba requerir evidencia de que un correo electrónico con un contenido específico fue recibido a una hora particular, el destinatario puede presentar una copia de la versión registrada 74 (Figura 8) del mensaje 70 del correo electrónico a los operadores del sistema, para la verificación. Para verificar el mensaje, en el paso 1001 el sistema desprende y descodifica la firma digital del documento anexo al mensaje. En el paso 1002, el sistema genera una comprobación aleatoria del balance del documento, y uno para cada archivo anexo al mensaje. En los pasos 1003 y 1004, las comprobaciones aleatorias son comparadas. Si la o las comprobaciones aleatorias del documento concuerdan con la o las comprobaciones aleatorias descodificadas, entonces el mensaje y sus anexos deben haber pasado a través del sistema y no han sido alterados desde su entrega al destinatario . Habiendo determinado que el correo electrónico está no alterado, los operadores del sistema pueden garantizar que : (1) el correo electrónico fue recibido por el sistema a una cierta hora; (2) el correo electrónico al parecer llegó al sistema vía una cierta ruta de Internet; (3) el correo electrónico al parecer es de un cierto remitente; y (4) el correo electrónico y sus anexos fueron entregados con el contenido específico que ellos contienen actualmente. Por otra parte, en el paso 1006, sí los valores de la comprobación aleatoria no concuerdan, entonces el operador no puede garantizar que el correo electrónico sea auténtico, por ejemplo, que el correo electrónico sea una versión precisa de un correo electrónico que fue recibido por el sistema . La Figura 11 ilustra cómo la invención puede ser utilizada por un negocio que utiliza herramientas electrónicas (un "negocio electrónico") . El negocio electrónico 30 puede utilizar el sistema para registrar todos los mensajes de correo electrónico que entran y que salen, provenientes de sus clientes 34. En este caso, el sistema incluye el servidor 36 de Protocolo de Oficina Postal (POP) y el servidor 38 de Protocolo de Transferencia de Correo Simple (SMTP) . Por ejemplo, el negocio electrónico 30 puede establecer su sitio en la red a formas de correo electrónico hacia los clientes, y para enviar preguntas y quejas 40 de los clientes 34. Las preguntas, quejas, órdenes, ofertas de compra y otra información 46, registradas, son enviadas al negocio electrónico 30 por el sistema. Los recibos son luego proporcionados a los clientes 34 vía el servidor 38 de SMPT . De esta manera, no existe pregunta respecto a si el cliente envió o no la comunicación y qué contenía ésta. Además, el negocio electrónico puede establecer un sitio 32 en la red a través del servidor RPost, de modo que cada comunicación con los clientes puede ser registrada. En otras palabras, a través de los datos de forma del sitio de la red, pueden ser registradas las órdenes 42 y las respuestas automáticas 44 a través del servidor del sistema; además, cualquier confirmación, avisos de cobro, apoyo a los clientes, y ofertas especiales a los clientes, enviados por el negocio electrónico a los clientes 34, pueden ser registrados, y la confirmación enviada al cliente para eliminar los argumentos respecto a qué fue ordenado, cuándo, o por quién. Si se desea, pueden ser proporcionados destinatarios idénticos a los clientes 34 y al negocio electrónico 30. Alternativamente, las funciones del servidor 36 de POP y el servidor 38 de SMTP pueden ser combinadas en un servidor del sistema simple. El POP es un protocolo utilizado para recuperar el correo electrónico proveniente de un servidor de correo electrónico. Muchas aplicaciones de correo electrónico (algunas veces llamados clientes de correo electrónico) utilizan el protocolo POP, aunque algunos pueden utilizar el Protocolo de Acceso de Mensaje en Internet (IMAP) más nuevo. Una versión de POP, llamada POP2 , requiere SMTP para enviar mensajes. Una nueva versión, POP3 , puede ser utilizada con o sin SMTP. SMTP es un protocolo para enviar mensajes de correo electrónico entre servidores. Muchos sistemas de correo electrónico que envían correo electrónico sobre la Internet utilizan SMTP para enviar mensajes desde un servidor a otro; los mensajes pueden ser luego recuperados con un cliente de correo electrónico utilizando ya sea POP o IMAP. Además, SMTP es en general utilizado para enviar mensajes desde un cliente de correo a un servidor de correo. Los servidores de correo electrónico pueden utilizar una variedad de protocolos para comunicarse con la Internet . Los protocolos comúnmente utilizados incluyen SMPT, P0P3 e IMAP4. Los lectores de correo están en el extremo opuesto del servidor. Ya que los servidores de correo reciben mensajes vía SMPT, los lectores de correo electrónico envían el correo electrónico a un servidor de correo utilizando SMPT. De igual modo, ya que los servidores de correo envían mensajes utilizando P0P3 y opcionalmente IMAP4 , los lectores de correo reciben mensajes provenientes de los servidores de correo mediante el uso del protocolo P0P3 o IMAP4. Aunque lo anterior describe en general un sistema y un método para verificar que un correo electrónico fue enviado y/o recibido, la presente invención puede aplicar a cualquier mensaje electrónico que puede ser transmitido a través de una red de mensajería electrónica o a través de cualquier compuerta electrónica. Los mensajes electrónicos pueden incluir texto, audio, video, gráficos, datos y anexos de diversos tipos de archivo. Los métodos y técnicas mostrados en la presente pueden ser programados dentro de los servidores y otras computadoras, y los programas de cómputo que implementan la invención pueden ser escritos sobre medios legibles en computadora, incluyendo pero no limitados a CD ROMs , RAM, unidades de disco duro y cinta magnética. Los servicios de registro de correo electrónico de acuerdo a la presente invención pueden ser agrupados con los servicios del Proveedor de Servicio de Internet (ISP) para proporcionar una solución ISP de proveedor simple, para clientes corporativos y otros clientes institucionales. La implementación de la invención anteriormente descrita está dentro de la experiencia del practicante ordinario en las técnicas de software . Aunque la presente invención ha sido descrita de este modo con detalle con respecto a las modalidades preferidas y los dibujos de las mismas, debería ser aparente para aquellos expertos en la técnica que pueden ser logradas diversas adaptaciones y modificaciones de la presente invención sin apartarse del espíritu y alcance de la invención. En consecuencia, se debe entender que la descripción detallada y los dibujos anexos como se describen anteriormente, no se pretende que limiten el alcance de la presente invención, la cual debe ser inferida únicamente a partir de las siguientes reivindicaciones y sus equivalentes legales apropiadamente construidos . En las siguientes reivindicaciones, aquellas reivindicaciones que contienen las palabras "medios para" se pretende que sean interpretadas de acuerdo con el título 35 del U.S.C. sección 112, párrafo 6 ; aquellas reivindicaciones que no incluyen las palabras "medios para" se pretende que no sean interpretadas de acuerdo con el título 35 del U.S.C. sección 112, párrafo 6.

Se hace constar que con relación a esta fecha, el mejor método conocido por la solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.

Claims (34)

REIVINDICACIONES Habiéndose descrito la invención como antecede, se reclama como propiedad lo contenido en las siguientes reivindicaciones :

1. Un método para documentar la entrega y contenido de un mensaje electrónico, caracterizado porque comprende : la recepción de un mensaje electrónico desde un remitente de mensajes, el mensaje electrónico tiene al menos una dirección de entrega electrónica, designada, asociada con éste ; la transmisión del mensaje electrónico a la dirección designada; la recepción de la información de notificación de la condición de entrega electrónica respecto a la entrega del mensaje electrónico a la dirección designada; el cómputo de un código de autenticación de mensaje, correspondiente al menos al mensaje; el ensamblaje de una copia de al menos una porción del mensaje, la información de notificación de la condición de entrega electrónica, y el código de autenticación del mensaje, el ensamblaje define un recibo electrónico; y la transmisión del recibo a un medio de almacenamiento .

2. El método de conformidad con la reivindicación 1, caracterizado porque la transmisión del recibo a un medio de almacenamiento comprende la transmisión del recibo al remitente del mensaje, y en donde el mensaje original es desechado después de transmitir el recibo electrónico al remitente ; un supuesto recibo y un supuesto código de autenticación de mensaje asociado con éste, son recibidos, y en donde se realiza una determinación de si el código de autenticación del supuesto mensaje, se refiere al mensaje.

3. El método de conformidad con la reivindicación 1, caracterizado porque el paso de computar un código de autenticación comprende: el cómputo de un primer compendio de mensaje que corresponde al menos a un cuerpo del mensaje; el cómputo de un segundo compendio de mensaje correspondiente a un anexo al mensaje; el cómputo de un compendio de mensaje completo, correspondiente al primero y segundo compendios de mensaje; y la codificación del compendio de mensaje completo, para crear una huella digital.

4. El método de conformidad con cualquiera de las reivindicaciones 1 a 3, caracterizado porque el cómputo de un código de autenticación de mensaje comprende: el cómputo de un compendio de mensaje, que es un algoritmo de encabezado seguro, correspondiente al menos al mensaje y a la información de notificación de la condición de entrega electrónica.

5. Un método para proporcionar prueba respecto a la entrega y contenido de un mensaje electrónico, caracterizado porque comprende: la recepción de un mensaje electrónico proveniente de un remitente, a través de una red de cómputo, el mensaje tiene una dirección de entrega asociada con éste; el envío del mensaje electrónicamente a un destino correspondiente a la dirección de entrega; la recepción de la información de notificación de la condición de entrega asociada con el mensaje y la dirección de entrega la provisión al remitente, de un recibo electrónico que incluye : una copia sustancial del mensaje, la información de notificación de la condición de entrega, y un compendio de mensaje computado sustancialmente de la copia de mensaje y de la información de notificación de la condición de entrega; a una fecha futura la recepción del recibo electrónico, electrónicamente, proveniente del remitente, y la verificación de que dicho compendio del mensaje corresponde al mensaje, y que el mensaje fue recibido por un manejador de mensajes electrónicos, asociado con la dirección de entrega; el envío del mensaje a una pluralidad de destinos adicionales, correspondientes a las direcciones de entrega adicionales asociadas con el mensaje.

6. Un método de conformidad con la reivindicación 5, caracterizado porque comprende: la recepción de la información de notificación de la condición de entrega, adicional, asociada con el mensaje y las direcciones de entrega adicionales; el envío de un mensaje de verificación de entrega al remitente, el mensaje de verificación de entrega que incluye : una lista de todas las direcciones; y la información de notificación de la condición de entrega, respectivamente correspondiente a todas las direcciones, la información de notificación de la condición de entrega que incluye para cada destinatario un listado de si la entrega fue o no exitosa y, si la entrega fue exitosa, la fecha y la hora en que ocurrió la entrega.

7. Un método para verificar la entrega de un mensaje electrónico, caracterizado porque comprende: en un sistema de computadora, la recepción de un mensaje electrónico proveniente de un remitente del mensaje, para el encaminamiento a una dirección de destino; el establecimiento de la comunicación con un servidor de mensajes electrónicos asociado con la dirección de destino, el servidor define un servidor de destino; la averiguación del servidor de destino para determinar si el servidor de destino apoya la funcionalidad de la notificación de la condición de entrega (DSN) ; la recepción de una respuesta a dicha indagación, la indagación y la respuesta conjuntamente definen un diálogo SMTP; la petición de la información de notificación de la condición de entrega, proveniente del servidor de destino de acuerdo a los resultados del diálogo SMTP; la transmisión del mensaje electrónico a la dirección de destino; la recepción de la información DSN proveniente del servidor de destino con respecto a la entrega del mensaje electrónico; y proporcionarle al remitente del mensaje al menos una porción del diálogo SMTP, y al menos una porción de la información DSN.

8. Un método para verificar que un mensaje electrónico fue enviado, caracterizado porque comprende: la generación de un mensaje electrónico para un destinatario, a partir de la información recibida de un originador o recipiente del mensaje; el envío del mensaje electrónico al destinatario; la generación de un compendio de mensaje correspondiente al contenido del mensaje electrónico; la codificación del compendio del mensaje; y el envío del mensaje electrónico y del compendio codificado al originador del mensaje.

9. Un método para probar posteriormente que un mensaje electrónico fue previamente enviado a un destinatario, caracterizado porque el método comprende: la recepción de un mensaje electrónico proveniente de una parte independiente, y la recepción además de una dirección correspondiente a un destinatario pretendido del mensaj e ; la creación de un código de validación correspondiente al mensaje; la transmisión de un código de validación a un medio de almacenamiento para el almacenamiento en éste; y el envío del mensaje al destinatario.

10. Un método para probar que un mensaje electrónico enviado a un destinatario ha sido leído, caracterizado porque el método comprende: la recepción de un mensaje electrónico y una dirección del destinatario; el cálculo de un compendio del mensaje correspondiente al mensaje electrónico; el despacho del mensaje electrónico, electrónicamente hacia la dirección del destinatario; la petición de una notificación de lectura; después de la recepción de la notificación de lectura, la generación de al menos un recibo de lectura, al menos un recibo de lectura incluye: una copia del mensaje; un primer compendio del mensaje para el mensaje electrónico correspondiente; y un segundo compendio del mensaje para la notificación de lectura proveniente del destinatario; y la provisión del recibo de lectura para la verificación posterior de que el mensaje fue recibido por el destinatario .

11. Un método para validar la integridad de una copia supuesta de un mensaje electrónico, caracterizado el método porque comprende : la recepción de la copia del mensaje electrónico supuesta, la copia supuesta incluye una firma digital y una historia de transmisión asociada con ésta; la descodificación de la firma digital; la generación de un compendio de mensaje basado en la copia supuesta; y la validación de la copia supuesta mediante la comparación de la firma digital descodificada y el compendio del mensaje, para determinar si los dos concuerdan.

12. Un método para documentar la entrega de un mensaje electrónico, caracterizado porque el método comprende : la recepción de un mensaje de correo electrónico proveniente de un remitente; el envío del mensaje al menos a un destinatario designado ; el registro o grabación de la información de entrega asociada con el envío del mensaje al menos a un destinatario designado; el cómputo de un compendio del mensaje correspondiente al mensaje y a la información de entrega; la transmisión del compendio del mensaje al remitente ; la eliminación del mensaje; y a un tiempo posterior, el examen del mensaje, la información de entrega y el compendio del mensaje; y la provisión de servicios de verificación de tercera parte, que atestiguan que el mensaje fue enviado al destinatario designado, a la hora indicada dentro de la información de entrega.

13. El método de conformidad con la reivindicación 12, caracterizado además porque comprende: la programación del agente de transporte de mensajes, asociado con el remitente, para redirigir el mensaje de correo electrónico de salida, originalmente dirigido al destinatario designado, a una tercera parte designada, y para alterar el mensaje para incluir la dirección de correo electrónico del destinatario designado; y en donde la tercera parte realiza los pasos de envío, registro, cómputo y transmisión; y la provisión para que el remitente del mensaje designe un mensaje de salida particular como un mensaje que va a ser registrado.

14. Un método para proporcionar servicios de registro de mensajes electrónicos al público, caracterizado el método porque comprende : la provisión de un sitio de la red mundial en el cual un usuario puede introducir un mensaje y designar un destinatario, al introducir la dirección electrónica del destinatario ; la recepción del mensaje y la dirección del destinatario vía el sitio de la red; el envío del mensaje a la dirección electrónica del destinatario; y la provisión de documentación segura al usuario que pertenece a: el contenido del mensaje, y la fecha y la hora en la cual el mensaje fue enviado a la dirección electrónica del destinatario; la recepción de la confirmación de entrega, concerniente a la dirección electrónica del destinatario: que incluye la confirmación de entrega como parte de la documentación segura; y la recepción de la información del recibo de lectura respecto a cuándo el destinatario designado abrió el mensaje electrónico para leerlo, la información del recibo que incluye la información del recibo de lectura como parte de la documentación segura.

15. Un método para documentar la entrega y el contenido de un mensaje electrónico, caracterizado porque el método comprende: el registro de los intercambios de protocolo de mensaje electrónicos que efectúan la entrega del mensaje a una autoridad de transporte de correo de destino (MTA) ; el ensamblaje de una copia de al menos una primera porción del mensaje, los intercambios del protocolo, un código de autenticación correspondiente al menos a una segunda porción del mensaje, el ensamblaje define un recibo electrónico; y la transmisión del recibo a un medio de almacenamiento .

16. El método de conformidad con la reivindicación 15, caracterizado además porque comprende: el ensamblaje y entrega de un reporte de entrega el cual, para cada entrega exitosa del mensaje, indica si el sistema es capaz de verificar, con base en los intercambios de protocolo registrados, la entrega del mensaje a un servidor de correo de destino o, alternativamente, si el sistema es capaz de verificar con base en una notificación MTA, la entrega del mensaje a un buzón electrónico correspondiente al destino.

17. Un método de transmisión de un mensaje desde un remitente hacia un destinatario, vía un servidor desplazado del destinatario, caracterizado porque incluye los pasos en el servidor, de: recibir el mensaje en el servidor desde el remitente ; transmitir desde el servidor hacia el destinatario, el mensaje y la dirección del servidor, y una indicación que representa la identidad del remitente, recibir en el servidor desde el destinatario una historia de saludo y de entrega del mensaje proveniente del servidor hacia el destinatario, y transmitir desde el servidor hacia el remitente el mensaje, una huella digital codificada del mensaje y el saludo y la historia de entrega del mensaje.

18. Un método de conformidad con la reivindicación 17, caracterizado porque: el servidor recibe desde el remitente una copia de la información previamente enviada por el servidor hacia el remitente, esta información incluye la huella digital codificada, y el mensaje, y el saludo y la historia de entrega del mensaje, cuando el remitente desea tener el mensaje autenticado por el servidor y en donde: el servidor no conserva una copia de la información transmitida desde el servidor hacia el remitente, después de que el servidor transmite al remitente el mensaje, la huella digital codificada del mensaje y el saludo y la historia de entrega del mensaje.

19. Un método de conformidad con cualquiera de las reivindicaciones 17 y 18, caracterizado porque: el servidor utiliza la información recibida por el servidor proveniente del remitente, para crear una huella digital del mensaje y una huella digital proveniente de la huella digital codificada, y compara estas huellas digitales para autenticar el mensaje recibido por el servidor desde el remitente .

20. En un método de transmisión de un mensaje desde un remitente hacia un destinatario vía un servidor desplazado del destinatario, de los pasos en el servidor caracterizados por: la recepción del mensaje en el servidor desde el destinatario , la generación de una comprobación aleatoria que constituye una sinopsis del mensaje en forma codificada, la codificación de la comprobación aleatoria con un código de codificación particular, para generar una huella digital codificada del mensaje, y la transmisión del mensaje y la huella digital codificada del mensaje hacia el remitente.

21. En un método de conformidad con la reivindicación 20, los pasos en el servidor caracterizados por : la generación, para cualquier anexo al mensaje, de una comprobación aleatoria que constituye una sinopsis del anexo en forma codificada, la codificación de la comprobación aleatoria con un código de codificación particular, para generar una huella digital codificada del anexo, y la transmisión del anexo y de la huella digital codificada del anexo al remitente, al mismo tiempo que el mensaje y la huella digital codificada del mensaje son transmitidos desde el servidor hacia el remitente.

22. En un método de conformidad con la reivindicación 21, los pasos en el servidor caracterizado po : la remoción del mensaje y la huella digital codificada del mensaje desde el servidor, después de la transmisión del mensaje y la huella digital codificada del mensaje desde el servidor hacia el remitente, y la remoción del anexo y la huella digital codificada del anexo, desde el servidor después de la transmisión del anexo, y la huella digital codificado del anexo, desde el servidor hacia el remitente.

23. Un método de conformidad con cualquiera de las reivindicaciones 20-22, el paso caracterizado por: la autenticación del mensaje con base en el mensaje, y la huella digital codificada del mensaje, transmitida desde el remitente hacia el servidor.

24. En un método de conformidad con cualquiera de las reivindicaciones 20-23, el paso caracterizado por: la autenticación en el servidor del mensaje recibido por el servidor proveniente del remitente, con base en el mensaje, y la huella digital codificada del mensaje, transmitido desde el remitente hacia el servidor, la autenticación es proporcionada por la generación de la huella digital del mensaje recibido por el servidor desde el remitente, y la huella digital proveniente de la huella digital codificada y por comparación de la huella digital, y mediante indicación de la autenticación cuando las huellas digitales son las mismas.

25. En un método de conformidad con cualquiera de las reivindicaciones 20-24, los pasos en el servidor caracterizados por: la recepción de un anexo proveniente del destinatario, la provisión, en el servidor, de una huella digital codificada del anexo, la transmisión hacia el remitente, al mismo tiempo que la transmisión del mensaje y la huella digital codificada del mensaje, del anexo y la huella digital codificada del anexo ; la recepción desde el remitente, de las copias del mensaje y el anexo del mensaje, y las huellas digitales codificadas del mensaje y del anexo, comparando respectivamente que ha sido recibido desde el remitente con relación al mensaje, y que ha sido recibido desde el remitente con relación al anexo, para autenticar el mensaje y el anexo con base en estas comparaciones .

26. Un método para verificar en un primer servidor, la entrega de un mensaje electrónico proveniente de un primer servidor hacia un servidor de destino, para una dirección de destino, caracterizado el método porque incluye los pasos de: recibir en el primer servidor un mensaje electrónico proveniente de un remitente del mensaje para el encaminamiento al servidor de destino, transmitir desde el primer servidor hacia el servidor de destino, el mensaje electrónico y las transacciones entre el primer servidor y el servidor de destino, con relación al mensaje electrónico vía un protocolo seleccionado de un grupo que incluye un protocolo SMTP y un protocolo ESMTP, el registro en el primer servidor, de las transacciones entre el primer servidor y el servidor de destino, vía el protocolo seleccionado del grupo que incluye el protocolo SMTP y el protocolo ESMTP, transmitir desde el primer servidor hacia el remitente, el mensaje y las transacciones entre el primer servidor y el servidor de destino, vía el seleccionado de los protocolos, y recibir en el primer servidor proveniente del remitente, el mensaje y las transacciones entre el primer servidor y el servidor de destino, vía el seleccionado de los protocolos, y autenticar el mensaje en el primer servidor, con base en el mensaje recibido por el primer servidor proveniente del remitente, y las transacciones recibidas por el primer servidor desde el remitente.

27. Un método de autenticación de un mensaje transmitido desde un remitente vía un servidor hacia un destinatario, caracterizado el método porque incluye los pasos en el servidor de : proporcionar una huella digital codificada del mensa e , transmitir el mensaje y la huella digital codificada hacia el remitente, recibir el mensaje y la huella digital codificada desde el remitente, y autenticar el mensaje con base en el mensaje y la huella digital codificada recibida por el servidor desde el remitent .

28. Un método de conformidad con la reivindicación 26, caracterizado porque: el servidor recibe desde el remitente un anexo que incluye una identificación del remitente y una dirección del servidor, y una identificación y la dirección del destinatario, y una huella digital codificada del anexo, y en donde : el servidor transmite al remitente el mens j y una huella digital codificada del mensaje, y el anexo y la huella digital codificada del anexo en donde: el servidor recibe el mensaje y el anexo y las huellas digitales codificadas del mensaje, y el anexo, y en donde : el servidor autentica el mensaje con base en los mensajes y la huella digital codificada del mensaje y el anexo, y la huella digital codificada, todos como son recibidos por el servidor desde el remitente.

29. Un método de conformidad con cualquiera de las reivindicaciones 25-27, caracterizado porque: el servidor autentica el mensaje al preparar huellas digitales del mensaje y el anexo, y las huellas digitales provenientes de las huellas digitales codificadas del mensaje y el anexo, y al comparar las huellas digitales relacionadas al mensaje, y confirmando que éstas son idénticas, y al comparar las huellas digitales relacionadas al anexo, y confirmando que las huellas digitales comparadas son idénticas.

30. Un método de transmisión de un mensaje desde un remitente hacia un destinatario vía un servidor desplazado del destinatario, caracterizado el método porque incluye los pasos, en el servidor, de: transmitir hacia el destinatario el mensaje y un anexo que incluye una identificación del remitente, y una dirección del servidor y una identificación y dirección del destinatario, recibir, desde el destinatario, el mensaje y el anexo que incluye la identificación del remitente y la dirección del servidor, y la identificación y la dirección del destinatario, y transmitir hacia el remitente el mensaje y el anexo, incluyendo la identificación del remitente y la dirección del servidor, y la identificación y la dirección del destinatario.

31. Un método de conformidad con la reivindicación 30, caracterizado porque: el servidor prepara las huellas digitales codificadas del mensaje y el anexo, y transmite las huellas digitales codificadas hacia el remitente con el mensaje y el anexo, y en donde: el servidor no conserva una copia de la información transmitida al remitente después de que éste transmite esta información al remitente.

32. Un método de conformidad con la reivindicación 30 o la reivindicación 31, caracterizado porque: el servidor procesa lo que éste ha recibido desde el remitente, después de que el remitente desea tener el mensaje autenticado, y en donde: el servidor autentica el mensaje con base en este procesamiento .

33. Un método de transmisión de un mensaje a través de la Internet desde un remitente hacia un destinatario vía un servidor desplazado del destinatario, caracterizado el método porque incluye los pasos en el servidor de: transmitir hacia el destinatario el mensaje y una identificación del remitente vía un protocolo seleccionado de un grupo que incluye los protocolos SMPT y ESMPT; recibir desde el destinatario el mensaje y un anexo vía un protocolo seleccionado de un grupo, incluyendo los protocolos SMPT y ESMPT, y transmitir hacia el remitente el mensaje y el anexo.

34. Un método de conformidad con la reivindicación 33, caracterizado porque incluye los pasos de: preparar en el servidor las huellas digitales codificadas del mensaje y el anexo; y transmitir las huellas digitales codificadas desde el servidor hacia el remitente, con el mensaje y el anexo, no conservar en el servidor la información transmitida desde el servidor hacia el remitente, cuando el servidor transmite el mensaje y el anexo, y las huellas digitales codificadas hacia el remitente, y preparar en el servidor las huellas digitales del mens je y el anexo y las huellas digitales provenientes de las huellas digitales codificadas, y comparar las huellas digitales con relación al mensaje, y comparar las huellas digitales con relación al anexo, para autenticar el mens je. RESUMEN DE LA INVENCIÓN Con el fin de proporcionar verificación de una tercera parte, del contenido y entrega de un mensaje electrónico tal como un correo electrónico, un servidor recibe el correo electrónico que se pretende sea enviado o encaminado hacia un destinatario específico, y "etiqueta" el mensaje para indicar que éste está "registrado" con el proveedor del servicio. El servidor establece luego una conexión de red telefónica directa con el Agente de Usuario de Correo (MUA) del destinatario, y transmite el correo electrónico etiquetado al MUA del destinatario, así como a los MUAs de cualesquiera otros destinatarios. Después de recibir las respuestas de los MUAs receptores, de que el mensaje fue exitosamente recibido, el servidor crea luego y envía al originador del mensaje un recibo electrónico. El recibo incluye uno o más y preferentemente todos de los siguientes: el mensaje original que incluye cualesquiera anexos originales; una tabla de éxito/falla de la entrega que lista cuáles MUAs de los destinatarios recibieron exitosamente el mensaje y a qué hora, y para cuáles MUAs existió una falla en la entrega y una firma digital correspondiente al mensaje y a los anexos. Al recibir el recibo en una fecha posterior y verificar que la firma digital concuerda con el mensaje y la información relacionada, el operador del sistema puede proporcionar la verificación independiente de tercera parte de que el recibo es un producto genuino de su sistema, y de que la información perteneciente al contenido y a la entrega del mensaje es correcta, sin la necesidad de archivar el mensaje original o el recibo.