MIME コンテンツ変換では Exchange 2000 Server および Exchange Server 2003年についてよく寄せられる質問

文書翻訳 文書翻訳
文書番号: 836555 - 対象製品
すべて展開する | すべて折りたたむ

概要

MIME 標準と別のメール システムが連携して動作することをエンコードの方法についてよく寄せられる質問への回答を掲載しています。ここでは、画像がゆがむか、読み取れないメール メッセージは、Microsoft Exchange 環境でのトラブルシューティング方法について簡単に説明します。

詳細

Q1: 電子メール メッセージの形式を教えてください。

A1:インターネット電子メール メッセージは RFC 2822 で定義されている標準の表示形式に従います。メッセージ ヘッダー フィールドと本文で構成されます。ヘッダー フィールドは、まとめて、」"メッセージのヘッダーの名前です。メッセージの本文を省略できます。ボディのないそれには、ヘッダーが、メッセージを送信できます。

ヘッダーは RFC 2822 形式の標準で定義されている一連の特殊な構文を持つ文字の行を格納します。本体には、ヘッダーを実行し、ヘッダーから (キャリッジ リターンする前に関係のない線) とライン フィードの [CRLF] は空行で区切られている文字列が含まれます。

ヘッダー フィールドのコロン (:、フィールド本体がされ CRLF によって終了しました。 その後、フィールド名で構成される線です。フィールド名、コロンを除いて印刷可能 US-ASCII 文字 (33 〜 126 の範囲内の値が、文字) の構成する必要があります。コロンを区切り文字として使用します。

フィールド本体は、CRLF を除いて、US-ASCII 文字の構成されます。ただし、フィールド本体は、ヘッダー圧縮破断で使用する場合は、CRLF を含めることができます。折り畳み、利便性のための単一行複数行にわたって表示されます。開くはこれの逆です。フィールドのすべてのボディ 3 と 4 の標準 RFC 2822 形式のセクションに記載されている構文に従う必要があります。

メッセージの本文は、1 つまたは複数のセクションが含まれます。本文の各セクションは、境界線で区切られています。Boundary パラメーターは、2 つのハイフン (-) で始まる文字列です。

Q2: MIME について教えてください。

A2:MIME は、さまざまな種類のコンテンツに 1 つのメッセージに使用できる、標準です。簡易メール転送プロトコル (SMTP) の形式のテキストとテキスト以外の両方の複数のコンテンツを含めるには、電子メール メッセージの MIME を拡張します。メッセージ部分のイメージ、オーディオ、またはテキストを別の文字に設定。標準の MIME から Rfc 2821、2822年などを派生します。

Q3: Exchange は MIME をどのように処理しますか。

A3:コンテンツ変換を実行する 3 つの主要なコンポーネントで Exchange です。
  • IMAIL コンポーネントは、インターネット メッセージを MAPI に変換のコア コンポーネントである/フォーマット、または交換します。また、メッセージの整合性をチェックします。
  • EXMIME コンポーネントはメッセージを Exchange の内部オブジェクトの形式で変換と MIME 形式のメッセージを生成するためです。
  • RFHTML はリッチ テキスト形式 (RTF) のメッセージに HTML やその逆、Outlook クライアント上の設定と、コンピューターの設定を Exchange Server に変換します。

Q4: MIME 形式の電子メール メッセージの最小要件を教えてください。

A4:MIME 形式の電子メール メッセージは通常、ヘッダーと本文があります。最低限、MIME メッセージは、ヘッダーが必要です。本体は省略可能です。ヘッダー セクションには、MIME バージョン 1.0 ヘッダー (RFC 2822 で定義されているメッセージごとに 1 つ) が含まれます。

本文セクションは次のとおりです。
  • コンテンツの種類 (これは省略可能です。既定のテキスト/形式は RFC 2822 5.2 で定義されているようです。
  • コンテンツ転送エンコードのヘッダーを (これは省略可能です。既定の RFC 2822 6.1 で定義されている 7 ビットです。
  • コンテンツ ディス ポジション ヘッダーを (これは省略可能です)
  • コンテンツ ID と (これは省略可能です)


Q5: MIME バージョン ヘッダーについて教えてください。

A5:MIME バージョン ヘッダー フィールドは MIME 形式のメッセージを示します。MIME をサポートしていない以前のソフトウェアから送信されるメッセージには、このフィールドはありません。メール クライアントがない場合はこのフィールドを使用して、MIME 以外のメッセージを区別するために。

Q6: コンテンツ タイプ ヘッダーを教えてください。

A6:コンテンツ タイプのフィールドの種類および形式のデータ内のフィールドを指定する使用されます。

ヘッダー タイプのマルチパート/混合、マルチパート/代替、号、テキスト、html、applefile アプリケーションと、アプリケーションと ms で tnef、アプリケーションまたはオクテット-ストリームがあります。

Q7: コンテンツ転送エンコードを何ですか。

A7:別のメール システムのデータを扱い、一部以前のメール システムはマルチ メディア データを処理できません。

マルチ メディア データを処理することはできません周りのシステムを使用するには、統一された 7 ビット形式にデータを変換するには、エンコード方式が使用されます。受信者がメッセージを受信すると、データを元の形式に復元されます。コンテンツ転送エンコード形式の例をいくつかは次のとおりです。
  • 引用符で囲まれた印刷可能です
  • Base 64
  • 8 ビット
  • 7 ビット
  • バイナリ


Q8: 転送エンコードで Exchange 5.5 実装方法はでしょうか。

A8:Exchange 5.5 は、引用符で囲まれた印刷可能な形式で、または必要に応じて 7 ビット形式でエンコードします。さらに、メッセージの 25% が 8 ビット文字 (US-ASCII 文字の範囲外にある文字) の構成されている場合 Exchange 5.5 base64 形式にエンコードします。これは、メッセージの本文のみに適用されます。base64 でエンコードされた添付ファイルは、常にです。

Q9: 転送エンコード Exchange 2000 Server で実装する方法ですか。

A9:ルーティング グループの境界および SMTP ターゲット先 Exchange 2000 サーバーがメールをエンコードする方法を決定します。Exchange 2000 は、引用符で囲まれた印刷用または 7 ビットのエンコードまたはトランスポート ニュートラル カプセル化形式 (2 サーバーと受信者間で別のルーティング グループとインターネットに送信する場合 TNEF)。

Exchange 2000 Server バイナリまたは TNEF の概要で、宛先サーバーは同じルーティング グループ内に送信する場合でエンコードされます。

Q10: 転送エンコード Microsoft Exchange Server 2003 の実装方法はでしょうか。

A10:ルーティング グループ境界の場合は、Exchange と SMTP のターゲット先も Exchange Server 2003年がメールをエンコードする方法を決定します。

混在モードでは、Exchange Server 2003年を引用符で囲まれた印刷用または 7 ビット エンコード (TNEF 形式) 2 サーバーと受信者間で別のルーティング グループとインターネットに送信するとします。

ネイティブ モードでは、Exchange Server 2003年バイナリ (TNEF の概要) を送信すると、宛先サーバーの同じボタンまたは別のルーティング グループ内にエンコードします。

Q11: コンテンツ ディス ポジション ヘッダーを教えてください。

A11:このヘッダー セクションが添付ファイルとして表示されますまたはメッセージの本文に表示されるかどうかを指定します。

Q12: 方法は添付ファイル交換のハンドル。

A12:Exchange Server 2003年のインターネット メッセージがネイティブ形式で保存します。これは、Outlook Express のようなインターネット形式対応クライアントから、メッセージが読み取られる場合は、その元の形式で描画されることを意味します。

ただし、IMAIL は、MAPI クライアントからメッセージが読み取られるときに、MAPI プロパティを [インターネット メール形式の適切な要素がマップされます。実際もインターネット メッセージがメールボックスに配信する前に、最低限の一連の MAPI プロパティからインターネット メッセージを昇格する必要があります。PR_SENT_REPRESENTING、PR_SUBJECT、受信者テーブルなどです。

その他の MAPI プロパティ PR_BODY、PR_HTML、および再試行できますインターネット形式を必要に応じて計算されます。変換は、MAPI クライアントがメッセージを最初に要求したときに発生します。Exchange 2000 Server には、そのネイティブの MIME プロパティ MAPI 形式に昇格させます。

コンテンツの変換中に Exchange Server は、受信 MIME メッセージをクライアントにレンダリングするとき 2003年では、IMAIL は次を行います。
  1. IMAIL は、完全なファイル名 (のチェックします。名前.ext) が MIME ヘッダーにします。名前が見つかった場合は、ファイル名が使用されます。
  2. IMAIL は、部分的なファイル名をチェックします。いずれかが見つかった場合は、IMAIL が表示されます、
    HKEY_CLASSES_ROOT と MIME/データベース/コンテンツの種類
    ファイル名の拡張子をコンテンツ タイプに対応するサブキーします。一致するコンテンツ タイプが見つからない場合は、添付ファイルをその拡張子が追加されます。一致するコンテンツ タイプが見つからない場合は、部分的なファイル名が使用されます。
  3. コンテンツ タイプまたはコンテンツの廃棄ヘッダーでファイル名が指定されていない場合は、IMAIL に一致するコンテンツ タイプを検索します。添付ファイルが検出された場合は、ATT の形式があります。名前.extは、 ext このコンテンツ タイプに関連付けられている拡張機能です。一致するコンテンツ タイプが見つからない場合は、".att"の拡張子が使用されます。Exchange 2000 Server では、コンテンツ タイプ ヘッダーでファイル名が必要です。


Q13: メッセージの構造について教えてください。

A13:完全なメッセージに表示されるすべてのヘッダーの例を次に示します。受信者は、本体部分のみが表示されます。括弧内のコメントが追加されました。

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: 理由メール アドレスはメッセージの本文に表示されます。

A14:最初"CRLF CRLF"MIME ストリームをメッセージ本文の先頭を示します。したがって、一連の<CRLF><CRLF>の間の 2 つのヘッダーがある場合は、クライアント (Microsoft Outlook または Microsoft Outlook Express) が意味を成さないメッセージが表示されます。

最初"CRLF CRLF"メッセージのインターネット ヘッダーをメッセージ本文から分離します。これらのヘッダーは、P1 ヘッダーとして知られています。P1 ヘッダーはエンベロープのヘッダーし、IMAIL によって処理されるインターネット メッセージの一部ではないです。

Exchange は、スマート ホスト、コンテンツ スキャン デバイス、ウイルス ウォール、またはファイアウォールに転送可能性があります。サード パーティ製のファイアウォール ソフトウェアは、メッセージがゆがむ場合があります。

また UNIX システムをファイアウォール、またはウイルス ウォールを電子メールのメッセージを受け取ることがあります。また、サード パーティ コンテンツ スキャン デバイスがネットワーク上があります。ネットワーク上のようなアプリケーションまたはデバイスがある場合は、受信者の制限を確認します。診断テストではそのようなデバイスやアプリケーションを使用しないでください。

Q15: 疑問符 (?) メッセージ内で表示されるにはか。

A15:疑問符 (?) でメッセージが表示される場合は、システム メッセージにはいくつかの ANSI または Unicode 文字を変換する方法を知らないことを意味します。メッセージが表示されます、クライアントが受信文字セットに一致するコード ページをインストールする必要があります。たとえば、Windows ワークステーション日本語のロケールを日本語で書かれたメッセージを表示するには、インストールされていることを確認します。

Q16: なぜ html 形式のメッセージを開けないことが、[アプリケーション ログにイベント 12002 および 12003 参照してください。

A16:アプリケーション ログ イベント、元 Exchange インフォメーション ストア、およびコンテンツの変換エラーです。これらのメッセージを無視することができ、受信したメッセージに影響がないです。しかし、クライアントに html 形式のメッセージを開くときに問題があるかどうかは、アプリケーション ログでこれらのメッセージの多くを参照してくださいする場合を参照してください。

このような場合は、service pack のバージョン、問題のあるメッセージ、アプリケーションおよびシステムのログのコピーのコピーのような診断情報を確立して、トラブルシューティングを行います。

Q17: なぜがメッセージ本文を添付ファイルとして表示。

A17:メッセージのソースについての情報を設定する必要があります。転送元サーバーのすべての詳細を確立する必要があります。送信者が UNIX ネットワーク上にあるかどうかを調べる必要があります。 </CRLF></CRLF>この問題の詳細については、マイクロソフト サポート技術資料を参照するのには、以下の「base をクリックします。
323482 Exchange は添付ファイルとして「インライン」MIME の Content-disposition ヘッダーを使用してメッセージが表示されます。
Q18: なぜ"これは、マルチパート メッセージの MIME 形式。"または」このメッセージ MIME 形式の電子メールの本文にです"表示しますか。

A18:テキストの本文で次のいずれかの参照してください可能性があります。
  • "これは、MIME 形式のマルチパート メッセージです。
  • 「このメッセージを MIME 形式でです。メールの読者がこの形式を認識できないため、このメッセージの一部またはすべて判読できません。"

このテキストは、最初の境界の前に挿入されます、すべてマルチパート メッセージでは、通常は存在し、電子メールの形式に問題がない限りがクライアントに表示されません。たとえば、ハード改行でメッセージが正しい位置に挿入された可能性があります。

この問題を解決するには、メッセージが Microsoft Exchange のインターネット メール サービスでアーカイブにします。メッセージのアーカイブを有効にするには、Exchange Server 2003年の Archive Sink ユーティリティを使用して、メッセージを .eml または .pst を保存し、さらに分析を行います。 アーカイブ シンク機能の詳細については、マイクロソフト サポート技術資料を参照するのには、以下の「base をクリックします。
307798Service Pack 2 で Archive Sink ユーティリティが利用します。
Q19: 33% 期待よりも、大きいメールのサイズであるし、しても、添付ファイルがない場合理由、base64 でエンコードされてでしょうか。

A19:次の文字セットを使用する場合この現象が発生します。
  • 日本語シフト JIS
  • (韓国語)
  • 日本語 EUC
  • 韓国語の ISO-2202年-KR
  • 台湾 TW の ISO-2202
  • 体字中国語の ISO-2202年-CN
  • 体字中国語の Big5、HZ_GB、GB18030


Q20: 他の一般的なと既知の問題について教えてください。

A20:けして、可能性があります Exchange Server 2003年サーバー間が中継されるメッセージと、メッセージの本文に、メッセージの受信者を表示可能性があります。

たとえば、インターネットから受信のインターネット Exchange Server 2003年コンピューター、および Exchange Server 2003年の別のコンピューターにルーティングされているメッセージにあります。
メッセージは受信インターネット Exchange Server 2003 年が正しく表示ことがありますが、バックエンドで Exchange Server が文字化けします。これらの現象は、メッセージの受信者数を制限する場合にも変わります。2 つの最も一般的な理由がいくつかの理由については、この問題が表示されます。
  • 以上の 1000年または 1024年文字は行長 998 文字ではなく、行にある RFC 2822 メッセージ ヘッダー。詳細については、要求のコメント (RFC) 2822年を参照してください。このためには、次のインターネット技術標準化委員会 (IETF) Web サイトを参照してください。
    http://www.ietf.org/rfc/rfc2822.txt?number=2822
    Exchange Server 2003年コンピューターには、バイナリ データを使用してまたはをチャンクに分割することによってメッセージを中継するは場合は、この問題が発生する可能性があります。チャンクは、チャンク単位で送信されるデータをサポートする SMTP 形式の拡張機能です。

    Exchange Server 2003年が 998 個を超える文字の行を持つメッセージを受信すると、SMTP サービスは、ヘッダーを解析し、行が 1000年文字を超えるであることを検出します。SMTP サービスに、この行のヘッダーの一部ではないとに本文が含まれていますと仮定します。

    Exchange Server のコンピューター上の SMTP サービスは、独自のヘッダーを再書き込みします。 メッセージ ID および日付ヘッダーを含む後に空白行または CRLF によって。
  • 行の長さの制限。RFC 2821 のトランスポート要件に従って 1,000年文字は CRLF を含む、1 行を持つメッセージに同意しない多くの実装です。したがって、メール アプリケーションこのようなメッセージを作成する必要があります。この問題を回避するには、Exchange Server が ESMTP 動詞 (チャンキング) 機能を無効にして Exchange Server のコンピューター形式のメッセージを中継するときの標準的な SMTP メッセージの書式を設定します。 詳細については、以下の記事番号 をクリックしてマイクロソフト サポート技術情報資料を参照してください。
    257569Exchange Server 2003年で Exchange 2000 Server で、ESMTP コマンドを無効にする方法
    821733 1,022 文字行を超えた場合に受信メッセージがゆがんでいます。

関連情報

ARPA インターネット テキスト メッセージの標準の形式の詳細については、RFC 822 を参照してください。これを行うには、次の IETF の Web サイトを参照してください。
http://www.ietf.org/rfc/rfc0822.txt?number=822
MIME の詳細については、RFC 2045、2046年、2047年、2048、および 2049年を参照してください。これには、次の IETF の Web サイトを参照してください。
http://www.ietf.org/rfc/rfc2045.txt?number=2045
http://www.ietf.org/rfc/rfc2046.txt?number=2046
http://www.ietf.org/rfc/rfc2047.txt?number=2047
http://www.ietf.org/rfc/rfc2048.txt?number=2048
http://www.ietf.org/rfc/rfc2049.txt?number=2049
コンテンツの廃棄ヘッダー フィールドの詳細については、RFC 2183 を参照してください。これには、次の IETF の Web サイトを参照してください。
http://www.ietf.org/rfc/rfc2183.txt?number=2183

プロパティ

文書番号: 836555 - 最終更新日: 2012年10月15日 - リビジョン: 7.0
この資料は以下の製品について記述したものです。
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
キーワード:?
kbfaq kbinfo kbmt KB836555 KbMtja
機械翻訳の免責
重要: このサポート技術情報 (以下「KB」) は、翻訳者による翻訳の代わりに、マイクロソフト機械翻訳システムによって翻訳されたものです。マイクロソフトは、お客様に、マイクロソフトが提供している全ての KB を日本語でご利用いただけるように、翻訳者による翻訳 KB に加え機械翻訳 KB も提供しています。しかしながら、機械翻訳の品質は翻訳者による翻訳ほど十分ではありません。誤訳や、文法、言葉使い、その他、たとえば日本語を母国語としない方が日本語を話すときに間違えるようなミスを含んでいる可能性があります。マイクロソフトは、機械翻訳の品質、及び KB の内容の誤訳やお客様が KB を利用されたことによって生じた直接または間接的な問題や損害については、いかなる責任も負わないものとします。マイクロソフトは、機械翻訳システムの改善を継続的に行っています。
英語版 KB:836555
Microsoft Knowledge Base の免責: Microsoft Knowledge Baseに含まれている情報は、いかなる保証もない現状ベースで提供されるものです。Microsoft Corporation及びその関連会社は、市場性および特定の目的への適合性を含めて、明示的にも黙示的にも、一切の保証をいたしません。さらに、Microsoft Corporation及びその関連会社は、本文書に含まれている情報の使用及び使用結果につき、正確性、真実性等、いかなる表明・保証も行ないません。Microsoft Corporation、その関連会社及びこれらの権限ある代理人による口頭または書面による一切の情報提供またはアドバイスは、保証を意味するものではなく、かつ上記免責条項の範囲を狭めるものではありません。Microsoft Corporation、その関連会社 及びこれらの者の供給者は、直接的、間接的、偶発的、結果的損害、逸失利益、懲罰的損害、または特別損害を含む全ての損害に対して、状況のいかんを問わず一切責任を負いません。(Microsoft Corporation、その関連会社 またはこれらの者の供給者がかかる損害の発生可能性を了知している場合を含みます。) 結果的損害または偶発的損害に対する責任の免除または制限を認めていない地域においては、上記制限が適用されない場合があります。なお、本文書においては、文書の体裁上の都合により製品名の表記において商標登録表示、その他の商標表示を省略している場合がありますので、予めご了解ください。

フィードバック

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com