検索
連載

Sender ID:受信者側の設定作業送信ドメイン認証技術解説(1/3 ページ)

Share
Tweet
LINE
Hatena

 前回は送信側でのSender IDの設定を説明した。Sender IDのようなIPアドレスベースの認証方式においては、送信側はDNSへのSPFレコードの公開だけで運用が開始できるので作業は比較的簡単だといえる。

 一方、受信側での作業は少し手間がかかる。実際にSPFレコードを読み出し、送信元サーバのIPアドレスを検査するプログラムを追加する必要があるのだ。今回は受信側での設定について説明する。

Sender IDの受信側での処理

 Sender IDの受信側では、認証するときに受信する、あるいはしつつある「送信ドメイン」を特定する。送信ドメインとは、Classic SPFであればSMTP通信のMAIL FROM:コマンドの引数に与えられるアドレスのドメイン部分であり、Sender IDではFrom:やSender:、Resent-From:やResent-Senderなどのメールヘッダに指定されているメールアドレスPRA(Purported Responsible Address)のドメイン部分である。

 送信ドメインを特定したら、DNSを使ってその送信ドメインのTXT(SPF)レコードを取得する。送信元のサーバのIPアドレスが取得したSPFレコードに記述されている条件にマッチするかチェックし、マッチしていれば認証成功である。

 送信元のIPアドレスの検査は受信側で行う。つまり、検査するプログラムを送信元サーバのIPアドレスが取得できる場所に配置する必要がある。一般には、ネットワークの外部から送られてくるメールを最初に受信する最も外側のMTAで実施する(図1)。

図1 サイトの構成例
図1 サイトの構成例

認証結果の種類

 RFCには認証処理の結果として次のものが挙げられている。これはSender IDとClassic SPFで共通である。

None SPFレコードが公開されていない
Neutral SPFレコードが「?」として公開されている条件にマッチした
Pass 認証処理に成功した
Fail SPFレコードが公開されているが、認証に失敗した
SoftFail SPFレコードが「~」として公開されている条件にマッチした
TempError 一時的な障害で認証処理が失敗した
PermError SPFレコードの記述に誤りがあるなどで認証処理に失敗した

●None

 SPFレコードが公開されていないため、認証できなかったことを示す。送信ドメイン認証では送信元についての評価が下せないため、従来どおりスパムフィルタを通すなどしてメールの扱いを決定する。結果がNoneだった場合には、メールを即座に受信拒否すべきではない。

●Neutral

 送信ドメインのSPFレコードが、例えば「v=spf1 ?all」のように定義されている場合、あるいは「v=spf1 +ip4:xxx.xxx.xxx.xxx ?all」のようにレコードの末尾が「?all」と定義されていて、先立つほかの条件にマッチせず「?all」にマッチした場合、Neutralとなる。

 RFCには、NeutralはNoneと同じように扱うべきであるとされている。また、SoftFailよりは正当性が高いものとして扱う可能性があるとも説明されている。結果がNeutralだった場合には、メールを即座に受信拒否すべきではない。

●Pass

 送信元のIPアドレスがSPFレコードにマッチし、認証に成功した場合である。送信ドメインは正当であるので、あとはその送信ドメインの評価に従ってメールを処理する。

●Fail

 SPFレコードが公開されているが、送信元のIPアドレスが「-」クオリファイヤの条件にマッチする場合である。「?all」や「~all」が末尾に設定されているSPFレコードを持つ送信ドメインのメールに対してはこの結果は発生しない。なお、RFCでは「all」の記述が省略されたSPFレコードに対して、どの条件にもマッチしない場合はNeutralになるとされている。

●SoftFail

 SPFレコードが公開されており、送信元のIPアドレスが「~」クオリファイヤの条件にマッチする場合である。RFCではFailとNeutralの中間位の扱いをすべきであるとされている。結果がSoftFailである場合には、メールを即座に受信拒否すべきではない。

●TempError

 一時的な障害で認証処理が失敗した場合である。対応としてはメールを一時エラー(4XX)で受信拒否するか、そのまま受信することになる。受信した場合は、少し厳しく扱うべきである。

●PermError

 SPFレコードは公開されているが、SPFレコードの記述に誤りがある場合などにPermErrorとなる。この結果であっても永続的な受信拒否をすべきではない。

Index

Sender ID:受信者側の設定作業

Page1

Sender IDの受信側での処理

認証結果の種類


Page2

チェック結果の扱い

-ホワイトリストとブラックリスト

-レピュテーション(Reputation)システム

sid-milterを使って受信側システムを構築する


Page3

認証結果ヘッダの付与と認証結果の利用法


Copyright © ITmedia, Inc. All Rights Reserved.

       | 次のページへ

Security & Trust 記事ランキング

ページトップに戻る