Torisugariの日記: メールボットの可能性 2
メールボットは、そのアドレス宛にメールを送ると、機械的な内容の返信をしてくれるソフトウェアで、通常はメールサーバー上で動いている、と思います。いえ、よく知らないんですが。で、これがもし、メールクライアントで動いていたら、ちょっとしたファイルサーバーとして使えますよね。
例えば、会社や学校から
fetch c:\foo\bar.txt
という本文のメールを送ると、電源付けっぱなしの自宅PCで、そのメールを受信したThunderbirdがbar.txtを添付ファイルにして送り返してくれる、とか。セキュリティ的には一抹の不安が残りますが、あったらワリと便利だと思います。ポイントはドメイン取得等のややこしいことを考えずに手軽に導入できることでしょうか。メールの利用者は、HTTPサーバーやメールサーバーを運営している人数に比べると、遥かに多いですから。
セキュリティの件をもう少しまじめに考えると、
・送信するファイルは限定すべき
・送信先(メールアドレス)を限定すべき
という感じがします。そのへんは、公開ディレクトリをボットに設定しておいて、アドレスリストに入っていないメールからのリクエストを弾けば、なんとかなりそうです。
ここまで考えると、これはちょっとしたファイル共有ネットワークにも成り得ますね。
fetch *bar.txt
みたいな感じで。
検索やMD5比較をつけて、それっぽいGUIで包めば(つまり人間はメール本文を直接読み書きしない)かなりそれらしくなると思います。難点は、
・ネットワーク内の匿名性皆無。
・レスポンスはあまりよくない。場合によっては分単位。
・通信効率上のメリットも皆無。
といったところでしょうが、公明正大な用途なら、こういうデメリットはさして問題にならないでしょう。TCP/IPで直接通信するといかにもP2Pという感じですが、メールだって途中経過を粗く見れば、クライアントからクライアントにメッセージを送っていることに変わりありません。確かに、ちょっと贅沢な感じはしますけど。メールアドレスとIP(特にv4)を比べるのは奇妙ながらも、結構面白そうだと思うのです。
あとは、ボット経由のHTTPプロクシなんてどうですかね。つまり、スラドが禁止の職場などで、
fetch http://srad.jp/index.pl
という本文のメールを送ると、自宅で待機しているThunderbirdが…
tclで書けば (スコア:1)
http://lowlife.jp/yasusii/stories/20.html
問題は経路の信頼度が低い場合、同じ指令が複数回届いたときにどうするか、指令は発令した順序で確実に処理されるのか、というあたりです。人間が読むメールと同じアカウント使うときは、命令がループしたり、通常のメールが命令と誤解される可能性をいかに減らすかとか。
デジャブ (スコア:1)
Accessing the Internet by E-mail FAQ [faqs.org]