Nejčastější dotazy týkající se formátu MIME a převodu obsahu na serveru Exchange 2000 Server a Exchange Server 2003

Souhrn

Tento článek obsahuje odpovědi na časté otázky týkající se standardu MIME a kódování metody, které umožňují různé poštovní systémy společně pracovat. Tento článek stručně vysvětluje, jak lze řešit nečitelné nebo nečitelný e-mailových zpráv v prostředí Microsoft Exchange.

Další informace

Q1: Co je formát e-mailové zprávy?

A1: Internetové e-mailové zprávy podle formátu standardy, které jsou definovány v dokumentu RFC 2822. Zpráva se skládá z polí záhlaví a obsahu. Pole záhlaví jsou společně s názvem "záhlaví" zprávy. Text zprávy je volitelné. Zprávu lze odeslat bez karoserie, nikoli však bez záhlaví.

Hlavička obsahuje posloupnost znaků, které mají speciální syntaxi řádky definované v standardu RFC 2822 formátu. Tělo obsahuje posloupnost znaků, které následují hlavičku a které jsou odděleny z hlavičky prázdný řádek (to znamená čáru nic před návratu vozíku) a odřádkování [CRLF].

Pole záhlaví jsou řádky, které se skládají z názvu pole následované dvojtečkou (:) následované subjekt pole a ukončeny znak CRLF. Název pole se skládají z tisknutelných znaků US-ASCII (tj znaků, které mají hodnoty mezi 33 a 126, včetně), s výjimkou dvojtečka. Dvojtečka se používá jako znak pro oddělení.

Pole text může být složen z libovolných znaků US-ASCII, kromě CRLF. Pole subjekt však může obsahovat CRLF při použití v záhlaví skládání a vysouvaly. Skládání je, když pro pohodlí jednoho řádku se zobrazí na více řádcích. Vysouvaly je to naopak. Všechna pole subjekty musí splňovat syntaxi popsané v oddílech 3 a 4 standardu RFC 2822 formátu.

Text zprávy může obsahovat jeden nebo více oddílů. Každá část těla oddělena hranici. Parametr hranice je textový řetězec, který začíná dva spojovníky (-).

Q2: Co je to MIME?

A2: MIME je standard, který slouží k zahrnutí obsahu různých typů do jedné zprávy. MIME rozšiřuje e-mailových zpráv, které chcete zahrnout více obsahu, textový a jiný než textový formát přenosu protokolu SMTP (Simple Mail). Části zprávy mohou být obrázky, zvuk, nebo nastaví text v různých znaků. MIME standard se odvozuje z RFC například 2821 a RFC 2822.

Q3: Jak Exchange zpracovat MIME?

A3: Existují tři hlavní součásti serveru Exchange provést převod obsahu:
  • Součást IMAIL je základní součást, která převádí internetových zpráv MAPI / Exchange formátu a naopak. Také zkontroluje integritu zprávy.
  • Součást EXMIME odpovídá pro překlad internetových zpráv v zastoupení vnitřní objekt na serveru Exchange a pro generování zpráv ve formátu MIME.
  • Součást RFHTML převede zprávy RTF (RICH Text Format), HTML a naopak, podle nastavení v klientovi aplikace Microsoft Outlook a nastavení v počítači Exchange Server.

Otázka č. 4: Jaké jsou minimální požadavky ve formátu MIME e-mailové zprávy?

A4: MIME e-mailové zprávy bude obvykle mít záhlaví a obsahu. Minimálně musí mít zprávy MIME hlavičku. Text je volitelný. Sekce záhlaví obsahuje záhlaví MIME verze 1.0 (jeden na zprávu, jak je definováno v dokumentu RFC 2822).

Část těla obsahuje:
  • Typ obsahu (to je nepovinné. Ve výchozím nastavení je text/plain, jak je definováno v dokumentu RFC 2822 5.2).
  • Záhlaví obsah-přenos-kódování (to je nepovinné. Výchozí hodnota je 7 bitů, jak je definováno v dokumentu RFC 2822 6.1.)
  • Záhlaví Content-Disposition (to je nepovinné.)
  • ID obsahu (to je nepovinné.)


Dotaz č. 5: Co je záhlaví verze MIME?

A5: V poli záhlaví verze MIME označuje formátované zprávy MIME. Zprávy odeslané z dřívějších softwaru, které nepodporují MIME není nutné toto pole. Poštovních klientů pomocí absence tohoto pole Rozlišovat zprávy bez kódování MIME.

6: Co je záhlaví typ obsahu?

A6: Pole Content-Type slouží k určení typu a podtyp dat v poli.

U některých typů záhlaví jsou multipart/smíšené multipart/alternativa, text/plain, text/html, aplikace/applefile, application/ms-tnef a application/octet-stream.

Q7: Co je obsah-přenos-kódování?

A7: Jiné poštovní systémy zpracování dat odlišně a některé starší systémy pošty nemůže zpracovat multimediální data.

Chcete-li vyřešit systémy, které nelze zpracovat multimediální data, kódovací schéma lze data převést do formátu uniform 7 bitů. Když příjemce obdrží zprávu, budou data obnovena do původního formátu. Obsah-přenos-kódování formátů příklady:
  • Tisknutelné uvozovkách
  • Base64
  • 8-bit
  • 7-bit
  • Binární


Otázka č. 8: Způsob kódování přenosu implementace serveru Exchange 5.5?

A8: Exchange 5.5 kóduje v tisknutelné uvozovkách formátu nebo ve formátu 7 bitů, jak je požadováno. Navíc Exchange 5.5 kóduje zprávy ve formátu base64, pokud 25 % zprávy je tvořena 8bitové znaky (tj. znaky, které jsou mimo rozsah US-ASCII). To platí pouze pro těla zpráv; přílohy jsou vždy kódování base64.

Dotaz 9: Způsob kódování přenosu implementace serveru Exchange 2000 Server?

A9: Směrování skupiny hranic a určení cílového SMTP určit, jak Exchange 2000 Server kóduje pošty. Exchange 2000 bude kódovat jako uvozovky vytisknout nebo 7bitové nebo Transport neutrální zapouzdření formát TNEF () při odesílání mezi dvěma servery nebo příjemci v různých skupin směrování a k Internetu.

Exchange 2000 Server bude kódovat v binárním nebo formátu TNEF souhrn k odeslání příjemci/server ve stejné skupině směrování.

Q10: Způsob kódování přenosu implementace serveru Microsoft Exchange Server 2003?

A10: Při směrování skupiny hranic, Exchange a SMTP cílových míst také určit, jak Exchange Server 2003 kóduje pošty.

V kombinovaném režimu, Exchange Server 2003 kóduje jako uvozovky vytisknout nebo 7 bitů (TNEF formát) při odesílání mezi dvěma servery nebo příjemci v různých skupin směrování a k Internetu.

V nativním režimu Exchange Server 2003 kóduje v binárním (formátu souhrn TNEF) při odesílání příjemce/server ve stejné nebo jiné skupiny směrování.

Otázka č. 11: Co je záhlaví Content-Disposition?

A11: Toto záhlaví označuje, zda oddíl bude zobrazen jako přílohu nebo zobrazí v těle zprávy.

Otázka č. 12: Jak Exchange zpracování příloh?

A12: Exchange Server 2003 ukládá zprávy sítě Internet v jejich nativním formátu. To znamená, že pokud jsou zprávy číst z Internetu formát aware klienta jako Outlook Express, budou vykresleny v jejich původním formátu.

Však při přečtení zpráv MAPI klienta IMAIL mapuje příslušných prvků ve formátu Internet vlastnosti rozhraní MAPI. Ve skutečnosti před internetovou zprávu i k poštovní schránce, minimální sadu vlastností rozhraní MAPI musí být povýšen z internetových zpráv; patří sem PR_SENT_REPRESENTING, PR_SUBJECT a tabulky příjemců.

Další vlastnosti rozhraní MAPI, jako PR_BODY, PR_HTML a PR_ATTACH_DATA_BIN jsou vypočítanou z formátu Internet na vyžádání. Převodu dochází, když klient rozhraní MAPI požádá první zprávy. Exchange 2000 Server pak podporuje nativní formát MAPI vlastnosti MIME.

Během převodu obsahu v Exchange Server 2003 při vykreslování příchozí zprávy MIME klientovi IMAIL provede následující akce:
  1. Kontroluje IMAIL úplný název souboru (název. Roz) v záhlaví MIME. Pokud je nalezen název, název souboru se používá.
  2. Název souboru částečné kontroluje IMAIL. Pokud je nějaká nalezena, IMAIL vypadá na podklíč HKEY_CLASSES_ROOT/MIME/databáze/typ obsahumapování přípony názvu souboru k typu obsahu. Pokud je nalezen odpovídající typ obsahu, toto rozšíření je přidán do přílohu. Pokud je nalezen žádný odpovídající typ obsahu, se používá název souboru částečné.
  3. Pokud žádné názvy souborů jsou uvedeny v záhlaví Content-type nebo Content-Disposition, IMAIL vyhledá odpovídající typu obsahu. Pokud je nějaká nalezena, příloha bude mít formát ATTnázev. linka, kde ext představuje rozšíření, který je spojen s tímto typem obsahu. Pokud je nalezen žádný odpovídající typ obsahu, se používá příponu ".att". Exchange 2000 Server vyžaduje název souboru v záhlaví Content-type.


13: Co je struktura celou zprávu?

Odpověď č. 13: Následuje příklad celou zprávu s všechny hlavičky, které jsou zobrazeny. Příjemcům se obvykle zobrazí pouze části těla. Byly přidány komentáře v hranatých závorkách.

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--



Q14: Proč se mailové adresy zobrazí v těle zprávy?

A14: První "CRLF CRLF" v proudu MIME označuje začátek textu zprávy. Proto pokud < CRLF >< CRLF > sekvence mezi dvěma záhlaví, klient (aplikace Microsoft Outlook nebo Microsoft Outlook Express) zobrazí poškozenými zpráva.

První "CRLF CRLF" odděluje Internetová záhlaví zprávy z textu zprávy. Tato záhlaví se nazývají záhlaví P1. P1 záhlaví záhlaví obálky jsou a nejsou součástí internetovou zprávu, která je zpracována IMAIL.

Exchange může předat inteligentnímu hostiteli, obsahu skenovacího zařízení, virus zdi nebo brány firewall. Software brány firewall jiných výrobců mohou někdy narušovat zprávy.

Může také zobrazovat e-mailové zprávy prostřednictvím systému UNIX, přes bránu firewall nebo přes zeď viru. Prohledávání obsahu zařízení jiných výrobců mohou být v síti. Pokud máte podobné aplikace nebo zařízení v síti, zkontrolujte omezení počtu příjemců. Vyhněte se použití těchto zařízení nebo aplikace diagnostických testů.

Q15: Proč otazníky zobrazí ve zprávě?

A15: Ve zprávě se zobrazí otazník, znamená to, že systém neví, jak přeložit některé znaky ANSI nebo Unicode, které jsou ve zprávě. Ujistěte se, že má klient kde je zobrazena zpráva znakových stránek, které odpovídají příchozí znakové sady nainstalovány. Například zajistěte k pracovní stanici Windows japonské národní prostředí nainstalována Chcete-li zobrazit zprávy, které jsou napsány v japonštině.

Otázka č. 16: Proč mám potíže při otevření zprávy ve formátu HTML a v tématu události 12002 a 12003 mé protokolu aplikace?

A16: Tyto události protokolu aplikace jsou ze zdroje úložiště informací serveru Exchange a chyby při převodu obsahu. Některé tyto zprávy mohou být ignorovány a nemají vliv na všechny přijaté zprávy. Ale mnoho z těchto zpráv v protokolu aplikace zobrazí, pokud klienti mají problémy při otevírání zprávy ve formátu HTML.

Pokud jde o případ, zavést další diagnostické informace jako verze aktualizací service pack, kopie zpráv problém, kopie aplikace a systémové protokoly a pak řešení.

Q17: Proč někdy zobrazení textu zprávy jako přílohu?

A17: Je nutné vytvořit informace o zdroji zprávy. Všechny podrobnosti o zdrojovém serveru je třeba vytvořit. Musí zkoumat, zda odesílatel je v síti UNIX. Další informace o tomto problému klepněte na následující číslo článku databáze Microsoft Knowledge Base:

323482 Exchange zobrazí zprávu, která obsahuje záhlaví MIME Content-Disposition "vložené" jako přílohu

Otázka č. 18: Proč vidět "Toto je zpráva více částmi ve formátu MIME." nebo "Tato zpráva je ve formátu MIME." v těle e-mailu?

A18: Může se zobrazit jedna z následující v těle textu:
  • "Toto je zpráva více částmi ve formátu MIME."
  • "Tato zpráva je ve formátu MIME. Protože vaše poštovní nerozumí tento formát, některá nebo všechna tato zpráva nemusí být čitelné."

Tento text je vložen před první hranice je obvykle přítomen v každé vícedílné zprávy a není viditelný pro klienta, pokud došlo k potížím s formát e-mailu. Například tvrdého zalomení řádku může byly vloženy ve zprávě na nesprávném místě.

Chcete-li tento problém vyřešit, zapněte zpráva archivace na Microsoft Exchange Internet Mail Service. Zapněte zpráva archivace, použít nástroj Exchange Server 2003 archivu jímky zprávu uložit jako EML nebo PST a poté provést další analýzu. Další informace o funkci jímky archivu, klepněte na následující číslo článku databáze Microsoft Knowledge Base:

307798 nástroj jímky archivu je k dispozici v Service Pack 2

Č. 19: Proč je o 33 % větší než očekávaná velikost pošty a proč je kódování base64 i v případě, že neobsahuje přílohy?



Odpověď 19: K tomuto chování dochází při použití následujících znakových sadách:
  • Japonské Shift-JIS

  • KOR

  • Japonština EUC

  • Korejský ISO-2202-KR
  • Tchaj-wan ISO-2202-TW

  • Čínští ISO-2202-CN

  • GB18030 čínských HZ_GB, Big5,


Otázka č. 20: Jaké jsou další známé a běžné problémy?

A20: Zprávy, které mají být přenášeny do jiného z jednoho serveru Exchange Server 2003 může být zkomolené a příjemci zprávy pravděpodobně zobrazí v těle zprávy.

Například to může dojít ve zprávě, který je směrován z Internetu do počítače s příchozí Internet Exchange Server 2003 a potom do jiného počítače Exchange Server 2003.
Zpráva pravděpodobně nezobrazí správně na příchozí Internet Exchange Server 2003, ale nečitelné na back-end Exchange Server. Tyto příznaky se může změnit, pokud se sníží počet příjemců zprávy. Tento problém se může zobrazit z několika důvodů, ale dva nejběžnější důvody jsou:
  • RFC 2822 záhlaví zpráv, které mají více než 1000 nebo 1024 znaků v řádku namísto 998 znaky v řádku. Další informace naleznete v tématu poznámky RFC (Request for) 2822. Na to naleznete na následujícím webu Internet Engineering Task Force (IETF):Tomuto problému může dojít, pokud mají být přenášeny zprávy do počítače se systémem Exchange Server 2003 pomocí binární data nebo bloků. Bloků je rozšířením formátu protokolu SMTP, který podporuje data odesílaná v blocích.

    Pokud Exchange Server 2003 obdrží zprávu, která obsahuje více než 998 znaky v řádku, služba SMTP analyzuje záhlaví a zjistí, že řádek je delší než 1000 znaků. Služba SMTP pak předpokládá tento řádek není součástí záhlaví a zahrnuje v těle.

    Službu SMTP v počítači Exchange Server bude znovu vytvořit vlastní záhlaví, včetně ID zprávy a záhlaví datum následuje prázdný řádek nebo znak CRLF.
  • Omezení délky řádku. Existuje mnoho implementací, které v souladu s dopravní požadavky RFC 2821 nepřijímá zprávy, které mají více než 1000 znaků na řádek, včetně CRLF. Proto aplikace mail nesmí vytvořit takové zprávy. Chcete-li tento problém vyřešit, vypněte možnost ESMTP sloveso (nebo bloků) v počítači Exchange Server a Exchange Server počítače do formátu formát zprávy v typické SMTP při zpráva je právě přenos vynutit. Další informace získáte klepnutím na následující číslo článku databáze Microsoft Knowledge Base:

    257569 jak vypnout protokol ESMTP slovesa v serveru Exchange 2000 Server a Exchange Server 2003

    821733 příchozí zpráva je poškozen, je-li na řádku přesahuje 1,022 znaků

Odkazy

Další informace o standardu pro formát textových zpráv ARPA Internet naleznete v dokumentu RFC 822. Chcete-li to provést, naleznete na následujícím webu sdružení IETF:Další informace o MIME naleznete v dokumentu RFC 2045, 2046, 2047, 2048 a 2049. Na to naleznete na následujících webech IETF:Další informace o poli záhlaví Content-Disposition naleznete v RFC. 2183. Na to naleznete na následujícím webu sdružení IETF:
Vlastnosti

ID článku: 836555 - Poslední kontrola: 16. 1. 2017 - Revize: 2

Váš názor