DE102004011042B4

DE102004011042B4 - Method and device for more efficient and secure encoding of e-mails

Info

Publication number: DE102004011042B4
Application number: DE102004011042A
Authority: DE
Inventors: Joerg Schwenk
Original assignee: Individual
Current assignee: Individual
Priority date: 2004-03-06
Filing date: 2004-03-06
Publication date: 2008-07-03
Anticipated expiration: 2024-03-07
Also published as: DE102004011042A1

Abstract

Verfahren zur Abbildung von Internet-E-Mails in ein reines XML-Format [XMaiL], dadurch gekennzeichnet,
dass sämtliche der nachfolgend genannten, in einer E-Mail enthaltenen Datenformate in XML-Datenformate überführt werden können:
– RFC 2822,
– MIME (gemäß RFC2045–2047 und RFC2049),
– S/MIME (gemäß RFC2311 und RFC2633),
– CMS/PKCS#7 (gemäß RFC3369),
– HTML (Version 4.01),
– OpenPGP (gemäß RFC2440);
dass die resultierende XML-Struktur [XMaiL] die Struktur der Internet-Mail widerspiegelt, und
dass die resultierende Struktur gemäß XML Schema validiert wird, wobei
– bei Datenformaten gemäß RFC 2822 die Unterteilung einer Internet-Mail in Header und Body dadurch berücksichtigt wird, dass es in der XML-Struktur genau zwei Nachfolgeelemente <Header> und <Body> des Wurzelelements gibt, die diese Struktur widerspiegeln;
– bei Datenformaten gemäß MIME die aus den Multipart-Datentypen des MIME-Standards (RFC2046) festgelegte Struktur in der resultierenden XML-Struktur erhalten bleibt.Method for mapping Internet e-mails into a pure XML format [XMaiL], characterized
that all of the following data formats contained in an e-mail can be converted into XML data formats:
- RFC 2822,
- MIME (according to RFC2045-2047 and RFC2049),
- S / MIME (according to RFC2311 and RFC2633),
CMS / PKCS # 7 (according to RFC3369),
- HTML (Version 4.01),
- OpenPGP (according to RFC2440);
that the resulting XML structure [XMaiL] reflects the structure of the Internet mail, and
that the resulting structure is validated according to XML Schema, where
- For data formats according to RFC 2822, the subdivision of an Internet mail into header and body is taken into account by the fact that there are exactly two successor elements <Header> and <Body> of the root element in the XML structure that reflect this structure;
- For data formats according to MIME, the structure determined from the multipart data types of the MIME standard (RFC2046) is retained in the resulting XML structure.

Description

Stand der TechnikState of the art

E-Mail ist neben dem WWW der wichtigste Dienst im Internet, und mit Abstand der ältere von beiden: Der RFC 822 „STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES" datiert vom 13. August 1982, und das darin beschriebene ASCII-basierte Textformat ist auch heute noch die Grundlage aller im Internet versendeten E-Mails.e-mail is next to the WWW the most important service on the Internet, and by far the older of both: The RFC 822 "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES "dated August 13, 1982, and the ASCII-based text format described in it is still today the basis of all e-mails sent on the Internet.

Schnell stellte sich heraus, dass die Nutzer mit E-Mails mehr übertragen wollen als reinen Text. Man behalf sich zunächst damit, die zu übertragenden Binärdateien von Hand in ein RFC 822-kompatibles Format zu konvertieren (z. B. uuencode unter UNIX), aber dies war keine befriedigende Lösung. So wurden im November 1996 die „Multipurpose Internet Mail Extension (MIME, RFC 2045–2049) verabschiedet, die eine plattformunabhängige Übertragungsmethode für beliebige Daten im RFC 822-Format festlegten. Die wichtigste Codierungsart für Binärdaten ist dabei base64, mit der eine Expansion der Daten um 33% einhergeht. MIME strukturiert die übertragenen Daten dabei in einer baumartigen Struktur, die mit Hilfe von trennenden Zeichenketten („boundary") aufgebaut wird.Fast turned out that users with emails transfer more want as pure text. At first they made use of it to transfer them binaries to manually convert to an RFC 822-compatible format (eg uuencode on UNIX), but this was not a satisfactory solution. So In November 1996, the "Multipurpose Internet Mail Extension (MIME, RFC 2045-2049) adopted a platform independent transfer method for any Data specified in RFC 822 format. The most important coding type for binary data doing base64, which is accompanied by an expansion of the data by 33%. MIME structures the transferred ones Data thereby in a tree-like structure, with the help of separating Strings ("boundary") is built.

Eine konsequente Weiterentwicklung des MIME-Standards stellt Secure MIME (S/MIME, RFCs 2311, 2312, 2630, 2632, 2633, ab März 1998) dar. Hier wird festgelegt, wie MIME-formatierte Daten mit Hilfe moderner kryptographischer Methoden gesichert werden können. Da kryptographische Operationen immer Binärdaten liefern, mussten hierzu die Mailstandards um binäre Datenformate ergänzt werden. Diese basieren letztendlich auf der Datenbeschreibungssprache „Abstract Syntax Notation 1" (ASN.1), die das genaue Gegenteil der MIME-Philosophie verkörpert: eine möglichst kompakte Darstellung der Daten durch bitgenaue Codierung.A Consistent further development of the MIME standard is provided by Secure MIME (S / MIME, RFCs 2311, 2312, 2630, 2632, 2633, from March 1998). Here it is determined how MIME-formatted data using modern cryptographic Methods can be secured. Since cryptographic operations always provide binary data, they had to the mail standards are binary Data formats added become. These are ultimately based on the data description language "Abstract Syntax Notation 1 "(ASN.1), which embodies the exact opposite of the MIME philosophy: one preferably compact representation of the data through bit-precise coding.

Durch die stürmische Entwicklung des WWW verwischten sich die Grenzen zwischen E-Mail und WWW: Bin Standard-E-Mail-Client muss heute HTML-codierte Mails mit eingebetteten Bildern darstellen und das HTTP-Protokoll sprechen können. Inzwischen beginnt XML das spezialisiertere HTML abzulösen, und so müssen die Clients auch hier nachrüsten.By the stormy Development of the WWW blurred the boundaries between e-mail and WWW: Bin Standard e-mail client today must have HTML-encoded mails with embedded Display images and speak the HTTP protocol. meanwhile XML begins to replace the more specialized HTML, and so must the Clients also retrofit here.

Ein erster Ansatz zur Transformation von MIME-E-Mails in XML-Daten wurde im Jahr 2000 von der Firma Mediaone unter dem Namen „eXtensible Mail Transport Protocol (XMTP)” vorgestellt. Das sehr knapp gehaltene Dokument dazu ist heute noch unter http://xml.coverpages.org/xmtp20000508.html zu finden. Nach Durchsicht dieses Dokuments muss man zu dem Schluss kommen, dass es sich dabei nur um eine direkte Übersetzung von MIME nach XML handelt, die keines der genannten Probleme löst:

• Die Struktur der erzeugten XML-Dokumente ist sehr unklar definiert; ein XML Schema, das eine XMTP-Nachricht akzeptiert, wird auch viele falsche XML- Daten akzeptieren. Das in dieser Anmeldung angegebene XML-Schema kann dagegen gültige von ungültigen XMaiL-Nachrichten klar unterscheiden.
• Um nur ein Beispiel zu nennen: Das MIME-Konstrukt „boundary" wird in MIME dazu verwendet, eine Baumstruktur im Body der E-Mail zu erzeugen. Da XML-Dokumente immer Baumstruktur haben, kann auf dieses Konstrukt eigentlich verzichtet werden, aber XMTP behält es bei.
• Sicherheitsfragen werden bei XMTP in keinster Weise angesprochen.

A first approach to transforming MIME emails into XML data was presented in 2000 by Mediaone under the name "eXtensible Mail Transport Protocol (XMTP)". The very brief document on this can still be found today at http://xml.coverpages.org/xmtp20000508.html. After reviewing this document, you have to conclude that this is just a direct translation from MIME to XML that does not solve any of the problems mentioned above:

• The structure of the generated XML documents is very unclear; An XML schema that accepts an XMTP message will also accept many incorrect XML data. The XML Schema specified in this application, on the other hand, can clearly distinguish valid from invalid XMaiL messages.
• Just to name a few examples: The MIME construct "boundary" is used in MIME to create a tree structure in the body of the e-mail, since XML documents always have a tree structure, but this construct can actually be dispensed with, but XMTP keeps it.
• Security issues are not addressed in any way with XMTP.

Die für den Stand der Technik wichtigsten Internetstandards sind (Request for Comments (RFC) der Internet Engineering Task Force (IETF), abrufbar unter http://www.ietf.org/rfc/rfcNNNN.txt):

• Proposed Standard RFC 1341 MIME (Multipurpose Internet Mail Extensions), 1992
• Proposed Standard RFC 1421 Privacy Enhancement for Internet Electronic Mail, 1993
• Draft Standard RFC 1521 MIME (Multipurpose Internet Mail Extensions), 1993
• Proposed Standard RFC 2015 MIME Security with Pretty Good Privacy (PGP), 1996
• Draft Standard RFC 2045 MIME (Multipurpose Internet Mail Extensions), 1996
• Informational RFC 2311 S/MIME Version 2 Message Specification, 1998
• RFC 2557 – MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)
• Proposed Standard RFC 2633 S/MIME Version 3 Message Specification, 1999
• Proposed Standard RFC 2822 Internet Message Format, 2001

The most important Internet standards for the state of the art are (Request for Comments (RFC) of the Internet Engineering Task Force (IETF), available at http://www.ietf.org/rfc/rfcNNNN.txt):

• Proposed Standard RFC 1341 MIME (Multipurpose Internet Mail Extensions), 1992
Proposed Standard RFC 1421 Privacy Enhancement for Internet Electronic Mail, 1993
• Draft Standard RFC 1521 MIME (Multipurpose Internet Mail Extensions), 1993
• Proposed Standard RFC 2015 MIME Security with Pretty Good Privacy (PGP), 1996
• Draft Standard RFC 2045 MIME (Multipurpose Internet Mail Extensions), 1996
• Informational RFC 2311 S / MIME Version 2 Message Specification, 1998
• RFC 2557 - MIME Encapsulation of Aggregate Documents, search as HTML (MHTML)
• Proposed Standard RFC 2633 S / MIME Version 3 Message Specification, 1999
Proposed Standard RFC 2822 Internet Message Format, 2001

Die wichtigsten zu berücksichtigenden XML-Standards sind (herausgegeben vom WWW-Konsortium, www.w3c.org):

• XML Base
• XML Signature
• XML Encryption
• Xpath
• XML Schema
• XSL und XSLT
• XHTML
• XML Key Management

The main XML standards to consider are (published by the WWW Consortium, www.w3c.org):

• XML Base
• XML Signature
• XML Encryption
• Xpath
• XML Schema
• XSL and XSLT
• XHTML
• XML Key Management

Problemstellung 1: Legacy CodeProblem 1: Legacy Code

Als Fazit können wir festhalten, dass E-Mail-Clients heute folgende, nicht verwandte Datenformate verarbeiten können muss:

• RFC 822 (in der aktuellen Version RFC 2822, nur für E-Mail),
• MIME (nur für E-Mail),
• S/MIME (Cryptographic Message Syntax, ASN.1-basiert, kompatibel zu PKCS#7 und den X.509-PKI-Standards) und
• HTML/XMLkomatibel zum WWW.

In conclusion, we can state that e-mail clients today must be able to process the following, unrelated data formats:

• RFC 822 (in the current version RFC 2822, only for e-mail),
• MIME (only for e-mail),
• S / MIME (Cryptographic Message Syntax, ASN.1-based, compatible with PKCS # 7 and the X.509 PKI standards) and
• HTML / XML-compatible to the WWW.

Da die ersten beiden Datenformate (RFC 822, MIME) in dieser Form nur bei E-Mails vorkommen, und das dritte denkbar inkompatibel zu den drei anderen ist (und daher völlig eigenständige Implementierungen erfordert), kann es in Zukunft ein Problem mit der Wartung dieses Codes geben.There the first two data formats (RFC 822, MIME) in this form only occur in emails, and the third conceivable incompatible with the three others is (and therefore completely independent Implementations requires), there may be a problem with it in the future the maintenance of this code.

Als weiterer Aspekt kommt hinzu, dass Firmen in Zukunft verpflichtet sein werden, ihre E-Mail-Geschäftskorrespondenz geeignet zu archivieren, wie dies auch bei schriftlicher Korrespondenz der Fall ist. Durch das oben aufgezeigte Nebeneinander unterschiedlichster Strukturen in einer E-Mail bietet sich hier als einzige Möglichkeit die Speicherung als BLOB (Binary Large OBject) in einer Datenbank an. Dadurch wird die Suche nach bestimmten Kriterien in der gesammelten E-Mail-Korrespondenz sehr aufwendig.When Another aspect is that companies commit in the future be their e-mail business correspondence suitable for archiving, as with written correspondence the case is. By the above-mentioned juxtaposition of different Structures in an e-mail are the only option here storing as BLOB (Binary Large OBject) in a database at. This will search for specific criteria in the collected E-mail correspondence very expensive.

Problemstellung 2: SicherheitProblem 2: Safety

Vertrauliche Informationen in E-Mails oder deren Anhängen können mitgelesen werden. Dieses Problem ist bekannt und wird im Prinzip durch die Internet-Standards S/MIME und OpenPGP gelöst Dennoch wird heute auch weiterhin nur ein geringer Anteil der Internet-Mails verschlüsselt. Dies hat folgende Gründe:

• Die für die Verarbeitung von S/MIME-Nachrichten verwendeten Algorithmen sind sehr komplex und wenig verbreitet, weil sie auf dem ASN.1-Datenformat basieren, das von allen sonst im Internet verwendeten Datenformaten denkbar weit entfernt ist. Konsequenterweise findet man in Open-Source-Projekten wie Mozilla (Nachfolger des Netscape Messenger) oder Linux fast keine S/MIME-Implementierungen, sondern lediglich OpenPGP.
• In OpenPGP wird den oben genannten vier Datenformaten ein fünftes hinzugefügt. Auch in OpenPGP werden die binären Ergebnisse kryptographischer Operationen auf spezielle Art und Weise codiert. Dabei wird aber das Schlüsselmanagement-Problem nicht sauber gelöst, und der Einsatz scheitert einfach daran, dass man den Schlüssel des Kommunikationspartners nicht kennt.

Confidential information in e-mails or their attachments can be read. This problem is known and is in principle solved by the Internet standards S / MIME and OpenPGP. Nevertheless, today only a small percentage of Internet mails continue to be encrypted. This has the following reasons:

• The algorithms used to process S / MIME messages are very complex and not very common because they are based on the ASN.1 data format, which is very far from any other data format used on the Internet. Consequently, in open source projects such as Mozilla (successor to Netscape Messenger) or Linux, there are almost no S / MIME implementations, only OpenPGP.
• In OpenPGP, a fifth is added to the above four data formats. Also in OpenPGP the binary results of cryptographic operations are coded in a special way. However, the key management problem is not solved properly, and the mission simply fails because one does not know the key of the communication partner.

Beide Ansätze haben eine gemeinsame Schwäche: Sie berücksichtigen die historisch gewachsene Trennung zwischen E-Mail-Header und E-Mail-Body (RFC 822, RFC 2822), und schützen nur letzteren mit kryptographischen Methoden. Dies hat folgende Konsequenzen:

• Absendeadressen (das „FROM:"-Feld im RFC 822-Header) sind kryptographisch nicht gesichert und können ggf. gefälscht werden, ohne dass ein E-Mail-Client dies anzeigt. S/MIME-Clients sollen zwar die Adresse im „FROM:"-Feld mit der Adresse im X.509-Zertifikat vergleichen, es ist jedoch keineswegs sicher, dass alle Clients dies auch tun. Für OpenPGP ist der entsprechende Sachverhalt noch zu klären.
• Empfängeradressen (das „TO:"-Feld von RFC 822) sind nicht kryptographisch geschützt (auch nicht durch eine Soll-Anweisung). Sie können für signierte Mails leicht manipuliert werden. (Für verschlüsselte Mails macht dies keinen Sinn, da sie vom geänderten Empfänger ja nicht gelesen werden können.

Both approaches have a common weakness: they take into account the historically grown separation between e-mail header and e-mail body (RFC 822, RFC 2822), and only protect the latter with cryptographic methods. This has the following consequences:

• Sender addresses (the "FROM:" field in the RFC 822 header) are not cryptographically secured and can be forged if they are not displayed by an e-mail client, although S / MIME clients should use the address in "FROM : "- Compare the field with the address in the X.509 certificate, but it is by no means certain that all clients will do so. For OpenPGP the corresponding facts still have to be clarified.
• Recipient addresses (the "TO:" field of RFC 822) are not cryptographically protected (not even by a target statement) They can easily be manipulated for signed mails (for encrypted mails this makes no sense since they are changed by the modified Receiver can not be read yes.

Diese Beobachtungen beeinträchtigen zum einen die Sicherheit normaler E-Mails (die vom Mailserver-Administrator signierte Mail „Sie haben Ihr Mailvolumen überschritten" könnte mit verändertem „TO:"-Feld auch an andere Nutzer weitergeleitet werden, und so für Konfusion sorgen), sie setzt aber auch die Wirksamkeit digitaler Signaturen als viel gepriesene Möglichkeit zur Verhinderung von SPAM-Mails außer Kraft:
Bei hinreichend großer Verbreitung digital signierter E-Mails könnte man SPAM-Mails aussortieren, indem man alle nicht signierten Mails in den Papierkorb wirft. Um diesen Filter zu überwinden müsste ein SPAM-Anbieter, so die gängige Argumentation, alle versendeten E-Mails signieren, was ihm einen Kostenfaktor in Form enorm gestiegenen Rechenaufwands aufbürden würde. Dieser auch finanziell bezifferbare Mehraufwand pro E-Mail würde SPAM wirtschaftlich unattraktiv machen.These observations, on the one hand, affect the security of normal e-mails (the e-mail signed by the mail server administrator "You have exceeded your mail volume" could also be forwarded to other users with a modified "TO:" field, causing confusion) but also overrides the effectiveness of digital signatures as a much-praised way to prevent spam emails:
With a sufficiently large spread of digitally signed emails one could sort out SPAM emails by throwing all unsigned emails into the wastebasket. To overcome this filter would have a SPAM provider, according to the common reasoning, all signed e-mails sign, which would incur him a cost in the form of enormously increased computational burden. This also financially quantifiable additional expenditure per E-Mail would make SPAM economically unattractive.

Dies ist jedoch nicht der Fall, da ein SPAM-Anbieter folgende Alternativen hat:

1. Er besorgt sich für jede Mailingaktion eine neue E-Mail-Adresse (für wenige Cent) und ein kostenloses E-Mail-Zertifikat. Dann signiert er eine Mail, speichert diese ab, schreibt ein kleines Programm, das nur die „TO:"-Zeile austauscht, und versendet die Mails wie gewohnt.
2. Falls der SPAM-Filter auf „NoSPAM"-PKIs (...) beschränkt wurde, kann er eine „gute" Mailadresse zum Signieren einer E-Mail verwenden, und dann auch das „FROM:"-Feld austauschen. Die Erfolgsrate dieses Vorgehens hängt von der Anzahl der E-Mail-Clients ab, die nicht korrekt prüfen, und müsste empirisch ermittelt werden.

However, this is not the case since a SPAM provider has the following alternatives:

1. He gets a new email address (for a few cents) and a free e-mail certificate for each mailing campaign. Then he signs an email, saves it, writes a small program that only exchanges the "TO:" line, and sends the mail as usual.
2. If the SPAM filter has been restricted to "NoSPAM" -PKIs (...), it can use a "good" email address to sign an email, and then also swap the "FROM:" field This procedure depends on the number of email clients that are not validating correctly and should be determined empirically.

Zeitstempel: Ein wichtiger Nachteil von E-Mail gegenüber normaler Post ist der fehlende Nachweis, wann eine Nachricht abgeschickt oder wann sie angekommen ist. Zumindest das ungefähre Absendedatum wird durch ein halbamtliches Siegel, den Poststempel, quittiert. Im Internet gibt es Zeitstempeldienste, die ähnliche Nachweiskraft besitzen, aber es ist unklar, wie sie in eine E-Mail sicher eingebunden werden sollen.Time stamp: An important disadvantage of e-mail over regular mail is the missing one Proof of when a message was sent or when it arrived is. At least the approximate Date of despatch is indicated by a semi-official seal, the postmark, acknowledged. On the Internet, there are time stamp services, the similar Own proof, but it is unclear how they are in an email should be securely integrated.

Lösung beider Problemklassen: XMaiLsolution both problem classes: XMaiL

Man kann nun versuchen, die oben aufgezeigten Probleme durch Erweiterung der bestehenden E-Mail-Standards zu lösen: Einbeziehung des Headers (oder bestimmter Headerfelder) in die Signatur durch Modifikation von S/MIME und OpenPGP, Entwicklung von MIME-Datenbanken, Einführung neuer Headerfelder für Zeitstempel.you can now try the problems outlined above by extension to solve the existing e-mail standards: inclusion of the header (or certain header fields) in the signature by modification from S / MIME and OpenPGP, development of MIME databases, introduction of new ones Header fields for Time stamp.

Ein solcher Lösungsansatz wirkt aber leicht anachronistisch in einer Zeit, in der alle Softwarefirmen bestrebt sind, ihre Produkte auf einen einzigen Standard hin auszurichten: XML. (Z. B. basieren in Office 2003 von Microsoft die Datenformate von Excel und Word bereits auf XML, andere Office-Produkte sollen folgen.)One such approach But it seems a bit anachronistic at a time when all software companies are anxious are aligning their products to a single standard: XML. (For example, in Microsoft Office 2003, the data formats are based Excel and Word already intended to XML, other Office products consequences.)

Die hier vorgeschlagen Lösung, XMaiL genannt, basiert auf der Idee, alle Datenstrukturen einer E-Mail in XML nachzubilden. Die XML Standardsuite bietet dafür heute alle nötigen Teilstandards.The here proposed solution, Called XMaiL, is based on the idea of having all the data structures of one Emulate e-mail in XML. The XML standard suite offers for today all necessary Part standards.

Dazu müssen die Datenstrukturen, die in den einschlägigen Internetstandards beschrieben sind, in XML-Datenstrukturen übersetzt werden. Dabei treten verschiedene Problem auf, die anhand der jeweiligen Standards gelöst werden müssen, und die hier beispielhaft für die jeweiligen Standards beschrieben werden sollen.To have to the data structures described in the relevant Internet standards are translated into XML data structures become. There are several problems that are based on the respective standards solved Need to become, and here for example the respective standards should be described.

Die genaue Umsetzung der ersten Gruppe von Standards in die zweite Gruppe kann mit Hilfe von XML Schemas erfolgen. Vereinfachte Versionen dieser XML-Schemas werden im Rahmen der Ausführungsbeispiele vorgestellt.The Accurate implementation of the first group of standards in the second group can be done using XML Schemas. Simplified versions These XML Schemas are presented within the framework of the exemplary embodiments.

Das Thema Sicherheit nimmt unter den Beispielen einen breiten Raum ein, da gerade hier große Verbesserungen möglich sind, die Umsetzung aber auf große Schwierigkeiten stößt.The Security issues are widely used in the examples because there are big ones Improvements possible but implementation is facing great difficulties.

Anmerkung zur Terminologie: Im Folgenden werden Teile einer E-Mail immer mit den Bezeichnungen aus den jeweiligen IETF-Standards bezeichnet, z. B. mit „Header" (ohne Anführungszeichen) für den Header einer E-Mail, und mit „TO-Feld" für die Zeile des E-Mail-Quelltextes, die mit „TO:" beginnt. Bestandteile der XML-Datenstruktur, die nach Maßgabe dieser Erfindungsmeldung aus der E-Mail gebildet wird, sind immer XML-Elemente und werden in spitzen Klammern angegeben, die von den XML-Tags bekannt sind, also z. B. <Header> und <TO>.annotation Terminology: In the following parts of an e-mail are always with designates the names from the respective IETF standards, z. Eg with "header" (without quotation marks) for the Header of an e-mail, and with "TO-field" for the line the e-mail source text, which starts with "TO:" the XML data structure, in accordance with this invention disclosure are formed from the email, are always XML elements and are in angle brackets specified by the XML tags, eg. Eg <Header> and <TO>.

Ausführungsbeispiel 1: Einfache E-Mail nach RFC 2822embodiment 1: Simple e-mail according to RFC 2822

Die Unterteilung einer E-Mail nach RFC 822 (bzw. RFC 2822) in Header und Body kann in XML dadurch nachgebildet werden, dass das Wurzelelement <XMaiL> genau zwei Unterelemente <Header> und <Body> besitzt. Es sind auch andere Aufteilungen möglich, aber die vorgeschlagene Unterteilung macht Sinn, weil in <Header> und <Body> sinnvollerweise völlig verschiedene Unterelemente vorkommen.The Subdivision of an e-mail according to RFC 822 (or RFC 2822) into headers and Body can be modeled in XML by the fact that the root element <XMaiL> has exactly two subelements <Header> and <Body>. There are too other splits possible, but the proposed subdivision makes sense, because in <Header> and <Body> usefully different Subelements occur.

Anmerkung: Diese Aussage wird auch nicht durch die Tatsache widerlegt, dass bestimmte MIME-Header bei einer E-Mail sowohl im Header als auch im Body gleichartige MIME-Felder wie „Content-Type: Multipart/Mixed" auftauchen; dies ist lediglich als historisches Relikt zu sehen, das beim Übergang von einem reinen (ASCII-)Textformat zu einem Multimediaformat unvermeidlich war.Annotation: This statement is not contradicted by the fact that certain MIME headers for an e-mail both in the header as well appear in the body similar MIME fields such as "Content-Type: Multipart / Mixed" ;. is merely a historical relic to be seen in the transition from a pure (ASCII) text format to a multimedia format inevitable was.

Die folgende Tabelle gibt die Umsetzung der Beispielnachricht aus Anhang A.1.1 von RFC 822 wieder. Da eine Leerzeile nach RFC 2822 die beiden Teile Header und Body der E-Mail trennt, wurde in der Tabelle auf eine zeilenweise Zuordnung der Bestandteile verzichtet. (Dies wird aber in den folgenden, komplexeren Beispielen getan.)

The following table shows the conversion of the example message from Appendix A.1.1 of RFC 822. Since an empty line according to RFC 2822 separates the two parts header and body of the e-mail, the table omits a line-by-line assignment of the components. (But this is done in the following, more complex examples.)

Abbildung 1: Übersetzung einer einfachen E-Mail nach RFC 2822 in das XMaiL-Format

Figure 1: Translation of a simple e-mail according to RFC 2822 into the XMaiL format

Das obige Beispiel ist eine direkte Übertragung der E-Mail-Struktur nach RFC 2822 in eine XML-Struktur. Im Gegensatz zu dem im Stand der Technik beschriebenen Verfahren wird hier aber die Unterteilung in Header und Body beibehalten, da diese konstitutiv für alle (auch die erweiterten) E-Mail-Formate ist. Die einzige Abweichung von diesem Prinzip ist die weitergehende Kapselung des eigentlichen Nachrichtentextes in die XML-Element <Text> und Plain>. Dies wurde im Hinblick auf die Erweiterung auf MIME-formatierte Mails gemacht, da so einfach strukturierte E-Mail wie in diesem Beispiel im heutigen Internet fast nicht mehr versendet werden.The The above example is a direct transfer the e-mail structure according to RFC 2822 into an XML structure. In contrast but the method described in the prior art is here but maintain the subdivision into headers and body as these are constitutive for all (also the extended) E-Mail formats is. The only deviation from this principle is the further encapsulation of the actual Message text in the XML element <text> and Plain>. That was with regard to the extension made to MIME-formatted mail, as simple structured email as in this example in today Internet almost no longer be shipped.

Bei dem angeführten Beispiel ist zu beachten, dass es durchaus noch sinnvolle Varianten bei der Umsetzung gibt. So könnten z. B. die Schachtelung des ASCII-Textes in die XML-Elemente <Text> und <Plain> auch durch ein eiziges XML-Element <TextPlain> ersetzt weden, das dann den Text enthalten würde.at the cited Example should be noted that there are still reasonable options in the implementation there. So could z. For example, the nesting of the ASCII text into the XML elements <Text> and <Plain> can also be done by a single file XML element <TextPlain> replaces weden, the then would contain the text.

Ein einfaches XML-Schema für dieses Beispiel könnte wie folgt aussehen.One simple XML schema for this example could look like this.

Abbildung 2: XML Schema zur Überprüfung, ob ein XML-Dokument eine gültige Übersetzung einer einfachen RFC 2822 E-Mail ist.

Figure 2: XML Schema to check if an XML document is a valid translation of a simple RFC 2822 e-mail.

Durch das in 2 wiedergegebene XML-Schema wird auch klar, warum es sinnvoll ist, die Unterteilung in Header und Body beizubehalten:

• Die Unterelemente des <Header>-Elements haben keine vorgegebene Reihenfolge; dies entspricht der Praxis in E-Mails nach RFC 2822.
• In das <Header>-Element können weitere, proprietäre Unterelemente eingefügt werden, in 2 angedeutet durch drei Punkte („..."). Dies entspricht der gängigen Praxis, Informationen über den sendenden E-Mail-Client einzufügen (siehe nächstes Beispiel).
• Einzelne Unterelemente des <Header>-Elements können mehrfach auftreten; auch dies entspricht der Praxis, dass E-Mail-Gateways der E-Mail auf ihrem Weg vom Sender zum Empfänger solche „Received:"-Einträge hinzufügen.
• Im Gegensatz dazu hat der Body einer Nachricht eine klar definierte Struktur, die bei dieser einfachen E-Mail sehr einfach strukturiert ist, durch die Einbindung von MIME-Mechanismen aber sehr flexibel wird.

Through the in 2 Also, it becomes clear why it makes sense to keep the subdivision into header and body:

• The subelements of the <Header> element do not have a given order; this corresponds to the practice in emails according to RFC 2822.
• Additional, proprietary subelements can be inserted into the <Header> element, in 2 indicated by three dots ("..."), which is the common practice of inserting information about the sending e-mail client (see next example).
• Individual subelements of the <Header> element can occur multiple times; Again, this is the practice of e-mail gateways adding such "Received:" entries to the e-mail on its way from the sender to the recipient.
• In contrast, the body of a message has a well-defined structure, which is very simple in this simple e-mail, but which becomes very flexible through the inclusion of MIME mechanisms.

Ausführungsbeispiel 2: MIME-formatierte E-Mailembodiment 2: MIME-formatted e-mail

Bei der Umsetzung der MIME-Struktur einer E-Mail, die in XML möglicht identisch nachgebildet werden soll, ergeben sich Schwierigkeiten, deren Lösung wie folgt beschrieben werden kann:

• Für jeden möglichen Wert des MIME-Attributs Content-Type werden zwei (bzw. ein) neues XML-Element gleichen oder ähnlichen Namens eingeführt:
– Alternative 1: Die Kombination Type/Subtype des MIME-Attributs wird in zwei XML-Elemente <Typ> und <Subtyp> übersetzt, wobei <Subtyp> ein Unterelement von <Typ> sein muss. (Beispiel: „Content-Type: Multipart/Mixed" wird zu <Multipart><Mixed> ... </Mixed></Multipart>.)
– Alternative 2: Die Kombination Type/Subtype des MIME-Attributs wird in ein XML-Element <TypSubtyp> übersetzt. (Beispiel: „Content-Type: Multipart/Mixed" wird zu <MultipartMixed> ... </MultipartMixed>.)
– Content-Type: multipart/mixed der Tag <MultipartMixed>)
• 1. Gliederungsebene: Das <Body>-Element der XMaiL enthält nur ein direktes Unterelement. Dieses Element entspricht dem MIME „Content-Type" im Header der E-Mail. (Alternativ wäre es auch möglich, dass der MIME-Content-Type des Body der E-Mail als Attribut des <Body>-Tags gespeichert wird, oder dass es kein <Body>-Element gibt, sondern nur ein Element, das dem MIME-Typ des E-Mail-Body entspricht. Weitere Alternativen sind denkbar, ändern den Gesamtansatz aber nicht.)

When implementing the MIME structure of an e-mail, which should be replicated identically in XML, difficulties arise, the solution of which can be described as follows:

• For each possible value of the Content-Type MIME attribute, two (or one) new XML element of the same or similar name are introduced:
- Alternative 1: The Type / Subtype combination of the MIME attribute is translated into two XML elements <type> and <subtype>, where <subtype> must be a subelement of <type>. (Example: "Content-Type: Multipart / Mixed" becomes <Multipart><Mixed> ... </ Mixed></Multipart>.)
- Alternative 2: The combination Type / Subtype of the MIME attribute is translated into an XML element <type subtype>. (Example: "Content-Type: Multipart / Mixed" becomes <MultipartMixed> ... </ MultipartMixed>.)
- Content-Type: multipart / mixed tag <MultipartMixed>)
• 1. Outline level: The <Body> element of XMaiL contains only one direct subelement. This element corresponds to the MIME "Content-Type" in the header of the e-mail (Alternatively, it is also possible that the MIME content-type of the body of the e-mail is stored as an attribute of the <Body> tag) there is no <Body> element, just an element that matches the MIME type of the email body, but other alternatives are possible but do not change the overall approach.)

Anmerkung: Das einige MIME-Attribute wie z. B. „Content-Type" und „Transfer-Encoding" bei MIME-E-Mails sowohl (einmal) im Header als auch (ggf. mehrmals) im Body einer E-Mail auftauchen, hat historische Gründe: Hätte ein solches Attribut im Header gefehlt, so hätte der E-Mail-Client den gesamten Body der Nachricht als reinen Text interpretiert.

• Weitere Gliederungsebenen: Je nach Art des Elements kann dieses ein oder mehrere Nachfolgeelement enthalten. Mehr als ein Nachfolgeelement ist dabei nur bei Elementen vom Typ <Multipart><XXX> (bzw. <MultiprtXXX>) möglich.
• Die genaue Umsetzung muss durch XML Schemata beschrieben werden, die sich so weit wie möglich an den entsprechenden MIME-Standards orientieren. Ein noch unvollständiges Beispiel dazu ist in 4 angegeben.

Note: This includes some MIME attributes, such as For example, "Content-Type" and "Transfer-Encoding" for MIME emails both (once) in the header and (possibly several times) appear in the body of an email, has historical reasons: Had such an attribute in the header missing, the e-mail client would have interpreted the entire body of the message as plain text.

• Further outline levels: Depending on the type of element, this may contain one or more successor elements. More than one successor element is only possible with elements of the type <Multipart><XXX> (or <MultiprtXXX>).
• The exact implementation must be described by XML schemas, which are based as far as possible on the corresponding MIME standards. An incomplete example of this is in 4 specified.

In der folgenden 3 werden der (gekürzte) Quelltext einer Originalmail (mit geänderten Mailadressen) im MIME-Quelltextformat, und parallel dazu ihre Umsetzung in das XMaiL-Format, wiedergegeben.In the following 3 The (shortened) source text of an original email (with changed mail addresses) in the MIME source text format, and at the same time their conversion into the XMaiL format, are reproduced.

Abbildung 3: Eine (relative komplexe) MIME-E-Mail und ihre Umsetzung in das XMaiL-Format.

Figure 3: A (relatively complex) MIME e-mail and its implementation in the XMaiL format.

In 3 wurde die Variante gewählt, Typ und Subtyp eines MIME-Elements in einem XML-Element zusammenzufassen. Das folgende, noch unvollständige XML-Schema gibt dagegen die Variante wieder, Typ und Subtyp in zwei getrennte, aber verschachtelte XML-Elemente zu übersetzen.In 3 The variant was chosen to combine the type and subtype of a MIME element in an XML element. The following incomplete XML schema, on the other hand, shows the variant of translating type and subtype into two separate but nested XML elements.

Abbildung 4: XML-Schema (unvollständig) für MIME-formatierte E-Mails.

Figure 4: XML schema (incomplete) for MIME formatted emails.

Ausführungbeispiel 3: S/MIME-verschlüsselte E-Mailembodiment 3: S / MIME encrypted e-mail

Gegeben sei der folgende (gekürzte) Quelltext einer Originalmail im S/MIME-Format, und parallel dazu die Umsetzung in das XMaiL-Format. Die grau hinterlegten Felder im S/MIME-Format sind in ASN.1 codiert und deshalb im ASCII-Quelltext der E-Mail nicht erkennbar (sie sind dort base64-codiert).given be the following (shortened) Source text of an original email in S / MIME format, and parallel to this Implementation in the XMaiL format. The gray fields in S / MIME format are encoded in ASN.1 and therefore in the ASCII source code of the e-mail not recognizable (they are base64 coded there).

Anmerkungen zu Ausführungsbeispiel 3:Comments on Embodiment 3:

• The Conversion of the ASN.1 / PKCS # 7 encoded representation of the encrypted Body of the sample e-mail in the displayed text format was through generates an automatic tool. This tool translates pure binary data without another ASN.1 structure into a sequence of hexadecimal numbers, the separated by a colon.
• In XML, the source text of the message is directly readable, it requires none Tools. binary data are shown here in base64 encoding. Same or the same Content representing binary data in the two columns are therefore not identical, but must be based on be assigned to the data structure. So z. For example, the hexadecimal number sequence 3A: DB: 98: 08: 1C: 2E: ... in the left column the same information as the ASCII sequence a6mWXDS ... naTB81jvHw = in the right column.

Ausführungsbeispiel 4: S/MIME-signierte E-Mailembodiment 4: S / MIME signed e-mail

Gegeben sei der folgende (gekürzte) Quelltext einer Originalmail im „clear-signed" S/MIME-Format, und parallel dazu die Umsetzung in das XMaiL-Format. Das „opaque-signed-Format ist ggf. mit dem Aufkommen von XML überholt. Die grau hinterlegten Felder im S/MIME-Format sind in ASN.1 codiert und deshalb im ASCII-Quelltext der E-Mail nicht erkennbar (sie sind dort base64-codiert).given be the following (shortened) Source text of an original email in "clear-signed" S / MIME format, and in parallel, the implementation in the XMaiL format. The "opaque-signed" format is possibly outdated with the advent of XML. The gray fields in S / MIME format are encoded in ASN.1 and therefore not recognizable in the ASCII source code of the e-mail (they are there base64 encoded).

Anmerkungen zu Ausführungsbeispiel 4:Comments on exemplary embodiment 4:

• The both XML elements, which are dashed in the XMaiL example Are clarified by the new security features of XMaiL: The <To> and <From> elements of the <Header> element can be unlike S / MIME or OpenPGP, included in the signature become.
• When new feature gives XMaiL the ability to by specifying in XPath which elements to sign and which ones are encrypted should be. The one needed XPath expression may be set interactively by the user in an email client, if applicable become.
• In the In the course of further adaptation of all data structures to XML offers It's also about recreating X.509 certificates in XML. All necessary constructs provides XML.

Ausführungsbeispiel 5: Verhinderung von SPAM-Mailsembodiment 5: Prevention of SPAM mails

Das Problem der SPAM-Mails kann mit der vorliegenden Erfindung wie folgt gelöst werden:

• Jeder Hersteller von XMaiL-Clients integriert ein Standard-Client-Zertifikat (und den dazugehörigen privaten Schlüssel) in das Programm, das nichts anderes zertifiziert, als dass bestimmte Teile einer E-Mail digital signiert wurden. Für diese Zwecke reicht ein Zertifikat weltweit aus, oder der Softwarehersteller könnte jedes Build der Software mit einem anderen Zertifikat versehen. Wichtig ist, dass diese Zertifikate mit der Software ausgeliefert werden können, und keine Konfigurationsarbeiten von Seiten des Nutzers erforderlich sind. Installiert der Nutzer später ein eigenes E-Mail-Zertifikat, so wird natürlich dieses anstelle des Standardzertifikats verwendet.
• Jeder XMaiL-Client signiert standardmäßig mit diesem Zertifikat das <From>, das <To> und das <Body>-Element jeder E-Mail. Die Signatur wird als „Enveloped Signature" dem Header-Element hinzugefügt. Alternativ dazu kann sie auch dem Body-Element hinzugefügt werden, das dann allerdings entsprechend modifiziert werden muss; in diesem Fall kann auch nicht das gesamte <Body>-Element signiert werden, sondern nur die Elemente ausschließlich des Signaturelements.
• Ebenfalls standardmäßig ist ein XMaiL-Filter aktiviert, der alle E-Mails ohne Signatur, mit ungültiger Signatur, oder alle E-Mail mit überlangem <To>-Element, in den SPAM-Ordner wegsortiert.
• Dem Spar-Mailer werden so Kosten aufgebürdet, da er für jede Gruppe von Adressaten (ungefähr zwischen 1 und 30 Empfängern, je nach erlaubter Größe des <To>-Elements) eine digitale Signatur erstellen muss. Durch Vergrößern der Schlüssellänge in den Zertifikaten, und durch Verkürzen des <To>-Elements, kann man diesen Kostenfaktor skalieren. Der Spar-Mailer kann auch keine fremden E-Mail-Verteilerlisten mehr benutzen, da hier das <To>-Element verändert und so die Signatur ungültig wird.
• Mit diesem Verfahren kann man auch den E-Mail-Missbrauch innerhalb von Unternehmen Herr werden: Der Mitarbeiter, der eine E-Mail an alle 20.000 anderen Mitarbeiter sendet, muss dann halt für den Rest des Tages auf seinen Computer verzichten.

The problem of spam emails can be solved with the present invention as follows:

• Each manufacturer of XMaiL clients integrates a standard client certificate (and associated private key) into the program that certifies nothing other than digitally signing certain portions of an email. For this purpose, a certificate is sufficient worldwide, or the software manufacturer could provide each build of the software with a different certificate. It is important that these certificates can be delivered with the software, and no configuration work by the user is required. If the user later installs his own e-mail certificate, this will of course be used instead of the standard certificate.
• By default, each XMaiL client uses this certificate to sign the <From>, <To>, and <Body> elements of each e-mail. The signature is added to the header element as an "Enveloped Signature." Alternatively, it can be added to the body element, but it must be modified accordingly, in which case the entire <Body> element can not be signed. but only the elements excluding the signature element.
• By default, an XMaiL filter is also activated, which sorts all e-mails without a signature, with an invalid signature, or all e-mail with an excess <To> element, into the SPAM folder.
• The Spar-Mailer is thus burdened with costs because it must create a digital signature for each group of addressees (approximately between 1 and 30 recipients, depending on the permitted size of the <To> element). By increasing the key length in the certificates, and shortening the <To> element, you can scale this cost factor. The Spar-Mailer can also no longer use external e-mail distribution lists, as this changes the <To> element and invalidates the signature.
• This process can also be used to deal with e-mail abuse within companies: The employee who sends an e-mail to all 20,000 other employees then has to give up his computer for the rest of the day.

Eine weitere Methode zur Lösung des SPAM-Problems, die gegenüber der vorher genannten den Vorteil hat, dass sie schnell (d. h. ohne großen Rechenaufwand), und auch in Mailservern überprüft werden kann, lässt sich wie folgt beschreiben:

• Ein wichtiges Element der E-Mail (z. B. das „TO"-Feld oder eine Kombination aus diesem und anderen Feldern wird ausgewählt. Diese Felder müssen die Voraussetzungen erfüllen, dass sie in jeder E-Mail andere Werte annehmen, und dass sie während des Transports nicht verändert werden.
• Über diese Felder wird eine erste (normale) Prüfsumme gebildet, die eine bestimmte Bitlänge, z. B. n-Bit, haben soll.
• Diese Prüfsumme, oder ein anderer geeigneter Wert, wird nun als Teil der Eingabe einer kryptographischen Einwegfunktion, z. B. einer Hashfunktion wie MD5 oder SHA-1, verwendet. Der E-Mail-Client des Senders steht nun vor der Aufgabe, eine Ergänzung zu dieser Prüfsumme zu finden, die zusammen mit der Prüfsumme wieder die Prüfsumme als Ergebnis liefert. Als Formel: f(P, D) = P, wobei f die kryptographische Einwegfunktion darstellt, P die Prüfsumme, und D den ergänzenden Datensatz. Ähnliche Verfahren wurden zur Abwehr von Denial-of-Service-Agriffen als „cryptographic client puzzles) bezeichnet. Im Gegensatz zu diesen Verfahren ist es hier wichtig, ein so genanntes „salt" (in vorliegenden Beispiel die Prüfsumme P, die in die Berechnung des Funktionswertes f(P, D) einfließt) hinzuzunehmen, um kryptographische Angriffe auf Basis des Geburtstagsparadoxons („birthday attacks") zu verhindern.
• Dieses Verfahren kann auch auf E-Mails angewandt werden, die nicht in das XMaiL-Format konvertiert wurden, und mit anderen als den genannten Datensätzen.

Another method for solving the SPAM problem, which has the advantage over the previous one that it can be checked quickly (ie without much computation effort), and also in mail servers, can be described as follows:

• An important element of the e-mail (eg the "TO" field or a combination of this and other fields is selected.) These fields must meet the requirements that they take different values in each e-mail and that they are not changed during transport.
• These fields are used to create a first (normal) checksum that has a specific bit length, for example: B. n-bit should have.
• This checksum, or other appropriate value, is now considered part of the input of a one-way cryptographic function, e.g. A hash function such as MD5 or SHA-1. The e-mail client of the sender is now faced with the task of finding a supplement to this checksum, which returns the checksum together with the checksum as the result. As a formula: f (P, D) = P, where f represents the one-way cryptographic function, P the checksum, and D the supplementary data set. Similar methods have been referred to as "cryptographic client puzzles" to defend against denial-of-service attacks. In contrast to these methods, it is important here to add a so-called "salt" (in the present example the checksum P, which is included in the calculation of the function value f (P, D)) in order to generate cryptographic attacks based on the birthday paradox ("birthday attacks ").
• This procedure can also be applied to e-mails that have not been converted to the XMaiL format and to records other than those named.

ÜbergangsszenarienTransition scenarios

Bei einem so überaus alten, populären und auf hunderte Millionen Client-Rechner verteilten Dienst wie E-Mail stellt sich zwangsläufig die Frage nach Übergangsszenarien: Wie kann ein neues Datenformat eingeführt werden, ohne die Funktionsweise des alten zu beeinträchtigen?at one so overwhelming old, popular and service distributed to hundreds of millions of client computers, such as e-mail inevitably arises the question about transitional scenarios: How can a new data format be introduced without the functionality to affect the old one?

Die natürliche Lösung besteht darin, beide Datenformate so lange wie möglich nebeneinander bestehen zu lassen. Folgender Ablauf wäre denkbar:

1. In der ersten Phase wird XMaiL nur als Archivierungsformat für E-Mails angewendet. Dazu wird ein Konvertierungsprogramm eingesetzt, dass eine Standard-E-Mail nach XMaiL konvertiert. Dieses Konvertierungsprogramm muss auch in umgekehrter Richtung funktionieren, d. h. die ursprüngliche E-Mail muss wieder hergestellt werden können. Die XMaiLs können dann in einer XML-Datenbank bequem archiviert werden.
2. In einer zweiten Phase können Unternehmen dazu übergehen, den internen E-Mail-Verkehr auf XMaiL umzustellen. Die Anbindung an den Internet-Dienst E-Mail bleibt dabei (im Gegensatz zu alten proprietären Lösungen wie Lotus Notes Mail) voll erhalten, da beide Formate ineinander umgewandelt werden können. Unternehmensinterne Sicherheitspolicies können dabei voll umgesetzt werden, z. B. die Regel, dass intern nur signierte XMaiLs in Umlauf sind (die von Virenschutzsoftware gescannt werden können), und eine Verschlüsselung (durch einen XPath-Ausdruck spezifiziert) erst im Konvertierungsgateway beim Übergang ins Internet angewandt wird.
3. Aufgrund des geringen Mehraufwands an Programmcode (die XML-Standards müssen von zukünftigen E-Mail-Clients alle unterstützt werden) werden in der dritten Phase alle gängigen E-Mail-Clients XMaiL-Unterstützung anbieten. Zu diesem Zeitpunkt ist eine Einführung möglich.

The natural solution is to let both data formats coexist as long as possible. The following process would be conceivable:

1. In the first phase, XMaiL will only be used as an e-mail archiving format. For this purpose, a conversion program is used that converts a standard e-mail to XMaiL. This conversion program must also work in the opposite direction, ie the original e-mail must be able to be restored. The XMaiLs can then be conveniently archived in an XML database.
2. In a second phase, companies can switch to internal email traffic on XMaiL. The connection to the Internet service E-Mail remains fully preserved (as opposed to old proprietary solutions such as Lotus Notes Mail), since both formats can be converted into each other. In-house security policies can be fully implemented, eg. For example, the rule that internally only signed XMails are in circulation (which can be scanned by antivirus software), and encryption (specified by an XPath expression) is only applied in the conversion gateway when transitioning to the Internet.
3. Due to the low overhead of program code (the XML standards must all be supported by future email clients), in the third phase, all major email clients will offer XMaiL support. At this time, an introduction is possible.

Zwei weitere Anmerkungen zum Thema Übergangsszenarien:

1. Das SMTP-Protokoll zum Senden und Empfangen von E-Mails muss nicht notwendigerweise an XMaiL angepasst werden: Ein Client kann die für SMTP benötigten Daten aus dem <Header>-Element der XMaiL extrahieren und an das SMTP-Gateway senden. Dieser RFC 822-Header kann „on the fly" immer dann generiert werden, wenn ein XMaiL-fähiges Gateway auf ein Legacy-Gateway trifft. Beim Übergang von einem Legacy-Gateway zu einem XMaiL-fähigen Gateway muss die neu hinzugekommene Information des RFC822-Header im <Header>-Element ergänzt werden. Die gesamt XMaiL wird von Legacy-Gateways als Body einer RFC822-E-Mail behandelt.
2. Während der Übergangphase stellt das Senden von RFC822-Header plus <Header>-Element im Body eine Lösung für nicht XMaiL-fähige Clients dar; der Client kann wahlweise das eine oder andere verwenden, das <Header>-Element wird dann im Body aber nicht angezeigt (z. B. <Header style="invisible"> o. ä.).

Two more notes on transition scenarios:

1. The SMTP protocol for sending and receiving emails does not necessarily have to be adapted to XMaiL: A client can extract the data required for SMTP from the <Header> element of XMaiL and send it to the SMTP gateway. This RFC 822 header can be generated "on the fly" whenever an XMaiL-capable gateway encounters a legacy gateway.When moving from a legacy gateway to an XMaiL-capable gateway, the newly added information of the RFC822- Headers in the <Header> element are supplemented.The overall XMaiL is used by legacy gateways as Body of an RFC822 e-mail.
2. During the transition phase, sending the RFC822 header plus the <Header> element in the body represents a solution for non-XMaiL-enabled clients; the client can optionally use one or the other, but the <Header> element will not appear in the body (for example, <Header style = "invisible"> or similar).

Claims

Method for mapping Internet e-mails into a pure XML format [XMaiL], characterized in that all of the following data formats contained in an e-mail can be converted into XML data formats: - RFC 2822, - MIME (according to RFC2045-2047 and RFC2049), - S / MIME (according to RFC2311 and RFC2633), - CMS / PKCS # 7 (according to RFC3369), - HTML (version 4.01), - OpenPGP (according to RFC2440); that the resulting XML structure [XMaiL] reflects the structure of the Internet mail, and that the resulting structure is validated according to XML schema, whereby - for data formats according to RFC 2822, the division of an Internet mail into header and body is taken into account by there are exactly two successor elements <Header> and <Body> of the root element in the XML structure which reflect this structure; - For data formats according to MIME, the structure determined from the multipart data types of the MIME standard (RFC2046) is retained in the resulting XML structure.

The method of claim 1, wherein the sub-elements of the XML element or the combination of XML elements that are of the Multipart / Mixed type represent, be presented in the predetermined order.

The method of claim 1, wherein the sub-elements of the XML element or the combination of XML elements that are of the Multipart / Parallel type represent, can be displayed in any order.

The method of claim 1, wherein of the sub-elements of the XML element or the combination of XML elements that are of the multipart / alternative type represent, exactly one is displayed.

The method of claim 1, wherein the XML element or the combination of XML elements that are of type Multipart / Signed represent, has exactly two successor elements, one of which is an element of Type is XML signature, which in turn contains a single <Reference> element, which is the other successor element referenced.

Process according to claims 1 to 5, characterized that the MIME data types built internally according to the standards CMS are, so in XML elements, in the Standards XML Signature (RFC3275) and XML encryption (XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002), that their structure is preserved.

Method according to claim 1, characterized that in the certificates, which formed according to the X.509 standard and in emails with Help of the standards S / MIME and CMS / PKCS # 7 are embedded Information in Structures of the XML Standards XML Signature (RFC3275) and XML key management (XML Key Management Specification (XKMS) Version 2.0, W3C Working Draft 18 April 2003) or that the structure an X.509 certificate Completely is transferred to an XML record, the elements used in the standard XML Signature (RFC3275).

Method according to claim 1, characterized in that that the MIME data types, which are built internally according to the standard OpenPGP, so in XML elements, which are defined in the standards XML Signature and XML Encryption, are transferred that their structure is preserved.

Method according to one of the preceding claims, characterized marked that any XML elements of the XML structure [XMaiL] using constructs from the field of standards XML signature (RFC3275) and XML encryption (XML Encryption Syntax and Processing, W3C Recommendation, 10 December 2002).

Method according to claim 9, characterized in that that a <FROM> element and a <TO> element of a <Header> element in the signature be included.

Method according to claim 10, characterized in that that in the XML structure [XMaiL] the elements <FROM> and <TO> and at least one more another subelement from the <Body> element or this itself signed.

Method according to one of claims 10 or 11, characterized that does not use an individual private key for signing becomes, but a key which is delivered together with the respective e-mail client and is marked as authentic by the email client manufacturer.

Method according to claim 9, characterized in that that an existing timestamp is included as an XML element and flows into the signature.

Method according to claim 9, characterized in that that a new element was included in the XML structure [XMaiL] which is a prototype of an element from the XML structure [XMaiL] under a one-way cryptographic function.

Process according to claims 1 to 8, characterized that the source code of a given e-mail according to RFC 2822 into a XML structure [XMaiL] converted and the result is output.

Process according to claims 1 to 8, characterized that a given XML structure [XMaiL] in the source code of a E-mail to RFC 2822 converted and the result is output.

Process according to Claims 15 and 16, characterized that the sequential execution the two opposite conversion steps again the starting object supplies.

Method according to claim 15, characterized in that that the output result is stored in an XML database becomes.

Method according to claim 16, characterized in that the input comes from an XML database.

Method according to claim 15, characterized in that that input from the internet or another network, in RFC 2822-based e-mail is sent, and that Result is routed to a network in which XML structures [XMaiL] can be used.

Method according to claim 16, characterized in that that the input comes from a network in which XML structures [XMaiL] can be used, and the result in the Internet or another network where RFC sends 2822-based emails will be forwarded.

Process according to claims 15, 16 and 18 to 21, characterized in that in the conversion security features according to the claims 9 to 14 added or removed.

Process according to Claims 15 to 21, characterized that information required for communication according to the SMTP protocol (RFC2821) extracted from the <Header> element be and while communication added in the SMTP protocol in the <Header> element.

Process according to claims 1 to 13, characterized that both emails according to RFCs 2045-2049, 2311, 2312, 2557, 2630, 2632, 2633 and 2822 as well as XML structures [XMaiL] are processed and can be represented.

Method according to Claim 24, characterized that the <Header> element is an attribute added will, with which its representation on terminals, which only emails after the RECs 2045-2049, 2311, 2312, 2557, 2630, 2632, 2633 and 2822 are not is shown.

terminal for the implementation of the method according to claims 15 to 25.