アカウント名:
パスワード:
決してMTAプログラマやメールクライアントプログラマの失業対策にあまり関心がない。
プログラマーはこんな矛盾した要求だらけの複雑怪奇なものには近寄りたくない
たとえばね、通知→確認→要求→応答という段階を踏むと考えてみると、
・通知フェイズ Aさんからあなた宛のメールが届いてます。取りに来てください。 →わかりました。取りに行きます。
・確認フェイズ メールがあるって聞いたんだけど本当にAさんからですか? →はい。本当にAさんからですよ。○○からダウンロードできます。
・要求フェイズ メッセージを受け取りたいので私のメールボックスに入れておいてください。
・応答フェイズ はい、わかりました。
だいぶ複雑だけど、これはこれで要求を満たしているでしょ。(こまかいことは自分で想像して補ってね♪)
え?どう見たら可能だと思えるんですか?
>> 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい >受信者のMUAがPOPサーバから無事にメールを取得完了した事を >POPサーバが送信者に通知できればいい。
POPしてそのまま/dev/nullに行ってたりしたら、全然「無事に届いて」ませんね。 クライアントサイドのフィルタリングソフトの誤動作とか、ウィルスチェッカの誤動作とかで、受信者が知らぬ間に消えてしまっている可能性もあります。 そもそも、「送信者は受信者に、メッセージが無事に届いたかどう
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
次世代メールが目指すもの (スコア:2, 参考になる)
/K
ユーザーは: (スコア:1)
Re:ユーザーは: (スコア:2)
温泉旅館のようなもので、これを温存し拡張し続けることが
短期的な失業対策としてはもっとも有効。
Re:次世代メールが目指すもの (スコア:1, おもしろおかしい)
Re:次世代メールが目指すもの (スコア:2)
必要とされるのはそれが理由だ。
Re:次世代メールが目指すもの (スコア:1)
たとえばね、通知→確認→要求→応答という段階を踏むと考えてみると、
・通知フェイズ
Aさんからあなた宛のメールが届いてます。取りに来てください。
→わかりました。取りに行きます。
・確認フェイズ
メールがあるって聞いたんだけど本当にAさんからですか?
→はい。本当にAさんからですよ。○○からダウンロードできます。
・要求フェイズ
メッセージを受け取りたいので私のメールボックスに入れておいてください。
・応答フェイズ
はい、わかりました。
だいぶ複雑だけど、これはこれで要求を満たしているでしょ。(こまかいことは自分で想像して補ってね♪)
/K
Re:次世代メールが目指すもの (スコア:1)
> 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい
> 受信者は自分がメッセージを読んだことを送信者に知られずに読みたい
Re:次世代メールが目指すもの (スコア:0)
送信者はそこまでの到達を確認できれば、あとは受信者側の問題だから
いいんじゃないでしょうか。
Re:次世代メールが目指すもの (スコア:1)
それでいいなら SMTP で 500 を受けた時点で OK なのでしょうか?
可能でしょ? (スコア:0)
> 受信者は自分がメッセージを読んだことを送信者に知られずに読みたい
受信者がメールを読んだ後にMUAを操作し、
受信者がMUAの機能を使って送信者に通知するかどうか決められればいい。
# これは今でも実現されてる
> 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい
受信者のMUAがPOPサ
Re:可能でしょ? (スコア:0)
え?どう見たら可能だと思えるんですか?
>> 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい
>受信者のMUAがPOPサーバから無事にメールを取得完了した事を
>POPサーバが送信者に通知できればいい。
POPしてそのまま/dev/nullに行ってたりしたら、全然「無事に届いて」ませんね。
クライアントサイドのフィルタリングソフトの誤動作とか、ウィルスチェッカの誤動作とかで、受信者が知らぬ間に消えてしまっている可能性もあります。
そもそも、「送信者は受信者に、メッセージが無事に届いたかどう
Re:可能でしょ? (スコア:0)
>POPしてそのまま/dev/null云々
>フィルタリングやらウィルスチェッカ云々
なるほど、受信者たる人間がそのメールの内容を完全に取得した事をもって「無事に届いた」事としますか。確かにもとの文面
| 送信者は受信者に、メッセージが無事に届いたかどうか、それはいつかを知らせて欲しい
これを字句通りそのまま解釈するとそうなりますが、バグや他のソフトの動作、ユーザの誤操作(#思いついたのでついでに追加)なんかを含めた保証なんて、プロトコルとして全然現実的でないので、
今は亡きOSI (スコア:0)
仕組みは違えど、概念的なサービス要素は参考になるかも。
Receipt Ntoficication(開封確認)
に加えての
Delivery Notification(到達確認)
や、セキュリティ関連(受信否認への対応)とか盛りだくさんでした。
#盛りだくさん過ぎて、ほとんど実用化されませんでしたが…
Re:今は亡きOSI (スコア:1)
Message Handling System
だと思ったけれど。
MHS
Message Handling System (GOSIP, X.400, Novell, SPX, IPX)
信ずる者は掬われる。