WO2012007322A1 - Verfahren zum versenden einer e-mail - Google Patents

Verfahren zum versenden einer e-mail Download PDF

Info

Publication number
WO2012007322A1
WO2012007322A1 PCT/EP2011/061327 EP2011061327W WO2012007322A1 WO 2012007322 A1 WO2012007322 A1 WO 2012007322A1 EP 2011061327 W EP2011061327 W EP 2011061327W WO 2012007322 A1 WO2012007322 A1 WO 2012007322A1
Authority
WO
WIPO (PCT)
Prior art keywords
mail
server
sending
recipient
sender
Prior art date
Application number
PCT/EP2011/061327
Other languages
English (en)
French (fr)
Inventor
Reinhold Bareiss
Original Assignee
Reinhold Bareiss
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Reinhold Bareiss filed Critical Reinhold Bareiss
Publication of WO2012007322A1 publication Critical patent/WO2012007322A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains

Definitions

  • the invention relates to a method for sending an e-mail that allows proof of sending the e-mail and proof of the content of the e-mail sent.
  • E-mail is increasingly being used for communication between companies, institutions, individuals and so on.
  • the non-prepublished patent application DE 10 2009 021 028 discloses a method for proving the access and content of an e-mail in which the sent e-mail is automatically stored in a server of a service provider. Saving the e-mail in the server of the service provider, however, may be undesirable for data protection reasons.
  • the invention is therefore based on the object of providing a method for sending an e-mail that provides proof of sending the e-mail and proof of the content of the e-mail sent without the e-mail in a server - - must be saved.
  • the process should further enable conventional e-mail programs to continue to be used without modification.
  • the invention solves this problem by a method according to claim 1.
  • the e-mail from a sender (as a rule) is sent as usual. sent a recipient.
  • the e-mail is sent in parallel or at the same time to a dedicated server that can not be manipulated by the sender or the recipient, at least with reasonable effort.
  • the sender's e-mail When the sender's e-mail is received by the server, it generates a hash code based on the e-mail and any attachments using a suitable, irreversible hash function.
  • the hash function maps the e-mail, including the contents of all address fields and all attachments, to the hash code, for example by the hash function processing the data of the e-mail in binary representation.
  • Possible values of the hash code can be scalar values from a subset of the natural numbers.
  • the hash code forms an anonymous fingerprint of the e-mail, whereby the hash code can be calculated from the e-mail, but not the e-mail from the hash code.
  • Modifying the e-mail also leads to a changed hash code in virtually all cases, as a result of which a subsequent change to the e-mail is delayed. - - is provable. Incidentally, reference is also made to the relevant specialist literature on hash codes.
  • the server now automatically stores the sender of the e-mail, the at least one recipient of the e-mail, a timestamp indicating when the e-mail was received in the server, and the hash code. It is understood that even more data of the e-mail can be stored, such as the subject line, etc.
  • a unique e-mail identification e-mail ID
  • the server now determines, for example, by appropriately reading out address fields of the e-mail, the recipient (s) and sends a request e-mail to the recipient (s) who provide a complete copy of the original e-mail and hash code includes.
  • a receipt confirmation e-mail is sent to the sender, which includes a complete copy of the original e-mail and hash code, for sending the e-mail from the sender to acknowledge to the server through the server.
  • the e-mail in the server including all attachments is irretrievably deleted to prevent unauthorized access to the e-mail from the outset.
  • proof of the content of the e-mail sent is possible based on the hash code, since the hash code forms an anonymized image of the e-mail. Modifying the e-mail also leads to a changed hash code in virtually all cases, as a result of which subsequent alteration of the e-mail can be detected.
  • the server is operated by a trusted service provider, whereby a manipulation of the data stored in the server, neither the sender nor the recipient (with reasonable effort) is possible.
  • the method according to the invention differs, for example, from simply confirming the receipt of the e-mail by the recipient, for example by simply confirming the receipt by reply e-mail, since the resulting data from the sender or the recipient in their respective systems comparatively can be easily manipulated.
  • a sender wishes to send an e-mail, whereby proof of sending the e-mail and proof of the content of the sent e-mail should be possible, it is sufficient to additionally enter the server e-mail address (eg @ trusteE-mail.com), for example, in a To field and / or a Carbon Copy (CC) address field.
  • server e-mail address eg @ trusteE-mail.com
  • the person bearing the burden of proof must provide the e-mail and the associated hash code. If the same hash code can be generated from the e-mail, it is proven that the e-mail has not been modified and is therefore identical to the originally sent e-mail.
  • the proof regarding the communication itself is stored tamper-proof in the server and can be retrieved from the server, for example by means of the e-mail ID or other parameters.
  • the request e-mail includes a request for the at least one recipient to confirm the receipt of the e-mail and / or the receipt of the request e-mail to the server.
  • the confirmation in particular with the exact confirmation time, is stored in the server and sent a receipt e-mail to the sender, which notifies the sender that the recipient is receiving the e-mail - - has confirmed.
  • the server checks for a given time interval whether an acknowledgment from the recipient is received, and sends a protocol e-mail to the sender with the content that the recipient has not confirmed the receipt of the e-mail if none during the predetermined time interval Confirmation is received by the server.
  • the protocol e-mail can also contain information about which recipient has confirmed the e-mail when and which recipient has not acknowledged receipt of the e-mail within the specified time interval.
  • the request to confirm the receipt of the e-mail to the server is formed as an HTTP link in the request e-mail sent by the server, wherein a click on the HTTP link by the recipient accesses causes the server to be logged in the server, where, for example, a server access time and a unique e-mail identification can be logged.
  • sending the e-mail from the sender to the at least one recipient and sending the e-mail from the sender in addition to the server includes entering the e-mail address of the at least one recipient in an An-address field and Entering the server's e-mail address into a CC address field of the e-mail to be sent.
  • recipient address and server address can be logically separated.
  • the e-mail address of the server can also be entered in addition to the address of the recipient in the To address field.
  • a sender SE sends in a first step 1, which is subdivided into sub-steps 1 a and 1 b, an e-mail in the sub-step 1 a to a receiver RE and in the sub-step 1 b to a server SRV.
  • Mail enters. After entering the addresses of the receiver RE and the server SRV in the e-mail to be sent this is sent by conventional.
  • All steps or actions performed in the server SRV are logged by the server in the form of a routing or transmission protocol, whereby it can be ensured, for example, by assigning a unique e-mail ID, that a unique assignment of the transmission protocol to the E-mail is possible.
  • the server SRV In a step 2, the server SRV generates a hash code of the entire e-mail according to a conventional method, whereby a so-called digital fingerprint of the e-mail is generated. However, the e-mail or content can not be regenerated from the hash code. Further, the server SRV stores the sender of the e-mail, the at least one recipient of the e-mail, an e-mail subject, a timestamp indicating when the e-mail has been received in the server, a uniquely generated e Mail ID and hash code. This data can be present, for example, as a transmission protocol, whereby the transmission protocol can be uniquely referenced by means of the e-mail ID. - -
  • step 3 the sending of the e-mail in step 1 b to the server SRV by the server SRV acknowledged by the fact that this sends a receipt confirmation e-mail to the sender SE, a complete copy of the e-mail, the Includes hash code and the email ID and confirms that the server SRV has received an email whose access is to be logged.
  • a step 4 the e-mail or its address fields received by the server SRV is / are searched to determine the address of the recipient RE that is to acknowledge the e-mail.
  • the server SRV in step 4 further sends a request e-mail to the recipient RE, a complete copy of the e-mail, the e-mail ID and the hash Code and by means of which the recipient RE is requested to confirm receipt of the e-mail sent in step 1 a to the server SRV.
  • the request to confirm receipt of the e-mail or the request e-mail to the server SRV is shown in the request e-mail sent in step 4 as a confirmation HTTP link.
  • step 4 i. after the sending of the request email, which includes a complete copy of the email, the email ID and the hash code, to the recipient RE, the communication process is logged to the recipient RE.
  • the status of a registered letter was reached, with additional proof of the content of the sent e-mail is possible.
  • step 5 the e-mail sent to the server SRV in step 1 b and all attachments of the e-mail for data protection reasons irretrievably ie safely deleted in the server SRV.
  • the data stored in step 2 ie the sender of the e-mail, the at least one recipient of the e-mail, etc., including the - -
  • Routing or transmission protocol stored in a unspecified darg Why this record can serve as a reference or handle of this record, for example, the e-mail ID.
  • the recipient RE When the recipient RE wishes to acknowledge receipt of the e-mail or the request e-mail, it clicks on the confirmation e-mail HTTP link, which in a step 6 causes access to the server SRV which is logged in server SRV with timestamp.
  • the server SRV then sends in a step 7 an acknowledgment e-mail to the sender SE, in which case the process is completed.
  • the sender SE can now use the received acknowledgment e-mail received in step 3, the hash code and the log data records in the server SRV to prove that the e-mail sent in step 1 has arrived at the recipient RE and what content or which attachments the e-mail had.
  • step 6 i. After an access to the server SRV has been logged due to the click on the confirmation HTTP link, the status of a write-in with a signed acknowledgment of receipt is present, whereby additional proof of the content of the acknowledged e-mail is possible.
  • the server SRV can notify the sender SE by means of a protocol e-mail that the receipt of the e-mail could not be detected.
  • the sender SE can now opt for alternative methods to send the message underlying the e-mail to the recipient RE, for example sending by mail with registered mail and return receipt.
  • the embodiment shown in Figure 1 is extended to the effect that the server SRV sends a request e-mail to each of the recipients and monitors which of the recipients confirms the receipt of the request e-mail.
  • the server SRV then informs the sender SE by means of a concluding protocol e-mail which recipients have confirmed receipt and which have not.
  • the embodiments shown enable a reliable proof of the access and the content of the e-mail sent by the sender SE if the receiver RE confirms the receipt.
  • the related protocol information is stored in the server SRV, which is usually operated by a service provider who ensures tamper-proof operation of the server SRV.
  • neither the sender SE nor the receiver RE can manipulate the corresponding data records, which would be possible, for example, in the case of a simple response e-mail or a read acknowledgment of the recipient RE.
  • the method can be used in conjunction with conventional e-mail programs, without the need for costly changes, for example so-called plug-ins. All you have to do is enter the e-mail address of the server SRV in an To field or a CC field, for example, Subscribe@trusteE-mail.com. The further essential steps are subsequently carried out automatically by the server SRV.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Ein Verfahren zum Versenden einer E-Mail, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht, umfasst die Schritte: Versenden der E-Mail von einem Absender (SE) an mindestens einen Empfänger (RE), Versenden der E-Mail von dem Absender zusätzlich an einen Server (SRV), Erzeugen eines Hash-Codes aus der E-Mail durch den Server, automatisches Speichern des Absenders der E-Mail, des mindestens einen Empfängers der E-Mail, eines Zeitstempels, der anzeigt, wann die E-Mail im Server empfangen worden ist, und des Hash-Codes in dem Server, automatisches Versenden einer Aufforderungs-E-Mail von dem Server an den mindestens einen Empfänger, die eine vollständige Kopie der E-Mail und den Hash-Code umfasst, Senden einer Empfangsbestätigungs-E-Mail an den Absender, die eine vollständige Kopie der E-Mail und den Hash-Code umfasst, und Löschen der E-Mail in dem Server.

Description

Verfahren zum Versenden einer E-Mail
Die Erfindung betrifft ein Verfahren zum Versenden einer E-Mail, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht.
E-Mail wird zunehmend zur Kommunikation zwischen Unternehmen, Institutionen, Privatpersonen usw. verwendet. Der Nachweis darüber, ob eine E-Mail tatsächlich beim Empfänger empfangen worden ist und welchen Inhalt die E-Mail hatte, ist jedoch nur schwer zu führen.
Die nicht vorveröffentlichte Patentanmeldung DE 10 2009 021 028 offenbart ein Verfahren zum Nachweisen des Zugangs und des Inhalts einer E-Mail, bei dem die versendete E-Mail automatisch in einem Server eines Dienstleisters gespeichert wird. Das Speichern der E-Mail in dem Server des Dienstleisters kann jedoch aus datenschutzrechtlichen Gründen unerwünscht sein.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren zum Versenden einer E-Mail zur Verfügung zu stellen, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht, ohne dass die E-Mail in einem Server - - gespeichert werden muss. Das Verfahren soll es weiter ermöglichen, dass herkömmliche E-Mail-Programme ohne Änderung weiter verwendet werden können.
Die Erfindung löst diese Aufgabe durch ein Verfahren nach Anspruch 1 .
Bevorzugte Ausführungsformen sind Gegenstand der Unteransprüche, die hiermit durch Bezugnahme zum Inhalt der Beschreibung gemacht werden.
Bei dem erfindungsgemäßen Verfahren zum Versenden einer E-Mail, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht, wird, wie üblich, die E-Mail von einem Absender an (mindestens) einen Empfänger gesendet. Zusätzlich wird die E-Mail parallel bzw. gleichzeitig auch an einen speziell hierfür vorgesehen Server gesendet, der weder vom Absender noch vom Empfänger, zumindest mit vertretbarem Aufwand, manipulierbar ist.
Wenn die E-Mail des Absenders durch den Server empfangen wird, erzeugt dieser mittels einer geeigneten, unumkehrbaren Hash-Funktion einen Hash-Code basierend auf der E-Mail und sämtlicher Anlagen. Die Hash-Funktion bildet hierbei beispielsweise die E-Mail inklusive des Inhalts sämtlicher Adressenfelder und sämtlicher Anlagen auf den Hash- Code ab, indem beispielsweise die Daten der E-Mail in binärer Darstellung durch die Hash-Funktion geeignet verarbeitet werden. Mögliche Werte des Hash-Codes können skalare Werte aus einer Teilmenge der natürlichen Zahlen sein. Der Hash-Code bildet einen anonymisierten Fingerabdruck der E-Mail, wobei der Hash-Code aus der E-Mail berechenbar ist, nicht jedoch die E-Mail aus dem Hash-Code. Ein Verändern der E-Mail führt in praktisch allen Fällen auch zu einem veränderten Hash-Code, wodurch ein nachträgliches Verändern der E-Mail nach- - - weisbar ist. Im Übrigen sei auch auf die einschlägige Fachliteratur zu Hash-Codes verwiesen.
Der Server speichert nun automatisch den Absender der E-Mail, den mindestens einen Empfänger der E-Mail, einen Zeitstempel, der anzeigt, wann die E-Mail im Server empfangen worden ist, und den Hash-Code. Es versteht sich, dass auch noch weitere Daten der E-Mail gespeichert werden können, beispielsweise die Betreff-Zeile usw. Zusätzlich kann eine eindeutige E-Mail-Identifikation (E-Mail-ID) erzeugt und abgespeichert werden, die als Referenz bzw. Handle für die E-Mail dient.
Der Server ermittelt nun, beispielsweise durch geeignetes Auslesen von Adressenfeldern der E-Mail, den bzw. die Empfänger und versendet eine Aufforderungs-E-Mail an den bzw. die Empfänger, die eine vollständige Kopie der originalen E-Mail und den Hash-Code umfasst.
Danach oder bereits nach dem Empfangen der E-Mail im Server wird eine Empfangsbestätigungs-E-Mail an den Absender gesendet, die eine vollständige Kopie der originalen E-Mail und den Hash-Code umfasst, um das Versenden der E-Mail von dem Absender an den Server durch den Server zu quittieren.
Abschließend wird die E-Mail im Server einschließlich sämtlicher Anlagen unwiederbringlich gelöscht, um einen unbefugten Zugriff auf die E- Mail von vorneherein zu unterbinden. Trotz des Löschens der E-Mail ist ein Nachweis über den Inhalt der versendeten E-Mail anhand des Hash- Codes möglich, da der Hash-Code ein anonymisiertes Abbild der E-Mail bildet. Ein Verändern der E-Mail führt in praktisch allen Fällen auch zu einem veränderten Hash-Code, wodurch ein nachträgliches Verändern der E-Mail nachweisbar ist. - -
Üblicherweise wird der Server von einem vertrauenswürdigen Dienstleister betrieben, wodurch eine Manipulation der im Server gespeicherten Daten weder vom Absender noch vom Empfänger (mit vertretbarem Aufwand) möglich ist. Hierdurch unterscheidet sich das erfindungsgemäße Verfahren beispielsweise auch vom bloßen Bestätigen des Erhalts der E-Mail durch den Empfänger, beispielsweise durch simples Bestätigen des Empfangs durch Reply-E-Mail, da die derart entstehenden Daten vom Absender bzw. vom Empfänger in ihren jeweiligen Systemen vergleichsweise einfach manipuliert werden können.
Wenn ein Absender eine E-Mail versenden möchte, wobei ein Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail möglich sein soll, genügt es, zusätzlich die Server- E-Mail-Adresse (z.B. einschreiben@trusteE-Mail.com) beispielsweise in ein An-Feld und/oder ein Carbon Copy(CC)-Adressenfeld einzutragen.
Für den Fall einer notwendigen Beweisführung muss derjenige, der die Beweislast trägt, die E-Mail und den zugehörigen Hash-Code beibringen. Wenn aus der E-Mail derselbe Hash-Code erzeugbar ist, ist bewiesen, dass die E-Mail nicht modifiziert worden und somit identisch mit der ursprünglich gesendeten E-Mail ist. Der Nachweis bezüglich der Kommunikation selbst ist im Server manipulationssicher hinterlegt und kann beispielsweise anhand der E-Mail-ID oder anhand anderer Parameter vom Server abgerufen werden.
In einer Weiterbildung umfasst die Aufforderungs-E-Mail eine Aufforderung für den mindestens einen Empfänger, den Empfang der E-Mail und/oder den Empfang der Aufforderungs-E-Mail an den Server zu bestätigen. Wenn die Bestätigung des Empfängers eingeht, wird die Bestätigung, insbesondere mit dem exaktem Bestätigungszeitpunkt, im Server gespeichert und eine Quittungs-E-Mail an den Absender gesendet, die dem Absender mitteilt, dass der Empfänger den Empfang der E-Mail - - bestätigt hat. Bevorzugt überprüft der Server während eines vorgegebenen Zeitintervalls, ob eine Bestätigung vom Empfänger eingeht, und sendet eine Protokoll-E-Mail an den Absender mit dem Inhalt, dass der Empfänger den Empfang der E-Mail nicht bestätigt hat, wenn während des vorgegebenen Zeitintervalls keine Bestätigung beim Server eingeht. Die Protokoll-E-Mail kann darüber hinaus Informationen darüber umfassen, welcher Empfänger wann die E-Mail bestätigt hat und welcher Empfänger den Empfang der E-Mail innerhalb des vorgegebenen Zeitintervalls nicht quittiert bzw. bestätigt hat.
In einer Weiterbildung ist die Aufforderung, den Empfang der E-Mail an den Server zu bestätigen, in der vom Server gesendeten Aufforderungs- E-Mail als ein HTTP-Link ausgebildet, wobei ein Klick auf den HTTP- Link durch den Empfänger einen Zugriff auf den Server bewirkt, der im Server protokolliert wird, wobei beispielsweise ein Serverzugriffszeitpunkt und eine eindeutige E-Mail-ldentifikation mitprotokolliert werden können.
In einer Weiterbildung umfasst das Versenden der E-Mail von dem Absender an den mindestens einen Empfänger und das Versenden der E- Mail von dem Absender zusätzlich an den Server ein Eintragen der E- Mail-Adresse des mindestens einen Empfängers in ein An-Adressenfeld und ein Eintragen der E-Mail-Adresse des Servers in ein CC- Adressenfeld der zu sendenden E-Mail. Auf diese Weise können Empfängeradresse und Serveradresse logisch voneinander getrennt werden. Selbstverständlich kann die E-Mail-Adresse des Servers auch zusätzlich zu der Adresse des Empfängers in das An-Adressenfeld eingetragen werden.
Die Erfindung wird nachfolgend unter Bezugnahme auf die beigefügte Figur beschrieben. Hierbei zeigt: - -
Fig. 1 einen Ablauf eines erfindungsgemäßen Verfahrens zum
Versenden einer E-Mail, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht.
Bezugnehmend auf Fig. 1 versendet ein Absender SE in einem ersten Schritt 1 , der in Teilschritte 1 a und 1 b unterteilt ist, eine E-Mail in dem Teilschritt 1 a an einen Empfänger RE und in dem Teilschritt 1 b an einen Server SRV. Dies geschieht beispielsweise dadurch, dass der Absender SE die E-Mail-Adresse des Empfängers RE in ein An-Adressenfeld der zu sendenden E-Mail einträgt und die E-Mail-Adresse des Servers SRV in ein CC-Adressenfeld derselben zu sendenden E-Mail einträgt. Nach dem Eintragen der Adressen des Empfängers RE und des Servers SRV in die zu sendende E-Mail wird diese herkömmlich versendet.
Sämtliche im Server SRV durchgeführten Schritte bzw. Aktionen werden durch den Server in Form eines Routing- bzw. Sende-Protokolls protokolliert, wobei beispielsweise durch Vergabe einer eindeutigen E-Mail-ID sichergestellt werden kann, dass eine eindeutige Zuordnung des Sende- Protokolls zu der E-Mail möglich ist.
In einem Schritt 2 erzeugt der Server SRV einen Hash-Code der gesamten E-Mail nach einem herkömmlichen Verfahren, wodurch ein so genannter digitaler Fingerabdruck der E-Mail erzeugt wird. Die E-Mail bzw. der Inhalt kann jedoch aus dem Hash-Code nicht regeneriert werden. Des weiteren speichert der Server SRV den Absender der E-Mail, den mindestens einen Empfänger der E-Mail, einen E-Mail-Betreff, einen Zeitstempel, der anzeigt, wann die E-Mail im Server empfangen worden ist, eine eindeutig erzeugte E-Mail-ID und den Hash-Code. Diese Daten können beispielsweise als Sende-Protokoll vorliegen, wobei das Sende- Protokoll mittels der E-Mail-ID eindeutig referenziert werden kann. - -
In einem Schritt 3 wird das Versenden der E-Mail im Schritt 1 b an den Server SRV durch den Server SRV dadurch quittiert, dass dieser eine Empfangsbestätigungs-E-Mail an den Absender SE sendet, die eine vollständige Kopie der E-Mail, den Hash-Code und die E-Mail-ID umfasst und die bestätigt, dass der Server SRV eine E-Mail erhalten hat, deren Zugang zu protokollieren ist.
In einem Schritt 4 wird/werden die durch den Server SRV empfangene E-Mail bzw. deren Adressenfelder durchsucht, um die Adresse des Empfängers RE zu ermitteln, der die E-Mail quittieren soll. Nachdem die Adresse des Empfängers RE im Server SRV ermittelt worden ist, sendet der Server SRV im Schritt 4 weiter eine Aufforderungs-E-Mail an den Empfänger RE, die eine vollständige Kopie der E-Mail, die E-Mail-ID und den Hash-Code umfasst und mittels der der Empfänger RE aufgefordert wird, den Empfang der im Teilschritt 1 a gesendeten E-Mail an den Server SRV zu bestätigen. Die Aufforderung, den Empfang der E-Mail bzw. der Aufforderungs-E-Mail an den Server SRV zu bestätigen, ist in der im Schritt 4 gesendeten Aufforderungs-E-Mail als ein Bestätigungs-HTTP- Link abgebildet.
Nach Schritt 4, d.h. nach dem Versenden der Aufforderungs-E-Mail, die eine vollständige Kopie der E-Mail, die E-Mail-ID und den Hash-Code umfasst, an den Empfänger RE liegt der Kommunikationsvorgang zum Empfänger RE hin protokolliert vor. Somit wurde der Status eines Einwurfeinschreibens erreicht, wobei zusätzlich ein Nachweis über den Inhalt der versendeten E-Mail möglich ist.
In einem Schritt 5 wird die im Schritt 1 b an den Server SRV gesendete E-Mail und sämtliche Anlagen der E-Mail aus Datenschutzgründen unwiederbringlich d.h. sicher im Server SRV gelöscht. Selbstverständlich bleiben die im Schritt 2 gespeicherten Daten, d.h. der Absender der E- Mail, der mindestens eine Empfänger der E-Mail usw. einschließlich des - -
Routing- bzw. Sende-Protokolls in einem nicht näher dargstellten Massenspeicher des Servers SRV gespeichert, wobei als Referenz oder Handle dieses Datensatzes beispielsweise die E-Mail-ID dienen kann.
Wenn der Empfänger RE den Empfang der E-Mail bzw. der Aufforderungs-E-Mail bestätigen will, klickt er auf den Bestätigungs-HTTP-Link der Aufforderungs-E-Mail, wodurch in einem Schritt 6 ein Zugriff auf den Server SRV bewirkt wird, der im Server SRV mit Zeitstempel protokolliert wird.
Der Server SRV sendet darauf in einem Schritt 7 eine Quittungs-E-Mail an den Absender SE, wobei für diesen Fall der Vorgang abgeschlossen ist. Der Absender SE kann nun anhand der in Schritt 3 empfangenen Empfangsbestätigungs-E-Mail, dem Hash-Code und der Protokolldatensätze im Server SRV nachweisen, dass die im Schritt 1 gesendete E- Mail beim Empfänger RE angekommen ist und welchen Inhalt bzw. welche Anhänge die E-Mail hatte.
Nach Schritt 6, d.h. nachdem ein Zugriff auf den Server SRV aufgrund des Klickens auf den Bestätigungs-HTTP-Link protokolliert worden ist, liegt der Status eines Einschreibens mit unterschriebenem Rückschein vor, wobei zusätzlich ein Nachweis über den Inhalt der quittierten E-Mail möglich ist.
Wenn der Empfänger RE innerhalb eines vorgegebenen Zeitintervalls, beispielsweise 3 Tagen, keine Bestätigung an den Server SRV sendet, kann der Server SRV den Absender SE mittels einer Protokoll-E-Mail benachrichtigen, dass der Zugang der E-Mail nicht nachgewiesen werden konnte. Der Absender SE kann sich nun für alternative Methoden entscheiden, um die der E-Mail zugrunde liegende Nachricht an den Empfänger RE zu versenden, beispielsweise das Versenden per Post mit Einschreiben und Rückschein. - -
Falls mehrere Empfänger vorhanden sind, wird die in Fig. 1 gezeigte Ausführungsform dahingehend erweitert, dass der Server SRV jedem der Empfänger eine Aufforderungs-E-Mail sendet und überwacht, welcher der Empfänger den Empfang der Aufforderungs-E-Mail bestätigt. Der Server SRV teilt dem Absender SE dann mittels einer abschließenden Protokoll-E-Mail mit, welche Empfänger den Empfang bestätigt haben und welche nicht.
Die gezeigten Ausführungsformen ermöglichen einen zuverlässigen Nachweis des Zugangs und des Inhalts der vom Absender SE gesendeten E-Mail, falls der Empfänger RE den Empfang bestätigt bzw. quittiert. Die diesbezüglichen Protokollinformationen werden in dem Server SRV gespeichert, der üblicherweise von einem Dienstleister betrieben wird, der einen manipulationssicheren Betrieb des Servers SRV sicherstellt. Mit anderen Worten können weder der Absender SE noch der Empfänger RE die entsprechenden Datensätze manipulieren, was beispielsweise bei einer einfachen Antwort-E-Mail bzw. einer Lesebestätigung des Empfängers RE möglich wäre.
Darüber hinaus ist das Verfahren aufgrund des erfindungsgemäßen Servers SRV, auf dem die zum Nachweisen wesentlichen Protokollschichten ablaufen, in Verbindung mit herkömmlichen E-Mail- Programmen verwendbar, ohne dass hierfür aufwändige Änderungen, beispielsweise sogenannten Plug-ins, notwendig wären. Es muss lediglich in einem An-Feld bzw. einem CC-Feld die E-Mail-Adresse des Servers SRV eingetragen werden, beispielsweise exemplarisch Einschrei- ben@trusteE-Mail.de. Die weiteren wesentlichen Schritte werden anschließend vom Server SRV automatisiert durchgeführt.

Claims

Patentansprüche
1. Verfahren zum Versenden einer E-Mail, das einen Nachweis über das Versenden der E-Mail und einen Nachweis über den Inhalt der versendeten E-Mail ermöglicht, mit den Schritten:
Versenden der E-Mail von einem Absender (SE) an mindestens einen Empfänger (RE),
Versenden der E-Mail von dem Absender zusätzlich an einen Server (SRV),
Erzeugen eines Hash-Codes aus der E-Mail durch den Server, automatisches Speichern des Absenders der E-Mail, des mindestens einen Empfängers der E-Mail, eines Zeitstempels, der anzeigt, wann die E-Mail im Server empfangen worden ist, und des Hash-Codes in dem Server,
automatisches Versenden einer Aufforderungs-E-Mail von dem Server an den mindestens einen Empfänger, die eine vollständige Kopie der E-Mail und den Hash-Code umfasst,
Senden einer Empfangsbestätigungs-E-Mail an den Absender, die eine vollständige Kopie der E-Mail und den Hash-Code umfasst, und
Löschen der E-Mail in dem Server.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Aufforderungs-E-Mail eine Aufforderung für den mindestens einen Empfänger umfasst, den Empfang der E-Mail und/oder den Empfang der Aufforderungs-E-Mail an den Server zu bestätigen.
3. Verfahren nach Anspruch 2, gekennzeichnet durch die Schritte:
Überprüfen durch den Server, ob eine Bestätigung von dem mindestens einen Empfänger eingeht, und wenn eine Bestätigung vom dem mindestens einen Empfänger eingeht, Speichern der Bestätigung im Server und Senden einer Quittungs-E-Mail an den Absender.
Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die Aufforderung, den Empfang der E-Mail an den Server zu bestätigen, in der vom Server gesendeten Aufforderungs-E- Mail als ein HTTP-Link abgebildet ist, wobei ein Klick auf den HTTP-Link einen Zugriff auf den Server bewirkt, der im Server protokolliert wird.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass
das Versenden der E-Mail von dem Absender an den mindestens einen Empfänger und das Versenden der E-Mail von dem Absender zusätzlich an den Server umfasst:
Eintragen der E-Mail-Adresse des mindestens einen Empfängers in ein An-Adressenfeld und Eintragen der E-Mail- Adresse des Servers in das An-Adressenfeld und/oder ein CC-Adressenfeld der zu sendenden E-Mail.
PCT/EP2011/061327 2010-07-14 2011-07-05 Verfahren zum versenden einer e-mail WO2012007322A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102010031346.7 2010-07-14
DE201010031346 DE102010031346B3 (de) 2010-07-14 2010-07-14 Verfahren zum Versenden einer E-Mail

Publications (1)

Publication Number Publication Date
WO2012007322A1 true WO2012007322A1 (de) 2012-01-19

Family

ID=44509234

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2011/061327 WO2012007322A1 (de) 2010-07-14 2011-07-05 Verfahren zum versenden einer e-mail

Country Status (2)

Country Link
DE (1) DE102010031346B3 (de)
WO (1) WO2012007322A1 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10122734B2 (en) 2016-11-29 2018-11-06 At&T Intellectual Property I, L.P. Secure email verification service
US11587083B2 (en) 2019-12-11 2023-02-21 At&T Intellectual Property I, L.P. Transaction validation service

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020040387A1 (en) * 2000-09-29 2002-04-04 Lessa Andre Santos Method for tracing an electronic mail message
US20050198511A1 (en) * 2003-11-21 2005-09-08 Tomkow Terrance A. System for, and method of, providing the transmission, receipt and content of an e-mail message
CH695844A5 (de) * 2000-07-10 2006-09-15 Rolf Oppliger Verfahren zur Erbringung von Empfangsbestätigungen für die Umsetzung von "eingeschriebenen Nachrichten" in einem elektronischen Nachrichtenvermittlungssystem.
DE102009021028A1 (de) 2009-05-07 2010-11-11 Bareiß, Reinhold, Dr. Verfahren und Server zum Nachweisen des Zugangs und des Inhalts einer E-Mail

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050021963A1 (en) * 2003-04-17 2005-01-27 Tomkow Terrance A. System for, and method of, proving the transmission, receipt and content of a reply to an electronic message

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH695844A5 (de) * 2000-07-10 2006-09-15 Rolf Oppliger Verfahren zur Erbringung von Empfangsbestätigungen für die Umsetzung von "eingeschriebenen Nachrichten" in einem elektronischen Nachrichtenvermittlungssystem.
US20020040387A1 (en) * 2000-09-29 2002-04-04 Lessa Andre Santos Method for tracing an electronic mail message
US20050198511A1 (en) * 2003-11-21 2005-09-08 Tomkow Terrance A. System for, and method of, providing the transmission, receipt and content of an e-mail message
DE102009021028A1 (de) 2009-05-07 2010-11-11 Bareiß, Reinhold, Dr. Verfahren und Server zum Nachweisen des Zugangs und des Inhalts einer E-Mail

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10122734B2 (en) 2016-11-29 2018-11-06 At&T Intellectual Property I, L.P. Secure email verification service
US11587083B2 (en) 2019-12-11 2023-02-21 At&T Intellectual Property I, L.P. Transaction validation service

Also Published As

Publication number Publication date
DE102010031346B3 (de) 2012-01-26

Similar Documents

Publication Publication Date Title
DE112020005289B4 (de) Teilweise sortierte blockchain
DE602005005312T2 (de) Verfahren und System zur Verwaltung elektronischer Nachrichten
DE19960977B4 (de) System für ein elektronisches Datenarchiv mit Erzwingung einer Zugriffskontrolle beim Datenabruf
DE112021000608T5 (de) Schnellere ansichtsänderung für eine blockchain
DE602005004671T2 (de) Verfahren und system zum senden von elektronischer post über ein netzwerk
DE112020005075T5 (de) Effiziente schwellenwertspeicherung von datenobjekten
DE102015214696A1 (de) Vorrichtung und Verfahren zum Verwenden eines Kunden-Geräte-Zertifikats auf einem Gerät
DE112021001671T5 (de) Netzübergreifendes bereitstellen von identitäten
WO2019229031A1 (de) Verfahren und system zum steuern einer freigabe einer ressource
DE112019006673T5 (de) Schutz vor datenverlust
DE112019005317T5 (de) Objektspeicher für garantierte inhalte zur sicherung und aufbewahrung
DE102010031346B3 (de) Verfahren zum Versenden einer E-Mail
DE112012000780B4 (de) Verarbeiten von Berechtigungsprüfungsdaten
WO2010128122A1 (de) Verfahren und server zum nachweisen des zugangs und des inhalts einer e-mail
EP3609148A1 (de) Verfahren und netzwerkknoten zur verarbeitung von messdaten
DE112021005625T5 (de) Automatisiertes zusammenführen von dlt-netzwerken
EP1902562B1 (de) Verfahren zur zustellung und archivierung von digitalen dokumenten
DE112021004120T5 (de) Schwellenwertverschlüsselung für sendeinhalt
DE102013108472B4 (de) Verfahren und Vorrichtung zum elektronischen Integritätsschutz
DE102006053450A1 (de) Signaturerweiterung
DE102018109240A1 (de) Multi-Chain basiertes Verfahren und System zum dauerhaften, anonymen und manipulationssicheren Verwalten und Nachweisen von Einwilligungen zur Versendung elektronischer Nachrichten
WO2020007613A1 (de) Verschlüsselungssystem für vertrauensunwürdige umgebungen
EP2850807A1 (de) Verfahren und system zum sicheren anfordern eines objektes über ein kommunikationsnetzwerk
EP3881568B1 (de) Verfahren zur aufnahme von bildinformationen mit einem mobilen endgerät und übertragung der bildinformationen an eine mit dem endgerät datenleitend verbundene servereinrichtung
EP1944928A2 (de) Verfahren und System zum gesicherten Austausch einer E-Mail Nachricht

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11737916

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11737916

Country of ref document: EP

Kind code of ref document: A1