携帯キャリアのなりすましメール対策に対応する
■
携帯キャリア各社は、2007年から「なりすましメール対策」といった名称で、PCから携帯に送信されるメールについてSPFレコードを使った認証を行うことで迷惑メールの着信を軽減させるサービスを提供しています。
ユーザとしての私の感触としては、たいへん効果があり迷惑メールから開放されるようになった、といったところです。
さて、なりすましメールをブロックする設定を行うと、迷惑メールばかりではなく自宅のメールサーバから自分の携帯に送信するメールまでもブロックされてしまうことになります。これは困ったものです。
そこで、プロバイダから割り振られる動的IPで運用するメールサーバにおける、携帯キャリアのなりすましメール対策への対応について考えてみます。
■
まず、携帯キャリアごとに対応すべきポイントを洗い出します。
docomo（概要 、仕様 ）
docomoは、以下の情報からSPFレコードを使った認証を行います。
au（仕様 ）
auは、以下の情報からSPFレコードを使った認証を行います。
ソフトバンク（仕様 ）
ソフトバンクは、以下の情報からSPFレコードを使った認証を行います。
これらをまとめると以下のようになります。
■
仮に、私が所有するドメインを「example.com」として環境の例を挙げます。
私の自宅のメールサーバは、受信サーバ(mail.example.com)と送信サーバ(mta.example.com)を分けた構成になっています。
また、メール送信時における上記の考慮すべき3つのポイントは以下のようになっています。
■
では、対応方法を考えてゆきます。
必要なのは、以下の条件を満たすDNSサーバ設定です。
MXレコード、および、Aレコードはあらかじめ以下のようになっています。
「example.com」(*3)(*4)のMXレコードには「10.0.0.1」(*1)と「172.16.0.1」(*2)の両方を登録していますので、SPFレコードを使って（Aレコードとは別である）「172.16.0.1」(*2)を求めることができます。これは便利です。
このような状況から、SPFレコード（TXTレコード）を以下のように設定しています。
これで、携帯キャリアのなりすましメール対策に対応できました。
■
最近では、大手のプロバイダや大規模な企業から順番に、SPFレコードを設定する動きが広まっているようです。
今後は、用途が限られているような小規模なメールサーバであっても、機能拡張や運用の拡大を想定するならば、SPFレコードを設定しておいて損はないかもしれません。
なお、ここで挙げた方法はほんの一例に過ぎませんので、さまざまな方法の中からあなたの環境に適した設定を行うのがよいと思います。
携帯キャリア各社は、2007年から「なりすましメール対策」といった名称で、PCから携帯に送信されるメールについてSPFレコードを使った認証を行うことで迷惑メールの着信を軽減させるサービスを提供しています。
ユーザとしての私の感触としては、たいへん効果があり迷惑メールから開放されるようになった、といったところです。
さて、なりすましメールをブロックする設定を行うと、迷惑メールばかりではなく自宅のメールサーバから自分の携帯に送信するメールまでもブロックされてしまうことになります。これは困ったものです。
そこで、プロバイダから割り振られる動的IPで運用するメールサーバにおける、携帯キャリアのなりすましメール対策への対応について考えてみます。
■
まず、携帯キャリアごとに対応すべきポイントを洗い出します。
docomo（概要 、仕様 ）
docomoは、以下の情報からSPFレコードを使った認証を行います。
- メールヘッダのFROMフィールド
- エンベロープFROM
au（仕様 ）
auは、以下の情報からSPFレコードを使った認証を行います。
- エンベロープFROM
- HELO(EHLO)ドメイン
ソフトバンク（仕様 ）
ソフトバンクは、以下の情報からSPFレコードを使った認証を行います。
- メールヘッダのFROMフィールド
これらをまとめると以下のようになります。
- 「メールヘッダのFROMフィールド」、「エンベロープFROM」、「HELO(EHLO)ドメイン」の3点において、SPFレコードを使った認証に成功する（送信元IPアドレスと一致する）ことが必要。
■
仮に、私が所有するドメインを「example.com」として環境の例を挙げます。
私の自宅のメールサーバは、受信サーバ(mail.example.com)と送信サーバ(mta.example.com)を分けた構成になっています。
また、メール送信時における上記の考慮すべき3つのポイントは以下のようになっています。
- メールヘッダのFROMフィールド → ○○○@example.com (*3)
- エンベロープFROM → ○○○@example.com (*4)
- HELO(EHLO)ドメイン → mta.example.com (*5)
■
では、対応方法を考えてゆきます。
必要なのは、以下の条件を満たすDNSサーバ設定です。
- SPFレコードを使って、「example.com」(*3)(*4)から「172.16.0.1」(*2)が求まること。
（※「10.0.0.1」(*1)ではなく「172.16.0.1」(*2)であること）
- SPFレコードを使って、「mta.example.com」(*5)から「172.16.0.1」(*2)が求まること。
MXレコード、および、Aレコードはあらかじめ以下のようになっています。
$ dig -t mx example.com ;; ANSWER SECTION: example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN MX 20 mta.example.com. ;; ADDITIONAL SECTION: mail.example.com. 60 IN A 10.0.0.1 mta.example.com. 60 IN A 172.16.0.1 $ dig -t mx mta.example.com ;; ANSWER SECTION: mta.example.com. 3600 IN MX 20 mta.example.com. ;; ADDITIONAL SECTION: mta.example.com. 60 IN A 172.16.0.1
「example.com」(*3)(*4)のMXレコードには「10.0.0.1」(*1)と「172.16.0.1」(*2)の両方を登録していますので、SPFレコードを使って（Aレコードとは別である）「172.16.0.1」(*2)を求めることができます。これは便利です。
このような状況から、SPFレコード（TXTレコード）を以下のように設定しています。
$ dig -t txt example.com example.com. 3600 IN TXT "v=spf1 +mx ~all" $ dig -t txt mta.example.com mta.example.com. 3600 IN TXT "v=spf1 +mx ~all"
これで、携帯キャリアのなりすましメール対策に対応できました。
■
最近では、大手のプロバイダや大規模な企業から順番に、SPFレコードを設定する動きが広まっているようです。
今後は、用途が限られているような小規模なメールサーバであっても、機能拡張や運用の拡大を想定するならば、SPFレコードを設定しておいて損はないかもしれません。
なお、ここで挙げた方法はほんの一例に過ぎませんので、さまざまな方法の中からあなたの環境に適した設定を行うのがよいと思います。