redbrickの日記： 電信八号-コメント(2)

どうも、反応ありがとうございます。

わたしが根拠薄弱のまま電八について放言してしまったというのに、
調査という方向に持っていって下さったwosamu氏、
大変感謝しております。
＃コメントの方にお礼をつけようかとも思いましたが、
＃コメントチェーンが長くなるのもなんなので、こちらに
＃書きます。本当にどうもありがとうございます。

今日は思い立って自宅の環境で電八を動かしてみました。

[入手経路]

電八オフィシャルサイトのDownloadから入手。

バージョン(送信e-mail headerより抜粋)：
X-Mailer: Denshin 8 Go V32.1.3.1

[自宅の他e-mailer環境・バージョン]
X-Mailer: WeMail32[2.08]

[試行内容]
自分の持つアドレスに、Toに複数エントリを入れて送信。
受け取ったら、そのまま返信。

以下に出てくるe-mail addressは例示のための全くのでたらめですが、
実在するか確認しておりません。
絶対にメールなど送らないでください。

[試行1]：電八からe-mailを送信。
以下、自分で受信したe-mailのheaderから抜粋(一部修飾済)。
Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Denshin 8 Go V32.1.3.1
Date: Sun, 16 Dec 2001 (以下略)
From: redbrick <[e-mail]>
To: [e-mail], [e-mail]
Subject: test_1

まともに受け取っている。
見るのも、テキストエディタで問題ないことを確認。

[試行2]：電八で受け取ったe-mailに返信。

Content-Type: text/plain; charset=iso-2022-jp
X-Mailer: Denshin 8 Go V32.1.3.1
Date: Sun, 16 Dec 2001 (以下略)
From: redbrick <[e-mail]>
To: redbrick <[e-mail]>,[e-mail]

見える。問題はないように見える・・が、返信e-mailを構成する際に
なぜかアドレスが<>付きのものに入れ替わってしまっている。
＃とりあえず、動作に問題あるわけではないけど・・・違和感あり(汗)。

[試行3]：WeMail32から出したe-mailを受信。

To: [e-mail], [e-mail]
Subject: test_from_wemail
Reply-To: [e-mail]
X-Mailer: WeMail32[2.08]
From: [e-mail]
Date: Sun, 16 Dec 2001 (以下略)

きちんと届くし見えている。特に問題があるようには見えない。

[試行4]：WeMail32で出したe-mailに返信。

X-Mailer: Denshin 8 Go V32.1.3.1
Date: Mon, 17 Dec 2001 (以下略)
From: redbrick <[e-mail]>
To: [e-mail]

・・・・。
き、消えている(汗)。[e-mail]のアドレスが(汗)。
電八から届いたe-mailに返信した場合はきっちり残っているのに、
何故？？
＃電八の、「勝手にFromのアドレス入れました」的な
＃挙動もなんか変だけど・・・(汗)。

また、返信時の操作として、メールを自分で編集する以外に
元のe-mailに含まれるToのアドレスを取り込む方法がないというのも
WeMail32に慣れた者としては違和感があったが、これは個人的感想ですね(汗)。
＃WeMail32ではe-mailの文面構成前に追加するアドレスを選択出来るためだと
＃思います。
＃Toにデフォルトで入れるわけではなくて、選択できるのが普通と思ってました。
＃まさか、手でエディタ上で追加しなければならないとは想像できませんでした(汗)。

[e-mail headerの相違点]

電八はインストール直後で送信・返信・転送などのテンプレートファイルを
全くいじってないためか、Reply-Toが付かない。
Fromはどちらもある。

[RFC2822を参照しながらの個人的意見]

返信時、FromもしくはReply-toにあるアドレスはToに入ってもよい
というのが、RFC2822にある。
＃強制ではないらしい(助動詞MAYの用法で)。
＃推奨と言えるかどうかはわからない。

ただ、その他にToに入っていたアドレスは、(返信時には)Ccに入れても
おかしくはないらしい。
＃個々の話の展開によってはToで送り直すってこともありえると思うが、
＃標準としてのこの見解には、個人的に異論はない。


[本日の推論結果]

それで、今までの電八の動作を見ると、ある想像を思いついた。
「電八はreply-toが付いたe-mailには、Toに複数アドレスがあっても
そのreply-toのアドレスしか取り込まないんじゃないだろうか？」

とりあえず、最初の粗い推論結果として載せておきます。
＃ちょっと遅くなったので、後の検証は後日にします。

RFC2822によると、Reply-toがあるe-mailに対しての返信コマンドでの
挙動は規定される性質のものではなく、実装依存だそうですので、
この挙動が即バグというわけではないようです。
＃次回からはトピック/アイコンを変えます(汗)。

あ、ちなみにちょっと気になったんですが。＞wosamu氏

>X-Mailer: Denshin 8 Go V32.1.3.1; sp2

このX-Mailerヘッダのうち、最後の"sp2"ってなんでしょ？
＃わたしのところに届いた知人のe-mailにも、わたしが入手した電八で
＃生成したe-mailにも付かないんですが・・・。

こっちでちょっと調べてみました。

[wosamu (4952)]

また長文ですいません。
>わたしが根拠薄弱のまま電八について放言してしまったというのに、
>調査という方向に持っていって下さったwosamu氏、
>大変感謝しております。
いえいえ、こちらとしてはユーザとしての当然の疑問を呈しただけですし
寧ろユーザでもないのに面倒がらずに調査に協力していただいているあなたに感謝しております。

>見える。問題はないように見える・・が、返信e-mailを構成する際に
>なぜかアドレスが付きのものに入れ替わってしまっている。
>＃とりあえず、動作に問題あるわけではないけど・・・違和感あり(汗)。

これは単にFrom:をTo:に入れるからじゃないでしょうか。

>返信時、FromもしくはReply-toにあるアドレスはToに入ってもよい
>というのが、RFC2822にある。
>＃強制ではないらしい(助動詞MAYの用法で)。
>＃推奨と言えるかどうかはわからない。
この文のことですかね？
http://www.puni.net/~mimori/rfc/rfc2822.txtから引用
（以下引用はすべてここから）

メッセージが別のメッセージのリプライ（返信）であるとき、大元のメッセー
ジの著者のメールボックス（Fromフィールドにあるメールボックス）あるいは
（存在するなら）Reply-To フィールドに規定されたメールボックスがリプラ
イのToフィールドにあらわれてもよい(MAY)。

ということならTO:に元のメッセージのFrom,Reply-Toが現れても良い、ということですよね？
なら電八のデフォルトの動作だと思います。
今回の件は大元のメールの宛先フィールド(TO)をどう取り扱うかの問題でしょう。
この文では大元のメールの宛先フィールドの動作に関しては記述されていません。
電八ではデフォルトのテンプレートでは
To: $RECOMMENDED-TO
となっておりまして、これがどういう仕様になっているかは正確には
調べきれてはいないのですが、これがreply-toに関しては今まで調べたような
動作をしている原因でしょう。
そもそもreply-toフィールドは

メッセージの著者が返信を送る先として提案するメールボックスを示す。

ということなのでわざわざこんなヘッダつけたのなら、そこだけ返信するべきだろうって
判断は自然なものと思えます。
特にメーリングリストとかならそういう動作が望ましいだろうとは思います。

注意：いくつかのメールアプリケーションは、リプライの宛先アドレスにもと
もとのメッセージの宛先アドレスを入れるような自動のリプライコマンドを持っ
ている。どのようにそれらのリプライコマンドが振る舞うかは実装依存であり、
この文書の範囲にない。特に、もともとのメッセージがReply-To:フィールド
を持っているときに、もともとの宛先アドレスを含むかどうかは、ここに書い
ていない。

結局のところ実装依存のようですね。
RFC的には一切関知しないと。

で、電信八号ではテンプレートのファイルでヘッダ情報を制御できますので
To: $RECOMMENDED-TO,$TO
とかかけばお望みの動作を実現できると思います。
もしご友人がそのような動作をお望みであるなら一度お試しされることをお勧めします。

>このX-Mailerヘッダのうち、最後の"sp2"ってなんでしょ？
>＃わたしのところに届いた知人のe-mailにも、わたしが入手した電八で
>＃生成したe-mailにも付かないんですが・・・。

最近はやったウィルスがらみで発見されたバグ修正を施したバージョンです。
現在はML内でテスト公開中ですが、もうまもなく一般公開されると思います。