Sender ID 認証が導入されている場合のメールの流れ

  1. 送信者が相手にメールを送信する
  2. 相手のメールサーバにメールが到達する
  3. 相手のメールサーバで、メッセージの送信元のドメイン情報(DNS)をしらべ、SPR レコードの有無をチェック。また、電子メールの IP アドレスが SPF レコードに公開されている IP アドレスのいずれかと一致するかどうかチェック。
  4. IP アドレスが一致している場合=認証されたとしてメールが配信。IP アドレスが一致しなかった場合は認証に失敗=メールは破棄。

Sender ID の導入

1.SPF レコードの作成

1-1. 自ドメインの認証(Identify Your Domain)

 Sender ID Tool 画面の右下にあるフォームにドメイン名を入れて【 Start > 】(開始)を押します。

senderid1.gif

1-2. SPF レコード作成ウィザード(SPF Record Wizard)

 次の画面では現在の DNS 情報が表示されます。 The wizard has checked DNS for information about pocketstudio.jp including: SPF, MX and A records. This information is displayed below.

ウィザードは pocketstudio.jp(設定対象ドメイン)の DNS 情報を確認しました。SPF には MX レコード・A レコードも含まれます。DNS 情報は以下に表示されます。

If an SPF record was found, you can verify its contents here and use the remaining steps of this wizard to modify the record if necessary. If no SPF record was found, you can use information from the domain's MX and A records to create a new SPF record.

もし SPF レコードが表示されている場合、既に登録手続きが済んでいるため改めて認証を行う必要はありません。
SPF レコードが無い場合には、設定したいドメインの MX と A レコードから新しい SPF レコードを作成します。

Click Next to continue.

続けるには【 Next 】をクリックしてください。

senderid2.gif

1-3. SPF レコード作成

 入力されるフォーム情報に従って SPF レコードが作成されています。ドメインによっては既に記入されている項目があるかもしれません。

  • Domain Not Used for Sending E-mail (ドメインでメール送信は行いません)
    senderid3.gif
    『 メール送信を行わないドメインの場合"No mail is sent from domain"にチェック 』を入れます。通常はメール送信を行うので、チェックを入れません。 Please check this option if this domain is not used for sending outbound e-mail. Domains which do not send out e-mail will have no outbound mail servers.
    このオプションは該当サーバから外部に向かってメール配信を行わない場合にチェックを入れてください。サーバ(ネットワーク)内部に配送されることはあっても、外部に一切配送されない場合に該当します。
  • Inbound Mail Servers Send Outbound Mail (外部へのメール送信)
    senderid4.gif
    通常のメールサーバは送信も行いますので、ここにチェックを入れます。加えて DNS 情報上の MX レコード(Mail Exchanger=メール配送サーバ)も表示されますので、ここもチェックです。ほかにもホスト名がある場合には、あわせてホスト名を登録します。
  • Outbound Mail Server Addresses (外部へのメール送信サーバ情報)
    senderid5.gif
    上から順に、DNS 上の A レコードを持つサーバからメールの送信があるかどうか、ドメイン名に割り当てる IP アドレスを指定するか(普通はチェックで良いみたいです)、次は他にも同ドメインを送信する可能性のあるサーバの IP アドレス、最後に、同サーバで用いる他のドメイン名の指定です。
  • Reverse DNS Lookup(逆引きホスト名)
    senderid6.gif
  • Outsourced Domain(メールサーバが扱う第三者ドメイン名)
    senderid7.gif
    メールの配送業務を委託している場合など、メールサーバから送信される可能性のある他のドメイン名を記述します。
  • Default(動作設定)
    senderid8.gif
    これまで上記で指定してきたメールサーバ情報をどのように扱うかの設定です。
    • Yes, もしかしたら違う IP からの送信があるかもしれません
    • No, 指定した IP からのみが正しいメールです
    • Neutral, 指定した IP かどうか何ともいえないので、設定を保留します
    • Discouraged, 上記の指定されていないホストからメールが送信される可能性があります(それじゃ、何のために設定したのか分からないよ……(汗)。
  • Scope(提要範囲)
    senderid9.gif

 一通り入力・確認が終わったら【 Next > 】(次へ)をクリックします。

1-4. SPF レコードの自動作成

 これまで入力・選択した内容に応じて SPF レコードが自動作成されます。
 私の pocketstudio.jp の場合は次のようになりました。

v=spf1 a mx ptr ip4:210.239.46.254 mx:sv.pocketstudio.jp ip4:210.128.158.225 a:pockets.to a:cyberteam.jp mx:pocketstudio.jp -all

 ページの注意書き(Instructions:)によると、SPF レコードは pocketstudio.jp ドメインの TXT タイプとして DNS レコードの定義が必要だそうです。

2. BIND(DNS)の設定

2-1. zone ファイルの変更

 今回設定対象としたドメイン名は『 pocketstudio.jp 』。このドメインに対して設定できた SPF レコードが前項の v=spf〜という行。

 BIND ではこの v=spf〜を TXT レコードとして保持しればいいようです。ということで、早速 pocketstudio.jp のゾーンファイルにテキスト・レコードの追加です。

 テキストレコードの追加は

IN TXT "v=spf〜"

 の記述で良いはずなので、

IN TXT "v=spf1 a mx ptr ip4:210.239.46.254 mx:sv.pocketstudio.jp ip4:210.128.158.225 a:pockets.to
a:cyberteam.jp mx:pocketstudio.jp -all"

 を MX レコードの下あたりに追加。

 最終的に BIND の ZONE 情報ファイルは以下のように。

$ cat pocketstudio.jp.zone
$TTL 86400
$ORIGIN pocketstudio.jp.
@               IN      SOA     sv.pocketstudio.jp. postmaster.pocketstudio.jp. (
                                20050628;Serial
                                60        ; Refresh 3 hours
                                3600      ; Retry   1 hour
                                1209600   ; Expire  1000 hours
                                86400 )   ; Minimum 24 hours
                IN      NS          sv.pocketstudio.jp.
                IN      NS          ns.at-link.ad.jp.
                IN      MX          10 sv.pocketstudio.jp.
                IN      TXT     "v=spf1 a mx ptr ip4:210.239.46.254  
mx:sv.pocketstudio.jp ip4:210.128.158.225 a:pockets.to a:cyberteam.jp 
mx:pocketstudio.jp -all"
pocketstudio.jp.        IN      A           210.239.46.254
sv              IN      A           210.239.46.254
                IN      MX          10 sv.pocketstudio.jp.
nsx.pocketstudio.jp.    IN A    210.128.158.225
                IN      MX      10 nsx.pocketstudio.jp.
ns              IN      CNAME   sv
ns1             IN      CNAME   sv
ftp             IN      CNAME   sv
mail            IN      CNAME   sv
www             IN      CNAME   sv

※TXT レコードの "〜" にかけては、実際には改行が入っていません

2-2. bind(named)再起動

 停止・再起動。(各ディストリビューションによって named 再起動の方法は異なります。これは Red Hat 系列の Vine の場合)

# /etc/rc.d/init.d/named stop
Shutting down named:                                       [  OK  ]
# /etc/rc.d/init.d/named start
Starting named:                                            [  OK  ]

2-3. dig コマンドで動作確認。

 dig コマンドを使って DNS 情報から TXT レコードを取得します。正常に表示されていれば、設定上の問題はありません。

$ dig pocketstudio.jp a txt +norec

; <<>> DiG 8.3 <<>> pocketstudio.jp a txt +norec
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41414
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUERY SECTION:
;;      pocketstudio.jp, type = TXT, class = IN

;; ANSWER SECTION:
pocketstudio.jp.        1D IN TXT       "v=spf1 a mx ptr ip4:210.239.46.254
mx:sv.pocketstudio.jp ip4:210.128.158.225 a:pockets.to a:cyberteam.jp
mx:pocketstudio.jp -all" 

;; AUTHORITY SECTION:
pocketstudio.jp.        1D IN NS        sv.pocketstudio.jp.
pocketstudio.jp.        1D IN NS        ns.at-link.ad.jp.

;; ADDITIONAL SECTION:
sv.pocketstudio.jp.     1D IN A         210.239.46.254
ns.at-link.ad.jp.       23h54m18s IN A  210.239.46.2 

;; Total query time: 1 msec
;; FROM: sv.pockets.to to SERVER: default -- 210.239.46.254
;; WHEN: Tue Jun 28 07:00:25 2005
;; MSG SIZE  sent: 33  rcvd: 251

3. 動作確認

 ここによると check-auth@verifier.port25.com にメールを送ると自動判定してくれるようなので、早速送ってみます。タイトル・本文ともに空白で送ってみました。

 暫く待つと……正しくチェックされたかどうかメールが届きます。

 以下は正常なメール【 pass 】ということは合格。

==========================================================
Summary of Results
==========================================================

mail-from check:  pass 
PRA check:  pass 
DomainKeys check:  neutral (message not signed)


==========================================================
Details:
==========================================================

HELO hostname:  pockets.to
Source IP:  210.239.46.254
mail-from:  zem@pocketstudio.jp
PRA Header:  from
PRA:  zem@pocketstudio.jp

 ちなみに、わざと指定されていないメールサーバからメールを送信すると、PRA check が fail (失敗)することが分かります。

==========================================================
Summary of Results
========================================================== 

mail-from check:  neutral 
PRA check:  fail (not permitted) 
DomainKeys check:  neutral (message not signed)

==========================================================
Details:
==========================================================

HELO hostname:  example.jp
Source IP:  xxx.xxx.xxx.xxx
mail-from:  zem@example.jp
PRA Header:  from
PRA:  zem@pocketstudio.jp

 もう1つ試してみました。From: 詐称テストです。しかも MTA は pocketstudio.jp の登録外のサーバから試すと、、

Hi. This is the qmail-send program at example.jp.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<auth-results@verifier.port25.com>:
Connected to xxx.xxx.xxx.xxx but sender was rejected.
Remote host said: 550 5.7.1 Sender-Id/SPF check failed: not permitted in
"MAIL FROM:<zem@pocketstudio.jp>"

 このように、Sender-ID が違うから受け取りを拒否するよ、という通知が戻ってきました。

結局 Sender ID ってどうよ?

  • Sender-ID をチェックする仕組みを MTA に組み込まないと、役に立たない
  • MTA 側の設定をしなくても、From: 詐称メールを防ぐ手だてとなる
  • MTA に Sender-ID をチェックする仕組みを組み込めばなおよし。

うわ。間違ってたらごめんなさい。

m(__)m 変なところがあればご指摘下さい。

  • ちょっとリソースが少ない状態で試してみたので、どこか変なところがあるかもしれません。忌憚なくご指摘ください! -- zem? 2005-06-28 06:11:03 (火)
  • Sender ID に関する情報サイトは少ないので大変役にたちました。「Discouraged, 上記の指定されていないホストからメールが送信される可能性があります(それじゃ、何のために設定したのか分からないよ……(汗)。」という部分についてなのですが、これは「このドメインからの正当なメールでも送信ドメイン認証が成功しない場合があるかもしれません」というような意味を持ちます。認証が万が一失敗しても受信拒否されないし、正規のメールの場合には相手のMTAがそのことを確認できるので意味はあると思います。詳しくはこちら http://www.atmarkit.co.jp/fsecurity/special/82senderid/sender104.html -- Kaid? 2006-07-16 11:27:25 (日)
  • いろいろ探していてここにたどり着きました。具体例と確認例があってとてもわかりやすく役に立ちました。 -- mere? 2007-08-16 13:03:16 (木)

##comment

情報元(リソース)

Sender ID Framework IT 専門家向け情報
http://www.microsoft.com/japan/mscorp/safety/technologies/senderid/technology.mspx
Sender ID リソース テクノロジに関するツールと情報
http://www.microsoft.com/japan/mscorp/safety/technologies/senderid/resources.mspx

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: Fri, 02 Nov 2007 13:50:01 JST (3129d)