メールサーバーの動作は結構バラバラだけど、
EC系で触ってた機会が多い割に、
ログによるエラー原因追及とかしかやった記憶が
無いこのPostFixの概要を把握。
プログラミング言語との連携方法も分かった。

メーリングリストについてだが、
簡単に言えば、エイリアス使ってアドレスを
プログラムなりに飛ばし、プログラム側は
stdin(標準入力)でその内容を読解して
メールの返答を返す様にする。
読解はmimetypeやらが面倒なので他のライブラリ
使って、ヘッダ部分にあるfromにメールを返す。
ここを参考にすればいいと思うよ。
http://coelacanth.dip.jp/emptymail.php
後はその情報をDBなりに登録しておき、
送りたい時間にcrontab設定したりでもすれば
簡単メーリングリスト完成。

PostFixというかメールサーバー自体は何を
してくれるか、についてはある程度同じ機構で

Message User Agent
(メールソフトみたいな感じ)
Mail Retrieval Agent
(メールの受信担当)
Message Transfer Agent
(どこに送るかと一時的なデータ保持)
Main Delivery Agent
(実際に送る係)

が動く事でメールが処理できる。
プロトコルとしては基本的な話だが
POP(受信)
SMTP(送信)
IMAP(メールのコピーとか検索やら)
DNS(宛先の問い合わせ)
が必要。

過去、数千件のメーリングリスト動かした際に
どうしても時間がかかる問題ってのがあった。
簡単な話、専用サーバーじゃない上に、
プログラムでウェイトも無しに送出すると
スパムと間違えられて止められたのよねｗ
複数台のサーバーでバランシングするみたいな
贅沢な環境は限られてるので、ってか中小では
まず無かろうなので、一回の全送出に2時間は
かかってた懐かしい思い出。

朝っぱらから歯医者行った。
その後、本を引っ張り出して再確認。
サンプルはGoogle Play Billing Libraryと言う事で
SDK Managerからダウンロードする。

やり取りの詳細が完全にOAuth認証思い出す訳だが、
同期と非同期メッセージの受け取り用レシーバとか
間に仲介役が入ったみたいな面倒な印象。
ただ、理解できなくは無いので、一旦進めてみる。
開発者登録とテストアカウントは別にしておかないと
後で確認作業の時に困る事だけ気に留めておく。

同日　15:40
静的メッセージで動作確認できた。
半分程動作は理解したが、大変面倒である。

後は運用サーバー側の購入時のデータ保存部分。

同日　18:36
実機落とし込み確認完了。
android.test.purchasedで確かに正常動作する。
ただ、さっきAndroid系記事で
全データ消失するハッキングがstring.xmlを使って
できるのではと出てたのがスゲー気になる。
http://gigazine.net/news/20140325-android-bug-app-delete-data/

Androidの場合、プリファレンスというxmlファイル
によるデータ保存機構があるので、初回はこれを使う。
次回以降はこのファイルを見て自動でログインする。
ログイン前にサーバー通信してユーザーを特定する。
UUIDが既存情報と違う場合はIPASSが合ってても
問い合わせ必須。

１、プリファレンスを意図的に消した。
２、他者が不正ログイン仕掛けてる。

どちらかだろうから、初回登録時にID、PASS以外に
もう一つ問い合わせ認証用の鍵を作っておいた方がいい。
つまり、最低限必要なのは４点
UUID、ID、パスワード、認証キー
こんな所か。

ログイン用のレイアウトとゲーミングスレッドは分離。
ゲーミングスレッドで処理しても意味無いし。
本格的に次は非同期通信入らななぁ。

同日　17:04
試験勉強ついでにCCENTの方にも手を出す。
ルーター本読んでたのが大活躍する。
とりあえず100ページ程読み進めて止める。
継続は力也。

同日　23:47
非同期通信一通り実装。挙動としては悪くない。

DDMSで見る限りサーバーからの送信データも
キチンと受け取れている。
後は、別に使い道は微妙だが課金構成も実装視野に
入れるべきかね。
あれメンドクサイんだよな・・・。

やってみたが、やっぱり８割だった。
そして5時間でも耐えられる用になってきた。
慣れは怖い。
そろそろ別作業した方がいいな、気分転換的にも。
・・・買い物行こう。

同日　21:48
Android進める。
制限時間秒数、パーティクル及びタッチ関連を
別スレッドで17ms処理させる様に改良。
後の問題はhttpRequestでのデータ同期処理。
端末データの同期をどうするかが曖昧なんで、
ちょっち考える。

そういや、スパム落ち着いてきたな。
一時期は１日10件ぐらい連続で来てたからな。

同日　23:00
IMEIとか端末IDとかMACアドレスとかも考えたが、
個人情報保護と管理責任の観点から、匿名性を保持して
データを作るとなると、結局結論として
UUID突合せとユーザー名及びパスワードになる。
暗号化については当然として、CSRF対策は仕様かな。
まぁ、虱潰しでも数ヶ月かかるような暗号化処理が
なされていれば問題は無いと考えていいだろう。
メンドクサイ事よ。
そもそも趣味プログラムだし、
管理側でそこまでログを取る気は無いので、
crontabで定期的にバックアップ生成するように
しておけば問題があってもユーザー毎にロールバック
できるだろうとも思う。
後はAsyncのdoInBackground処理での通信頻度。
これがネックになりそう。
アイテム使用や取得データ閲覧系統はサーバーに
情報保持してないと改竄防げないからなぁ。
結局非力なサーバーでは大きな処理は出来ない、か。