Häufig gestellte Fragen über MIME und die Konvertierung von Inhalten in Exchange 2000 Server und Exchange Server 2003

Zusammenfassung

Dieser Artikel enthält Antworten auf häufig gestellte Fragen zu MIME-Standard und die codieren Methoden, die verschiedenen mailing-Systemen zusammenarbeiten können. Dieser Artikel beschreibt kurz wie verstümmelt oder nicht lesbare e-Mail-Nachrichten in einer Umgebung mit Microsoft Exchange beheben können.

Weitere Informationen

F1: Was ist das Format einer e-Mail-Nachricht?

A1: E-Mail-Nachrichten folgen den formatstandards, die in RFC 2822 definiert. Eine Nachricht besteht aus Headerfeldern und Text. Die Headerfelder heißen "Header" der Nachricht zusammen. Der Nachrichtentext ist optional. Eine Nachricht kann ohne Text, jedoch nicht ohne Header gesendet werden.

Die Kopfzeile enthält eine Folge von Zeichen mit einer besonderen Syntax Zeilen im Format Standard RFC 2822 definiert. Der Nachrichtentext enthält eine Folge von Zeichen, die den Header folgen und aus dem Header (eine Linie, die nichts Carriage Return) und Zeilenvorschub [CRLF] eine Leerzeile getrennt.

Kopfzeilenfelder sind Linien, die aus einem Feldnamen gefolgt von einem Doppelpunkt, gefolgt von einem Rumpf Feld und endete ein CRLF. Ein Feldname muss außer dem Doppelpunkt druckbaren US-ASCII-Zeichen (Zeichen, deren Werte zwischen 33 und 126 liegen,) bestehen. Der Doppelpunkt wird als ein Trennzeichen verwendet.

Feld Text kann von US-ASCII-Zeichen, mit Ausnahme der CRLF bestehen. Feld Text enthält jedoch ein CRLF im Header Falten und Abrollen. Faltung ist, der Einfachheit halber eine Zeile in mehrere Zeilen angezeigt wird. Entwicklung ist die Umkehrung dieser. Alle Feld stellen muss die Syntax 3 und 4 im standard RFC 2822 Format beschrieben.

Der Hauptteil der Nachricht kann einen oder mehrere Abschnitte enthalten. Jeder Textabschnitt wird durch eine Grenze getrennt. Der-Begrenzungsparameter ist eine Textzeichenfolge, die mit zwei Bindestriche (-) beginnt.

F2: Was ist MIME?

A2: MIME ist eine Standardmethode, mit der Inhalte verschiedener Typen in einer einzigen Nachricht enthalten. MIME erweitert Format Simple Mail Transfer Protocol (SMTP) e-Mail-Nachrichten an mehrere Inhalte, Text- und nicht-Text enthalten. Teile der Nachricht möglicherweise Bilder, audio oder Text in anderen Zeichen festgelegt. MIME-Standards von RFCs 2821 und 2822 abgeleitet.

F3: Wie geht Exchange um mit MIME?

A3: Es gibt drei Hauptkomponenten in Exchange, die Inhalt konvertieren:
  • Die Komponente IMAIL ist die Kernkomponente, die Internet-Nachrichten zu MAPI konvertiert / Exchange Format und umgekehrt. Außerdem überprüft die Integrität der Nachricht.
  • Die Komponente EXMIME ist verantwortlich für Internetnachrichten Exchange interne Objekt Darstellung übersetzen und Nachrichten im MIME-Format.
  • Die RFHTML-Komponente konvertiert Rich Text Format (RTF) Nachrichten HTML und auf Microsoft Outlook-Client und auf dem Exchange Server-Computer.

F4: Was sind die Mindestanforderungen für eine MIME-formatierte e-Mail-Nachricht

A4: Eine MIME-formatierte e-Mail-Nachricht haben normalerweise einen Header und Text. Zumindest müssen eine MIME-Nachricht eine Kopfzeile. Der Text ist optional. Kopfzeilenbereich enthält einen MIME-Version 1.0-Header (eine pro Nachricht gemäß RFC 2822 definiert).

Der Body-Bereich enthält:
  • Inhaltstyp (Dies ist optional. Der Standardwert ist Text/Plain gemäß RFC 2822 5.2.)
  • Content-Transfer-Encoding-Header (Dies ist optional. Der Standardwert ist 7-Bit gemäß RFC 2822 6.1.)
  • Content-Disposition-Header (Dies ist optional).
  • Content-ID (Dies ist optional).


F5: Was ist eine MIME-Versionsheader

A5: Feld MIME-Header gibt eine Nachricht im MIME-Format. Dieses Feld keinen Nachrichten aus früheren Software, die MIME nicht unterstützen. E-Mail-Clients verwenden das fehlen dieses Feldes zu nicht-MIME-Nachrichten.

F6: Was ist Content-Type-Headers

A6: Inhalt-Feld wird an den Typ und Untertyp der Daten in einem Feld verwendet.

Die Header-Typen sind Multipart/mixed, mehrteilige/Alternative Text/Plain, Text/html, die Anwendung/Appledatei, Application/ms-Tnef und Application/Octet-Stream.

F7: Was ist Content-Transfer-Encoding?

A7: Andere e-Mail-Systeme Daten anders behandeln und einige frühere e-Mail-Systeme nicht Multimediadaten behandeln.

Um Systeme umgehen, die Multimediadaten verarbeiten kann, wird ein Codierungsschema zu einheitlichen 7-Bit-Format verwendet. Wenn der Empfänger die Nachricht empfängt, werden die Daten in ihr ursprüngliches Format wiederhergestellt. Beispiele für Content-Transfer-Encoding-Formate sind:
  • Quoted-printable
  • Base64
  • 8-bit
  • 7-bit
  • Binäre


F8: Wie erfolgt Transfer-Encoding in Exchange 5.5?

A8: Exchange 5.5 codiert quoted printable-Format oder im 7-Bit-Format als erforderlich. Exchange 5.5 codiert außerdem Nachrichten im base64-Format, wenn 25 % der Nachricht besteht aus 8-Bit-Zeichen (Zeichen, die außerhalb des US-ASCII). Dies gilt nur für den Nachrichtentext. Anlagen sind immer base64-codiert.

F9: Wie ist Transfer-Encoding in Exchange 2000 Server implementiert?

A9: Routinggruppengrenzen und SMTP-Ziel Ziele bestimmen, wie Exchange 2000 Server e-Mail-Nachrichten codiert. Exchange 2000 wird als quoted printable- oder 7-Bit codiert oder Transport Neutral Encapsulation TNEF (Format) beim zwischen zwei Servern/Empfänger in verschiedenen Routinggruppen und an das Internet senden.

Exchange 2000 Server wird im Binär- oder Zusammenfassung TNEF codieren Empfänger/Server in derselben Routinggruppe.

F10: Wie ist Transfer-Encoding in Microsoft Exchange Server 2003 implementiert?

A10: Routing Grenzen bestimmen Exchange und SMTP Zielregionen auch wie Exchange Server 2003 Nachrichten codiert.

Im gemischten Modus von Exchange Server 2003 quoted printable- oder 7-Bit codiert (TNEF-Format) beim zwischen zwei Servern/Empfänger in verschiedenen Routinggruppen und an das Internet senden.

Im einheitlichen Modus codiert Exchange Server 2003 binär (Summary-TNEF) beim Senden an Empfänger/Server in derselben oder anderen Routinggruppen.

F11: Was ist ein Content-Disposition-Header?

A11: Dieser Header gibt an, ob ein Abschnitt als Anlage werden oder im Textkörper Nachricht angezeigt.

F12: Wie Exchange behandelt Anlagen?

A12: Exchange Server 2003 speichert Internetnachrichten im Originalformat. Dies bedeutet, dass eine Internet-Format-fähigen Client wie Outlook Express die Nachrichten gelesen werden, sie in ihrem ursprünglichen Format gerendert werden.

Beim Lesen von Nachrichten von einem MAPI-Client ordnet IMAIL, die entsprechenden Elemente in das Internetformat zu MAPI-Eigenschaften. Bevor eine Nachricht auch an ein Postfach geliefert wird, muss in der Tat ein minimalen Satz von MAPI-Eigenschaften der Internetnachricht gefördert werden. Dazu gehören PR_SENT_REPRESENTING, PR_SUBJECT und Empfängertabelle.

Andere MAPI-Eigenschaften wie PR_BODY, http://Schemas.Microsoft.com/mapi/proptag/0x10130102 und PR_ATTACH_DATA_BIN werden vom Internet-Format bei Bedarf berechnet. Konvertierung tritt auf, wenn ein MAPI-Client die Nachricht zum ersten Mal anfordert. Exchange 2000 Server wird dann die systemeigenen MIME-Eigenschaften in das MAPI-Format.

Während der Content-Konvertierung in Exchange Server 2003 bei der Wiedergabe einer MIME-Nachricht an einem Client führt IMAIL Folgendes aus:
  1. IMAIL überprüft einen vollständigen Dateinamen (Namen. Ext) in MIME-Header. Ein Name gefunden wird, wird der Dateiname verwendet.
  2. IMAIL überprüft ein partieller Dateiname. Wenn eine gefunden wird, untersucht IMAIL Unterschlüssel HKEY_CLASSES_ROOT/MIME/Datenbank/Inhaltstypden Inhaltstyp Erweiterung zuordnen. Ein entsprechenden Inhaltstyp gefunden wird, wird die Erweiterung der Anlage hinzugefügt. Wenn keine entsprechenden Inhaltstyp gefunden wird, wird der Teil eines Dateinamens verwendet.
  3. Keine Dateinamen im Inhaltstyp oder Content-Disposition-Header angegeben, sucht IMAIL entsprechenden Inhaltstyp. Wenn gefunden, wird die Anlage Format ATTNamenhaben. Ext, Ext die Erweiterung ist, die diesen Inhaltstyp zugeordnet ist. Wenn keine entsprechenden Inhaltstyp gefunden wird, wird eine Erweiterung der ".att" verwendet. Exchange 2000 Server erfordert einen Dateinamen in der Content-Type-Header.


F13: Welche die vollständige Meldung ist?

A13: Folgendes ist ein Beispiel für eine vollständige Nachricht mit allen Headern angezeigt. Empfängern wird im Allgemeinen nur die Körperteile angezeigt. Kommentare wurden hinzugefügt, in Klammern.

Received: from SMTP server (server1.example1.com IP address) 
by Receiver SMTP version 1.0 (server2.example2.com IP address);

Mon, 28 Oct 2002 08:42:42 -0500 (EST)

Message-ID: <006@example1.com>

From: "User1" <user1@example1.com> (RFC 2822 sender)

To: "User2" user2@example2.com> (RFC 2822 recipient)

Subject: A test message to see if you can see me now!

Date: Mon, 8 Nov 2002 13:46:54 +0100

MIME-Version: 1.0

Content-Type: multipart/mixed;
boundary="----=_NextPart_000_005A_01C27E88.79B98A90"

X-Priority: 3

Return-Path: user1@domain1.com

X-OriginalArrivalTime: 28 Oct 2002 13:45:00.0541 (UTC)
FILETIME=[35F0A2D0:01C27E88]



This is a multi-part message in MIME format (If you see this in the message
body, there is a problem. Notice there is no space or CRLF in the headers in the previous text. There must be no space until the message body itself)



This message is in MIME format. Since your mail reader does not understand this
format, some or all of this message may not be legible. (If you see this in the
message body, there is a problem)



------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary)



Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit



Can you see me now??! (This is the text of the message. You see this in your mail client.)



------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary. See Multipart/Mixed
definition earlier in this article.)

Content-Type: image/jpeg;

name="Haloweenpictures.jpg"

Content-Transfer-Encoding: base64 (All attachments in Exchange 2000 Server are encoded by using base64 and bloat 33%.)

Content-Disposition: attachment;

filename="Haloweenpictures.jpg"



/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB (Base64 data in raw format. This is the picture being encoded in binary format; to
be repackaged later back as a picture.)

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

------=_NextPart_000_005A_01C27E88.79B98A90--



F14: Warum werden e-Mail-Adressen im Textkörper der Nachricht angezeigt?

A14: Die erste "CRLF CRLF" in der MIME-Stream kennzeichnet den Beginn des Nachrichtentextes. Daher besteht eine Folge < CRLF >< CRLF > zwischen zwei Header, der Client (Microsoft Outlook oder Microsoft Outlook Express) eine unlesbare Nachricht angezeigt.

Die erste "CRLF CRLF" trennt Nachrichtentext Nachrichtenkopfzeilen Internet. Diese Header werden als P1-Header bezeichnet. P1-Header Umschlag Header und sind nicht Teil der Nachricht, die von IMAIL verarbeitet.

Exchange kann ein Smarthost Content Scanner, Virenschutz und Firewall weiterleiten. Firewallsoftware von Drittanbietern kann manchmal Nachrichten verzerrt.

Sie können auch e-Mail-Nachrichten über ein UNIX-System, über eine Firewall oder Viren-Wall erhalten. Außerdem kann ein Inhaltsscan-Geräts im Netzwerk sein. Wenn Sie ähnliche Programme oder Geräte in Ihrem Netzwerk haben, überprüfen Sie aktiv wird. Verwenden Sie diese Geräte oder Programme Diagnosen.

F15: Warum werden Fragezeichen in meiner Nachricht angezeigt?

A15: Wenn Fragezeichen in der Nachricht angezeigt, bedeutet dies, dass das System nicht weiß, dass einige ANSI- oder Unicode-Zeichen übersetzen, die in der Nachricht. Sie müssen sicherstellen, dass der Client, in dem die Nachricht angezeigt wird, Codepages installiert verfügt den eingehenden Zeichensatz. Beispielsweise stellen Sie sicher, dass Windows Workstation hat das japanische Gebietsschema installiert, Anzeigen von Nachrichten, die in Japanisch geschrieben werden.

F16: Warum sind HTML-Nachrichten öffnen und angezeigt Ereignisse 12002 und 12003 in meinem Anwendungsprotokoll?

A16: Diese Ereignisse im Anwendungsprotokoll der Quelle Exchange-Informationsspeicher und Konvertierung von Inhalten auftreten. Einige dieser Nachrichten kann ignoriert und wirkt sich nicht auf die Nachrichten haben. Aber wenn viele dieser Nachrichten in den Anwendungsprotokollen angezeigt werden, wenn Clients Probleme beim Öffnen von HTML-Nachrichten.

Wenn dies der Fall ist, weitere Diagnoseinformationen wie Service Pack-Versionen, Problem Nachrichten kopiert und Systemprotokolle, einrichten und dann die Problembehandlung.

F17: Warum sehe ich manchmal Nachrichtentext als Anlage?

A17: Sie müssen Informationen über die Quelle der Nachricht einrichten. Sie müssen alle Details des Quellservers einrichten. Überprüfen Sie, ob der Absender auf einem UNIX-Netzwerk ist. Weitere Informationen, klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

323482 Exchange zeigt Meldung mit "Inline" MIME-Content-Disposition-Header als Anlage

F18: Warum sehe ich "Dies ist eine mehrteilige Nachricht im MIME-Format" oder "Diese Nachricht ist im MIME-Format" im Textkörper der E-mail?

A18: Die folgenden im Text auftreten:
  • "Dies ist eine mehrteilige Nachricht im MIME-Format."
  • "Diese Nachricht ist im MIME-Format. Da Ihr e-Mail-Leseprogramm nicht dieses Format unterstützen, können einige oder alle dieser Nachricht nicht lesbar."

Dieser Text wird vor der ersten Begrenzung, ist in der Regel in jeder mehrteilige Nachricht und ist nicht für den Client angezeigt, wenn ein Problem mit dem e-Mail-Format vorliegt. Beispielsweise kann ein harten Zeilenumbruch in der Nachricht in der falschen Position eingefügt wurden.

Um dieses Problem zu beheben, schalten Sie Nachricht Archivierung für Microsoft Exchange Internet Mail-Dienst. Um Nachricht Archivierung aktivieren, Exchange Server 2003 Archive Sink Dienstprogramm Speichern der Meldung als EML oder PST-Datei und führen Sie dann eine Analyse. Weitere Informationen über Archive Sink Feature klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

307798 das Archive Sink Dienstprogramm ist in Service Pack 2 verfügbar

F19: Warum Meine Mail ist 33 % größer als erwartet, und warum base64-codierte auch wenn sie keine Anlagen enthalten?



A19: Dieses Verhalten tritt auf, wenn die folgenden Zeichensätze verwenden:
  • GBK

  • KOR

  • Japanisches EUC

  • Koreanische ISO-2202-KR
  • Taiwan ISO-2202-TW

  • Chinesische ISO-2202-CN

  • GB18030 Chinesisch HZ_GB, Big5,


F20: Was sind andere und bekannte Probleme

A20: Nachrichten von einem Exchange Server 2003-Server zu einem anderen weitergeleitet werden können, werden falsch angezeigt, und die Empfänger der Nachricht möglicherweise im Textkörper der Nachricht angezeigt.

Beispielsweise kann dies in einer Nachricht, die aus dem Internet auf eine eingehende Internet Exchange Server 2003-Computer und auf einem anderen Exchange Server 2003-Computer weitergeleitet wird.
Die Nachricht möglicherweise einwandfrei auf eingehende Internet Exchange Server 2003 aber verzerrt auf Back-End-Exchange Server. Diese Symptome können auch ändern, sinkt die Anzahl der Empfänger für die Nachricht. Dieses Problem kann aus mehreren Gründen angezeigt werden, aber die beiden häufigsten Gründe sind:
  • RFC 2822-Nachrichtenköpfe, die mehr als 1000 oder 1024 Zeichen in einer Zeile und nicht 998 Zeichen in einer Zeile haben. Weitere Informationen finden Sie in Request for Comments (RFC) 2822. Dazu finden Sie auf der Website der Internet Engineering Task Force (IETF):Dieses Problem kann auftreten, wenn Nachrichten an einen Exchange Server 2003-Computer mithilfe von Binärdaten oder Segmentierungweitergeleitet werden. Segmentierung ist eine Erweiterung des SMTP-Formats, die Daten in Segmenten unterstützt.

    Wenn Exchange Server 2003 eine Nachricht, die über 998 Zeichen in einer Zeile empfängt, der SMTP-Dienst Header analysiert und entdeckt, dass die Zeile mehr als 1000 Zeichen. Der SMTP-Dienst übernimmt diese Zeile gehört nicht zu einem Header und im Text enthält.

    Der SMTP-Dienst auf dem Exchange Server-Computer wird dann eigene Header umschreiben Nachrichten-ID sowie ein DATE-Header folgt eine Leerzeile oder ein CRLF.
  • Grenzwerte der Zeile Länge. Es gibt viele Implementierungen, die Beförderung gemäß RFC 2821 keine Nachrichten akzeptieren, die mehr als 1000 Zeichen pro Zeile das CRLF. Daher müssen e-Mail-Programme Nachrichten nicht erstellen. Um dieses Problem zu umgehen, deaktivieren Sie die Funktion zum ESMTP Verb (oder Segmentierung) auf Exchange Server-Computer und erzwingen Sie die Exchange Server-Computer Format Standard SMTP Nachrichten formatieren, wenn die Nachricht weitergeleitet wird. Für Weitere Informationen klicken Sie auf die folgenden Artikelnummer der Microsoft Knowledge Base:

    257569 wie ESMTP-Verben in Exchange 2000 Server und Exchange Server 2003 deaktiviert

    821733 eingehende Nachricht ist verzerrt, wenn die Zeile 1022 Zeichen überschreitet

Referenzen

Weitere Informationen zum Standard für das Format von ARPA-Internettextnachrichten finden Sie in RFC 822. Hierzu finden Sie auf der folgenden IETF-Website:Weitere Hinweise zu MIME finden Sie in RFC 2045 2046, 2047, 2048 und 2049. Dazu finden Sie auf der folgenden IETF-Websites:Weitere Informationen über das Content-Disposition-Header-Feld finden Sie in RFC 2183. Dazu finden Sie auf der folgenden IETF-Website:
Eigenschaften

Artikelnummer: 836555 – Letzte Überarbeitung: 10.01.2017 – Revision: 1

Feedback