第5章

5.2 送信側の対応

ISP での対応するためには、メールに利用しているドメインについて、3.2.4 で解説した SPF レコ

5.2.1 概要ードの記述が必要です。

ISP が送信するメールは、一般の企業やSPF レコードには、メールの出口である各種組織のドメイン名を利用して送信されホストのグローバル IP アドレスが含まれるメールに比べて、その規模が大きかった

るような、ネットワークアドレスや IP アり、利用目的が多様であることにより様々ドレス、ドメイン名などを記述します。こな種類のメールが送受信される、という特れらの出口には、通常の送信用のホスト以徴があります。送信ドメイン認証技術を送外に、例えば、受信側が一時的に受け取ら信側で導入し、ISP を経由しない詐称されなかった場合に移される再配送用のホストたメールを区別できるようにすることは、や、メールサービスで利用しているドメイ

ISP のドメイン名の信頼度を向上させるたン名を使った顧客向けの連絡用の送信用メめに非常に重要です。

ールサーバなども含める必要があります。

送信ドメイン認証技術は、送信者情報が5.2.2.1.1 サブドメイン利用時の注意偽装されているかどうかを確認可能とする技術なので、送信側で送信ドメイン認証技

メールサービスに、複数のドメイン名が術を導入することにより、迷惑メールの多利用できるようになっている場合には、そい ISP のドメイン名が、逆に迷惑メールのれぞれのドメインについて SPF レコード送信元として判断されてしまう可能性もあを記述する必要があります。

ります。ISP から日々大量に送信されるメ

また、複数のドメイン名を利用しているールの中に、メールの受信者にとって迷惑場合で、それぞれがサブドメインの構成とメールとなるようなメールが含まれていななっており、それらの親ドメインをメールいか、それらが誰から送信されているのかサービスに利用していないときは、注意がを管理することも重要です。自社のドメイ必要です。SPF レコードが記述されていなン名に対して迷惑メールを送信するドメイ

いドメイン名は、詐称されても受信側で判ンとしての評判が下がらないように、何ら定できませんので、よく目にするドメインかの監視等の管理が必要です。

名の認証結果が fail / softfail などの認証失敗でない場合には、誤解を与えてしまう可5.2.2 送信ドメイン認証技術の導入能性がありますので、3.2.3 と 4.1.2.2 で解説したとおり、以下のように、メールに利5.2.2.1 SPF/Sender ID の導入

用しない親ドメインの場合は、明示的にすべて認証が失敗するような SPF レコード

ネットワーク方式の送信ドメイン認証技を宣言した方が良いでしょう。

術である SPF / Sender ID を送信側で導入

59

第5章

ISP での対応

example.jpTXT "v=spf1 -all"apple.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"peach.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"mango.example.jp TXT "v=spf1 +ip4:192.168.0.4 -all"

図表５－１

サブドメインがある場合の SPF レコードの例

5.2.2.1.2 転送処理

あれば、受け取ることは可能になります。
SPF の場合は、送信者情報としてリバー60

一度受信したメールを、あらかじめ設定

スパス を利用しますので、 4.2.1.2 で解説された別のメールアドレスへ送信する転送

したとおり、転送時に送信元の情報を利用機能は、古くから提供されてきた機能の一するのではなく、転送者のメールアドレスつですが、 4.2.1.2 で解説したとおり、ネを設定し直すことによりこの問題は回避でットワーク方式の送信ドメイン認証技術ときます。ただし、単純にリバースパスを書の相性は良くありません。すなわち、現在き換えてしまうと、転送先で受け取れなか提供されている多くの転送機能は、転送時った場合やエラーメールなどが、ループしのリバースパスに元々の送信者のリバースてしまう可能性があります。そのため、転パス情報をそのまま使いますので、転送先送時に書き換えるメールアドレスは、ローでの SPF の認証は失敗してしまいます。

カルパート部分に何らかの印となるような転送設定は、メールの利用者がそれぞれ文字列を別途挿入し、通常の受信メールと設定しますし、転送先のメール利用者は転転送メールの戻りメールとを区別できるよ送者と同一であることが一般的です。そのうな工夫も考えられます。通常の受信メーため、転送先のメール受信設定で、転送元ルは転送し、転送したメールが戻ってきたからのメールが SPF の認証が失敗しても場合には、そのまま転送せずに利用者のメ受け取るようなフィルタ等の設定が可能でールボックスに格納するなどです。

第5章

ISP での対応

5.2.3 迷惑メールの管理者に通知できない場合に問題となる可能性がありますので、利用者のサポートは十分多くのユーザが利用する ISP のメールに行う必要があります。また、送信側にもサービスでは、自身のドメイン名の評判をフィルタを導入することで新たな費用が発下げないような運用を心がける必要があり生する可能性もありますので、費用対効果ます。

なども含めて検討する必要があります。

例えば、迷惑メールが自社のメールサーバを経由して送信されていた場合には、そ5.2.3.2 送信者の特定とその対策手順の確立の迷惑メールの受信側からの申告により、ブラックリストに登録され、以降そのブラ迷惑メールが ISP のメールサーバからックリストを利用しているメール受信側に送信される可能性を完全に排除することは通常のメールも含めた全ての届かなくなっ困難ですので、問題を大きくしないためにてしまうことが考えられます。近年の迷惑も、仮に迷惑メールが送信されても、受信メールの増加傾向により、こういった迷惑者からの連絡があった場合などには、そのメール対策を行うメール受信者は増えてい迷惑メールを誰が実際に送信したのかを判ますし、送信ドメイン認証技術の普及によ断する仕組みが重要になります。

りドメイン名による受信制御が行われることが予想されます。
そのための対策としては、以下の事項が考えられます。

送信者を特定するには、メール送信時に送信者の認証を ID とパスワードによって行う SMTP-AUTH を導入し、メールヘッダやメール送信ログに、その AUTH ID を5.2.3.1送信側の迷惑メール対策記録するなどして、誰が実際に送信したかを調べる方法があります。最近では、不正迷惑メールの送信元となる ISP と判断プログラム (マルウェア) に感染して、利用されないためには、そもそも迷惑メールが者が知らない間に外部から制御されて迷惑外部に送信されないような仕組みがあればメールを送信することが問題となっており、良いことになります。現在、多くの ISP で

SMTP-AUTH にも対応したマルウェアがはメール受信時に迷惑メールかどうかを判現れているのではないかともいわれていま定する迷惑メールフィルタを提供しています。そのため、AUTH ID を利用して迷惑メす。こういったフィルタがメールの内容かール送信者を特定し、利用者への通知及びら判断するタイプのものであれば、それを解決のためのサポートを行うことは、顧客送信時にも適用し、迷惑メールを送信しよ保護の意味でも重要になってきます。また、

うとしている場合に保留することによって、迷惑メールの大量送信を抑制するために、外部への送信を抑制することができます。

AUTH ID 単位で、一定時間内に送信できる

しかし、迷惑メール判定には誤判定が発生しますし、送信されなかったことが送信62メール数を制限する方法があります。

第5章

ISP での対応

5.2.3.3 送信者情報を変更できないような仕組

送信者情報のドメインと異なるようなことみがある場合は、同様に何らかの対策が必要になります。
送信ドメイン認証技術で送信者情報として使われるのは、リバースパスと From ヘ

5.2.3.4 エラーメール処理

ッダアドレスのドメイン部分となります。
受信側で送信ドメイン認証が失敗しないた

受信したメールが宛先不明で配送できな

めには、これらが正しい情報となっている

かった場合は、メールの送信者にエラーメ必要がありますので、顧客からメールが投ールを送信する必要があります。エラーメ

稿された場合に、これらの情報が認証失敗ールは、リバースパスに指定されたメールするものになっていないかどうかを、配送アドレスに送信されます。迷惑メールの多前に確認すると良いでしょう。

くは、このリバースパスを詐称する場合が多いので、結果として不要なエラーメール

メール投稿時に指定されたこれらの情報が、あらかじめ送信ドメイン認証に失敗することが分かった場合に、ISP が取りうる対応方法の例を以下に示します。

がメールアドレスを詐称された側に大量に送信されることになります。
ISP では、決まったドメインを使ってメールサービスを提供しますので、詐称に使われる可能性が比較的高いドメイン名であ(a) メールの投稿そのものを受け付けない(エラー応答する)(b) リバースパスの場合、ISP のドメイン名のメールアドレスに付け替える(c) From ヘッダアドレスの場合、Senderる一方、不特定多数にサービスを提供していることもあり、宛先不明となる迷惑メールも多く、結果として不要なエラーメールを多数送信している可能性もあります。こうした不要なエラーメールを抑制するため

ヘッダなどに ISP のドメイン名のメーには、次の対策があります。

ルアドレスを追加する(a) メールの受信時点で宛先が存在するかを確認して存在しない場合は受け取らな

これまで、多くのメールサービスでは、

いこれら送信者情報の指定方法については比(b) 受信時に送信ドメイン認証技術で認証

較的緩やかな運用をしていました。そのたが失敗した場合にエラーメールを送信しめ、このような対応を急激に行うと、利用ない者にとって混乱の原因になりかねませんので、事前の周知が重要になります。

(a) の対策のために、メールの受信時に、宛先が存在するかを確認するには、顧客管

また、DKIM の場合も From ヘッダアド理を行っているシステム (データベースなレスのドメイン名とは無関係ではありませど) とリアルタイムで問合せできることがんので、DKIM-Signature ヘッダに示される必要です。メールシステムの構成として、

63

第5章

ISP での対応

メールスプールが存在するかどうかで宛先の SMTP 処理を継続しない、という方法

不明かどうかを MTA ではなく、MDA が判があります。断している場合には、システムの変更が必要になります。また、メール受信時に宛先宛先不明時にエラーメールを返す送信先不明かどうかを SMTP 上の応答として返は、詐称されていない実際の送信元です。

すことになりますので、送信側でその応答そのため、送信ドメイン認証技術で認証がを確認することにより、実在するメールア失敗した送信先、例えば SPF / Sender ID

ドレスかどうかを簡単に調べることができで認証結果が fail / softfail となった送信元てしまいます。よく使われるローカルパー

や、DKIM で認証が失敗した場合や、ADSPトの文字列を総当たり的に指定して実在すで fail/discard であったような送信元には、るメールアドレスを取得する攻撃は、辞書エラーメールを送信する必要はありません。

攻撃 (DHA: Directory Harvesting Attack)このため、(b) の対策を実施することも考えと呼ばれます。これを防ぐためには、一定られます。

数以上の宛先不明が発生した場合に、以後64

第5章

5.3 メール受信側としての検討5.3.1 概要

ISP での対応

5.3.3 メールの配送制御

改めての説明になりますが、送信ドメイン認証技術は、あくまでも「特定の送信元第３章で解説したとおり、送信ドメインから確かに送信されたかどうか」を機械的認証技術を用いることにより、メールの受に判断するための技術であり、認証結果と信側が認証を行うことで、そのメールが本メールのコンテンツは何の関係もないもの

当にそのドメインから発信されたかどうかです。ISP では多様な利用者にサービスをを判定することができます。送信ドメイン提供するという性質上、送信ドメイン認証認証技術は、送信側の対応も必須ではあり技術での認証結果の取り扱いについては、ますが、受信側が対応を進めることは送信特に慎重になるべきです。

側の導入モチベーションにも繋がるものです。そのため、送信ドメイン認証技術の普5.3.3.1 配送前制御に関する注意

及に向けてのよいサイクルを生むためにも、ISP では積極的に受信時の認証およびラベ送信ドメイン認証技術による認証結果をリングを行うべきであり、受信したメール利用した受信側のアクションで特に注意すを適切に取り扱う努力を行っていることを、べきなのが、認証結果による配送方法の取利用者・送信者へアピールしていくことが扱いです。4.1.3 で解説したとおり、送信ド望まれます。

メイン認証技術では、受信者の意図しないメーリングリスト経由での再配送や送信時5.3.2 利用する送信ドメイン認証技術の選定ポリシーの記述ミスなどによって認証が失敗する場合もあります。特に、ISP ではさ

受信時に利用する送信ドメイン認証技術

まざまな受信者による利用シーンが考えらを選定する場合には、4.1.1 を参考にします。

れるため、送信ドメイン認証技術による認送信ドメイン認証技術を複数導入すれば、証結果だけを利用して、一律にメールの受ドメインの正当性の判断に利用できる情報信を拒否したり破棄したりする取り扱いをは増えますが、認証のために必要な追加コしてはなりません。ただし、以下の場合にストが増加する場合があります。特に ISPはこの限りではありません。

の場合、取り扱うメールの通数が一般的な(a) 受信設備の高負荷による緊急避難など企業に比べ多くなりますので、機能を追加する設備の規模も大きくなると考えられま

限定的対応の場合(b) エンドユーザからの個別の同意があるす。現状のネットワーク構成やハードウェ

場合アを考慮しながら、段階的に送信ドメイン(b) による場合には、エンドユーザに対し認証技術を導入していくことが現実的でしてリスクについて十分な説明を行うとともょう。

に、簡易に機能を解除させたり、個別に回

65

第5章

ISP での対応避できるような機能を設けるなどの機能的ができる権利もしくは機能を持つタイプの配慮もした上で、個別に同意を取って提供ものでなければなりません。

しなければなりません 。
5.3.3.4 認証結果の可視化による利用者のユー5.3.3.3 ホワイトリストやドメインレピュテー

ザビリティ向上

ションの活用利用者が認識できるように認証結果の表4.1.4.3 で示したとおり、送信ドメイン認示を行うためには、Web ブラウザ経由や証の結果と、ISP が事前に用意したホワイMUA 経由など、表示領域を任意に制御できトリストやドメインの評判（ドメインレピるような環境でメールを閲覧する必要があュテーション）情報と照合することもできります。

ます。照合結果によって、メールに特別な一部の ISP では Web ブラウザ上でメマークを付与したり、迷惑メール判定を実ールを利用できるサービスを提供していま施せずにフィルタを通過させたりするなどすが、このような環境の場合、画面インタの活用方法が考えられます。また、サービーフェース中に認証に利用したドメイン名

スの利用者が個別にドメインを設定するこや認証結果、ホワイトリストなどとの照合とにより、Web ブラウザや MUA 上でのフ結果を分かりやすく表示させることが可能

ォルダ振分けなどに利用できるようにするです。一方 MUA ではこのような画面表示サービス形態も考えられます。

に標準的に対応しているクライアントはま

ISP が他組織により提供されるホワイト66だほとんど存在していません。

リストやレピュテーション情報を利用する

送信ドメイン認証結果を分かりやすく表場合は、自組織のポリシーと一致しないこ示するアプリケーション環境が整い、利用とも十分に考えられるので注意が必要です。

者が積極的に利用できるよう、ISP としてそのため、これらホワイトリストやレピュ可能な取り組みを推進することが好ましい

テーション情報は、自組織でコントロールといえます。

第5章

5.4 ユーザ周知

ISP での対応

受信側の対応については、どの技術を採用しているかを説明する必要があります。

送信ドメイン認証を導入する場合には、導認証結果をラベリングとして記述する場合

入した結果として発生する影響について、ユには、ラベリングの確認方法を、代表的なメーザに周知する必要があります。周知の方法

ールクライアントの設定方法について説明すは、メールや郵便物で行う方法もありますが、ることが推奨されます。また、フィルタサー

最低限ホームページでの周知は実施するべきビスを提供する場合には、該当のサービスのです。

利用方法に加えて、利用した場合の影響につなお、ユーザへの周知内容は、各社の対応いて説明することが必要です。特に、ユーザ内容によっても異なりますが、ユーザは送信にはドメイン詐称に対する認識が少ないため、ドメイン認証という技術の理解をすることがどのような送信方法のメールがフィルタリン困難な場合も多いと想定されるため、表現方グされるかを図解なども用いて説明すること法や影響をよりわかりやすくする工夫が必要が推奨されます。

です。特に、「送信ドメイン認証技術」という表現にこだわらず、ユーザの理解を得られる表現を使うことも重要です。
5.4.1 送信側の対応

ユーザによるメールの利用方法により認証が失敗してしまう場合として、送信側では、ユーザが自社のサーバ（MSA）経由で送信アドレスを該当ドメイン以外で送信した場合と、ユーザが自社のサーバ以外のサーバから該当ドメインのメールを送信したケースの２つがあります。後者については、自社の管理外の問題であるため、ユーザに対して必ずしも説明する必要はないとも思えますが、前者と合わせて説明することが望ましいものです。
また、送信側の対応について、導入した技術と期待される効果を説明することが推奨されます。
5.4.2 受信側の対応

67