パーソナルツール
現在の場所: ホーム ブログ DB2 9 を利用したメール・アーカイブ・システムの開発 (2)
« 2018January »
Su Mo Tu We Th Fr Sa
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      
このBlogについて
 代表の向井田ことMUKAです。当ブログサイトでは、MAGICやDB2に関する技術者向け情報を公開しています。お気軽にお立ち寄り下さい。
最近のエントリ
twitter / 新RT機能を英語モードで・・・ muka 2009年11月19日
twitter / List Widget muka 2009年11月03日
twitter API / Retweet の仕様が・・・ muka 2009年10月30日
twitter API / Lists muka 2009年10月24日
IBM Rational Software Conference 2009 と アジャイル開発 muka 2009年10月08日
twitter API / geoタグ! muka 2009年10月01日
Twitter Developers Meetup in Tokyo muka 2009年09月11日
Club DB2 2009/9/4 muka 2009年09月05日
最近のコメント
Re:Club DB2 2009/8/29 muka 2009年09月01日
Re:Club DB2 2009/8/29 SIM 2009年08月31日
最近のトラックバック
Club DB2 8/29の感想エントリと今後の予定 Unofficial DB2 BLOG 2009年09月01日
カテゴリ
misc (47)
dbMAGIC (47)
DB2 (47)
mail (47)
Web (47)
twitter (47)
 

DB2 9 を利用したメール・アーカイブ・システムの開発 (2)


「RFC822」って?


 前回までは、メールアーカイブの全体像について説明してきましたので、今回から少しずつ細かい話をしていきたいと思います。
 今回は、メールのXML化についてです。

 メールデータを如何にXML化するか?という問題は、一番最初の問題となりました。つまり、どのようにしてメールデータをXMLで表現するかということなのですが、そもそもメールとはどういう構造になっているのかとかどのようにやり取りされるものなにかとかを良く知らないといけません。
 でも、これはKさんの技術協力を頂くことによって、殆ど割と簡単に行うことができました。Kさんは、メールサーバを長年開発していまして、細かいメールの仕様については、当たり前のように熟知している、いわゆる「その道のプロ」の方です。以前から別な仕事でも、XMLでデータ化するようなプログラムを作ってもらっていたりしましたから、割とこちらから指示することもなくXML化するプログラムを作ってしまいました。

 さて、一番最初にその出力されたXMLを見たときに思ったのは、「RFC822って何だ?」でした。
 XML文書には、必ず「文書要素」もしくは「ルート要素」と呼ばれるものがあるのですが、それがまさしく "RFC822" だったんです。
 当時は聞きなれない番号だったのと、「文書要素」ならもう少し一般的な名称・・・例えば、「MailMessageData」とか?・・・になるのかなぁ?なんて思っていましたから、ちょっと意外だったのを記憶しています。

 さて。「RFC822」ですが、もともとはメールのヘッダ等の情報について規定した仕様だったようです。現在はその仕様もいろいろと拡張されているそうです。(「RFC2822」他)
 いずれにしても、当システムで扱うXMLファイルは、メールメッセージデータの本来的な仕様に基づき、それをありのままの形で表現しようとしたものになっています。

 次に、具体的な、スキーマ情報についてみてみましょう。


当システムで扱うメールデータ用のXMLスキーマ



 当システムで利用しているメールメッセージXMLのスキーマ情報について、概略ですが説明していきます。

  • 文書要素「RFC822」配下
     文書要素「RFC822」の子要素としては、エンベロープの情報「Envelope」、ヘッダの情報「Header」、本文の情報「Body」を持つことができる構造となっています。
     この3つの要素が主要なデータとなります。

    ma_011.jpg

  • エンベロープ情報
     エンベロープ情報の子要素には、送信者の情報「MAIL_FROM」と宛先「RCPT_TO」の情報を持てるようにしてあります。
    ma_012.jpg


  • ヘッダ情報
     ヘッダ情報の子要素には、約40種のものが予約されています。RFC822では「From」, 「Subject」,「Date」の3つが必須らしいのですが、過去に「Date」を付けないメールクライアントが流行ったという話もあるそうで、その真相は良く分かりません。
     ということで、ここで紹介するスキーマ上は全てオプショナルにしてあります。


    ma_013.jpg

  • 本文情報
     本文情報の子要素は、ちょっと複雑な構造になります。
     複数個繰返し可能な「Data」要素の下に、再度「Header」や「Body」要素が現れる形です。


    ma_014.jpg

ここで、幾つかの補足をしておきましょう。


エンベロープ情報(/RFC822/Envelope)

 エンベロープというのはもしかしたら馴染みが無いかもしれませんが、メールサーバはメールヘッダの「From」や「To」ではなく、別個の情報を元に 配送します。例えば、SPAMメール等で良くあるのは、ヘッダのFromとは別のアドレスから送信してくるなどの場合です。
 当スキーマでは、それらの情報を含めて記述が可能になっているのがポイントです。

 また、「BCC」の宛先情報については、この 「RCPT_TO」の情報から検索することが可能で す。ヘッダの「To」や「Cc」に存在しない送信先がエンベロープにあれば、それは「BCC」で送信したと判断することが可能です。

 ちなみに、エンベロープを処理しないモードが「Mail2XML」のオプションにあります。
 これはエンベロープの情報を取得するためには、ちょっとした仕掛けが必要になるのですが、それが使用できない場合等、この出力しないオプションを使用することも可能です。
 その場合は、「RFC822/Envelope」を作成しません。


本文情報(/RCC822/Body)

 多少複雑な構造になっていますが、これは、簡単に言えば、マルチパート形式のメール(入れ子構造になっている)をサポートするためです。
 具体的な例を示してみます。

  1. 単純な形式のメール
    いわゆる本文のみがあり、添付ファイルなどの無い場合です。
    このときは、次のようなパターンになります。
    <RFC822>
    <Header>
     <Content-Type>text/plain; charset=iso-2022-jp</Content-Type>
    </Header>
    <Body>
    <Data>
    <Body>本文です。</Body>
    </Data>
    </Body>
    </RFC822>

  2. HTMLメール

     ヘッダ「Content-Type」が「multipart/alternative」のいわゆるマルチパート形式のメールになります。

    <RFC822>
    <Header>
     <Content-Type>multipart/alternative; boundary="..."
    </Content-Type>
    </Header>
    <Body>
    <Data>
    <Header>
    <Content-Type>text/plain;charset="..."</Content-Type>
    </Header>
    <Body>本文です。</Body>
    </Data>
    <Data>
    <Header>
    <Content-Type>text/html;charset="..."</Content-Type>
    </Header>
    <Body>&lt;HTML&gt;&lt;BODY&gt;
    本文です。&lt;/BODY&gt;&lt;/HTML&gt;
    </Body>
    </Data>
    </Body>
    </RFC822>

  3. 添付ファイルのあるメール
     ヘッダ「Content-Type」が「multipart/mixed」の、同じくマルチパート形式のメールになります。
     通常モードでは、添付ファイルのエンコードされた情報は除去されます。
     添付ファイルをテキスト化するオプションを組み込んだ場合は、それぞれの本文情報(/RFC822/Body/Data[n]/Body)に抽出したテキストが挿入されます。
    <RFC822>
    <Header>
     <Content-Type>multipart/mixed; boundary="..."
    </Content-Type>
    </Header>
    <Body>
    <Data>
    <Header>
    <Content-Type>text/plain;charset="..."</Content-Type>
    </Header>
    <Body>ファイルを送信します。</Body>
    </Data>
    <Data>
    <Header>
    <Content-Type>application/octet-stream;name="文書.DOC"
    </Content-Type>
    <Content-Transfer-Encoding>...</Content-Transfer-Encoding>
    </Header>
    </Data>
    </Body>
    </RFC822>

  4. その他
    テキスト本文の複数存在するもの、HTML形式でテキスト本文の無いもの、HTML形式で添付ファイルのあるものなど、組み合わせはいろいろですが、いずれもマルチパート形式のメールとして処理されます。


DB2 9を利用する上での考慮点


 さて、DB2 9へ作成したXMLファイルを格納する際に、設計上考慮しておかなければならない点がいくつかあります。


  • 要素内のテキストの長さ
     ひとつの要素内に格納できるテキストの長さには制限があり、32KByteまでです。
     ところが、メールメッセージの場合は、ちょっと長い文章だと、軽く超えてしまいます。
     しかも悪いことに、DB2 9に格納してしまうと、そのカラム(XML形式)に対する検索が一切できなくなってしまうんです。
     よもやこういう制限は無いと思っていたんですが、やってみて初めて知ることとなりました。(せめて、他のエラー同様、インポート時にはじいてしまってくれたほうがよほど親切なのではないかと...?)

     さて、しょうがないので、これを解決するために、「Body」(/RFC822/Body/Data/Body)は32KByteを超えないように適当な箇所で分けて格納する処理をMail2XMLに入れることで対応しました。
     /RFC822/Body/Data/Body[1]  ・・・  最初の8KByte
     /RFC822/Body/Data/Body[2]  ・・・  次の8KByte
     /RFC822/Body/Data/Body[3]  ・・・  更に次の8KByte
      ...
    皆さんも、長い文章をXMLに格納する場合はご注意下さい。

  • 使用できる文字コード
     これは、XMLで使用可能な文字コードの仕様らしいのですが、時々文字化け等により思わぬコードが混入してしまうことがあります。
     このような場合、たとえWebブラウザ上は何の問題もなく表示できたとしても、DB2にインポートする時点で厳しくはじかれます。(こちらは全く容赦してくれません(^^;)
     プログラム(Mail2XML)で使用できない文字コードをカットするように対処しましたが、最初から文字化けしているメールの場合もあります。また、添付ファイルをテキスト化する時点でそれに失敗することもあります。このあたりは、ある程度割り切りが必要かもしれません。
     参考になりそうなページをリンクしておきます。


XMLサンプルデータ


 せっかくなので、WordとExcelとPDFの3種類の文書を添付したメールのサンプルデータを作ってみました。その元データとXMLに変換した結果を一まとめにしたものをアップロードしておきます。参考にしてみて下さい。

ma_015.jpg



お知らせ


 MSJさんのパッケージ掲載サイトに当製品の紹介ページを掲載して頂きました。
 宜しければアクセスしてみて下さい。


 



DB2 9 を利用したメール・アーカイブ・システムの開発 (1) DB2 9 を利用したメール・アーカイブ・システムの開発 (1)
サイズ 12914 - File type text/html
パッケージソフト.com パッケージソフト.com
サイズ 1 kB - File type text/plain
メールのXML形式変換サンプル メールのXML形式変換サンプル
サイズ 35.0 kB - File type application/x-lzh