お薦め ページ

メニュー

ハワイ島 遊覧飛行ツアー

ハワイ島 Ｂ＆Ｂ・ホテル

ハワイ島 不動産情報

ハワイ島 情報・観光ガイド

ブログ(Blog)

その他

関連サイト

: 日付別 アーカイブ :

2007年8月12日 - 2007年8月18日

« 2007年8月 5日 - 2007年8月11日 メイン 2007年8月19日 - 2007年8月25日 »

2007年8月18日

Gmail をつかった SPFの実態調査

「 SFP:Sender Policy Framework（センダー・ポリシー・フレームワーク）」が 実際にメールが受信される再にどのように評価されているのかを Gmailを例にとって検証してみる。

Gmailには「ヘッダー情報を表示」というオプションがあり、 それを選択すると、受け取ったそれぞれのメールのヘッダー情報をみることができる。

まず、SFPレコードを全く指定していないメール・サーバーから送られてきている例としては、 
Received-SPF: neutral (google.com: 205.178.146.61 is neither permitted nor denied by best guess record for domain of xxx@xxx.com) client-ip=205.178.146.61;
Authentication-Results: mx.google.com; spf=neutral (google.com: 205.178.146.61 is neither permitted nor denied by best guess record for domain of xxx@xxx.com) smtp.mail=xxx@xxx.com
という２行がメールのヘッダー情報内に見つかる。 「xxx@xxx.com」の部分が 送信者の用メール・アドレス。 SPFの評価の結果として「 neutral 」となっている。

一方、SFPレコードが適切に設定されているメール・サーバーから送られてきている例としては、 
Received-SPF: pass (google.com: domain of xxx@xxx.com designates 76.96.62.40 as permitted sender) client-ip=76.96.62.40;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of xxx@xxx.com designates 76.96.62.40 as permitted sender) smtp.mail=xxx@xxx.com
のような２行となり、 SPFの評価の結果が「 pass 」となっている。

その他の場合として、結果が「 softfail 」となる場合もある。

このように、Gmailはアカウントも作りやすいので、 SFPレコードに関するテストを行いたい場合には、 gmailのアカウント作り、そのアカウントへメールを出してみて メールのヘッダー情報を見てみることにより、確認することができる。

カテゴリー: Mail     22:35 | コメント (0) | トラックバック (0)

2007年8月17日

SPFレコードの nslookup コマンドによる調査方法

SPFレコード は DNSのテーブルに TXTレコード として記述することになっている。 そのため、その内容を確認するには、 昨日のブログで紹介した、 マイクロソフト(Microsoft)の 「Sender ID Framework SPF Record Wizard」 などを利用しなくても、「nslookup」や「dig」、「host」と いった DNSを調査するコマンドを利用することによっても調査することができる。

DNS関連の 情報を調査するコマンド「nslookup」は FreeBSD や Linux では もちろん、Windows XP でも利用できるコマンドだ。 では例として、昨日のブログでも調査した 「 comcast.net 」を調査してみる。 まずは、FreeBSD上から 
% nslookup
> set type=TXT
> comcast.net
Server:         68.87.76.178
Address:        68.87.76.178#53

Non-authoritative answer:
comcast.net     text = "v=spf1 ip4:76.96.28.0/23 ip4:76.96.30.0/24 ip4:76.96.60.0/23 ip4:76.96.62.0/24 ?all"
と、このように、当たり前だが 昨日のブログと同じ内容が表示される。 用は、「set type=TXT」と、タイプを「TXT」型にするだけ。

同じことを「 dig 」コマンドを使って行ってみると、 
% dig -t TXT comcast.net

; <<>> DiG 9.3.4-P1 <<>> -t TXT comcast.net
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33987
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;comcast.net.                   IN      TXT

;; ANSWER SECTION:
comcast.net.            300     IN      TXT     "v=spf1 ip4:76.96.28.0/23 ip4:76.96.30.0/24 ip4:76.96.60.0/23 ip4:76.96.62.0/24 ?all"

;; Query time: 62 msec
;; SERVER: 68.87.76.178#53(68.87.76.178)
;; WHEN: Fri Aug  8 13:13:53 2007
;; MSG SIZE  rcvd: 125
となる。 残念ながら、Windows XP には「 dig 」コマンドは付属していないようだ。

同様に「 host 」コマンドからでも情報を得ることができる。 
% host -t TXT comcast.net
comcast.net descriptive text "v=spf1 ip4:76.96.28.0/23 ip4:76.96.30.0/24 ip4:76.96.60.0/23 ip4:76.96.62.0/24 ?all"


【参考リンク】

カテゴリー: Mail     22:00 | コメント (0) | トラックバック (0)

2007年8月16日

「SPF」および「Sender ID」の SPFレコード実例

最近このブログで話題にしている SPFレコードを 新たに作成する前に、 昨日のブログでふれた、マイクロソフトの 「Sender ID Framework SPF Record Wizard」 をつかって、実際のSPFレコードの記述例をみてみる。

このウィザード・ページの Step 1 では、現実のドメイン名を入力すると、 その ドメインの 現在の SPFレコード の内容を表示してくれる。 まず、「Sender ID」の推進役の「 microsoft.com 」は、 
v=spf1 mx include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.microsoft.com ~all
となっている。 チョットだけ解説すると、 「 v=spf1 」というのがバージョンを示している。 そして、「mx」が microsoft.com のMXレコードに登録されている IP を参照すること。 さらに「 include: 」が その後に続けて記述されている ホストを参照する、ということ。 そこで、「 include: 」されている例として「 _spf-a.microsoft.com 」は、 
v=spf1 ip4:216.99.5.67 ip4:216.99.5.68 ip4:202.177.148.100 ip4:203.122.32.250 ip4:202.177.148.110 ip4:213.199.128.139 ip4:213.199.128.145 ip4:207.46.50.72 ip4:207.46.50.82 a:delivery.pens.microsoft.com a:mh.microsoft.m0.net ~all
となっており、ここの「 ip4: 」は直接 IPアドレスを示しており、 「 a: 」は、これに続けて記述されているホストの「Aレコード」（IPアドレス）を参照することを意味している。

では次に「 google.com 」は、 
v=spf1 include:_netblocks.google.com ~all
それから、「 gmail.com 」は、 
v=spf1 redirect=_spf.google.com
となっており、「 redirect= 」というモディファイヤが記述され、 全てを「 _spf.google.com 」に任せるということだ。 ここでの注意点は、 最後に 「~all」とか「?all」とかが付いていないこと。 では、そのリダイレクト先の「 _spf.google.com 」は、 
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ?all
となっており、「 ip4: 」が列挙されている。

それでは私も使っている「 comcast.net 」は、 
v=spf1 ip4:76.96.28.0/23 ip4:76.96.30.0/24 ip4:76.96.60.0/23 ip4:76.96.62.0/24 ?all
となっている。

日本の「 yahoo.co.jp 」は、 
v=spf1 include:spf01.yahoo.co.jp include:spf02.yahoo.co.jp ~all
となっていて、「include:」している。 その例として「 spf01.yahoo.co.jp 」は、 
v=spf1 ip4:124.83.147.0/24 ip4:124.83.153.0/24 ip4:124.83.155.0/24 ip4:124.83.165.0/24 ip4:124.83.168.0/24 ip4:124.83.170.0/24 ip4:124.83.178.0/23 ip4:124.83.181.0/24 ip4:124.83.195.0/24 ip4:124.83.200.0/24 ip4:124.83.212.0/24 ip4:202.93.80.0/23 ip4:202.93.83.0/24 ip4:202.93.84.0/23 ip4:202.93.86.0/24 ip4:202.93.88.0/24 ip4:202.93.90.0/24 ip4:203.141.34.0/24 ip4:210.80.241.0/24 ip4:211.14.23.0/24 ~all
と、なっており、たくさんの 「 ip4: 」が定義されている。 ちなみに、日本のヤフー「 yahoo.co.jp 」には このようにSPFレコードが定義されているが、 米国ヤフーの「 yahoo.com 」には、SPFレコードが定義されていない。

【参考リンク】

カテゴリー: Mail     22:51 | コメント (0) | トラックバック (0)

2007年8月15日

Sender ID とは

昨日のブログでもふれた 送信ドメイン認証技術である「 SPF 」と深い関わりのある技術に 「 Sender ID 」という技術がある。 これは、マイクロソフト(Microsoft)が提唱していた技術 「Caller ID for E-Mail」と SPF とを統合した技術だ。

ただし、「 Sender ID 」については マイクロソフトが特許を持っている部分があり、 そのライセンスについて業界では大きな議論を呼んでいた。 しかし マイクロソフトは その後 多くの批判にあい、 その結果、Sender ID のライセンスに対しては、 料金 または その他の特許使用料を要求しないことを明確にすることによって、 現在のところ問題は解決されたようだ。

現在では、マイクロソフトは 「Sender ID ホームページ」 というサイトで、「 Sender ID 」の普及に努めている。 ここには、「 Sender ID 」に関する詳しい説明や関連ドキュメントに加えて、 英語ではあるが、 「Sender ID Framework SPF Record Wizard」 というウィザード・ページがあり、そこで、ウィザードに答えるだけで SPFレコードの作成が自動的にできてしまう。

また、具体的なSPFレコードの記述方法や公開方法、また、 オリジナルの「SPF」と「Sender ID」の違いなどについては、 ＠IT の 「Sender ID：送信者側の設定作業」 ページに詳しく解説されている。

【参考リンク】

カテゴリー: Mail     22:09 | コメント (0) | トラックバック (0)

2007年8月14日

SPF (Sender Policy Framework) とは

「 SFP:Sender Policy Framework（センダー・ポリシー・フレームワーク）」とは、 メールの送信元アドレスの偽装を防止する技術のひとつで、 SMTPによるインターネットのメール配送を拡張し、 送信ドメインを認証する技術である。

Pobox.com社の創設者Meng Wong氏が提唱した方式だそうで、 無差別に大量に送られる広告メール(SPAMメール)の 抑止につながるとして期待されている。

e-Wordsの「SPF」ページから SPFの説明を引用させていただくと、
あるドメインのメールを送信することができる正規のサーバのIPアドレスをリストして管理する。 そのドメインと無関係なメールサーバを利用して送信元を偽ったメールを送信しようとすると、 受信側でそのことを検出して自動的に受け取りを拒否することができる。 これにより、SPAM業者が 大手プロバイダなどの有名なドメイン名を含むメールアドレスを利用することを防ぐことができるようになる。 ただし、多くの企業やプロバイダが参加しなければ効果が上がらず、 また、SPAM業者が自前ドメインのメールを送信することは防げない。 受け取りを拒否するドメインのブラックリストを用意するなど、別の対策を併用する必要がある。
となっている。 具体的には、上記の 「メールを送信することができる正規のサーバのIPアドレスをリスト」 するのは、DNSのTXTレコードを用いている。

また、マイクロソフト(Microsoft)が提唱していた技術 「Caller ID for E-Mail」と このSPF とを統合した 「Sender ID」という技術と深い関わりがある。

【参考リンク】

カテゴリー: Mail     22:22 | コメント (0) | トラックバック (0)

2007年8月13日

OP25B(Outbound Port 25 Blocking) とは

スパム・メール や ウイルス・メール が 問題となりだしてから久しいが、 この対策の一環として、ISP（インターネット・サービス・プロバイダ）の中には 「 OP25B(Outbound Port 25 Blocking) 」と言う対策をとっているところがある。

メールの送信には 通常TCPの25番ポートが利用されているが、 ISPの会員ユーザーが、外部のメールサーバーを利用して スパム・メールやウイルス・メールを送信することを防止するために、 25番ポートと外部との通信をブロックしてしまうことを 「 OP25B(Outbound Port 25 Blocking) 」と言っている。

自分が加入しているプロバイダーが この OP25B を行っている場合、 通常そのプロバイダーが提供しているメールサーバーを利用しているかぎり問題は起きないが、 どうしてもそのプロバイダーが提供しているメールサーバーではない 外部のメールサーバーを利用しなければならない場合には、 その外部のメールサーバーが 「サブミッション・ポート」と呼ばれる 25番以外の受信してくれるポートを準備している必要がある。 また、メールを送信する側のソフトウェアの方も、 それに対応した設定を行う必要がある。 通常、サブミッション・ポートは587番になっている。

【参考リンク】

カテゴリー: Mail     22:29 | コメント (0) | トラックバック (0)

2007年8月12日

唯川恵「5年後、幸せになる」

昨日のブログが「1年後の君へ」であったが、 こちらは、 「5年後、幸せになる」。 唯川恵（ゆいかわ けい）氏のエッセー。

この本は、女性誌「モニク(Monique)」に 1996年9月から1997年8月号に 連載されていた記事に加筆・編集したモノ。 銀行勤務の10年にもおよぶOL体験をもつ唯川恵氏が 自分の体験談・失敗談を基に現在のOLに向けた、 タイトルのとおり、幸せになるためのメッセージ。

本の構成としては、内容が３つのセクションに分かれている。 そして、それぞれのセクションの始まりの裏ページに 短いコメントが小さな文字で書き記されている。 そのコメントをみると、著者がそのセクションで訴えたいことが 垣間見られると思うのでそこの部分だけ引用させていただくと、

第１セクション(p12)
若い頃、私は男の人にこう言われるのが夢でした。
「結婚したら、君を幸せにするよ」
それを言われると、
これで間違いないんだ、私は必ず幸せになれるんだ、と
確信した気持ちでいられたのです。
でも、今はそんなことを考えていた自分が恥ずかしい。
誰かから貰う幸せなんて、
どんな価値があるというのでしょう。


第２セクション(p70)
顔は変わります。
本当です。顔は作られていくものなのです。
これを読んでいるみなさんはまだ若いし、
いろいろ美醜で悩むこともあるかもしれません。
でも、人生は長いのです。
何年後、いえ何十年後、
女の勝負は目先のことだけではなく一生かけてつけるのです。


第３セクション(p128)
損をする、というのは
人生にとって大切なことです。
その中にいろいろな真実が隠されているのです。
たとえ損をしても、
好きという思いがあれば決して後悔しません。
その感情こそが、必ず自分を幸福にしてくれるのです。


このように、３つのセクションの巻頭コメントを挙げさせていただいたが、 この本全体のコンセプトとしては、 第１セクションのコメントにあるように、 幸せは誰かから貰うものではなくて、 自分自身で行動して、自分自身で感じるもの、 というような気がする。

ウィキペディアによると、 この「5年後、幸せになる」 を出版した1997年の５年後の 2002年に『肩ごしの恋人』で第126回直木賞を受賞した、とある。 確かに、５年後には、唯川恵氏自身、作家として幸せになっているわけだ。

【参考リンク】

カテゴリー: 本・書籍     22:16 | コメント (0) | トラックバック (0)

« 2007年8月 5日 - 2007年8月11日 メイン 2007年8月19日 - 2007年8月25日 »
 
ハワイ島での遊覧飛行ツアーとＢ＆Ｂのスペシャリスト、スカイメリカ
Copyright © 2003,2009 Skymerica Corp. All rights reserved.