携帯電話のキャリアメールアドレスに正しくメール送信する 技術解説的なやつ

メールサーバ

携帯電話のキャリアメール等にメールを送信する場合、何も設定していないpostfixのサーバからメールを送信すると、なりすまし規制などで、正しくメールが送信されないことが多いです。

というのを、本気で解決してみました。

※ドメインの拒否設定されている端末には届きません。

 

■結局何をすればいいんだろう

まずは、結論から。技術情報と合わせて、解釈すると以下のことをすればいいようです。

○ドメインを取得して、MXレコードとSPFレコードを正しく設定
○送信元メールサーバの設定(ドメインにしたがって、正しく名乗るように変更)

1つずつ要素を確認してみようと思います。

■まずは各社の基準を調査する

各社ごとに、ある程度メールの規制に関して公開しています。読んでみましょう。

▽DOCOMO

送信ドメイン認証(Sender ID/SPF)について | ご注意事項 | iモードメール | サービス・機能 | NTTドコモ
なりすましメールを防ぐための迷惑メール対策設定に利用する、送信ドメイン認証の注意点についてご紹介いたします。
iモードセンタが送信ドメイン認証をする際は、送信元のIPアドレスと、DNSサーバに公開された送信用メールサーバの
IPアドレスとを比較し、合致した場合にのみメール受信し、不一致の場合や、当該IPアドレスがDNSサーバに存在しないなど、整合性がとれない場合には
受信しません。
したがいまして、お客様が、「全て拒否する」と設定された場合には、DNSサーバに必要な対処を行っていないISP事業者様や企業様などからのメールは認証ができないため受信できません。
(お客様が、併せてドメインやアドレスを指定して受信設定をしている場合には、そのドメイン・アドレスからのメールであれば受信することができます。)

 

▽AU

送信ドメイン認証SPFレコードについて | auメール(@au.com/@ezweb.ne.jp)へメール送信する際の注意事項:サービス・機能 | au
auメール(@au.com/@ezweb.ne.jp)へメール送信する際の注意事項の送信ドメイン認証SPFレコードについてのページ。auスマートフォン(スマホ)・携帯電話のメールのサービス・機能・アプリをご紹介します。基本的なメールの送受信...
SPFレコードの確認には、エンベロープFromに記述されているドメインを使用致します。
エンベロープFromが記述されていない場合には、SPFレコードの確認は、HELOドメインを使用しますので、EHLO/HELOにも正しい送信ドメインを記述されますようお願い致します。
EZwebにメールを送信するドメインのSPFレコードはTXTレコードで公開してください。
IPアドレスの指定にはIPv4を使用してください。
※お客さまが迷惑メールフィルターの「なりすまし規制
(高)」をご利用になる場合、エンベロープFromに加えてPRAに記述されているドメインを使用したSPFレコードの確認を行い、SPFレコードが無い場合はメールを拒否します。PRAとして以下の順にヘッダをチェックします。

Resent-Sender → Resent-From → Sender → From

 

▽ソフトバンク

http://www.softbank.jp/mobile/support/antispam/settings/indivisual/antispoof/
https://www.email.softbank.ne.jp/help/j/antispoof.html

あまり情報がありません。一旦無視します。ほかが届けば大体届くでしょう。

 

■技術要素の調査

各社の基準を確認した結果、いくつか用語が出てきました。今度はそれを読み解いてみます。

▼エンベロープFrom

Fromは2つ存在します。このエンベロープFromとヘッダの
Fromとあります。エンベロープFromを元にメール配信されます。

通常はエンベロープとヘッダは同一だけど、メーリングリスト
などの時は異なります。

例:

メーリングリストのアドレスが、test@hogehoge.orgで、送信者が
xxxx@gmail.comのときエンベロープfromはtest@hogheoge.orgで
ヘッダのFromは送信者のアドレスであるxxxx@gmail.comになります。
で、gmail等で見ると差出人はtest@hogehoge.orgではなく、
xxxx@gmail.comから送信された、と表示されます。

※※※エンベロープFROMをまとめると※※※

○エンベロープFromは実際に配送時に使われるアドレス
○ヘッダFromはメール受信した時の情報表示用。

→ヘッダFromを偽って表示の偽装ができるという寸法です。

 

▼SPFレコード

Sender Policy Frameworkの略。DNSのレコードとして設定します。メールの受信側のサーバがこのSPFレコードを使います。SPFレコードには以下の情報が書かれています。

※※※SPFレコードをまとめると※※※

○受信側が確認するための情報をDNSサーバに記載しておく
DNSサーバには、「このIPから送信されたメールは偽装されていないです」という記述が書いてある。

○受信側のサーバが、ドメインを元にSPFレコードを確認する。
▽メールのヘッダとかに書いてあるIPアドレスとSPFレコードのIPがあっていれば、偽装されていない。
▽承認できなければ、それは偽装されている可能性が高いと判断して規制。メールは届かない

記述例:

IN TXT "v=spf1 +ip4:192.0.2.1 +ip4:192.0.2.21 -all"

この記述だと192.0.2.1と192.0.2.21のサーバから送信されたメール以外は承認できない。という設定になります。

書式はここを見るとわかりやすいです
http://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/
https://www.ipa.go.jp/security/topics/20120523_spf.html

 

▼EHLO/HELOドメイン

メール送信は以下の様な前準備を行います。

1.送信元が送信先に接続する
2.送信元が送信先に対してHELO ドメイン名 で自分のドメインを名乗る
3.送信先が送信元が名乗ってきたHELOのドメインをチェック(設定次第だけど。。)
4.ドメインが正しかったら(名前解決チェック)、接続OKにして、次の処理へ
で、HELOドメインと言っているのは、2.のところで名乗るドメイン名のことです。ここで全く関係のないドメインを設定するとと正しく送信されません。

 ※※※EHLO/HELOドメインをまとめると※※※

送信元のサーバが送信先のサーバに名乗るドメイン名のこと。送信元が嘘をつくと、送信先が切断する場合がある。
AUの「エンベロープFromが記述されていない場合には、SPFレコードの確認は、HELOドメインを使用しますので、EHLO/HELOにも正しい送信ドメインを記述されますようお願い致します」
というのはエンベロープFromが無いときは、こっちをドメインを確認するよ。と言っています

 

▼PRA

Purported Responsible Addressの略

SPFレコードの時はエンベロープFromのドメインを元にチェックをしていましたが、PRAはメールのヘッダに書いてあるResent-Sender、Resent-From、Sender、Fromを順番に確認してSPFレコードをチェックするようにします。

※※※PRAをまとめると※※※

SPFのレコードが設定されていることが前提。SPFレコードのチェックとやっているい事は同じ。ドメインを確認する場所が異なる。

 

■最後にまとめ

というところを踏まえて、一番初めに書いた結論をみてみると、なんとなく理解ができると思います。正しく設定すれば結構届くものです。

○ドメインを取得して、MXレコードとSPFレコードを正しく設定
○送信元メールサーバの設定(ドメインにしたがって、正しく名乗るように変更)