- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 600円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 300円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 400円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 490円
- » Kindle
- » iBooks
- » kobo
- » B.W.
- 200円
doncha.net制作・発行:KindleやiBooks、楽天kobo、BOOK☆WALKERで読む電子書籍
ケータイメールでtwitterに発言

ついこないだ、ちらっと書いたtwitterにメールで発言するスクリプトを。
ぐーぐる様詣でをすれば、すぐに出てくるネタで新鮮味もないんだけど、メールを受け取るところからの解説記事が少なかったんで、自分メモ。
前提としてメールサーバーはqmail。
HOMEにtwitter用のドットファイルを用意する。たとえば .qmail-mytwitter。中身はパイプでスクリプトに渡しているだけの1行。たとえばこんな感じ
| twitter.pl
送られてきたメールは、このtwitter.plが処理する。
twitterに投稿するにはユーザー名とパスワードが必要なので、データベースでもcsvファイルでもいいから、なにかに記録・登録しておく。このとき一緒に、投稿に使うケータイのメールアドレスも記録・登録する。
送られてきたメールをかまわずtwitterに投稿するわけにはいかない。まずは誰から送られてきたメールなのかを判定する必要がある。
qmailの環境変数 RPLINE は return path (ほぼ送信元のメールアドレスのこと)が入るので、これを使う、てのがキモ。こいつを見て、登録されているメールアドレスなら、そのユーザー名とパスワードを使って、twitterに投稿する。登録されていないメールアドレスだったら、なにもしない。
送り先のメールアドレスがバレても、returnpathのチェックが入る。returnpathを偽装されても登録されているメールアドレスでチェックをする。エラーの場合は何も返さず沈黙する。
てことで、なりすましや何かの踏み台に使われることも、ない、ハズ。セキュリティ的に問題になりそうなのはパスワードを平文で保存しているところ。でも、twitterそのものが認証はBasic認証だし、jsonpでAPIを使ってるひとのソースをみるとJavascriptにユーザー名とパスワードを書くことになっているのが目につく(=パスワード丸見え)
てことで、ここは目をつぶってtwitterだけにしか使わないパスワードにする・定期的にパスワードを変えることでカバーしよう。DBにしろcsvにしろ、ウチのポンコツサーバーから持ち出される、なんてことはほぼ考えられないし。
後は、誰が書いても、どんな環境でも、ほぼ同じスクリプト。
↓こんなでメールを解析して
メール本文と文字コードを取り出して
↓こんなでtwitterにPOSTする
メッセージが140文字以上だったらなにもしない。
ケータイのメールアドレスから取り出したユーザー名とパスワードを$twtに渡すのでそれを使ってtwitterのBasic認証をする。
メッセージ本体はhtmlエンコードをする。
POSTで投稿する。
というだけの手抜きなシロモノ。
twitterみたいな気楽な巨大チャットにはモバイルは最適、だと思う。ケータイで使えるモバツイッターや、iPhoneなどのスマートフォン向けのアプリが充実してるのも当然。わたしの場合はauで、パケットのコースのこともあるので、メールで投稿できたほうがいいかな、と。
ケータイで見るのをどうしようか検討中。とりあえず、ezwebで見るようにスクリプトを書いたんだけど、なんかビミョー。それなら、空メールを送ったら返信で最新のつぶやき20個とかメールで返してもらうのも、あり、かなと。こっち側はまだ試行錯誤、だ。
» ローカル環境で電子書籍を作る、Macアプリ・Windows版ツール 「かんたんEPUB3作成easy_epub」