ふわっとした情報から一次ソースまでたどり着く方法（RFC編）

0. 要旨

「メールアドレスのドットの連続はRFC違反」みたいな ふわっとした情報があって興味をもったとき、 技術屋なら 「どのRFCのどのセクションにどのように記述されているか」 みたいな一次ソースを当然確認したくなるでしょう？
今回、メールアドレスのルールが気になって調べたのでここに記録しておく。

1. 一次ソースまでの道のり

1.1. Wikipedia日本語版「メールアドレス」

ざっと説明を読む。ふむふむ。 RFC 5321とRFC 5322への参照がある。 取り合えずリンクを開く。
（今回は、Wikipedia日本語版に参照先まで書いてあってラッキーなパターン。 日本語版に参照がなくても英語版を眺めると参照先が見つかることもあるし、 さらにインターネットをさすらう場合もある。）

1.2. RFCを眺める

タイトルは
RFC 5321：Simple Mail Transfer Protocol
RFC 5322：Internet Message Format
で、どちらもボリュームがある。
RFC 5321から読むことにする。

1.3. RFC 5321を眺める

まず左上にObsoleted byがないことを確認する。
（もしObsoleteになっているなら、 Obsoleted by: XXXXのXXXXを読むべきだから。）
長いのでさらさらスクロールしてみる。
中程でバッカス・ナウア記法（BNF）的な 表記を見つけて手を止める。その節は 「4.1.2.  Command Argument Syntax」。
読んでみるが、いまいち解決しない。
@の左側はLocal-partと呼び、それはDot-stringであって、、、 と書いてあるが、atext以降が解決していない！ そしてこの文書にはatextはこの1個しかない！

1.4. RFC 5322を眺める

気を取り直して、RFC 5322を開き「atext」を検索する。 3個めのatextでBNF的な表記に出くわす。その節は「3.2.3.  Atom」。 atextが定義されている。なんだatextは普通の文字 （アルファベットと数字といくつかの記号）のことか。

1.5. RFC 5321に戻る

ここで、RFC 5321 4.1.2に戻る。
----------------------------------------------
（前略）
   Dot-string     = Atom *("."  Atom)
   Atom           = 1*atext
（後略）
----------------------------------------------
たしかに、Local-partは確かにドットは連続しないわ、と納得する。

＜読み方＞
読み方は人によるところが大きい。
私はボトムアップが一番理解しやすいので、 最下層（定義に近いもの）から順番に組み立てるように理解する。
「Atomは任意個の普通の文字。
Dot-stringは先頭にAtomあって、その後に任意個の｛.（ドット） とAtomの連結｝が続く。
ということは.（ドット）は連続で現れないし、先頭にも最後尾（@の直前）にも現れない！」

1.5. RFC 5321とRFC 5322

だけど、RFC 5321の途中からRFC 5322の定義を読むのでよいのか、 と我に返る。
RFC 5321で5322を検索すると 「1.2.  History and Context for This Document」に 「RFC 5322はcompanion documentだよ」と書いてあるので、 よいことにする。

2. おまけ

2.1. ITEFのRFCのページ

ITEFのRFCのページは便利。
https://tools.ietf.org/html/rfc5321
Obsoleteになっているもの、updateがあるものは 最上部で分かるし、 他のRFCへの参照はハイパーテキストリンクになっている。

2.2. バッカス・ナウア記法（Backus-Naur form）

BNFは学部3年のときに情報学科の講義で勉強して、 なるほどすごい、と思った。
でも、いつもギリシャのお酒の好きな神様を思い浮かべてしまう。 （綴りはちょっと違う）

2.3. Request For Comment

RFCに「違反」という言葉は似合わないと思っている。
「法令」ではない、ただの「Standard」なのだから、 「準拠していない」くらいが適切と思う。

以上

FreeBSD に手動で font を install する方法

1.IPA font
私は、FreeBSDをメインマシンのOSとして利用していて、かなり快適に暮らしている。（マウスを使うのが苦手なのと、セキュリティー面で安心感で、WindowsよりFreeBSDが好きだ。）

そんな日常生活を送るのに不可欠なものが、"フリーな"日本語フォントである。幸いなことに独立行政法人　情報処理推進機構(IPA) http://www.ipa.go.jp/ が無償でIPAフォントを配布しており、FreeBSD では ports からinstall することができる。(明朝、ゴシック)と（固定幅、変動幅）の直積、計4種類がある。

しかし、2チャンネルの芸術作品AAは、MS Pゴシックで表示されることを前提としており、IPAPGothic では表示が崩れてしまう（どちらもPropotional font ではあるが、変動幅の設定が異なるため）。

MS Pゴシックと同じ変動幅を持つフリーなフォントは古くはモナーフォントがあるが、現在は開発が停止しているらしいので、今回は IPAモナーフォントを install した。

2.install の方法
(1) download
IPAモナーフォントの本家サイトhttp://www.geocities.jp/ipa_mona/から、opfc-ModuleHP-1.1.1_withIPAMonaFonts-1.0.8.tar.gzをダウンロードする。

(2) install
$ tar xzvf opfc-ModuleHP-1.1.1_withIPAMonaFonts-1.0.8.tar.gz
$ sudo -s
# mkdir /usr/local/share/font-ipamona/
# mv opfc-ModuleHP-1.1.1_withIPAMonaFonts-1.0.8/fonts/*.ttf /usr/local/share/font-ipamona/
# ln -s /usr/local/share/font-ipamona/* /usr/local/lib/X11/fonts/OTF/
 （OTF はOpen Type Font の略なのでOTFの下にした。どこでもいい。）
(3) ためしてみよう
firefox でアスキーアートのあるページ （例：あなろぐま http://l19.chip.jp/chidejika/）を表示して
Edit -> Preference -> Content -> Fonts & Colors で IPAMonaPGothic を選んでみよう。

(4) トラブルシューティング
/etc/X11/xorg.conf のSection "Files" に FontPath "/usr/local/lib/X11/fonts/OTF/" がなければ追記すべし。

3. おまけ
フリーの日本語フォントみたいな、作るのにお金はかかる（手作業だから、お金を払って外注する）けど、あればみんなが役に立つことは、税金でやるべきことであると思う。

4. 参考文献
IPAフォントのページ http://ossipedia.ipa.go.jp/ipafont/index.html
IPAフォントと異字体 http://ossipedia.ipa.go.jp/ipamjfont/
IPAモナーフォントの本家 http://www.geocities.jp/ipa_mona/
アスキーアートの例（あなろぐま） http://l19.chip.jp/chidejika/

iPad2 生活の準備1 - iTunes Store でお金を払えるようにする

iPad2 は便利そうだという結論になったので(今度記事にする予定)、買う準備を始めることにした。まずは iTunes Store でお金を払う手段について調べた。

オンライン決済はかなり普及していて、身の回りでもオンライン決済を利用する人は多い。
でも私は基本的に the Internet は危険なところと思っていて、ネットショッピングをしてもカード番号を打ち込んだことはない。
amazon -> 必ず、コンビニ払い、コンビニ受け取り。住所も削除してある。メールアドレスもフリーメールのアドレス。
航空券 -> 予約はオンラインでして、旅行代理店で決済。クレジットカードで払うこともあるが、ある程度生協を信用しているから。
宿 -> ビジネスホテルの予約はほぼネット予約を使う。値段が全然違うから。でも正確な住所は書かないこともある。現地で現金払いできるところにしか基本的には泊まらない。

そもそも、オンライン決済でなくても、信用できそうなところで高額な買い物をするときしかクレジットカードは使わない。生協、鉄道会社(定期券)、くらい。

あとは、Suicaで買い物もしないなあ。何も悪いことはしていないけど、情報が生じることが嫌だ。でも edy は特定のスーパーの店舗でのみ使っていて、無記名でその店舗での買い物情報が集まるくらいは便利さとのトレードオフでぎりぎり許容範囲である。

さて iTunes Store でお金を払う方法を調べた。

手段1.2枚目のクレジットカード
オンライン決済用のバーチャルカード
http://www.smbc-card.com/nyukai/add/virtual/index.jsp
を限度額の小さい2枚目として持とうかと考えたが、1枚目の限度額を下げれば良い気もして保留。使い分けると、情報が盗まれたときの被害が多少は減るような気もするので、そのうち作るかもしれない。

手段2. Vプリカ
http://vpc.lifecard.co.jp/guide/use.html#guide_check
「プリペイドでクレジットカードとして使える」という宣伝文句に惹かれたが、現金でプリペイドすることはできず、別のクレジットカードで支払うという仕様。
それって何がうれしいか考えたが、2枚目のクレジットカードと同じで、使い分けると、情報が盗まれたときの被害が多少は減るような気もする、ということか。2chのスレ
http://toki.2ch.net/test/read.cgi/credit/1309483837/
を読んだが、エロサイト用か。1のバーチャルカードより使う可能性は低い。

手段3. iTunesカード
そう、ここまで調べてから、iTunes カードの存在を知ったのだ。
http://store.apple.com/jp/browse/home/shop_ipod/itunes_cards
これが必要十分ではないか。現金で、セブンイレブンや家電量販店で買える、プリペイドカード。私はこれが欲しかった。
参考) iTunes Storeでハッキング被害に遭わないためにいますぐできる3つの方法＋α http://www.ttcbn.net/no_second_life/archives/3119

ということで iTunes カードで、iTunes Storeでお金を払える見通しがついた。

しかし、「頻繁にクレジットカード情報流出！」と聞くが、みんなよく怖くないなあ。金銭的には損はしないけど、個人情報が漏れることが「気持ち悪い」と私は思うのだ。感覚と価値観の問題だから、とやかく言わないけど。

メールの安全性について

メールの安全性(盗聴、改ざん、なりすまし、否認を防ぐ)を確保するための手段はいくつかある。何があるかを調べたのでメモしておく。

中間者攻撃による攻撃は、PKI(公開鍵基盤)を用いない限り防げない。

DKIMは、送信メールサーバはメールの内容に、送信メールサーバのもつ暗号鍵でsignetureをつける。送信メールサーバを管轄するDNSサーバに公開鍵を置いておく。受信メールサーバは、Fromに書いてある送信メールサーバを管轄するDNSサーバの公開鍵と証明書で、送信メールサーバを秘密鍵を持っているサーバとして認証する。
オレオレ公開鍵でも中間者攻撃がなければ、文面改竄検知が可能。

SPFはFromに書いてある送信メールサーバが本当に送信メールサーバであるかを、Fromに書いてある送信メールサーバを管轄するDNSサーバに確認する。文面改竄検知は不可能。
RFCではExperimentalの扱いだから「ついてないと受け取らない」はやるべきではない。

ヘッダから手動で安全性を確保するなら、
1. Received を上から追いかけ、変なところを通っていないか調べる。
2. Received の最下行の送信者のIPからdomain nameを正引きする。($ whois xxx.xx.xx.xx)
3. 2の結果をdigする。($ dig example.com txt)
文面改竄検知は不可能


私見では、文面改竄されたら困るものはたいてい見られ困る級のものだから、そもそも暗号化して送れと思ったのだが、見られていいものに、中間者がウイルスファイルを添付するとかは攻撃としてありうる。これはオレオレDKIM級で防ぐことができるものだ。
あと、ヘッダから手動で確認はSPFに負けてないと思うがどうだろう。

ちなみに某検索最大手は DKIM(PKIによる認証)をしている。
某航空会社は SPFに対応している。
某I機構、某大学は 認証なし。しっかりしよう。

参考文献
DKIMについて RFC4871
http://www.ietf.org/rfc/rfc4871.txt
SPFについて RFC4408
http://www.ietf.org/rfc/rfc4408.txt

追記(2011年７月12日)
SPFの主目的は「Fromを偽装したスパムを弾くこと」らしい。SPFはその目的にはかなった手段だ。
それから、中間者攻撃は「技術的に可能だけれどもかなり大変。悪人がコストをかけても改竄したいと思わなければやらない」。だから普通はあまり気にしなくてよい。楽にできて、やらないよりマシな技術というものはたくさんあるから、それはやったらいい。

クラウドコンピューティングと(動画)ファイル共有の未来

先日、友人にドリームジャンボのCMを紹介しようと思った。
今はもう放送されていないが、幸いYoutubeでとってあったので、URLをメールで送った。
http://www.youtube.com/watch?v=K0swXbQmbaQ


クラウドコンピューティングの時代だなあ。

URLと動画Fileの関係は、C言語におけるポインタとデータの関係に同じだ。
別の関数がデータにアクセスするためには、データを直接やりとりせずに
データの所在地を示すポインタのやりとりだけで済ませた方が、
memory spaceとdata copyにかかる時間の節約にもなるので、
ポインタは非常に便利である。
同様に友人に動画を見せたい場合もURLをポインタとして渡せば充分だ。

必要なら、関数と同じように勝手にlocalでcopyをとればいいだけだ。

しかしながら、未だに、クラウドコンピューティングは
サーバーがサーバー群であり、ネットワークがインターネットである
サーバークライアント方式だという理解のままである。





また、技術とは別の所だが、YouTubeなどの動画(ファイル)共有システムには、

著作権法上の問題がある。CMなどは広告主がインターネット上にアップロード
してくれればいいのだが、改変されるのが嫌なのだろう(ほかにも出演者との契約とか
もあるだろうが)。
すべての再生可能なデジタルデータは技術的には改変可能なので
(暗号化しても再生可能だということは、最終的には単純なRGBデータになる。
再生ソフトとOSがバイナリでのみ配布されないかぎり、RGBを盗むことは可能
(例えば、copy不可のpdfだって画面キャプチャーしてデータを保存することは原理的には
できる。プログラムとして出回っているかは知らないが) 。
世の中には数多の動画編集ソフトがある)、それが嫌なのだろう。

しかしながら、法律と取り締まりを厳しくするか、動画再生ソフトを企業が独占販売すれば
改変されたものが出回らなくなるはずだ。そうなったとき、インターネット上の動画共有が
どうなるのか楽しみでもある。