2014年5月14日水曜日

3分でDKIMの概念が分かる実践的ガイド

迷惑メール対策の仕組みとしては、SPF、DKIM、DMARCの3種類が主に使われています。

このうちSPFは日本でも広く使われていますが、DKIMは情報が少ないために殆ど使われている事例を見かけません。DKIMは決して難しすぎるわけではないのですが、概念を把握できるような情報が日本語で存在しないため、概要を掴むのに苦労します。

さて、DKIMとは何でしょうか。

一言でいうと、メールに電子署名を付与するための手法です。電子署名を付与することで、正しい送信者から送信されていることを証明し、送信者を詐称する迷惑メールに対抗します。

ややこしいのは、「誰が署名するのか」「署名を検証したらどう使うのか」ということが利用者の裁量に任されており、そのせいで概念が極めて掴みにくくなっています。


署名する方法と、署名を検証する方法はシンプルです。DNSにレコードを追加して、そこにRSA公開鍵をおきます。送信者は対応する秘密鍵を使ってメールに署名します。受信者はDNSに問い合わせして公開鍵を取得し、その公開鍵を使って署名を検証します。

DNSに記載するドメイン名は、(selector)._domainkeys.(domain)という形式になり、そのselectorとdomainは署名中で指定することができます。gmail._domainkeys.example.comというドメインであれば、example.comの持ち主が署名しているということが証明されます。

selectorは鍵の名前と考えれば良いかと思います。DKIMでは、異なるサーバーから送信する場合など、同じドメインに対して複数の鍵を使うことが多いので、鍵に名前をつけて管理できるようになっています。

このことから分かるのは、SPFはDNSに記載があると強制的に検証されますが、DKIMの場合は、あくまで送信されたメールに署名が付与されている場合のみ検証されるということです。SPFとDKIMは大きく違います。


「誰が署名するのか」ということですが、基本的にはFromアドレスの持ち主が署名するのが最も効果的な方法です。Envelope Fromなどが署名しても良いと思いますが、Envelope FromはSPFで検証できますので、DKIMではFromのドメインで署名する方がベターでしょう。

「検証した結果どうするのか」ということですが、いまのところは目立つ効果はあまりありません。DMARCと組み合わせてFromアドレス偽装を完全に防いだり、Fromアドレスを証明することで迷惑メールと認定されにくくしたり、そういった効果が期待されます。

最近はgmailを始め、各社のメールサーバーが迷惑メール認定を極めて厳しくしていますので、こうした手法を取り入れて迷惑メール認定を防ぐことはビジネス上、重要だと思います。

DKIMを付与するだけで、メールの送信に計算量がかかるようになるので、単純な大量送信迷惑メールとは一線を画することができます。


さて、DKIMの具体的な導入方法ですが、以下の通りです。

自分でRSA鍵ペアを生成する場合は、opensslを使って以下のようなコマンドで生成します。

openssl genrsa -out rsa.private 1024
openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM

ここで注意する点は、鍵長を1024bitにすることです。2048bitにするとDNSの1レコードに収まらなくなり互換性の問題を生じます。512bitは短すぎて受信者に検証拒否されます。

gmailのようなメールサーバーでは、鍵ペアを生成する機能を持っていますので、それを使って下さい。

DNSでは、(selector)._domainkeys.(domain)という形式のドメインに対して、以下のようなレコードを追加します。

v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB

署名したり署名を検証する方法については、メールサーバーやライブラリによりますので、それらの製品のマニュアルを参照して下さい。gmailなどは容易にDKIM対応が可能です。


DKIMについてより詳しく知りたい場合は、残念ながらRFCを読むしかないかと思います。

http://tools.ietf.org/html/rfc6376

2014年5月12日月曜日

真の人月商売こそが受託開発産業を救う ― 請負契約ではITプロジェクトは失敗する

私は自分では受託開発を原則として請けないことにしていますし、受託開発という産業にはあまり興味がありません。しかし現実問題として日本のソフトウェアビジネスの大半は受託開発産業です。

また自分では受託開発を請けないけれど、他人や他社にプログラミングを外注することはあります。今日は、受託開発のお話です。


受託開発産業でよく言われることに「人月商売からの脱却」などというフレーズがありますが、そうした発言はまさに愚の骨頂と思います。経済やビジネスの原理原則を知らない愚かきわまりない発言です。

受託開発というのは、プログラマーという専門職の時間を使って作業を提供して、その成果物を納品する仕事なのですから、コストは当然プログラマーの作業時間となります。

商品の値段というのは、通常はコストに利益を乗せて売られますから、プログラマーがどれだけ働いたかで算出されるのは、きわめて自然な値付け方式です。

「そうではなく、そのシステムが顧客にどれだけ価値をもたらすかで売りたい」という人がいますが、顧客の注文で作るシステムなのですから、その価値は顧客しか知りませんし、その顧客の価値を開発者が得られる理由がありません。

もしソフトウェアの価値でお金を取りたいのであれば、受託開発をやめて、自分で製品を作るべきです。もしくは受託開発で作ったものを、他社にパッケージ販売すればいいでしょう。そうしてみればソフトウェアの価値は良く分かります。

マッキンゼーなどの戦略コンサルタントから、建設業界まで、顧客の注文に応じてサービスを提供する企業では、基本的には労賃+材料費といった計算方法で価格を決めています。

その人月単価をいくらにできるのかは、プログラマーの能力と、企業のブランド力や交渉力/営業力次第でしょう。人月だからといって、プログラマが一律に同じ値段でなければいけない理由がありません。


日本の受託開発産業を悪くしているのは、人月計算ではなく、請負契約などによって受託企業に成果物への責任を負わせる契約慣行です。

あらかじめ完成品の総額を決めて、それから開発にかかるという方式の請負契約は、ソフトウェアのように細かい仕様が全て先に決まらない業界には全く適していない方式です。ソフトウェアの開発は、製造や工事よりも研究開発に近い性質のものであり、見積もりを前もって正確に行うのは極めて困難です。

そうして請負契約でプロジェクトが開始されれば、始まるのはお決まりのパターンです。

発注者は可能な限り多くの仕様を詰め込もうとし、様々な点で修正を求めてきます。それにたいして受注者は、リスク分を見積もりに大幅に上乗せし、仕様をなるべく簡略化しようとし、変更を拒否することを試み、なるべく安いプログラマを使って最小のコストで最低限動くものを仕上げようとします。

これはまさにlose-loseの状況です。

こうした契約形態のせいで、予算超過リスクを負える大企業がシステムを受注し、それを多重下請け形態で、プログラマのスキルとは無関係に、ただ大量の人を集めて、低い品質のシステムをでっちあげるという歪んだ産業構造が生まれました。

請負契約は、あらかじめ仕様を細部まで詰め切れるプロジェクトにしか適用できません。

数十万円の超小規模案件ならそれでも良いでしょうが、大きなプロジェクトになると、仕様策定自体が一大プロジェクトになってしまい、ウォーターフォールで多くの仕様の誤りが生じるので無駄過ぎますね。ルールの厳格な政府調達ならともかく、民間企業がそんな無駄をする理由はありません。


ソフトウェア開発というのは、建設業よりもコンサルティング業に近い産業です。

あらかじめ仕様と設計を細部まで定義して、それにもとづいて見積もりを立てるウォーターフォール方式が良い方法ではない以上、成果を約束させるのではなく、拘束時間に基づいてお金を払うしかありません。準委任契約/派遣契約などに切り替えるということです。

その場合、請負契約のように総額の予算や納期が契約で決まっているわけではありませんし、プロジェクトマネジメントは発注側で行い、発注側が予算や納期について責任を負うことになります。もし発注側にプロマネを出来る人がいなければ、ITコンサルタントなどを雇わなければなりません。

しかし、それにより、発注者と受注者は同じゴールに向かって歩むことが可能になります。「良いソフトウェアを作る」という共同のゴールを持つことができるようになります。

日本でも、いまどきのインターネット企業などでは、請負契約で業者にシステムを作らせているところはないでしょう。そんな方式では、開発速度も遅く、品質も下がってしまうので、競争を勝ち残れません。

一般企業にとってもITの重要性が増す中で、良いソフトウェアを作るためにソフトウェア内製化などに切り替える企業が増えているといった話もあるようです。


発注者側にとって、時間払いの新方式に切り替えるのは、そこまで難しい話ではありません。プロマネをしてくれるITコンサルタント企業さえ見つかれば、実現できるでしょう。

この新方式では総額が決まっていないので発注者にとって余分なリスクがあるようにも思われますが、実際は逆です。

できてもいないシステムの総額にたいして請負契約を結べば、受注者がへぼい仕事をしても途中でキャンセルすることもできず、結局はお金を払ったのにへぼいシステムしかできないというリスクが大きいのです。

それに対して、時間払い方式であれば、品質に満足できなければ合理的な予告期間のあとでいつでも契約を終了することができるでしょう。これはリスクを減らす方向に働きます。

とくに最近はシステムが完成しなくても、どんどん出来たところから動かしてみて、品質を顧客がチェックしていくことができるので、よりこうした方法は実現しやすくなりました。


受注側がこの方式に切り替えるためには、顧客側にも変化を要求することになるので、もっとハードルが高いです。

しかし株式会社ソニックガーデンのように、顧客にこうした方式を要求して、実践している会社もあります。

報われない、疲弊するといった悩みを抱えている受託開発企業は、契約形態を見直して、本当に顧客のためになる仕事をできるように変えていくしかないのではないでしょうか。

人月からの脱却ではなく、真の人月として、働いた時間に応じてお金をもらう、それがプロフェッショナルの働き方だと思います。ワインバーグは「コンサルタントの秘密」で何十年も前にそれを述べています。

では。