Kompira 標準ライブラリ mail_parseについて

コメント

14件のコメント

  • Ichiro Takahashi

    フィックスポイントの高橋です。

    試しに、例示いただいた件名のみをジョブフローで mailto() を用いてエンコードすると以下のようになり、これを mail_parse() すると、マルチバイトのシングルクオーテーション(ユニコードでU+2019)としてパースできるようでした。メールがどのようにエンコードされていたかによって、うまく解析できていない可能性もございますので、お手数ですがメールヘッダの件名部分のソースを張り付けていただけますでしょうか。

    MIME-Version: 1.0
    Content-Type: text/plain; charset="utf-8"
    Content-Transfer-Encoding: 7bit
    Subject: =?utf-8?q?Don=E2=80=99t_leave_your_Windows_Server_2008_R2_workloads_at_ri?=
    =?utf-8?q?sk?=

     

    0
    コメントアクション Permalink

    ご回答ありがとうございます。

    ご依頼頂きました件、下記に件名部分のソースを貼り付け致しました。

    こちらで認識はあっていますでしょうか。

    --------

    Subject: Don’t leave your Windows Server 2008 R2 workloads at risk

    Content-Type: multipart/alternative; boundary="0000000000001dee2f05a45bd986"
    X-TM-AS-MML: disable

     

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    ソースの貼り付けありがとうございます。

    しかし拝見すると、Subject ヘッダにマルチバイトのシングルクオーテーションがそのまま含まれているように見えます。メールのヘッダには US-ASCII 文字しか使えないと決められていますので、マルチバイト文字を含む場合は先の回答のようになんらかのエンコード(何種類かあります)がなされているはずです。

    ご利用になっているメールアプリケーションが件名のデコードされた情報を表示している可能性もございますので、デコードされていない状態のヘッダをご確認いただけますでしょうか。(あるいは、本当にマルチバイト文字をヘッダに含むメールが送信されているならば、その送信元が規約を守っていない形式でメールを送信している可能性も考えられます)

    0
    コメントアクション Permalink

    ちなみにmail_parseした結果、subjectをprintすると下記のような結果となっています。

     

    subject: =?UTF-8?B?RG9u4oCZdA==?=
     leave your Windows Server 2008 R2 workloads at risk

     

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    上記結果から推測するとある種の方式でエンコードされたヘッダがうまく解析できていないのであろうかとは考えられます。

    ちなみに以前、「mail_parse() でパースされたヘッダの文字が欠落していることがある」という問題があり、Kompira v1.5.5.post5 で修正しております。今回の現象が該当するかは分かりませんが、もし v1.5.5.post5 より前の Kompira をご利用いただいている場合は、アップデートしていただくことで解消する可能性もあるかもしれません。

    0
    コメントアクション Permalink

    経緯としてベンダーから送付されるメールをパースし、後続の処理につなげたいと考えており、テストとしてベンダーから送付されたメールをそのまま転送することで評価を行っています。

    この場合、「デコードされていない状態のヘッダ」を確認するには送信済みボックスにあるメールのヘッダーを確認すれば良いでしょうか?

    であれば、「Subject: Don’t leave your Windows Server 2008 R2 workloads at risk」とあるので、上記でいう規約を守っていない形式で送信されている可能性が高いということでしょうか?

    また、上記のように「ある種の方式でエンコード」されたヘッダにおいてv1.5.5.post5以前のkompiraではうまく解析できない場合があり、Kompira v1.5.5.post5以降では解決できる可能性があると認識していますが、該当のメールを送付するこ解消するかご確認頂くことは可能でしょうか?(当方の環境ではv1.5.5.post2となっております。)

     

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    はい、「送信済みボックスにあるメールのヘッダーを確認すれば」はそのとおりなのですが、上にも書いたとおりご利用になっているアプリケーションによっては、ヘッダを生のまま表示しているのではなく、人が読みやすいようにデコードしたヘッダを表示している可能性はあります。アプリケーションの仕様をご確認いただくか、メールを生のまま保存(エクスポート)するような機能があれば、テキストエディタで確認するといった手段はあるかもしれません。

    あるいは、当該メールを加工せずに送付いただければ、こちらでパースできるかの確認は可能です。

    0
    コメントアクション Permalink

    当該メールを送付させて頂く許可が出ましたので、送付させて頂き確認頂きたいのですが、どのように送付すれば良いでしょうか?

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    では、お手数ですが、私宛(下記メールアドレス)までメールでご送付いただけますでしょうか。

    takahashi@fixpoint.co.jp

     

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    対象メールのご送付ありがとうございます。

    別便にて受け取ったメールを確認したところ、Subject ヘッダは適切にエンコードされているように見受けられました。

    次に、下記のようなジョブフローにメッセージ全体を文字列として mesg パラメータに渡して、パースできるかを確認してみました。

    |mesg|
    [
    parsed = mail_parse(mesg)] ->
    print(parsed['Subject'])

    手元ですぐに確認できた最新の v1.5.5.post8 および古い v1.4.10.post5 のいずれにおいても、コンソールに以下のように期待する件名が表示できていました。

    Don’t leave your Windows Server 2008 R2 workloads at risk

    メールチャネルで実際にメールを受信したわけではありませんが、mail_parse() としては想定通りに動作しているように考えられます。

    どのようなジョブフローでメールのパース処理と「期待される件名を取得できない」を判断されましたでしょうか?実際のジョブフローや結果をご提示いただくと、なにか分かるかもしれません。

    0
    コメントアクション Permalink

    こちらでも少し確認しましたが、ベンダーから受信したメールのヘッダーと、それを転送したメールのヘッダーが異なっているようです。

    ・ベンダーからの受信したメールヘッダ

    Subject: =?UTF-8?Q?Don=E2=80=99t_leave_your_Windows_Server_2008_R2_workloads_?=
    =?UTF-8?Q?at_risk?=

    ・受信したメールを個人端末のメーラー(Becky)で取り込み、転送した際のメールヘッダ

    Subject: =?UTF-8?B?RG9u4oCZdA==?=
    leave your Windows Server 2008 R2 workloads at risk

     

    上記から、受信したメールを転送する際にメーラー側(Becky)で特殊なエンコードを行っているため、本事象が発生しているということでしょうか。

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    ご確認ありがとうございます。

    ベンダーから受信したメールヘッダであれば問題なくパースできますが、転送されたメールのヘッダの場合は古い Kompira ではパースできずに下記のようになりました(先に張り付けていただいた結果と同じですね)。

    =?UTF-8?B?RG9u4oCZdA==?=
     leave your Windows Server 2008 R2 workloads at risk

    このことから、転送されたさいにメールヘッダのエンコードが変更されていて、その形式に古い Kompira では対応できていないことが考えられます。

    しかし、最新の v1.5.5.post8 でも以下のようになり、Don’t と leave の間の空白が失われているようです(上に張り付けられた転送時メールヘッダの2行目の行頭に空白を入れてパースしてみました)。これはやはり転送時のメールヘッダの書き換えが影響している可能性はあるかと思います。

    Don’tleave your Windows Server 2008 R2 workloads at risk

     

    0
    コメントアクション Permalink

    ご回答ありがとうございます。

    もう少し質問ですが、本件のような検証を行いたい場合、何か良い方法はございませんでしょうか?

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    まず汎用的なメールの取り扱いは一般的には難しい処理に分類されます。歴史的経緯により様々な仕様の変遷があったり、規約に従っていない実装が存在したりします。また日本語を含む非英語圏の文字の取り扱いも複雑になります。検証として「これさえしておけば万全」といった方式は存在しないので、ここでは私が気を付けているようなことをご紹介したいと思います。

    • 実際に取り扱う予定のメールを可能な限り多種・多数サンプリングして、それをテストデータとしてパース処理の結果が想定通りか確認する。
    • 想定通りにパースできないものがあった場合、他のメールアプリケーションでは想定通りに表示されるか確認する。
    • 他のアプリで表示されるが mail_parse() ではうまくパースできない場合、メールヘッダの形式が RFC に準拠しているか確認する。
    • 小さい python スクリプトを作成して当該ヘッダがパースできるか確認して、mail_parse() の問題か切り分ける。

    メール処理系のなかには仕様に厳密に準拠していなかったり、古い仕様にしか対応していないものなどもあります。また、(対応している)仕様に厳密な実装をしていて、すこし仕様から逸脱した箇所をエラー扱いする場合もありあす。Kompira の実装言語である python のメール処理系は比較的厳密に処理すると言われています。

    メールヘッダの形式が規約に則っているかといった仕様を厳密に確認するには、RFC というインターネットプロトコルなどに関する仕様などを記述した文書を確認します(たとえば RFC2822 (https://tools.ietf.org/html/rfc2822) など)。

    今回の事例で言えば、mail_parse() が対応できないヘッダ形式(仕様に厳密には準拠していない可能性はある)が存在する、メールアプリでメールを転送するときにヘッダ形式が変わってしまう場合がある、といったことが関連していると思います。元メールの件名は想定通りにパースできていたため、メールを転送する箇所に問題があると考えるならば、転送を別の方式にすることなどもご検討いただくとよいかもしれません。

    参考になさってみてください。

    0
    コメントアクション Permalink

サインインしてコメントを残してください。