突然の送信拒絶に始まる騒動
２０１６年の２月だったか、３月だったか。添付ファイルを伴う迷惑メールが急増しました。
テレビの報道でも盛んに取り上げられていましたから皆さんも記憶にあるのではないかと思います。
私が管理しているサーバー（レンタル）でもサンプルで確認している数アドレスだけでもこれまでの数倍から数十倍の迷惑メール到達量になり慌てて社内に注意喚起のメールを送ったものです。
これまでも迷惑メール（スパムメール）の問題は深刻です。
２００９年半ばに世界の総メール送信数約６．３兆通のうち５．７兆通がスパムだったという話は我が目を疑う現実です。
その後の迷惑メール対策（フィルターの性能向上や摘発等）により徐々に減少傾向にあった迷惑メールは。２０１５年の半ばになってようやく総量の５割程度まで減ったそうです。
それでも５割ですけどね。
効果的だが副作用も多い迷惑メール対策の現状－ブロックリスト
独自のアルゴリズムや辞書、学習による迷惑メール対策がある一方、送信元の身元証明や送信量の変化等を判断基準にして迷惑メール判定をするシステムも注目度が上がっている感じがします。
例えば迷惑メール送信サーバーに見える疑わしい活動を検出して登録していく「ブロックリスト」というサービスは無数に存在しています。
ブロックリストサイトの特徴としては無数にあるブロックリストサイトが同じ判断基準で判定をしているちう事ではないところです。私が管理しているサーバーも何度か誤ったブロックリストに登録されたことがありますが、その場合も様々なブロックリストサイトに一気に登録されることはなく、２～３のサイトに登録されて終わりました。
また意外と気軽に解除申請が出来る所も不思議です。
大抵のブロックリストサイトでは解除申請さえあればあっさり登録を解除します。
例えばさくらのレンタルサーバーではブロックリストサイトへの登録解除申請を代行していたりもします。
（万能ではありませんが）
効果的だが副作用も多い迷惑メール対策の現状－レピュテーション
その他にも最近特に気になっているのが、IPレピュテーション（IP reputation）やメールレピュテーション（mail reputation）と言われる評価システムです。
メールの送信量の変化や前述のブロックリストへの登録の有無、第三者からの通報などにより、送信元のIPアドレスやメールアドレスがメール送信元としてどうか、その評判を表すのがレピュテーションです。
メールのレピュテーションについては「senderbase.org」で確認できる。
一般的にGOOD、NEUTRAL、POORの３段階で評価され、おおむね１日１回程度の更新がされているようです。
２０１６年以前はレピュテーションによって突然メールが届かなくなるような事はあまり多くありませんでした（ありましたが）でも、今年に入ってから国内でも様々なところにメールが送れなくなり対応に追われました。
判定の大きな要素として「メールの通信量」を評価するのですが、先月の送信量の平均値と昨日の送信量を比較して急激に増加すればPOOR、大きくマイナスであればGOODと判定されます。という事は不定期配信のメールマガジン等は突発的に送信数が増加するため、意図せずPOOR評価を受ける可能性があるという事です。
それを避けるために「IPを育てる」とか「IPをウォームアップする」という表現があるそうです。
段階的にメールの送信量を増やしていき、大量のメール送信に耐えられるIP（耐えられるレピュテーション）に育てるという。
サーバー管理者は専用ソフトなどを使いこのメンテナンスを行ったりもするそうです。
・・・考えられない。
効果的だが副作用も多い迷惑メール対策の現状－PTRレコード
もう一つ最近重要視されているのがPTRレコードと呼ばれるものです。
IPアドレスは「正引きDNS（Forward DNS）」でドメイン名を導くことが出来ます。
例 xxx.xxx.xxx.xxx → inst-web.com
ドメイン名は「逆引きDNS（Reverse DNS）」でIPアドレスを導くことが出来ます。
例 inst-web.com → xxx.xxx.xxx.xxx
もし、送信者が正しい送信者で、PTRレコード（逆引き情報）を正しく掲載していれば
正引きしたものを逆引きすれば同じIPアドレスである事を確認できます。
逆に送信者が身元を詐称していた場合などは正引きと逆引きの情報が一致せず送信元が不審者であると確認できるという事です。
この方法はSPFレコードを一歩踏み込んだ形でしているものの様に感じますが、より客観的に送信元の正当性を確認できる仕組みです。
逆引きDNSやPTRレコード対策はレンタルサーバーでは積極的に編集したり設定したりする事が出来ない場合が多いです。
また、あまり積極的に情報が公開されていないような気もするので、調べる方法が少ないのも困りものです。
ちなみにさくらのレンタルサーバーでは自動で付与されるホスト名が逆引きDNSとして登録されているのを確認しました。
（VPSや占有サーバープランでは手動編集ができるようです）
迷惑メール対策の功罪
個人的な推測ですが、添付ファイルによる迷惑メールが瞬間的に世界規模で流行した結果、ISPや迷惑メール対策サービス提供会社が締め付けを厳しくしてきているのではないかと思います。
レンタルサーバー等は一つのIPアドレスを多くのユーザーで共有することが多いですが、これは同一IP内の他のユーザーの評価による影響を強く受けることになります。
どれだけ自分のメール送信に気を使っていてもとばっちりを受ける可能性はゼロではありません。
そして本来まっとうにメールを利用しているユーザーからのメールを、説明もなく拒絶する迷惑メール対策は果たして正しいのか？という議論はこれまでも多く起こってきました。
私個人としては「迷惑メールのフラグを付加する」ぐらいが出来る事だと思います。
当事者同士がまったく意識しないメールレピュテーションで突然メールが届かなくなる、そして届かなくなったのは受信側のサーバーがメールを拒絶したから。
これは業務で使用するメールのシステムとしては非常に問題があると思います。
拒絶した側に解除申請をしてみる
ちなみに、今回の自社内でのメール送信不具合問題の際には相手に「メールの拒絶を解除してほしい」と依頼してみました。
相手がどのようにメールサーバーや迷惑メールフィルターサービスを運用しているのかわからないので一概に言えませんが、素早い対応を見せたところでは５分ほどでホワイトリストに追加してもらうことが出来ましたが、一社KDDIの何かを使用していたところでは解除に相当の手間が掛かったようでした。
メールが拒絶された場合の確認
メールレピュテーションをもってメールが拒絶されると以下のようなメールが返信されます。
同様のメールが来たら、自分のメールサーバーが何かネガティブな判定を受けていないか確認してみてください。
PTRレコード（逆引きDNS設定）を確認してみる－debouncer.com
サーバーに届いたメールを捌くのがMTAと呼ばれるシステムです。
メールの素性を確認したりサーバー内のどのアドレス宛なのかを確認したりするのがMTAでおせっかいな郵便局みたいなものです。
MTAがどのように正引き、逆日にDNSを確認するのか、どのようなプロセスでチェックされているのかについて日本語での記載があまり探せず困っていましたが、英語の記事の中ではまずIPから送信元ドメインを確認し、そのドメインからIPを逆引きする事で行っているとの記載がありましたのでこれを信じたいと思います。
では自分のサーバーがどのような設定になっているのかを実際に確認していきましょう。
debouncer.com
このウェブサイトではドメイン名（独自ドメインもOK）を入力することで、DNSの正引きと逆引きをまとめて確認してくれます。
さくらインターネットのレンタルサーバーを利用している方がこのページを使用してて確認すると、初期登録ドメインでも独自ドメインでもなく、ホスト名が表示されることに注目してください。
さくらのレンタルサーバーではホスト名を逆引きDNSに設定しているのでこのようになります。
PTRレコード（逆引きDNS設定）を確認してみる－port25.com
check-auth@verifier.port25.comにメールを送る。
このアドレスはSPFレコードが正しく設定されているのかを確認する場合に紹介したことがあったかと思います。
内容を見ていくと「HELO hostname」という記載がありますが、これはメール送信時に送信元から送信先に「三河屋から来ました！」と自己紹介しているものだそうです。
私の様にサーバーの知識がないと「あれ？メールアドレスは独自ドメインで送っているのに、挨拶はホスト名がしているの？」と不思議に思いますが、メールのやり取りをするサーバーがそれなんでしょうね。ふむふむ。
==========================================================
Summary of Results
==========================================================
SPF check: pass
DomainKeys check: neutral
DKIM check: neutral
Sender-ID check: pass
SpamAssassin check: spam
==========================================================
Details:
==========================================================
HELO hostname: wwwxxx.sakura.ne.jp
Source IP: aaa.bbb.ccc.ddd
mail-from: xxx@inst-web.com
———————————————————-
SPF check details:
———————————————————-
Result: pass
ID(s) verified: smtp.mailfrom=xxxxx@inst-web.com
DNS record(s):
inst-web.com. SPF (no records)
inst-web.com. 3600 IN TXT “v=spf1 +ip4:aaa.bbb.ccc.ddd +ip6:(IPv6アドレス) +a:wwwxxx.sakura.ne.jp +mx ~all”
PTRレコード（逆引きDNS設定）を確認してみる－nslookup
コマンドプロンプトでnslookupと入力しましょう。そうするとコマンド待機状態になります。
その後、IPアドレスを入力してみる。
> aaa.bbb.ccc.ddd
サーバー: UnKnown
Address: (IPv6アドレス)
名前: wwwxxx.sakura.ne.jp
Address: aaa.bbb.ccc.ddd
ホスト名が表示されるのを確認。
ホスト名を入力してみる。
> wwwxxx.sakura.ne.jp
サーバー: UnKnown
Address: (IPv6アドレス)
権限のない回答:
名前: wwwxxx.sakura.ne.jp
Addresses: (IPv6アドレス)
aaa.bbb.cccc.ddd
PTRレコードを確認する
set type=ptr
> aaa.bbb.ccc.ddd
サーバー: UnKnown
Address: (IPv6アドレス)
権限のない回答:
set type=ptr
aaa.bbb.ccc.ddd
ddd.ccc.bbb.aaa.in-addr.arpa name = wwwxxx.sakura.ne.jp
逆引きでホスト名に到達するのを確認。
PTRレコード（逆引きDNS設定）を確認してみる－メールヘッダー（gmail.com）
gmailをお持ちの方は自分のgmailアドレス向けにメールを送り、ヘッダー情報を確認してみる。
自分のメールアドレスとは違う環境に送ってみるという意味でgmailで確認してみます。
Delivered-To: xxxxxxx@gmail.com
Return-Path:
Received: from wwwxxxx.sakura.ne.jp (wwwxxxx.sakura.ne.jp. [xxx.xxx.xxx.xxx])
by mx.google.com with ESMTPS id xxxxxxxxxxxxxxxxxxxxxxxxx
for
(version=TLS1 cipher=AES128-SHA bits=128/128);
Fri, 27 May 2016 22:51:06 -0700 (PDT)
Received-SPF: pass (google.com: domain of xxxxxx@inst-web.com designates xxx.xxx.xxx.xxx as permitted sender) client-ip=xxx.xxx.xxx.xxx;
レシーブドフロムにホスト名が記載されている。
ついでにSPFレコードもpassな事を確認。
まとめ
幸いこれらの対策（というか確認作業）で自分が利用しているレンタルサーバーではDNSの逆引きにもPTRレコードも対応していたことが確認できました。
みなさんのレンタルサーバーでもSPFレコードやDNS逆引きに正しく対応している事を確認できればメールが突然拒絶されるリスクを低減できるかも知れませんね。
0コメント