Multipurpose Internet Mail Extensions - Versionsgeschichte

CyberBibliothekar: /* growthexperiments-addlink-summary-summary:1|1|0 */

CyberBibliothekar — Tue, 01 Apr 2025 11:00:55 GMT

Linkvorschlag-Funktion: 1 Link hinzugefügt.

← Nächstältere Version		Version vom 1. April 2025, 13:00 Uhr
Zeile 14:		Zeile 14:
	Es gibt eine Erweiterung dieses Standards namens [[S/MIME]] (Secure MIME), der auch das [[Kryptographie\|Verschlüsseln]] und [[Elektronische Unterschrift\|digitale Signieren]] von Nachrichten erlaubt. Außerdem existiert mit [[PGP/MIME]] (beschrieben in <nowiki>RFC 2015</nowiki><ref name="RFC2015" /> und <nowiki>RFC 3156</nowiki><ref>{{RFC-Internet \|RFC=3156 \|Titel=MIME Security with OpenPGP \|Datum=2001-08}}</ref>) auch eine [[Pretty Good Privacy\|PGP]]-kompatible Erweiterung für sicheren Datenaustausch.		Es gibt eine Erweiterung dieses Standards namens [[S/MIME]] (Secure MIME), der auch das [[Kryptographie\|Verschlüsseln]] und [[Elektronische Unterschrift\|digitale Signieren]] von Nachrichten erlaubt. Außerdem existiert mit [[PGP/MIME]] (beschrieben in <nowiki>RFC 2015</nowiki><ref name="RFC2015" /> und <nowiki>RFC 3156</nowiki><ref>{{RFC-Internet \|RFC=3156 \|Titel=MIME Security with OpenPGP \|Datum=2001-08}}</ref>) auch eine [[Pretty Good Privacy\|PGP]]-kompatible Erweiterung für sicheren Datenaustausch.

	Eine Multipart-Message enthält mehrere Bodyparts, die durch benannte Grenzlinien (''boundary'') abgegrenzt werden, bei deren Bezeichner sichergestellt werden muss, dass dieser nicht im restlichen Bodypart vorkommt. Häufig geschieht dies durch Wahl einer zufälligen Zeichenfolge, deren Auftreten im restlichen Bodypart unwahrscheinlich ist. Beispiel für eine einfache Multipart-Message (mit einem verkürzten boundary, das hier als <code>frontier</code> festgelegt ist):		Eine Multipart-Message enthält mehrere Bodyparts, die durch benannte Grenzlinien (''boundary'') abgegrenzt werden, bei deren [[Bezeichner]] sichergestellt werden muss, dass dieser nicht im restlichen Bodypart vorkommt. Häufig geschieht dies durch Wahl einer zufälligen Zeichenfolge, deren Auftreten im restlichen Bodypart unwahrscheinlich ist. Beispiel für eine einfache Multipart-Message (mit einem verkürzten boundary, das hier als <code>frontier</code> festgelegt ist):

	<pre>		<pre>

TenWhile6: Änderungen von 2A01:599:B0F:ADAD:58FD:1455:AD09:24C8 (Diskussion) wurden auf die letzte Version von Matthäus Wander zurückgesetzt: grund?

TenWhile6 — Mon, 29 Apr 2024 18:56:25 GMT

Änderungen von 2A01:599:B0F:ADAD:58FD:1455:AD09:24C8 (Diskussion) wurden auf die letzte Version von Matthäus Wander zurückgesetzt: grund?

← Nächstältere Version		Version vom 29. April 2024, 20:56 Uhr
Zeile 55:		Zeile 55:
	To: <eva@example.org>		To: <eva@example.org>
	Subject: Umlaute dank MIME		Subject: Umlaute dank MIME
			MIME-Version: 1.0
			Content-Type: text/plain; charset=[[ISO 8859-15\|iso-8859-15]]
			Content-Transfer-Encoding: 8bit

	Wären die drei zusätzlichen Kopfzeilen nicht, wäre diese Zeile nicht leserlich.		Wären die drei zusätzlichen Kopfzeilen nicht, wäre diese Zeile nicht leserlich.

2A01:599:B0F:ADAD:58FD:1455:AD09:24C8: /* Beispiel */

2A01:599:B0F:ADAD:58FD:1455:AD09:24C8 — Mon, 29 Apr 2024 18:55:43 GMT

Beispiel

← Nächstältere Version		Version vom 29. April 2024, 20:55 Uhr
Zeile 55:		Zeile 55:
	To: <eva@example.org>		To: <eva@example.org>
	Subject: Umlaute dank MIME		Subject: Umlaute dank MIME
	MIME-Version: 1.0
	Content-Type: text/plain; charset=[[ISO 8859-15\|iso-8859-15]]
	Content-Transfer-Encoding: 8bit

	Wären die drei zusätzlichen Kopfzeilen nicht, wäre diese Zeile nicht leserlich.		Wären die drei zusätzlichen Kopfzeilen nicht, wäre diese Zeile nicht leserlich.

Matthäus Wander: HC: Entferne Kategorie:IT-Standard; Ergänze Kategorie:Internetstandard

Matthäus Wander — Wed, 26 Jul 2023 21:43:39 GMT

HC: Entferne Kategorie:IT-Standard; Ergänze Kategorie:Internetstandard

← Nächstältere Version		Version vom 26. Juli 2023, 23:43 Uhr
Zeile 184:		Zeile 184:

	[[Kategorie:E-Mail]]		[[Kategorie:E-Mail]]
	[[Kategorie:~~IT-Standard~~]]		[[Kategorie:Internetstandard]]
	[[Kategorie:Multipurpose Internet Mail Extensions\| ]]		[[Kategorie:Multipurpose Internet Mail Extensions\| ]]

Matthäus Wander: katsort

Matthäus Wander — Wed, 26 Jul 2023 12:23:47 GMT

katsort

← Nächstältere Version		Version vom 26. Juli 2023, 14:23 Uhr
Zeile 185:		Zeile 185:
	[[Kategorie:E-Mail]]		[[Kategorie:E-Mail]]
	[[Kategorie:IT-Standard]]		[[Kategorie:IT-Standard]]
	[[Kategorie:Multipurpose Internet Mail Extensions]]		[[Kategorie:Multipurpose Internet Mail Extensions\| ]]

Matthäus Wander: HC: Ergänze Kategorie:Multipurpose Internet Mail Extensions

Matthäus Wander — Wed, 26 Jul 2023 12:20:23 GMT

HC: Ergänze Kategorie:Multipurpose Internet Mail Extensions

← Nächstältere Version		Version vom 26. Juli 2023, 14:20 Uhr
Zeile 185:		Zeile 185:
	[[Kategorie:E-Mail]]		[[Kategorie:E-Mail]]
	[[Kategorie:IT-Standard]]		[[Kategorie:IT-Standard]]
			[[Kategorie:Multipurpose Internet Mail Extensions]]

PerfektesChaos: tk k

PerfektesChaos — Sun, 25 Jun 2023 13:14:34 GMT

tk k

Änderungen zeigen

Ulanwp: 4 Vorlagenparameterfehler beseitigt: RFC führt im Parser zum Fehler: Linktext ungültig; RFC maskiert; Vorlagen nach Internetquelle konvertiert und fehlende Sprachparameter eingefügt

Ulanwp — Sun, 29 Jan 2023 14:53:27 GMT

4 Vorlagenparameterfehler beseitigt: RFC führt im Parser zum Fehler: Linktext ungültig; RFC maskiert; Vorlagen nach Internetquelle konvertiert und fehlende Sprachparameter eingefügt

@@ Zeile 102: / Zeile 102: @@
 *: Dieser Untertyp ist für Systeme vorgesehen, die alle Typen von Inhalten zugleich präsentieren können.
 * multipart/related
-*: Dieser Untertyp ist separat in RFC 2387 definiert und zur Kombination mehrerer Inhalte vorgesehen, die nur zusammen Sinn ergeben. Die in RFC 2557 definierte [[MIME Encapsulation of Aggregate HTML Documents|MIME Encapsulation of Aggregate Documents]] baut darauf auf. Sie war die Konsequenz aus dem Umstand, dass [[Hypertext Markup Language]] (HTML) kein Standard für MIME werden konnte.<ref>{{cite web
+*: Dieser Untertyp ist separat in RFC 2387 definiert und zur Kombination mehrerer Inhalte vorgesehen, die nur zusammen Sinn ergeben. Die in RFC 2557 definierte [[MIME Encapsulation of Aggregate HTML Documents|MIME Encapsulation of Aggregate Documents]] baut darauf auf. Sie war die Konsequenz aus dem Umstand, dass [[Hypertext Markup Language]] (HTML) kein Standard für MIME werden konnte.<ref>{{Internetquelle |url=https://www.rfc-editor.org/info/rfc2854 |titel=&#82;&#70;&#67; 2854 - The 'text/html' Media Type |hrsg=[[Internet Engineering Task Force]] |datum=2000-06 |abruf=2022-01-01 |sprache=en}}</ref> Zudem wurde der Begriff ''[[Internet Media Type]]'' und schließlich der Begriff ''XHTML&nbsp;Media&nbsp;Type'' für Ausrichtung auf das [[Hypertext Transfer Protocol]] (HTTP) statt auf das [[Simple Mail Transfer Protocol]] (SMTP) geprägt.<ref>{{Internetquelle |url=http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020430/ |titel=XHTML Media Types |hrsg=[[World Wide Web Consortium]] |datum=2002-04-30 |abruf=2011-07-25 |sprache=en}}</ref>
 ==== message ====
@@ Zeile 143: / Zeile 130: @@
 === MIME Part 4 – Registration Procedures ===
 === MIME Part 5 – Conformance Criteria and Examples ===

Bernhard Wallisch: Änderung 219794968 von 37.24.185.178 rückgängig gemacht. Wieso??

Bernhard Wallisch — Wed, 02 Feb 2022 15:59:16 GMT

Änderung 219794968 von 37.24.185.178 rückgängig gemacht. Wieso??

← Nächstältere Version		Version vom 2. Februar 2022, 17:59 Uhr
Zeile 131:		Zeile 131:
	Ursprünglich war es nicht erlaubt, im Betreff von E-Mails Umlaute oder andere Sonderzeichen zu verwenden, sondern nur die in [[ASCII]] definierten Zeichen.		Ursprünglich war es nicht erlaubt, im Betreff von E-Mails Umlaute oder andere Sonderzeichen zu verwenden, sondern nur die in [[ASCII]] definierten Zeichen.
	Ein Betreff wie „Schöne Grüße“ konnte dann, je nachdem, von welchen Programmen die E-Mail übertragen wurde, als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr\|_e“ ankommen.		Ein Betreff wie „Schöne Grüße“ konnte dann, je nachdem, von welchen Programmen die E-Mail übertragen wurde, als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr\|_e“ ankommen.
	Um diese Probleme zu beheben, wurde in RFC 1522<ref>https://datatracker.ietf.org/doc/html/rfc1522, später erweitert durch RFC 2047 im Jahr 1996</ref> im Jahr 1993 ein Verfahren definiert, wie der Betreff beim Absender codiert und beim Empfänger wieder decodiert wird, ohne dass während der Übertragung die Daten verfälscht werden, ~~dieses~~ besteht aus folgendem Schema:		Um diese Probleme zu beheben, wurde in RFC 1522<ref>https://datatracker.ietf.org/doc/html/rfc1522, später erweitert durch RFC 2047 im Jahr 1996</ref> im Jahr 1993 ein Verfahren definiert, wie der Betreff beim Absender codiert und beim Empfänger wieder decodiert wird, ohne dass während der Übertragung die Daten verfälscht werden. Dieses besteht aus folgendem Schema:
	: <code>=?Zeichensatz?Kodierung?Kodierter Text?=</code>		: <code>=?Zeichensatz?Kodierung?Kodierter Text?=</code>

37.24.185.178: /* message */

37.24.185.178 — Wed, 02 Feb 2022 12:08:48 GMT

message

← Nächstältere Version		Version vom 2. Februar 2022, 14:08 Uhr
Zeile 131:		Zeile 131:
	Ursprünglich war es nicht erlaubt, im Betreff von E-Mails Umlaute oder andere Sonderzeichen zu verwenden, sondern nur die in [[ASCII]] definierten Zeichen.		Ursprünglich war es nicht erlaubt, im Betreff von E-Mails Umlaute oder andere Sonderzeichen zu verwenden, sondern nur die in [[ASCII]] definierten Zeichen.
	Ein Betreff wie „Schöne Grüße“ konnte dann, je nachdem, von welchen Programmen die E-Mail übertragen wurde, als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr\|_e“ ankommen.		Ein Betreff wie „Schöne Grüße“ konnte dann, je nachdem, von welchen Programmen die E-Mail übertragen wurde, als „Sch?ne Gr??e“, „Sch�ne Gr��e“ oder „Schvne Gr\|_e“ ankommen.
	Um diese Probleme zu beheben, wurde in RFC 1522<ref>https://datatracker.ietf.org/doc/html/rfc1522, später erweitert durch RFC 2047 im Jahr 1996</ref> im Jahr 1993 ein Verfahren definiert, wie der Betreff beim Absender codiert und beim Empfänger wieder decodiert wird, ohne dass während der Übertragung die Daten verfälscht werden. ~~Dieses~~ besteht aus folgendem Schema:		Um diese Probleme zu beheben, wurde in RFC 1522<ref>https://datatracker.ietf.org/doc/html/rfc1522, später erweitert durch RFC 2047 im Jahr 1996</ref> im Jahr 1993 ein Verfahren definiert, wie der Betreff beim Absender codiert und beim Empfänger wieder decodiert wird, ohne dass während der Übertragung die Daten verfälscht werden, dieses besteht aus folgendem Schema:
	: <code>=?Zeichensatz?Kodierung?Kodierter Text?=</code>		: <code>=?Zeichensatz?Kodierung?Kodierter Text?=</code>