迷惑メール対策

メールを利用していればたいてい迷惑メールを受信したことがあると思う。
迷惑メールはかなり面倒な存在である。
これらの対策にはいろいろな方法が存在し、いろいろ提供されている。
プロバイダで提供しているもの、クライアントソフトで提供しているものなどがある。
今回は私が利用しているメーラーThunderbirdでの方法を説明する。
Thunderbirdを前提にした説明になるが他の環境でも応用は可能である。

対象環境

• IMAP
• Thunderbird

方針

• 受信ボックス一カ所だけだけ見れば新着がすべて見れるようにする。
• 新着は受信ボックスのみ見ればよく手間が減る。
• スマホなどで利用するとき受信ボックスがアクセスしやすいものを考慮している。
• 例：iphone標準の「メール」
• 受信時に自動的にメールにタグをつける。
• フォルダ分けされていなくてもタグにて色分けさせメールの見分けがつけやすくする。
• 利用者は受信ボックスを見てタグ付けが問題なければタグに基づいてフォルダ振り分けを行う。
• 受信ボックスの件数を減らし、可読性をよくする。

方法

説明用の環境例としてgmailを用いる。

1. サーバー側での自動的なフィルタリング（迷惑メールフィルタも含む）は行わない。
• gmailではデフォルトで迷惑メールフィルタが動作するのでこれをオフにする。
• webブラウザでgmailにアクセスし、from欄に「*」を入力したフィルタを作成する。
2. クライアント側で受信時に各メールにタグをつける。
• Thunderbiradのメッセージフィルタを利用する。
• フィルタを適用するタイミングを「メールチェック時と手動実行」にする。
• フィルタの設定は後述する。
3. ユーザーは後にタグに基づいてメールをフォルダに振り分ける（フィルタリングルールを作って自動で行う）。 
•  Thunderbiradのメッセージフィルタを利用する。
•  フィルタを適用するタイミングを「手動実行」にする。
•  フィルタの設定は後述する。 

メッセージフィルタルール

メッセージフィルタを用いてタグ付けとフォルダ振り分けを行う。
タグ付けの後にフォルダ振り分けを行う。
以下はその一例である。

1. タグ付けルール
1. 信頼できるアドレス（完全一致）
• 例：差出人がアドレス帳にある
2. ある程度信頼できるアドレス（ドメインなどでタグ付け）
• 通販サイトや企業、学校などからのメールを想定
• 例：差出人が次で終わる@apple.com
• 例：差出人または宛先、CC、BCCに次を含む
•  メーリングリストなどでは件名に規則的なものがつかわれているばあいがある。
• 例：件名に次を含む
3. 迷惑メール1
• 基本的にドメインを見て判定します。
• 例：差出人が次で終わる .mobi
• 末尾がcom, co.jp, jp, ac.jpなど決まったところ以外はだいたい迷惑メールの傾向がある
• orgなど他にもあるので自分のやりとりするアドレスの傾向を見て決める。
• 例：差出人が次で終わる @docomo.ne.jp
• 携帯からのメールは知り合いのアドレスを登録しておいて引っかからないようにする。
• PCメールに携帯メールは知り合い以外からはそこまで送られてこないと仮定している
4. 迷惑メール2
• 自分宛ではないメール
• 自分のアドレスが差出人、CC、BCCにない場合は迷惑メールとする。
• タグがない場合以外ではタグをつけない。
• メーリングリストなどでは自分のアドレスが含まれない場合があるため。
• 他のフィルタでタグ付けされるように設定する。
• 例：
• 条件１：差出人または宛先、CC、BCCに次を含まない　自分のアドレス
• 条件２：タグが空　
2. フォルダ振り分けルール
1. タグに基づいてフォルダ振り分けを行う
• 例：タグに次を含む

まとめ

迷惑メールフィルタでは基本的にメールの中身を見て過去のメールと似たものを迷惑メールと判定している。
この方法では、迷惑メールではないものを迷惑メールと判定してしまう場合がどうしても発生する。
そのような場合がなるべくなくなるような方法を考案している。
また、スマホなどでフォルダ分けした場合に受信ボックス以外を見れないなどの弊害をなくすことも考慮している。

この方法では欠点もある。
１つ目は設定が煩雑であること。
自分が送受信するメールのアドレスをある程度把握している必要がある。
また、送受信するアドレスが変化した場合にフィルタのメンテナンスが必要であること。
2つ目はフィルタリングが多段になるために処理が時間がかかること。

以上のような利点と欠点を持っているが、個人的にはかなり便利になった。
迷惑メールで困っている方の参考になれば幸いです。

Javaコーディング規約

ここのがすごい参考になりました。
http://www.acroquest.co.jp/webworkshop/javacordingrule/javacordingrule.html

gmailに他のメールアドレスを統合

gmailで他のメールを受信するようにすることでメールアカウントを統合できます。

やり方は以下を参照。
https://support.google.com/mail/answer/21289?rd=1

gmailでの受信はpop3に対応している必要があります。
統合するとGmailを介しているだけ受信が遅くなります。
また、Webからアクセスしている場合からなら受信アドレスにあわせて送信アドレスを変更できます（設定が必要）。
しかし、メールクライアントソフトウェアを利用している場合はそれができない場合があります（Thunderbiardにて確認）。

1つの（無料）gmailアカウントで受信できるpop3アカウントの制限は5つです。
ただし、多段にすることで簡単にその制限をなくせます。

例：

• gmail#1
• gmail#2
• yahoo#3
• yahoo#4
• yahoo#1
• yahoo#2
• hotmail#1
• icloud#1

例では合計８つのアカウントを統合しています。
黒丸が統合先アカウント、白丸がgmail#1で受信するアカウント、黒四角がgmail#2で受信するアカウントになります。
この方法の問題点は段の低い方（例では黒四角）がより受信に時間がかかるということです。
なので、低い段には重要度が低いアドレスをおくといいです。

吉里吉里 KAGでのfor, foreachマクロ

吉里吉里のKAGには繰り返しがありません。
そこでマクロを作ってみました。

そこそこうまくできたのですが、不満点というか欠点として繰り返し処理（for文の中身）を一連の流れの外に書く必要があります。
もっと使いやすくしたのですが現状ではここまでが限界でした。
もっといいのがある。もっと良くできる。など意見があれば連絡ください。

マクロの説明

最初に通常KAGで私が書くときの書き方を
次に、作成したマクロの使用例をいくつか書きます。
最後にマクロの中身です。

KAGでのfor文

０から９を表示するだけです。

for, foreachマクロの使用例

for文1
上の例と同じく０から９を表示します。
tf.iを増やしながら*doのラベルの処理を行います。
tf.iの初期値は０です。

for文2
こちらは２から９を表示します。
startでtf.iの初期値を指定できます。

foreach文１
foreach文の例です。
この例では配列内の数値が順番に表示されます。
listに配列もしくは配列の入った変数名を指定できます
tf.elemが各要素になります。

foreach文２
scenarioフォルダ内のファイルを表示する例です。

foreach文３
bgmフォルダ内のファイル一覧から再生リストを作成する例です。
listを指定しない場合はtf.listが操作される配列になります。
そうすることでtf.listとtf.iでtf.elemのかわりをすることができます。
tf.elemで書くと面倒な場合などで利用できます。
この場合、tf.elemにそのまま置き換えるとファイル名が変数名と判断されるためにエラーになるためにこのようにしています。
（tf.elemでもエスケープシーケンスを使って文字列扱いにすれば解決できます。）

foreach文４
tf.list以外を利用したときはlistに変数名を指定します

for, foreachマクロの実装

重要な部分だけ説明します。
まず、[eval exp="mp.val=Scripts.eval(mp.list)"]の行です。
KAGのマクロでは引数は文字列で渡されるようです。
そこでScripts.eval()で変数名から中身の配列への参照を得ています。
次に[call target="&mp.func"]の行です。
func引数に指定された文字列のラベルにジャンプします。
ジャンプ先の最後のreturnタグで戻ってくることを想定しています。
またKAGにおいてマクロは呼び出し元のコンテキストで実行されるようです。
すなわち、storage引数が呼び出しもとファイルと同じ物となります（forマクロと呼び出し元は異なるファイルと仮定）。
そのため、このコードでは呼び出し元と同じファイル中のラベルをfunc引数に指定する必要があります。
違うファイルのラベルを呼べるようにするにはstorage引数を追加するだけでおそらく可能です。

AVGの演出技術

AVGの演出技術に調べていて大変参考になるものを見つけたので紹介しておきます。

http://hwm2.gyao.ne.jp/serio/games/direction.html

長いけどとても参考になります。
2011年が最終アップデートなので最近の情報がないのが残念な点です。
が、今でも十分に通用するでしょう。
もう一つ、残念な点に文字ばっかりというのがありますが版権の都合上しょうがないかと。
体験版探して自分で確かめるのが一番いいかも。
もちろん、時間とお金があれば製品版で確かめるのもありです。

というか、どれくらいゲームやったのかが気になる・・

Xlink kai仕組み３

Xlink Kaiを解析した結果の説明の３回中の3回目です。

Kaiの通信は主に３つの系統に分かれると説明しました。
１つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
２つ目はPSP間の通信です。
３つ目はPM（Private Message）やり取りを行う通信です。

下の図はそれら３つの通信をまとめた図です。

今回は3つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
青の矢印は３つ目に用いられる通信経路です。
ここで行われる通信は主にPMに用いられます。

まず、プロトコルについて説明します。
User Interfaceとkaiengine間の通信はUIによります。
kaiengine間の通信はUDPです。
よってPMのやりとりに信頼性がありません。

文字化けについてまとめて書いておきます。
文字化けには主に3つほど原因があります。
1つめはWeb UIで日本語などを表示できない問題です。
フローティングパネルは文字エンコーディングを指定をうまくできないようです。
2つめはPMにおけるkaiengineで送信する文字エンコーディングの問題です。
7.4.18以前ではshift-jisが7.4.22以降ではutf-8が用いられます（正確にはOSなどにも依存する）。
通常のチャットではサーバーが変換してくれるために文字化けはありませんがPMではサーバーを介しないために文字化けが発生してしまいます。
3つめはMac OSのkaiengineのバグです。
Web UIとkaiengineで通信するとき日本語エンコーディングは変な変換がなされるようです。
ちなみに、ある一定の変換をすれば元のバイナリに変換できます。

以上、Xlink Kaiをいろいろ解析した結果をまとめてみました。

Xlink Kai仕組み２

Xlink Kaiを解析した結果の３回中の２回目です。

Kaiの通信は主に３つの系統に分かれると説明しました。
１つはチャットやアリーナの移動などのKaiのサーバーを介した通信です。
２つ目はPSP間の通信です。
３つ目はPM（Private Message）やり取りを行う通信です。

下の図はそれら３つの通信をまとめた図です。

今回は２つ目について主に説明していきます。
上の図で通信経路は矢印で表されています。
黄の矢印は２つ目に用いられる通信経路です。
ここで行われる通信は主にPSPが通信するデータを中継するだけです。

先にどうやってKaiが動作しているかを大雑把に説明します。
通常はPSP同士が通信しているるわけなのですが、PSPの替わりにWifiアダプタと接続するようにします。
PSP間の通信は暗号化されていないアドホックモードですのでSSIDさえあっていれば簡単にできます（というかそういう風に設計したのではないでしょうか）。
あとはWifiアダプタで受信したパケットを取得しネットワークを介して中継するだけです。
パケットの取得はパケットキャプチャと呼ばれ、OSで用意されていますのでそれを利用しています。
普通はライブラリ（winpcap, libpcapなど）が提供されているのでそれを利用するようです。
取得したパケットはトンネリングという技術を用いてKaiengineからKaiengineへ送信します。
トンネリングは新しい送信先と送信元の情報をつけて送信する方法です。
トンネリングされたパケットを受信したKaiengineはあとはWifiアダプタを用いてPSPに送信します。
送信するだけと書きましたが、おそらくWifiアダプタは中継モードと呼ばれるものになっています。
中継モードとは文字通り自分以外からのパケットを中継するモードです。
中継モードでは送信元が自分以外のパケットを送信できるのに対して、通常は送信できません。
おそらく中継モードがXlinkモードとその他での差異だと推測できます（おそらく他にもあります）。
ということでXlinkの動作とパケットキャプチャ、トンネリング、中継モードが主要な技術要素であることを説明しました。

次に通信プロトコルについて見ていきます。
PSPとWifiアダプタの通信はEthernet（Wifi）パケットをブロードキャストで行っているようです。
ちなみにイーサネットより上の階層のプロトコルはオリジナルになっています（TCP/IPではない）。
kaiengine間UDPは通信になります。UDP通信の方が即応性があるために用いられています。
しかしながら、信頼性はないのでパケットを損失し、ラグやワープが発生することがあります。

ここで、なぜアリーナでプレイをしてはいけないかを説明しておきます。
少し上でPSPとWifiアダプタはブロードキャストで通信していると説明しました。
ブロードキャストというのは不特定多数に送信する方法です。
そのため、グルーピングがそのままではできないのでSSIDによりグルーピングを行っています。
モンハンで言えば集会所ごとにSSIDを変えています。
しかし、パケットキャプチャでは受信時にEthernetパケットとして受信するためにSSIDの情報が失われます。
そのため、この方法はXlinkではできないようです。
そこでKaiでは部屋を用意しているわけです。
仕組み上、ブロードキャストは誰宛かわからないのでkaiengineは部屋（アリーナ）にいるすべての人にパケットを送信します。
そのため部屋（アリーナ）にいる人数が多くなるほど負荷が多くなることになります。
とくにモンハンなどではクエにいくと通信量が増えます。

ここでどのくらいの負荷増加になるか計算してみます。
一人分のプレイ時の負荷増加分をΔとします。
プレイ人数をXとします。
アリーナ内の人数をαとします（自分たちも含めて）。
このときの負荷増加分はX×Δ×α
ΔをMHP3rdで計測したところ5KB/sec位でした。
X=4, α=100だとします。
すると全体の負荷増加分は2MB/secと結構な値になります。
この値は全体の負荷です。
個人の負荷は20KB/secになります。

これが多いか少ないかは回線にもよるので何とも言えませんが、アリーナでプレイをすると他人の負荷になってしまいます。
そのため、アリーナでのプレイは基本的に避けるべきです。
ただし、人数が少ないときはたいした負荷でもないので負荷的には別に問題ないです。

最後にセキュリティの話を書いておきます。
kaiengineはパケットキャプチャをしてそのパケットを送信していると説明しました。
このときkaiengineはキャプチャした通信を内容を見ずにすべて送信します。
これはwifiアダプタを正しく選択していれば問題ないのですが、間違っていた場合に面倒なことになります。
たとえば、LAN内通信に用いているNIC（Network Interface Card）が選択された場合に、LAN内での通信が漏れることになります。
また、正しくアダプタが選択している場合でもPSPから送らなくてもいい情報が送信されている場合もあります。
実際に送信されているのを確認したのものとしてPSPに設定しているニックネームがあります。
もし本名などを設定しているなら変更した方がいいでしょう。

次回最後の3つ目のPMのやりとりを行う通信について説明していきます。