2006年04月06日
携帯電話のふりをしたPCからのメールを拒否する方法
SPF (Sender Policy Framework) という、送信元アドレスの偽装を検出する仕組みがあります。
実は主要な携帯キャリアはSPFに対応しています。ドコモ、auは去年の12月に、WILLCOM、Vodafoneがつい先日の2006年3月に対応しました。
携帯電話のメールアドレスはドメインパートが決まっているので、
という判別をすれば、携帯電話からのメールのみを受け付けることができ、envelope fromを(携帯電話からのように)偽装したメールを排除することができます。具体的には、携帯電話からの空メールを受信する処理でこのような判別が有用なのではないかと思います。
実は主要な携帯キャリアはSPFに対応しています。ドコモ、auは去年の12月に、WILLCOM、Vodafoneがつい先日の2006年3月に対応しました。
- 報道発表資料 : 「なりすましメール」防止に向けた取り組みを推進 | お知らせ | NTTドコモ
- KDDI 会社情報: ニュースリリース > 送信ドメイン認証技術の導入開始について
- WILLCOM｜送信ドメイン認証サービスの開始について
- 迷惑メール対策を強化｜ボーダフォン
携帯電話のメールアドレスはドメインパートが決まっているので、
- 送信元メールアドレスのドメインパートが携帯電話のものかどうか。
- SPFチェック失敗していないかどうか。
という判別をすれば、携帯電話からのメールのみを受け付けることができ、envelope fromを(携帯電話からのように)偽装したメールを排除することができます。具体的には、携帯電話からの空メールを受信する処理でこのような判別が有用なのではないかと思います。
具体的にどういう判別ロジックを実装すればよいか、ということで、SPFパッチを当てたqmailの場合を考えてみたいと思います。
SPFパッチを当てたqmailをインストールしたら、
とします。これで、qmailがSPFの結果をReceived-SPFというヘッダに挿入してくれるようになります。（この設定値の場合はqmailのレイヤではSPFの結果がどうであれメールを拒否したりはしません）
これでメールアドレス(dot-qmail)毎にSPFのチェックができるようになりました。
次に、どうやって先に挙げた判別処理を実装するか考えてみます。
qmailでは、dot-qmailにコマンドを列挙した場合、コマンドの終了コードで後続のコマンドを処理するかどうかを制御することができます。
例えば、
とした場合、コマンドcheck-mobileがexit 0した場合は続いてcheck-spfが実行されますが、もしcheck-mobileがexit 99した場合は後続のcheck-spfとreceive-blank-emailは実行されません。
今回はこの挙動を利用して、「失敗」と判別した場合はexit 99する判別プログラムを2つ(携帯電話ドメインチェックとSPFチェック)考えてみたいと思います。
まずドメインパートが携帯電話のものかどうかを判別する実装を考えます。
qmailの場合、変数SENDERにenvelope fromが格納されているので、SENDERに対して携帯ドメインのパターンマッチングを行って、マッチした場合はexit0、しなかった場合はexit 99すればよいでしょう。それほど複雑ではないので、正規表現を持ち出すまでもなくshのcase文でも実装可能だと思います。
ただ、bounce mailの場合、SENDERは空もしくは『#@[]』になるので、SENDERがこれらの場合は例外処理をすべきでしょう。
続いてSPFチェックです。
SPFパッチを宛てたqmailで前述の設定をした場合、次の様なヘッダが追加されます。
「pass」や「fail」の部分には他に、「none」「unknown」「neutral」「softfail」が入る可能性があります。
なので、「fail」もしくは「softfail」の場合はアドレス偽装だとしてexit 99すればよいでしょう。
これでアドレスを偽装して携帯電話のふりをしたメールを排除することができるようになりました。
今回はdot-qmailにチェックプログラムを羅列する構成にしました。この構成のメリットは、既存のdot-qmailに僅か2行追加するだけでよく、導入コストがほとんどないという点です。
同様の問題で困っている方は是非、お試しください。(ひ)
SPFパッチを当てたqmailをインストールしたら、
# echo 1 > /var/qmail/control/spfbehavior
とします。これで、qmailがSPFの結果をReceived-SPFというヘッダに挿入してくれるようになります。（この設定値の場合はqmailのレイヤではSPFの結果がどうであれメールを拒否したりはしません）
これでメールアドレス(dot-qmail)毎にSPFのチェックができるようになりました。
次に、どうやって先に挙げた判別処理を実装するか考えてみます。
qmailでは、dot-qmailにコマンドを列挙した場合、コマンドの終了コードで後続のコマンドを処理するかどうかを制御することができます。
例えば、
| check-mobile
| check-spf
| receive-blank-email
とした場合、コマンドcheck-mobileがexit 0した場合は続いてcheck-spfが実行されますが、もしcheck-mobileがexit 99した場合は後続のcheck-spfとreceive-blank-emailは実行されません。
今回はこの挙動を利用して、「失敗」と判別した場合はexit 99する判別プログラムを2つ(携帯電話ドメインチェックとSPFチェック)考えてみたいと思います。
まずドメインパートが携帯電話のものかどうかを判別する実装を考えます。
qmailの場合、変数SENDERにenvelope fromが格納されているので、SENDERに対して携帯ドメインのパターンマッチングを行って、マッチした場合はexit0、しなかった場合はexit 99すればよいでしょう。それほど複雑ではないので、正規表現を持ち出すまでもなくshのcase文でも実装可能だと思います。
ただ、bounce mailの場合、SENDERは空もしくは『#@[]』になるので、SENDERがこれらの場合は例外処理をすべきでしょう。
続いてSPFチェックです。
SPFパッチを宛てたqmailで前述の設定をした場合、次の様なヘッダが追加されます。
Received-SPF: pass (klab.org: local policy designates AAA.BBB.CCC.DDD as permitted sender)
Received-SPF: fail (klab.org: SPF record at klab.org does not designate AAA.BBB.CCC.DDD as permitted sender)
「pass」や「fail」の部分には他に、「none」「unknown」「neutral」「softfail」が入る可能性があります。
なので、「fail」もしくは「softfail」の場合はアドレス偽装だとしてexit 99すればよいでしょう。
これでアドレスを偽装して携帯電話のふりをしたメールを排除することができるようになりました。
今回はdot-qmailにチェックプログラムを羅列する構成にしました。この構成のメリットは、既存のdot-qmailに僅か2行追加するだけでよく、導入コストがほとんどないという点です。
同様の問題で困っている方は是非、お試しください。(ひ)
klab_gijutsu2 at 18:36│Comments(0)│TrackBack(0)
