[debian-users:15336] Re: mbox migration.(was Re: )

["Katsuya Nagai" <katsuya@xxxxxxxxx>]

永井 克弥＠大和郡山市です。Debian 固有の話題ではなくて申し訳ありま
せん。

>>>> "Ken N." <kenn@xxxxxxxxxxxxxxxxx> wrote
>>>>  at Tue, 11 May 1999 22:49:53 +0900
>>>>  in <199905111222.VAA23673@xxxxxxxxxxxxxxxxxxxxxx>
>>>>  Subject: [debian-users:15333] Re: mbox migration.(was Re: )

kenn> 何の参考になるとおっしゃっているのかは存じませんが、少なくとも
kenn> Message-ID: について考察する上で、あのような文書を参考にするよ
kenn> うなことはしないように気をつけたいものですね。

岸本さんの御紹介下さった、

  http://www.ne.jp/asahi/cyber/taki/win-mailer/message-id.html

の文書は、僕も良くまとまっていて良い文書だと思っています。どこがま
ずいのでしょうか?  Message-ID: だけに関しても 
${UNIQ}${OWN-REACHABLE-MAIL-ADDRESS} を使うのも、現実的で良い考え
だと思いますが。

# ${UNIQ} は Date & Time とか PID を適切に組み合わせて生成する。

>> Header は、接続元がちゃんと用意してあるのが正しい実装
>> だと思います。たとえば、Date フィールドとか。

kenn> いきなりDateなどと話を振られても困りますが、ヘッダ一般について
kenn> そのような理解をなさっているのであれば、もう少し見識を深められ
kenn> たほうが良いと思います。

僕が Date: を出したのは、Message-ID: とは異なり SMTP でも NNTP で
も Recommended だったと記憶しているからです。Date: は AS IS で付け
れば良いけど、Message-ID: に関してはさまざまな考察があるという点で
は確かに僕の引合が悪かったと思います。申し訳ありませんでした。

# 見識に関しても、RFC も流し読み程度でしか読んだことがないので確か
# に低いのかも知れません。

kenn> E-MailやNetnews などのメッセージに付加される属性について、その
kenn> 属性を定義する責任を負うべきなのは誰(あるいはどのシステム)なの
kenn> か、または、その属性を定義してもいいのは誰と誰(あるいは、どの
kenn> システムとどのシステム)なのか、といった観点から考察してみると
kenn> 良いでしょう。Message-ID: というヘッダが、そのメッセージにおけ
kenn> るどのような属性であるかがわかれば、どうしてUser agent側で普通
kenn> 用意する必要がないのかもわかります。

Ken N. さんの御意見は抽象的で高度ですので僕には難しすぎるのですが、
僕は SMTP とか NNTP とかのプロトコルを境界面として各々のフィールド
が要/不要であると判断すべきと理解しています。当然、SMTP での 
Received: や NNTP での Path: などは途中の MTA (ご存知の通り M は 
Mail ではなく Message の M として使用しています) で作成/追加して意
味があるものです。また、SMTP や NNTP は MTA 間でのプロトコルととら
まえると、Date: や Message-ID: などは、そのプロトコルを介して 
Message が転送される時点で付いていなければならないと考えています。

Received: は MTA 間でフィールドの追加が発生しますし、Path: は 
MTA 間でフィールドの改編 が発生しますが、Message-ID: や Date: は
Message が生成された時点から不変であるべきだと思っています。あくま
でも MUA でも SMTP や NNTP を介して接続しに行く限りは、自己で 
Date: や Message-ID: などを用意しなければいけないという (Qmail の
実装に近い?) 考え方です。

# 僕は、Broken SMTP Client--PostPet も抱えているので ofmip に転ん
# でしまいましたが...。ちなみに PostPet は Broken POP3 Client (?)
# でもあります。

別段、SMTP/NNTP で接続された最初の MTA が存在しないフィールドを補
う方式でも、世界が上手くまわるのであれば良いとも思います。以前に申
し上げたように、ヘンなものを付けるくらいならない方のがマシという考
えには賛同致します。ただし、あくまでも接続するその MUA (と思われる
もの) が単一の Host へのみの接続で全く並列配送をしないという条件下
でですが。

この考え方は間違っていますでしょうか?  それとも論点/認識がずれてい
ますでしょうか (こっちの方が可能性大かも)?

--
Katsuya Nagai <katsuya@xxxxxxxxx> URL:http://www.kcn.ne.jp/~katsuya/

Private, Nara Prefecture, Japan.
// The hacker isn't the cracker, do you know?