MIME

Für Mime als Kunstform, siehe Pantomimenkünstler. Für andere Verwendungen siehe Mime (Disambiguierung).

Mehrzweck -Internet -Mail -Erweiterungen (MIME) ist ein Internetstandard das erweitert das Format von Email Nachrichten zur Unterstützung des Textes in Zeichensätze außer ASCIIsowie Anhänge von Audio-, Video-, Bildern- und Anwendungsprogrammen. Nachrichtenkörper können aus mehreren Teilen bestehen, und Header-Informationen können in Nicht-ASCII-Zeichensätzen angegeben werden. E -Mail -Nachrichten mit MIME -Formatierung werden in der Regel mit Standardprotokollen wie der übertragen Simple Mail Transfer Protocol (SMTP), die Postprotokoll (Pop) und die Internet -Nachrichtenzugriffsprotokoll (IMAP).

Der MIME -Standard ist in einer Reihe von angegeben Anfragen nach Kommentaren: RFC 2045Anwesend RFC 2046Anwesend RFC 2047Anwesend RFC 4288Anwesend RFC 4289 und RFC 2049. Die Integration mit SMTP -E -Mail ist in angegeben RFC 1521 und RFC 1522.

Obwohl der MIME -Formalismus hauptsächlich für SMTP entwickelt wurde, sind seine Inhaltstypen auch für andere wichtig Kommunikationsprotokolle. In dem Hypertext Transfer Protocol (Http) für die Weltweites Netz, Server setzen zu Beginn einer Webübertragung ein MIME -Headerfeld ein. Clients verwenden die Inhaltstyp oder Medientyp Header So wählen Sie eine geeignete Zuschaueranwendung für den angegebenen Datentyp aus.

Geschichte

MIME stammt aus dem Andrew Messaging -System, das Teil von war Andrew -Projekt entwickelt bei Carnegie Mellon Universität (CMU) als plattformübergreifende Alternative zum Andrew-spezifischen Datenformat.[1]

MIME -Headerfelder

Mime-Version

Das Vorhandensein dieses Headerfeldes zeigt an, dass die Nachricht mime-formatiert ist. Der Wert ist normalerweise "1.0". Das Feld erscheint wie folgt:

Mime-Version: 1.0

Laut Mime-Co-Schöpfer Nathaniel BorensteinDie Versionsnummer wurde eingeführt, um Änderungen des MIME -Protokolls in nachfolgenden Versionen zu ermöglichen. Borenstein gab jedoch Kurzbeziehungen in der Spezifikation zu, die die Implementierung dieses Merkmals behinderten: "Wir haben nicht angemessen angegeben, wie man mit einer zukünftigen Mime -Version umgeht. Wenn Sie also etwas schreiben, das 1.0 weiß das auf unterschiedliche Weise. Und das Ergebnis ist, dass es für das Internet nahezu unmöglich wäre, jemals eine 2.0 oder eine 1.1 zu definieren. "[2]

Inhaltstyp

Dieses Headerfeld gibt das an Medientyp des Nachrichteninhalts, bestehend aus a Typ und Subtyp, zum Beispiel

Inhaltstyp: Text/Ebene

Durch die Verwendung der Mehrfachviertel Typ, MIME ermöglicht E -Mail -Nachrichten, dass Teile in a arrangieren. Baumstruktur Wenn die Blattknoten kein Multipart-Inhaltstyp sind und die Nicht-Blattknoten eine Vielzahl von mehrteiligen Typen sind. Dieser Mechanismus unterstützt:

  • einfache Textnachrichten mithilfe Text/einfach (Der Standardwert für "Inhaltstyp:")
  • Text plus Anhänge (Multipart/gemischt mit einer Text/einfach Teil und andere Nicht-Text-Teile). Eine MIME-Nachricht mit einer angehängten Datei zeigt im Allgemeinen den ursprünglichen Namen der Datei mit dem Feld "Inhaltsdisposition" an, so dass die Art der Datei sowohl durch den MIME-Inhaltstyp als auch die (normalerweise OS-Spezifisch) Dateiname Erweiterung
  • Antwort mit Original beigefügt (Multipart/gemischt mit einer Text/einfach Teil und die ursprüngliche Nachricht als Nachricht/RFC822 Teil)
  • alternative Inhalte wie eine Nachricht, die sowohl in klarem Text als auch in einem anderen Format gesendet wurde, z. B. Html (Mehrparteiger/Alternative mit dem gleichen Inhalt in Text/einfach und Text/HTML Formen)
  • Bild, Audio, Video und Anwendung (zum Beispiel, Bild/JPEG, Audio/MP3, Video/MP4, und Anwendung/MSWord usw)
  • Viele andere Nachrichtenkonstrukte

Inhaltsdisposition

In den ursprünglichen MIME -Spezifikationen wurden nur die Struktur von Mail -Nachrichten beschrieben. Sie befassten sich nicht mit dem Problem der Präsentationsstile. Das Feld Content-Disposition-Header wurde in RFC 2183 hinzugefügt, um den Präsentationsstil anzugeben. Ein MIME -Teil kann haben:

  • ein in der Reihe Inhaltsdisposition, was bedeutet, dass es automatisch angezeigt werden sollte, wenn die Nachricht angezeigt wird, oder
  • ein Anhang Inhaltsdisposition, in diesem Fall wird es nicht automatisch angezeigt und erfordert eine Handlungsform vom Benutzer, um es zu öffnen.

Zusätzlich zum Präsentationsstil das Feld Inhaltsdisposition Enthält auch Parameter für die Angabe des Namens der Datei, des Erstellungsdatums und des Änderungsdatums, die vom E -Mail -Benutzer des Lesers zum Speichern des Anhangs verwendet werden können.

Das folgende Beispiel stammt aus RFC 2183, wo das Kopfzeilenfeld definiert ist:

Inhaltsdisposition: Anhang; Dateiname = Genome.jpeg; Modification -date = "Mi, 12. Februar 1997 16:29:51 -0500";

Der Dateiname kann wie in RFC 2231 definiert werden.

Ab 2010 eine Mehrheit von E -Mail -Benutzeragenten folgte diesem Rezept nicht vollständig. Das weit verbreitete Mozilla Thunderbird Mail Client ignoriert die Inhaltsdisposition Felder in den Nachrichten und verwendet unabhängige Algorithmen, um die MIME -Teile automatisch anzuzeigen. Thunderbird vor Version 3 sendet auch neu komponierte Nachrichten mit in der Reihe Inhaltsdisposition für alle MIME -Teile. Die meisten Benutzer sind sich nicht bewusst, wie die Inhaltsdisposition festgelegt werden soll Anhang.[3] Viele Mail -Benutzeragenten senden auch Nachrichten mit dem Dateinamen in der Name Parameter der Inhaltstyp Kopfball statt der Dateiname Parameter des Headerfeldes Inhaltsdisposition. Diese Praxis ist entmutigt, da der Dateiname entweder mit dem Parameter angegeben werden sollte Dateiname, oder mit beiden Parametern Dateiname und Name.[4]

In HTTP das Feld des Antwortheaders Inhaltsdisposition: Anhang wird normalerweise als Hinweis für den Client verwendet, um die Antwortkörper als herunterladbare Datei zu präsentieren. Normalerweise beim Erhalt einer solchen Antwort a Webbrowser fordert den Benutzer auf, seinen Inhalt als Datei zu speichern, anstatt ihn als Seite in einem Browserfenster mit anzuzeigen, mit Dateiname Vorschläge des Standarddateinamens.

Content-Transfer-Codierung

Im Juni 1992 definierte MIME (RFC 1341, seit RFC 2045) eine Reihe von Methoden zur Darstellung von binären Daten in anderen Formaten als ASCII -Textformat. Das Content-transfer-codieren: Das MIME-Headerfeld hat eine 2-seitige Bedeutung:

  • Es zeigt an, ob a Binär-bis-Text-Kodierung Das Schema wurde oben in der ursprünglichen Codierung verwendet, wie in dem Header vom Typ des Inhalts angegeben:
  1. Wenn eine solche Binär-bis-Text-Kodierungsmethode verwendet wurde, heißt es, welche.
  2. Wenn nicht, liefert es eine deskriptive Etikett für das Format von Inhalten in Bezug auf das Vorhandensein von 8-Bit- oder Binärinhalten.

Der RFC und der Ianas Liste von Übertragungscodierungen definieren die nachstehend gezeigten Werte, die nicht fallempfindlich sind. Beachten Sie, dass "7bit", "8bit" und "binär" bedeutet, dass keine Binär-zu-Text-Codierung auf der ursprünglichen Codierung verwendet wurde. In diesen Fällen ist das Header -Feld tatsächlich überflüssig, damit der E -Mail -Client die Nachrichtenbehörde entschlüsselt, aber es kann immer noch als Indikator dafür nützlich sein, welche Art von Objekt gesendet wird. Werte 'zitiert' und 'Basis64Sagen Sie dem E-Mail-Client, dass ein Binär-bis-Text-Codierungsschema verwendet wurde und dass eine entsprechende anfängliche Dekodierung erforderlich ist, bevor die Nachricht mit seiner ursprünglichen Codierung gelesen werden kann (z. B. UTF-8).

  • Geeignet für die Verwendung mit normalem SMTP:
    • 7bit - bis zu 998 Oktetten pro Zeile des Codebereiches 1..127 mit CR und LF (Codes 13 bzw. 10), nur als Teil eines CRLF -Zeilen -Endes erscheinen. Dies ist der Standardwert.
    • zitiert - Wird verwendet, um beliebige Oktettsequenzen in ein Formular zu codieren, das die Regeln von 7bit erfüllt. Entwickelt, um effizient und meist menschlich lesbar zu sein, wenn sie für Textdaten verwendet werden, die hauptsächlich aus US-ASCII-Zeichen bestehen, aber auch einen kleinen Teil von Bytes mit Werten außerhalb dieses Bereichs enthalten.
    • Basis64 - Wird verwendet, um beliebige Oktettsequenzen in ein Formular zu codieren, das die Regeln von 7bit erfüllt. Entwickelt, um für Nicht-Text-8-Bit- und Binärdaten effizient zu sein. Manchmal werden für Textdaten verwendet, die häufig Nicht-US-ASCII-Zeichen verwenden.
  • Geeignet für die Verwendung mit SMTP -Servern, die die unterstützen 8bitmime SMTP -Erweiterung (RFC 6152):
    • 8 Bit - Bis zu 998 Oktetten pro Linie mit CR und LF (Codes 13 bzw. 10) dürfen nur als Teil eines CRLF -Liniens erscheinen.
  • Geeignet für die Verwendung mit SMTP -Servern, die die BinaryMime SMTP -Erweiterung (RFC 3030) unterstützen:
    • binär - Jede Sequenz von Oktetten.

Es gibt keine Codierung, die ausdrücklich für das Senden beliebiger binärer Daten über SMTP -Transporte mit der 8 -Bitmime -Erweiterung ausgelegt ist. Wenn Binarymime nicht unterstützt wird, sind Base64 oder zitierbar (mit ihrer zugehörigen Ineffizienz) manchmal immer noch nützlich. Diese Einschränkung gilt nicht für andere Verwendungen von MIME wie Webdiensten mit MIME -Anhängen oder MTOM.

Coded-Wort

Seit RFC 2822 verwenden die Feldnamen und -werte von Message Header -Feldzeilen ASCII -Zeichen. Werte, die Nicht-ASCII-Daten enthalten, sollten den MIME verwenden Coded-Wort Syntax (RFC 2047) anstelle einer wörtlichen Zeichenfolge. Diese Syntax verwendet eine Zeichenfolge von ASCII -Zeichen, die sowohl die ursprüngliche Zeichenkodierung (die "angibt,Charset") und die Inhaltsübertragungskodierung, mit der die Bytes des Zeichens in ASCII-Zeichen abgebildet werden.

Die Form lautet: "=?Charset?Codierung?codierter Text? =".

  • Charset Kann jeder Zeichensatz sein, der mit registriert ist und mit Iana. Normalerweise wäre es das gleiche Zeichen wie der Nachrichtenkörper.
  • Codierung Kann beides sein "Q"Kennzeichnung q-codieren, die dem ähnlich ist zitiert Codierung oder "B"Bezeichnet Basis64 Codierung.
  • codierter Text ist der qcodierte oder base64-kodierte Text.
  • Ein Coded-Wort Möglicherweise ist nicht mehr als 75 Zeichen lang, einschließlich Charset, Codierung, codierter Textund Grenzwerte. Wenn es wünschenswert ist, mehr Text zu codieren, als in eine zu passen Coded-Wort von 75 Zeichen, mehrere Coded-WortS (durch CRLF -Raum getrennt) kann verwendet werden.

Unterschied zwischen Q-Codierung und zitierbarem Druck

Die ASCII -Codes für das Fragezeichen ("?") Und Equals Sign ("=") werden möglicherweise nicht direkt dargestellt, da sie das codierte Wort abgrenzen. Der ASCII -Code für Raum kann möglicherweise nicht direkt dargestellt werden, da ältere Parser das codierte Wort unerwünscht aufzuteilen. Damit die Codierung kleiner und leichter zu lesen ist, wird der Unterstrich verwendet, um den ASCII -Code für den Raum darzustellen, der den Nebeneffekt erstellt, den Unterstrich nicht direkt darstellen kann. Die Verwendung von codierten Wörtern in bestimmten Teilen von Headerfeldern führt zu weiteren Einschränkungen, auf denen Zeichen direkt dargestellt werden können.

Zum Beispiel,

Betreff: =? ISO-8859-1? Q? = A1hola, _se = f1or!? =

wird als "Subjekt: ¡Hola, Señor!" Interpretiert.

Das codierte Wortformat wird nicht für die Namen der Headerfelder verwendet (zum Beispiel Thema). Diese Namen sind normalerweise englische Begriffe und immer in ASCII in der rohen Nachricht. Beim Anzeigen einer Nachricht bei einem nicht englischen E-Mail-Client können die Feldnamen des Headers vom Kunden übersetzt werden.

Mehrteilige Nachrichten

Die MIME -Multipart -Nachricht enthält a Grenze im Kopffeldfeld Content-Type:; Diese Grenze, die in keinem der Teile auftreten darf, wird zwischen den Teilen und am Anfang und am Ende des Botschaftskörpers wie folgt platziert:

Mime-Version: 1.0 Inhaltstyp: Mehrfachviertel/gemischt; Grenze=Grenze Dies ist eine Nachricht mit mehreren Teilen im MIME -Format.--Grenze Inhaltstyp: Text/schmucklos Dies ist der Körper der Nachricht.--Grenze Inhaltstyp: Anwendung/Oktettstrom Content-transfer-codieren: Basis64 PGH0BWW+CIAGPGHLYWQ+CIAGPC9OZWFKPGOGIDXIB2R5PGOGICAGPHA+VGHPCYBPCYB0AGUGUGE Ym9kesbvzib0Agugbwvzc2fnzs48L3A+CIAGPC9IB2R5PGO8L2H0BWW+CG == --Grenze--

Jeder Teil besteht aus seinem eigenen Inhaltsheader (null oder mehr Content- Headerfelder) und ein Körper. Mehrteilige Inhalte können verschachtelt werden. Das Content-Transfer-Encoding eines mehrteiligen Typs muss immer "7bit", "8bit" oder "binär" sein, um die Komplikationen zu vermeiden, die durch mehrere Decodierungsebenen ausgestattet werden. Der mehrteilige Block als Ganzes hat kein Zeichen; Nicht-ASCII-Charaktere in den Teilschichten werden von der behandelt Coded-Wort System, und die Teilkörper können bei Bedarf bei der Anpassung des Inhaltstyps Charsets angegeben haben.

Anmerkungen:

  • Bevor die erste Grenze ein Bereich ist, der von mime-konformen Kunden ignoriert wird. Dieser Bereich wird im Allgemeinen verwendet, um Benutzern alter Nicht-Mime-Clients eine Nachricht zu vergeben.
  • Es liegt an dem Senden -Mail -Client, eine Grenzzeichenfolge auszuwählen, die nicht mit dem Körpertext zusammenspricht. In der Regel wird dies durch Einfügen einer langen Zufallszeichenfolge durchgeführt.
  • Die letzte Grenze muss am Ende zwei Bindestriche haben.

Mehrteilige Subtypen

Der MIME-Standard definiert verschiedene mehrteilige Message-Subtypen, die die Art der Nachrichtenteile und ihre Beziehung zueinander angeben. Der Subtyp ist in der angegeben Content-Type Headerfeld der Gesamtnachricht. Zum Beispiel hätte eine mehrteilige Mime -Nachricht mit dem Digest -Subtyp ihre Content-Type Setzen Sie als "Multipart/Digest".

Der RFC definierte zunächst vier Subtypen: gemischt, verdau, alternativ und parallel. Eine minimal konforme Anwendung muss gemischt und verdau werden. Andere Subtypen sind optional. Anwendungen müssen nicht anerkannte Subtypen als "mehrteilig/gemischt" behandeln. Zusätzliche Subtypen wie signiert und Formdaten, die seitdem in anderen RFCs getrennt definiert wurden.

gemischt

Multipart/Mixed wird zum Senden von Dateien mit unterschiedlichem Senden verwendet Content-Type Headerfelder inline (oder als Anhänge). Wenn Sie Bilder oder andere leicht lesbare Dateien senden, werden die meisten E -Mail -Clients inline angezeigt (sofern nicht ausdrücklich angegeben mit Inhaltsdisposition: Anhang in diesem Fall als Anhänge angeboten). Der Standard-Inhaltstyp für jeden Teil ist "Text/Plain".

Der Typ ist in RFC 2046 definiert.[5]

verdauen

Multipart/Digest ist eine einfache Möglichkeit, mehrere Textnachrichten zu senden. Der Standard-Inhaltstyp für jeden Teil ist "Message/RFC822".

Der MIME -Typ ist in RFC 2046 definiert.[6]

Alternative

Der mehrteilige/alternative Subtyp zeigt an, dass jeder Teil eine "alternative" Version desselben (oder ähnlichen) Inhalte ist, die jeweils in einem anderen Format, das durch den Header des Inhaltstyps gekennzeichnet ist, gekennzeichnet ist. Die Reihenfolge der Teile ist erheblich. RFC1341 Staaten: Im Allgemeinen sollten Benutzeragenten, die mehrteilige/alternative Entitäten zusammenstellen, die Körperteile in zunehmender Präferenzreihenfolge platzieren, dh mit dem bevorzugten Format zuletzt.[7]

Systeme können dann die "beste" Darstellung auswählen, die sie verarbeiten können. Im Allgemeinen ist dies der letzte Teil, den das System verstehen kann, obwohl andere Faktoren dies beeinflussen können.

Da es unwahrscheinlich ist, dass ein Kunde eine Version senden möchte, die weniger treu als die einfache Textversion ist, platziert diese Struktur die einfache Textversion (falls vorhanden) zuerst. Dies erleichtert das Leben für Benutzer von Kunden, die mehrteilige Nachrichten verstehen.

Am häufigsten wird Multipart/Alternative für E -Mails mit zwei Teilen verwendet, einem einfachen Text (Text/Ebene) und einem HTML (Text/HTML). Das einfache Textteil bietet eine rückwärts gerichtete Kompatibilität, während der HTML -Teil die Verwendung von Formatierung und Hyperlinks ermöglicht. Die meisten E -Mail -Clients bieten eine Benutzeroption an, um einen einfachen Text gegenüber HTML zu bevorzugen. Dies ist ein Beispiel dafür, wie sich lokale Faktoren auswirken können, wie eine Anwendung welcher "beste" Teil der angezeigten Nachricht auswählt.

Obwohl beabsichtigt ist, dass jeder Teil der Nachricht denselben Inhalt darstellt, verlangt der Standard in keiner Weise. Zu einer Zeit, Anti-Spam-Filter würde nur den Text/den einfachen Teil einer Nachricht untersuchen,[8] Weil es einfacher zu analysieren ist als der Text/HTML -Teil. Aber Spammer Nutzte dies schließlich und erstellte Nachrichten mit einem harmlos aussehenden Text/einfachen Teil und Werbung im Text/HTML-Teil. Die Anti-Spam-Software hat schließlich auf diesen Trick eingeholt und Nachrichten mit sehr unterschiedlichem Text in einer mehrteiligen/alternativen Nachricht bestraft.[8]

Der Typ ist in RFC 2046 definiert.[9]

verbunden

Ein Mehrfach-/Verwandter wird verwendet, um anzuzeigen, dass jeder Meldungsteil eine Komponente eines Aggregats ist. Es gilt für zusammengesetzte Objekte, die aus mehreren miteinander verbundenen Komponenten bestehen-die richtige Anzeige kann nicht erreicht werden, indem die Bestandteile individuell angezeigt werden. Die Nachricht besteht aus einem Root -Teil (standardmäßig die erste), die auf andere Teile verweist, die wiederum auf andere Teile verweisen können. Nachrichtenteile werden häufig auf Inhaltlich. Die Syntax einer Referenz ist nicht spezifiziert und diktiert stattdessen durch die im Teil verwendete Codierung oder Protokoll.

Eine übliche Verwendung dieses Subtyps besteht darin, eine Webseite mit Bildern in einer einzelnen Nachricht zu senden. Der Wurzelteil würde das enthalten Html Dokumentieren Sie und verwenden Sie Bild -Tags, um Bilder zu verweisen, die in den letzteren Teilen gespeichert sind.

Der Typ ist in RFC 2387 definiert.

Bericht

Multipart/Bericht ist ein Nachrichtentyp, der Daten enthält, die für einen Mailserver gelesen werden sollen. Es wird zwischen einem Text/einer Ebene (oder einem anderen Inhalt/Typ leicht lesbar) und einer Nachricht/Zustellungsstatus aufgeteilt, die die für den Mailserver formulierten Daten enthält.

Der Typ ist in RFC 6522 definiert.

unterzeichnet

Eine mehrteilige/signierte Nachricht wird verwendet, um a anzuhängen Digitale Unterschrift zu einer Nachricht. Es hat genau zwei Körperteile, einen Körperteil und einen charakteristischen Teil. Der gesamte Körperteil, einschließlich MIME -Felder, wird verwendet, um den Signaturteil zu erstellen. Viele Signaturtypen sind möglich, wie "Anwendung/PGP-Signatur" (RFC 3156) und "Anwendung/PKCS7-Signatur" (S/mime).

Der Typ ist in RFC 1847 definiert.[10]

verschlüsselt

Eine mehrteilige/verschlüsselte Nachricht hat zwei Teile. Der erste Teil enthält Steuerungsinformationen, die zum Entschlüsseln des zweiten Teils der Anwendung/des Oktetts erforderlich sind. Ähnlich wie bei signierten Nachrichten gibt es verschiedene Implementierungen, die anhand der separaten Inhaltstypen für den Steuerteil identifiziert werden. Die gängigsten Typen sind "Anwendung/PGP-verschlüsselt" (RFC 3156) und "Anwendung/PKCS7-MIME" (S/mime).

Der in RFC 1847 definierte MIME -Typ.[11]

Formulardaten

Der MIME -Typ Mehrfachfrist/Formdaten wird verwendet, um Werte auszudrücken, die über ein Formular eingereicht wurden. Ursprünglich definiert als Teil von Html 4.0, es wird am häufigsten zum Senden von Dateien mit verwendet Http. Es ist in RFC 7578 angegeben, das RFC 2388 ersetzt. Beispiel

X-Misch-Replace

Der Inhaltstyp Multipart/X-Mixed-Replace wurde als Teil einer Technologie zu emulieren entwickelt Serverschub und Streaming über HTTP.

Alle Teile einer gemischten Replace-Nachricht haben die gleiche semantische Bedeutung. Jeder Teil "ersetzt" - die vorherigen Teile, sobald er vollständig empfangen wird. Kunden sollten die einzelnen Teile verarbeiten, sobald sie ankommen, und sollten nicht auf die gesamte Nachricht warten.

Ursprünglich entwickelt von Netscape,[12] es wird immer noch unterstützt von Mozilla, Feuerfuchs, Safari, und Oper. Es wird üblicherweise in verwendet IP -Kameras als MIME -Typ für MJPEG Ströme.[13] Es wurde von Chrome für Hauptressourcen bis 2013 unterstützt (Bilder können weiterhin mit diesem Inhaltstyp angezeigt werden).[14]

Umfang

Der Mehrteil-/Byterange wird verwendet, um nicht zusammenhängende Bytebereiche einer einzelnen Nachricht darzustellen. Sie wird von HTTP verwendet, wenn ein Server mehrere Byte -Bereiche zurückgibt und in RFC 2616 definiert ist.

RFC -Dokumentation

  • RFC1426, SMTP-Dienstverlängerung für 8-Bit-MimetRansport. J. Klensin, N. befreit, M. Rose, E. Stefferud, D. Crocker. Februar 1993.
  • RFC1847, Sicherheitsmultipartionen für MIME: Multipart/signiert und mehrteilig/verschlüsselt
  • RFC3156, MIME -Sicherheit mit OpenPGP
  • RFC2045, MIME TEIL 1: Format von Internet -Nachrichtenkörpern
  • RFC2046, MIME TEIL 2: Medientypen. N. befreit, Nathaniel Borenstein. November 1996.
  • RFC2047, MIME TEIL DREI: Message Header-Erweiterungen für Nicht-ASCII-Text. Keith Moore. November 1996.
  • RFC4288, MIME TEIL FAST: Medientyp -Spezifikationen und Registrierungsverfahren.
  • RFC4289, MIME Teil vier: Registrierungsverfahren. N. Freed, J. Klensin. Dezember 2005.
  • RFC2049, MIME Teil 5: Konformitätskriterien und Beispiele. N. Freed, N. Borenstein. November 1996.
  • RFC2183, Kommunikation von Präsentationsinformationen in Internetnachrichten: Das Feld Content-Disposition-Header. Troost, R., Dorner, S. und K. Moore. August 1997.
  • RFC2231, MIME -Parameterwert und codierte Wortverlängerungen: Zeichensätze, Sprachen und Kontinuationen. N. Freed, K. Moore. November 1997.
  • RFC2387, Der MIME Multipart/verwandte Inhaltstyp
  • RFC1521, Mechanismen zur Angabe und Beschreibung des Formats von Internet -Nachrichtenkörpern

Siehe auch

Verweise

  1. ^ Terry Gliedt (27. Mai 1996). "Nachrichten - ein Multimedia -Mailer".
  2. ^ "Geschichte der Mime". networkworld.com. Februar 2011.
  3. ^ Giles Turnbull (2005-12-14). "Thunderbird zwingen, ausgehende Anhänge richtig zu behandeln". O'Reilly Mac DevCenter. Abgerufen 2010-04-01.
  4. ^ Ned befreit (2008-06-22). "Name und Dateiname Parameter". Abgerufen 2017-04-03.
  5. ^ RFC 2046, Abschnitt 5.1.3
  6. ^ RFC 2046, Abschnitt 5.1.5
  7. ^ "RFC1341 ABSCHNITT 7.2 DER MIELDIVIGE-Inhaltstyp". World Wide Web Konsortium. Abgerufen 2014-07-15.
  8. ^ a b "Überblick über Anti-Spam-Filtertechniken" (PDF). Internationales Forschungsjournal für Ingenieurwesen und Technologie. 4 (1). Januar 2017. S2CID 212596952. Abgerufen 2020-02-20.
  9. ^ RFC 2046, Abschnitt 5.1.4
  10. ^ RFC 1847, Abschnitt 2.1
  11. ^ RFC 1847, Abschnitt 2.2
  12. ^ "Eine Erforschung dynamischer Dokumente". Netscape. Archiviert von das Original Am 1998-12-03.
  13. ^ "Webcam Monitor Setup -Dokumentation". Deskshare. Archiviert Aus dem Original am 05.05.2010.
  14. ^ "249132 - Unterstützung für mehrteilige/x -mixte Replace -Hauptressourcen entfernen - Chrom - Monorail". bugs.chromium.org. Abgerufen 2017-10-10.

Weitere Lektüre

  • Hughes, L (1998). Internet -E -Mail -Protokolle, Standards und Implementierung. Artech House Publishers. ISBN 978-0-89006-939-4.
  • Johnson, K (2000). Internet -E -Mail -Protokolle: Ein Entwicklerhandbuch. Addison-Wesley Professional. ISBN 978-0-201-43288-6.
  • Loshin, P (1999). Wesentliche E -Mail -Standards: RFCs und Protokolle praktisch gemacht. John Wiley & Sons. ISBN 978-0-471-34597-8.
  • Rhoton, J (1999). Programmierhandbuch zu Internet Mail: SMTP, Pop, IMAP und LDAP. Elsevier. ISBN 978-1-55558-212-8.
  • Wood, D (1999). Programmieren von Internet Mail. O'Reilly. ISBN 978-1-56592-479-6.

Externe Links