title_parttitle_parttitle_part
静岡県浜松市であれこれソフトを開発している A.K.I Software のブログです。日々の開発日記やサーバー・セキュリティ関連の話題なども掲載。
<< 2024/04 >>123456789101112131415161718192021222324252627282930
《《《 ネットワーク機器の購入は Amazon で! 》》》
Powered by BLOM Version 2.02a Memo その3 と Microsoft OSP (Open Specification Promise)
小さくも大きくも閉じたりもしません
11/11/17 16:21 / PMailServer2

今回は Memo が多いのですが、Version 2.02a で SPF Classic に加えて Sender ID に正式対応します。
ついでに SPF にも少し変更を加えています。

まず結論として「Sender ID に関して安心して実装及び利用できるという確信を得たので、対応します。」

以降はややこしい説明になりますので、読み飛ばしても結構ですが、ソフトウェア開発には対応したくても色々な事情がありますよ。的な読み物にもなります。

まず、SPF Classic と Sender ID について少しご説明を。

PMail Server に現在搭載されている SPF は SPF Classic と呼ばれる古い形式のみです。
これは、SMTP プロトコル中で指定される MAIL FROM: で指定されたメールアドレスに対して、DNS の TXT レコードに登録されている SPF 情報から送信者が正しいとされているサーバーから送信されているか否かを判断します。

ここまでが SPF Classic です。

Sender ID は、SPF Claasic に加えてメールのヘッダ(エンベローブ)内で指定されている From: 等の項目に対してもチェックを行います。(PRA方式)

さて、ここで今まで対応してこなかった理由が1つ出てきます。

メールのヘッダ中の情報を使って対応する。これは、Purported Responsible Address (PRA) 方式といい、実は Microsoft 社が特許を持っています。
(Sender ID については Microsofot 社が提唱した規格で、この中に PRA 方式が含まれている。DNS を使った認証については、SPF Classic も Sender ID も同じ仕組み(メカニズム)を採用している)

PRA 方式では、
1) Resent-sender:
2) Resent-from:
3) Sender:
4: From:
の順番で評価を行います。

実際には 1,2 に関してはなんぼでも偽装が可能なのでチェックは行いません。(するかもしれませんが)
Sender: に関しては PMail Server で Sender: を追加する項目がありますが、これは SMTPプロトコル中の MAIL FROM: の内容をセットされているのですが、それは元々 MAIL FROM: の時点でチェックを行いますので PRA ではチェックをしません。(プロトコル中で行うので、メールを受信する時点で拒否できた方が効率が良い為)
結果としてヘッダ中の From: のみをチェックすることになります。

閑話休題。

特許の話に戻りますが、Sender ID が提唱された当時(2006〜2007年頃?)、PRA 方式は Microsoft 社が特許を保持しており、これを利用するにあたって「Microsoft 社とライセンス料は掛かりませんが、書面でライセンスを交わす必要がありました」
(提唱当時にライセンスを交わす必要がある条件が広範囲に渡っていたり、RFC化するにあたって、一悶着あったのですが)

Sender ID に対応するには、ライセンスを結ばなくてはならず、A.K.I Software がライセンスを結ぶだけであれば良いのですが、利用者もライセンスを結ぶ必要があるようにも解釈できたので、それならば Sender ID には対応せず、SPF Classic のみで行こうということになりました。

(ユーザー様も実装されていれば使うのが普通ですが特許ですので、ライセンスを結ぶ必要があったことを知らなかったでは通じません。万が一でも迷惑かける訳にはいかない、と警戒していた訳です)

これがずっと SPF Classic のみで Sender ID には対応してこなかった理由です。SPF と省略せず SPF Claasic としていたのもこれが理由です。

時は流れて 2011年。
PMail Server のユーザー様からこの PRA 形式についてお問い合わせを頂きました。
で、上記のような理由があり対応が難しい旨をお伝えした所、Microsoft Open Specification Promise を教えて頂いた訳です。

この、Microsoft Open Specification Promise ですがどんなものかと言うと・・・
下記の URL をご参照ください。
http://www.microsoft.com/ja-jp/mic/interop/standards/osp/default.aspx

意訳すると

1)このリストにある物については、Microsoft 社は特許請求は行いません。(特許料を取らない)

2)1の約束は将来に渡って覆しません。

3)このリストにある特許に関して、特許の侵害だ!と Microsoft に訴訟を起こさない限り有効です。(行った場合は対抗措置を取る。とも言えます。私はしませんが)

とこんな感じです。
そして、リストのセキュリティの項目を見ますと、Sender ID もリストに含まれています。(他にも様々な特許をオープンにしていることがわかります。Office形式なんかも入っていますね。仮想化の VHD 形式なんかも入っています)

んで、更に読んでみて、私なりに解釈した結果

1)Microsoft OSP の中のリストの中に SenderID で「E-Mail を使った認証」及び「ヘッダ中にある Mail From: を使った認証(PRA)」があるので Sender ID は MS OSP の対象である。

2)特許について懸念していた点については、1のリストに含まれるのでサブマリン特許のような問題は存在しない。

3)ライセンスの問題については、その仕様に含まれる条件を満たす必要はあるが(これは例えば著作権表記等)利用にあたって Microsoft に署名や通知等は基本的に行う必要は無い。(OSP 全般の FAQ 2項目目)

4)OSP においてサブライセンスは存在しないので、エンドユーザーが利用しても、書面等において Microsoft に通知する必要は無い。(それ以前に3により、署名や通知等を行う必要はない)

と解釈することができました。

前置きが長いのですが、結果として「今、現在 Sender ID を実装しても、A.K.I Software に特許についての問題は発生しない。また書面等によるライセンスを結ばなくとも大丈夫である。これはエンドユーザーである PMail Server のユーザー様にも適用される。もちろん無償で利用することができ、これは将来に渡っても約束される」と懸念していた事項が全て解決していることを意味します。

もちろん、法律的な解釈や公式な回答ではありませんので、公式な回答が必要になるならば、Microsoft 社本社に問い合わせる必要があると思いますが、内容からして「特許使うなら金払え」的な内容ではなく、Microsoft社が他から特許侵害の訴えを起こされた場合に対する対抗策の為、また特許による技術進歩が妨げられないようにする為の対策であると見えます。(Unisys社のGIF 圧縮形式のライセンス問題を覚えている方も多いと思います。)

ということで、懸念していたことも全て解決したと見なし、Sender ID に正式に対応することになりました。


しかし、このような文書があるとは・・・
もっと早く知っていれば、もっと早く対応できたのにな〜

[更新日付:2011/11/17 16:21:55]
トラックバックを見る(0)
Log Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+sl+befc21f404fbcdd4029b88f4297f1140948ee1ea]
TB Link [https://akisoftware.com/cgi-bin/blom.exe?akisoft+tb+befc21f404fbcdd4029b88f4297f1140948ee1ea]

記事へのコメント

コメントはありません

名前
コメントキー
 
コメントする時はキーを正確に入力して下さい
コメント
アドレスを含んだコメントはできません
© 2008-10 A.K.I Software all rights reserved.