エンコードされたヘッダーフィールドにつNo.16479
yorupica さん 04/01/31 12:47
 
yorupicaです。

大変便利に鶴亀メールを使わせていただいております。


最近、仕事の関係で海外の方とメールをやり取りすることが多くなり、
彼らからのメールに返信した際にサーバーからエラーが返ってくる
ことが頻繁に起こるようになりました。

受信ログを調べてみると、送り元がFrom/To/Ccに書いてくるe-mail
アドレスに特徴がありました。

たとえばFromフィールドが次のようなエンコードされており、
これに返信すると、返信先のメールアドレスがおかしな具合に
分解されてしまいます。

From: =?utf-8?B?VGhvDWFuZWaQIPOpY29sYXM=?= <xxx@xxxxxxxxxx>
(<>内のE-Mail addressは都合により伏せさせていただきます)


問題は前半のエンコードされた部分で、デコードすると次のように
カンマが入っています。鶴亀メールでのヘッダー表示もこれと
同じになります。

Doe, John <xxx@xxxxxxxxxx>


このようなメールに返信すると、鶴亀さんはカンマの部分までを
e-mailアドレスと判断するらしく、返信メールのアドレスが
次のように分解されてしまいます。

Doe@yyyyyy, John <xxx@xxxxxxxxxx>


yyyyyyの部分はどうやら私のアカウントがあるメールサーバーの
ホスト名が勝手にくっつくようです。


ヘッダーフィールドをデコードした結果なので、なんともしがたい
のかもしれませんが、できればこのカンマが入ったアドレスの場合、
""で自動的にクオートするか、エンコードする設定はありませんで
しょうか?


以上、よろしくお願いいたします。

[ ]
RE:16479 エンコードされたヘッダーフィーNo.16481
Iranoan さん 04/01/31 17:07
 
 yorupica さん今日は、Iranoan です。
 念の為お断りしておくと、開発者とは何の関わりも無い単なる一ユーザです。
> Doe, John <xxx@xxxxxxxxxx>
>
>
> このようなメールに返信すると、鶴亀さんはカンマの部分までを
> e-mailアドレスと判断するらしく、返信メールのアドレスが
> 次のように分解されてしまいます。
>
> Doe@yyyyyy, John <xxx@xxxxxxxxxx>
 この様な加工をしなくても、送信時に再びエンコードをしない限り、ドメイ
ンが無ければ、送り元と同じドメインとして処理するメール・サーバでは、結
局同じことになります。本来名前の部分に「,」を含めたければ、ASCII のみ
なので「"」でくくり、
"Doe, John" <xxx@xxxxxxxxxx>
と書くべきでしょうね。ただこれは相手のあることなので...。

 そこで返信元の From ヘッダ若しくは存在すれば Reply ヘッダが複数のア
ドレスと判断できるような形式で、宛先にそれが含まれるときに限って、例外
処理をすると良いと思います。この辺りの判断は、秀まるおさんにお願いする
として、末尾のマクロを「マクロ」→「マクロ登録」→「自動起動」の「送信
用エディタ起動時」に登録しておくと、取り敢えず回避できると思います。
//----------------- remakeTo.mac ----------------------------------
loaddll "tkinfo.dll";
$from = dllfuncstr( "RootHeader", "Reply-To" );
if( $from == "" )$from = dllfuncstr( "RootHeader", "From" );
if( dllfunc( "CountEmailList", $from ) > 1 ){
  #i = strstr( $from, " <" );
  if( #i == -1 )#i = strstr( $from, "<" );
  if( #i != -1 ){
    #x = x;
    #y = y;
    $to = "\"" + leftstr( $from, #i ) + "\"" +
      rightstr( $from, strlen( $from ) - #i );
    $s = searchbuffer;
    #s = searchoption;
    call ResetHeader "^To:", $from, $to;
    call ResetHeader "^Cc:", $from, $to;
    call ResetHeader "^Bcc:", $from, $to;
    moveto #x, #y;
    setsearch $s, #s;
  }
}
freedll;
endmacro;

ResetHeader:
  moveto 0, -9999;
  searchdown2 $$1, regular, nocasesense;
  if( result ){
    selectline;
    replaceallfast $$2, $$3, inselect;
    escapeinselect;
  }
  return;

[ ]
RE:16479 エンコードされたヘッダーフィーNo.16491
秀まるお2 さん 04/02/02 16:45
 
 Iranoanさんからマクロも提示されたようですが、ここはやはり鶴亀メール側
で適当に対処しないと面倒この上ないと思います。しかし、BASE64デコードした
中にコンマがある場合は全体を""で囲むというような単純な処理では済まないと
思います。

 いざ対応するとなると、もしかしてレベルダウンのバグが発生するかもしれな
くて少々怖いので、もうちょっと時間のある時に対応する予定ってことで、しば
らくお待ちください。

[ ]
RE:16491 エンコードされたヘッダーフィーNo.16500
秀まるお2 さん 04/02/02 23:05
 
 ちなみにですが、

    From: =?utf-8?B?VGhvDWFuZWaQIPOpY29sYXM=?= <xxx@xxxxxxxxxx>

 これをデコードしても、こちらでは

    Doe, John <xxx@xxxxxxxxxx>

 のような内容は出てきません。それで仕方なく、

    From: =?iso-2022-jp?Q?ABC=2CABC?= <xxx@xxxxxxxxxx>

 のようなテストデータを作って試してみました。念のため書くと、Outlook
Expressでも鶴亀メールと同じく、「ABC」と「ABC <xxx@...>」の2つのメール
アドレスがあるように解釈されます。

 ではありますが、適当に対応したいと思いつつも、やはりこの辺の扱いは非常
に難しくて、レベルダウンの可能性がかなりあります。ということで、

 − From:ヘッダについてのみ。
 − エンコードされた内容中にコンマを含まない。
 − デコードされた内容中にコンマがある。
 − デコードされた内容中のコンマの後ろに"<"の文字がある。
 − デコードされた内容中にダブルクォーテーション記号を含まない。

 という条件の場合に限り、コンマを含む部分をダブルクォーテーションで囲む
ことにします。

 次のV3.20βにてそうします。

[ ]
RE:16481 エンコードされたヘッダーフィーNo.16519
yorupica さん 04/02/03 19:10
 
Iranoanさん、

コメントとマクロありがとうございます!

風邪で伏せってしまい、レスポンスが遅くなりました・・・

別途秀まるおさんから、ありがたいコメントをいただいておりますが、
3.20β?までの間、ご提示いただいたマクロをつかわせていただこう
と思います。


[ ]
RE:16500 エンコードされたヘッダーフィーNo.16520
yorupica さん 04/02/03 19:16
 
秀まるお2さん

コメントありがとうございます。

> ちなみにですが、
>
>    From: =?utf-8?B?VGhvDWFuZWaQIPOpY29sYXM=?= <xxx@xxxxxxxxxx>
>
> これをデコードしても、こちらでは
>
>    Doe, John <xxx@xxxxxxxxxx>
>
> のような内容は出てきません。それで仕方なく、
※すみません、言葉足らずでした・・・コピー&ペーストにちょうどよいのがなく、
手打ちで例示させていただいたものです。余計なお手数をおかけしてしまいました。
申し訳ありません。

> 次のV3.20βにてそうします。
恐れ入ります。公開されましたら使用レポートさせていただきます。
よろしくお願いいたします。


[ ]
RE:16520 エンコードされたヘッダーフィーNo.17002
yorupica さん 04/03/10 18:40
 
ハードディスクがクラッシュしたりして、すっかりご報告が
遅れてしまいました。

3.20β(現在は3.20β5を使用中)で問題のアドレスを持つ方とメールのやり取りをし
ていますが、見事にクオートされており、おかげ様でスムーズにメールのやり取りが
できています。ありがとうございます!

※ひとつよくなると欲が出るもので、いずれはCCも対応していただければなぁ・・と
思っております。

[ ]
RE:17002 エンコードされたヘッダーフィーNo.17003
yorupica さん 04/03/10 18:48
 
すみません。使用しているβバージョンを間違えました。
3.20β5ではなく3.50β5の間違いです。

[ ]
RE:17002 エンコードされたヘッダーフィーNo.17042
秀まるお2 さん 04/03/12 15:41
 
> ※ひとつよくなると欲が出るもので、いずれはCCも対応していただければなぁ・・と
> 思っております。

 From:部分の場合だと、メールアドレスが1つしか入ってないという前提で処
理できるんですが、To: Cc: の場合はエンコードされた中以外に元々コンマがあ
る可能性があって、処理が難しいです。

 ということで現状程度の対応で勘弁してください。

 あんまり困るなら、やはり送り主に言って直してもらうべきだと思います。

 (他にメールを受けてる人もみんな困ってるはずだし)

[ ]
RE:17042 エンコードされたヘッダーフィーNo.17045
Mattz さん 04/03/12 16:18
 
Mattzです。

> From:部分の場合だと、メールアドレスが1つしか入ってないという前提で処
>理できるんですが、To: Cc: の場合はエンコードされた中以外に元々コンマがあ

rfc822 とか読む限りでは、「Fromフィールドにカンマ区切りで複数アドレス」は
許されてたりしますので、その前提はよろしくないかもしれません。
(日本語訳:http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc822j.html )

※原文にあたったわけではないので曖昧に言ってみたり。

[ ]
RE:17045 エンコードされたヘッダーフィーNo.17048
EMiCC さん 04/03/12 17:42
 
1ユーザーのEMiCCです。

>rfc822 とか読む限りでは、「Fromフィールドにカンマ区切りで複数アドレス」は
>許されてたりしますので、その前提はよろしくないかもしれません。
>(日本語訳:http://www.asahi-net.or.jp/~bd9y-ktu/dtd_f/rfc_f/rfc822j.html )

読んでみてもよく判りませんでした (^_^; が、たとえ仕様で許されていたとしても、
「"複数"アドレスからの"1通の"メール」なんていう状況は運用上想定できないんで、
そこまで厳密に準拠しなくてもいいんじゃないかと思います。

[ ]
RE:17048 エンコードされたヘッダーフィーNo.17049
tnobu2 さん 04/03/12 17:58
 
>読んでみてもよく判りませんでした (^_^; が、たとえ仕様で許されていたとしても、
>「"複数"アドレスからの"1通の"メール」なんていう状況は運用上想定できないんで、
>そこまで厳密に準拠しなくてもいいんじゃないかと思います。

こちらの文章の方がもうちょっとわかりやすいかも
http://www.puni.net/~mimori/rfc/rfc2822.txt

要約すると、規約上はFrom:にはメールの差出人という意味ではなく、その
内容に責任を持つ人々等を列挙するフィールドということのようです。
一般的には差出人という解釈になっていると思うので、複数アドレスの存在
を考えなくても問題ないとは思いますが。

[ ]
RE:17048 エンコードされたヘッダーフィーNo.17051
秀まるお2 さん 04/03/12 18:05
 
 今回の話はあくまでyorupicaさんの受けている特殊なメールについての話です。
From:ヘッダにコンマを含むメール全般についての話とは関係ありません。

[ ]
RE:17051 エンコードされたヘッダーフィーNo.17053
EMiCC さん 04/03/12 19:17
 
> 今回の話はあくまでyorupicaさんの受けている特殊なメールについての話です。
>From:ヘッダにコンマを含むメール全般についての話とは関係ありません。

そうでした。
話を混同してしまってすみません。

#でも tnobu2 さんのコメントは勉強になりました。
#ありがとうございました。>tnobu2 さん

[ ]
RE:17042 エンコードされたヘッダーフィーNo.17071
yorupica さん 04/03/15 18:30
 
秀まるお2さん

コメントありがとうございます。
> From:部分の場合だと、メールアドレスが1つしか入ってないという前提で処
>理できるんですが、To: Cc: の場合はエンコードされた中以外に元々コンマがあ
>る可能性があって、処理が難しいです。
>
> ということで現状程度の対応で勘弁してください。
私もそのつもりです。あくまで可能であれば、というつもりでしたので、処理が難し
いということであれば、無理を言うつもりは毛頭ありません。


[ ]