Sendmail社は、実環境への適用シナリオをもとにした長時間にわたる試験を実施し、昨年来話題になっている新しい電子メールの送信者認証技術のインターネット電子メールサイトへの導入方法についてのレコメンデーションを作成しました。以下に報告します。
送信者認証技術の目的は、いまだに自由に送信者を名乗ってメールを送信することを許してしまう、基本的に匿名の通信である電子メール通信に責任確認についてのレイヤを加えるというものです。
単純に誰がそのメッセージを送信したかという情報だけでは、そのメッセージがスパムかそうでないかを判断するのに充分ではありません。メッセージの送信元についての信頼性の高い情報が、メッセージを無条件に受け取る、フィルタ処理する、またその場で受信拒否するなどの、アクションを自動的に決定するときに非常に重要なツールになります。
この文書では、Sendmailの送信者と受信者のそれぞれに、いつ電子メール送信者認証を扱うべきかというレコメンデーションとともに、ソフトウェアやウィザードや試験のリソースなどへのリンクを末尾のページに紹介します。 電子メールの送信者認証技術の最新の情報については、http://sendmail.netにアクセスしてください。
現在の主要な認証方式はすべて、メールの送信元のドメインを認証する方法で策定されています。これによって、認証機構を導入する時に必要となるさまざまな作業をエンドユーザではなく、この新技術やそれを導入するプロセスを既に十分に理解しているシステム管理者が行えるようになっています。この認証方式には大きく２つの種類があります。１つはIPベース認証方式（メールを送信しているホストのアドレスを検査するもの）で、もう１つは、暗号化ベースの認証方式（メール上に設定してある電子署名を検査するもの）です。両者ともに送信者のドメインのDNSレコードに情報を公開し、その公開された情報をインバウンド（訳注：外部からサイト内部への方向）のメールゲートウェーで検査することで成り立っています。暗号化ベースの認証方式では送信者は送信するメールのすべてに電子署名する必要があります。
IPベース認証方式 - SPFとSender IDIPベースの認証方式はつぎのように動作します:メッセージの受信者はそのメッセージの送信者と”称する”ドメインにメールを送信するときに利用したIPアドレスのリストを知らせるよう要求します。もし、受信者が現在受け付けているコネクションの発信元がそのリスト上に含まれていれば、メッセージは認証成功したことになります。
IPベース認証を現在リードしているのは、Sender Policy Framework（SPF）とSender IDです。これらのプロトコルは同じようなレコード形式を利用しますが、メールの異なる部分を検査します。SPFでは、SMTP通信のなかでやり取りされるエンベロープのバウンスアドレス（訳注: MAIL FROM: の引数にあたるアドレス）を検査します。通常、エンドユーザがこのアドレスを目にする事はないので、ヘッダ詐称に対する防御としては弱いと言えます。Sender IDはFrom、Sender、Resent-From、Resent-Senderなどのユーザが目にするヘッダを検査します。それゆえ、ユーザが自分で使っているメールクライアントソフト上で見る情報を確認できます。ただ、注意が必要な点としては、認証されるアドレスが、ユーザが常に参照するFromアドレスでなくても良いという点です。
これら２つの方式での制限は、今日的なメールネットワークの複雑さと、メッセージが送信者から受信者に配送される経路の不確定さに起因しています。さまざまなメールの転送やメーリングリストシステムの実装から、正当なメールが、その送信者のアドレスが存在可能な領域の全く外部から送信されてくる場合があります。いずれの方式も、認証情報を複数のホップ（中継地点）にわたって伝搬させるために、メールを変更する仕組みをもっています（SPFでのSRSやSender IDでのPRA）が、実際には直前のホップの検査が可能なだけで、元々の送信者の検査はできません。それらのメールのデータ変更が、メール配送経路についての重要な詳細情報を変更してしまうため、また、メールのデータの変更処理が将来のend-to-end の暗号化ベース認証方式と互換性が保てない可能性があるため、Sendmailとしては、転送を行うサイトにSRSやPRAヘッダ追加を実施しない事をお勧めします 。
暗号化ベースの認証方式は、送信者のサイトにおいて、メールのいくつかのヘッダやボディに電子署名を作成して、それをメールに付加することで実現します。送信者は署名に利用した公開鍵を自身のDNS上で公開し、受信者がチェックできるようにします。メッセージの受信時には、そのメールの送信について責任をもったドメインの公開鍵を取得し、そのメール上の署名と取得した鍵と同時に公開してあるポリシーをもとに認証処理を実施します。
暗号化ベース方式の利点は、転送を実施する中継サーバでメールのデータ変更をしなくても、end-to-endの認証を提供できることです。メーリングリストにおいてヘッダを追加したりディスクレーマーを追加したりするなど、中継サーバがメールのデータを変更してしまい、電子署名の有効性を壊してしまう可能性があります。しかし、実際には中継点での多くのメールのデータ変更は、メールの転送や、メーリングリストサービスなどよく知られ、かつ明確に定義されたエージェント（訳注：転送を行うソフトウェアやメーリングリストサーバなど）により要求された処理の結果であるといえます。
いまある電子メールのインフラストラクチャは一筋縄でいく相手ではありません。メッセージは転送され、データ変更される場合もあり、また経路も変化します。時には送信者や受信者への理解なしに一方的に廃棄されたりもします。電子署名の利用を考慮しないでデザインされた柔軟すぎるプロトコルとさまざまな実装毎の違いが、伝送中でのメールのデータ操作を、一般的なものにし、また、実装毎に非常に異なったものにしています。 認証プロトコルが広く使われるようになったとしても、すべてのメッセージの送信元を特定できるようになるとは限りません。しかし、検査が必要な領域を他と切り離し、明確にすることが可能になります。
あるアドレスに到着したメールを第２のアドレスに再配送する処理です。最終的な受信者からの要求によって行われます。学生時代や以前の職場のアドレスや同好会（例えば、職能団体など）でのアドレス、また利用していないISPのアドレス、インターネットでの仮名アドレスなど、自分のメールアドレスに向けてメールの転送を行わなくてはいけない様々なアドレスがあります。そうした転送システムは普通、どのようにメールを受信したかについて、１つ１つ記録しながらメールを配送しています（大抵の場合、１、２行のReceived行を追加したり、アンチスパムやアンチウィルスシステムでの転送においてはヘッダの追加など）が、依然、メールの転送システムがメールを転送するときに、元々の認証情報を失ったり壊したりしてしまう可能性があります。とくにIPベース認証方式だと転送に対応できません。したがって、メールの受信者は転送アドレスから来たメールについてに注意することが重要です。転送中に認証情報が壊されてしまい、本来正しいメールであるにも関わらず、間違って認証に失敗して受信拒否されたり、廃棄されてしまう可能性に慎重に対応する必要があります。受信者はどこらかメールが転送されてきたか特定できるようにシステムを整備する必要がありますし、また、（信頼に足る）転送サイトにおいて受信されたメールが最終の配送先に転送されるまえに、認証を協調しておこなえるようにするなど特別な処理を実施する必要があります。
より信頼性の高い暗号化ソリューションに互換性のない変更を行う可能性があるので、Sendmailは現時点ではSRSや他のメール転送でのメールデータ変更の実施を推奨しません。
メーリングリストはインターネット上で共同作業する場合の基盤といえるツールになっており、また、今日では、複雑なソフトウェアパッケージによって運用されています。それらのソフトは特定の条件にあったメールだけをリストに配送するように、またリスト上のすべての宛先に正しくフォーマットしたメールを配送するよう厳密に動作します。 メーリングリストのヘッダを追加したり、"unsubscribe"する方法の説明をメール本文の先頭や末尾に追加したり、複数のメールの”ダイジェスト”を作成し１日に１度送信したりするようなメールデータの変更が一般に行われます。単純な複数アドレスへの展開以上の機能をもつメーリングリストはそれ自体が送信する実体として扱われるべきで、メーリングリスト自体が、これらの認証技術を利用するためのデータ変更を実施する必要があります。 認証されたアドレスからメーリングリストへメールを送信した場合は、メーリングリストは、そのオリジナルの送信者や、またそのアドレスがリストに投稿できる権限をもっているかについていくらか正確に判断できるようになります。メーリングリストの司会者は話題にあっていなかったり、攻撃的であったりするようなメールの送信者を特定できるようになります。認証を受ける送信者として、メーリングリストは自身のアドレスが正しい事をそのメーリングリストの参加者に証明できます。そして、参加者は、投稿されたメールを個々の投稿者からではなく、そのメーリングリストから配送されたものとして、認証し受信する事が可能になります。
一般的には、メーリングリストにとって認証システムの導入が実際に価値があると信じます。そして、メーリングリストの管理者に対して、この文書に説明してあるレコメンデーションの利用を強く推奨します。 特に、メーリングリストはそのリストに投稿しようとする送信者を認証するべきであり、必要であればその認証処理結果を参加者に通知するべきです。 参加者に対してメールを送信するものとして、メーリングリストの管理者はメーリングリストから出て行くメールが承認されたMAIL FROM （エンベロープ）アドレス（例えば、list-owner@list-domain.comなど）を使って正しく認証できるように設定する必要があります。そして、参加者に配送される前に、データ変更後のメールに再署名します。
マーケティングの資料等の大量配送のために契約しているサードパーティの送信者の把握と協力が必要です。彼らがどのようにシステムを運用しているかを理解する事と、あなたのドメインを悪用しないようなセーフガードの設定が必要になります。それらの外部の送信者の送信方法や送信した内容によって受信者の間で望ましくない評判が起きる場合を想定して、また、単に管理を簡単にするために、例えば、あなたのドメインのサブドメインの権限を彼らに与える方法も考えられます。そうすると個々のパートナーやマーケッティングのキャンペーン毎に暗号化用の鍵を変更できます。
送信者認証が世にひろまると、受信者があなたからのメールを受信する時に、あなたのドメインの過去の振る舞いを、あなたのメールを受信するかどうかを決める重要なポイントとすることに注意してください。パートナーのメール送信やマーケッティングのメールを別のドメインで区別することは賢明です。そうすることであなたのプライマリのドメインを厳密に管理でき、またサードパーティの起こした失敗によってあなたのドメインの評価に傷がつく事もありません。
Sendmailとしては、すべてのサイトで送信メールにIPベース認証方式と暗号化認証方式の両方を利用して認証するように計画することを推奨します。インターネットメールのインフラストラクチャの不確定な特性と、あなたが送信したメールが最終の受信者まで到達するときにどの経路で配送されるかを完全に知る事ができないという事実から、複数の認証方式を利用する事で、最後の受信者が受け取るときに、その送信者の証明がより容易になります。
SPFとSender IDのレコードは末尾に"~all"指定するべきです。そうすることで、あなたが”自分のドメインから送出されるメールがリレーサーバの一覧としてリストされているサーバから送出される事には自信があるが、異なる経路を通過したメールが正当かどうかについてはっきりと判断できない。”ということを受信者に伝える事ができます。この"Soft fail"指定はメールの受信についての厳しい基準を持っているサイトが過剰反応的にその場でメールを受信拒否してしまうことを防ぎます。
"~all"指定しないケースの１つに、あなたのドメインが一切メールを送信しない場合があります。そのような場合、"-all"レコードを１つ指定するだけで、このドメインからは決してメールが送信されない事、またこのドメインからメールが届いた場合は”詐称”されたものであるという事を伝える事ができます。
送信者へのレコメーンデーションとして、SPFとSender IDのレコードを公開することをおすすめします。"v=spf1"の１レコードを公開することで実施できます。いくつかのサイトでは特許出願中になっていることと、Sender IDのライセンスについて懸念をお持ちのようですが、しかしながら、これらの問題は受信側のサイトでメールを認証するときのプログラムコードに適用されるものです。送信者としては、受信者があなたのメールをチェックするのに必要な認証情報をできるだけ提供することが重要です。このことからも、２種類のレコードを公開する事を奨励しています。
Sender IDでチェックされる事になるあなたのメールのFrom:ヘッダと、SPFでチェックされることになる、MAIL FROM:のバウンスアドレスが同じ場合は、１つの"v=spf1"レコードを公開するだけでOKです。受信者はエンベロープとヘッダの両方にそのルールを適用するように解釈できます。From:ヘッダがエンベロープアドレスと異なる場合は、別の"spf2.0/pra"レコードを使ってそれらの違いを指示できます。もし、受信者にFrom:ヘッダかまたはバウンスアドレスのどちらかだけをチェックさせたい場合は、"v=spf1 ?all" か "spf2.0/pra ?all"のどちらかを公開します。受信者に対して、それぞれSPFで認証チェックさせるかSender IDで認証チェックさせるかを効果的に指定できます。
YahooやGmail、AOL、そしてEarthlinkなどが利用開始することで、DomainKeysは現在、暗号化（送信者認証）方式をリードしています。暗号化認証方式はIPベース認証方式にあるような転送に関する制限がないため、完全なend-to-endの認証方式であると言えます。受信者に可能な限り認証対象者の情報を与えるために、IPベースの認証方式と、電子署名をあわせて利用することをお勧めします。そうすることで、長期的にはメールリレーに関わる問題が特定できるとともにその問題を修正することが可能になります。
暗号化認証方式を利用する場合には、アウトバウンド送信の最終段階で電子署名を実施することが重要です。会社のディスクレーマーをメールに追加したり、メールを送信したメールクライアントが正しいフォーマットでメールを作成しておらず、メールを再フォーマットするなど、メールデータの変更が署名した後に行われると電子署名が壊れます。
暗号化認証方式は継続して改良がなされており、将来完全な標準が策定され、おそらくIETFより公開されることになります。これから1年の間にこの分野ではいくつかの成果が追加で報告されることが期待できます。
認証情報によって、受信者はメールを受信するしないの判断に利用できる全く新しい情報を得る事ができます。スパム送信者も自身のドメインを所有し認証可能なメールを送信する事が想定されるので、送信者認証それだけではそうした判断に十分な情報であるとは言えません。受信者はメールを受信するかしないかの最終判断をくだすために、許可リストやreputation（訳注:ドメインの信用評価）、またaccreditation（訳注:ドメインの信用認定）などそのホストに関する他の情報とあわせて評価することになります。
IPベースの認証方式や暗号化方式を含めて複数の認証情報を扱えるようにします。そうすることでそのうちの１つが転送中に破壊されたとしても、依然、認証できるようになります。
メールの送信者の認証にパスしたからと言って、そのメールが自動的に受信したいメールであると必ずしも判断される訳ではない事を理解する必要があります。すでに多くのスパム送信者がSPFや他のプロトコルを利用して、彼らの送出するメールを認証可能にしています。彼らは、認証チェックをパスしただけでそのメールを受信者が自動的に受け取ってくれる事を望んでいます。 検査にパスした認証情報を利用して、許可リストと比較したり、reputationサービスを利用したり、チャレンジ-レスポンス型の認証や、メール上のePostageの受容など他の方式を利用するなどつぎの段階の処理へ進む事が可能になります。
認証失敗したメールについては、そもそも認証チェックされていないものとして扱うべきです。または、すこし厳しくします。どのように認証に失敗したか、また最後に受信した時のメールの送信元（最終中継点が転送サービスであったかメーリングリストであったか）を判断の材料にします。認証チェックされていない、または認証失敗したメールについては、送信者のアドレスを元にチェックすることができませんので、（現在使われているような）コンテンツスキャンベースのスパムフィルタを利用してチェックするべきです。
認証情報が転送中に誤って破壊されてしまったかもしれない正当な（スパムでない）メールを特定するために、認証失敗したメールのフィルタリングの結果を比較します。そして、その情報を使って、認証失敗したという条件だけで厳しく扱わないようにしなくてはいけない特定の（転送やメーリングリスト）配送パスを把握できます。
SMTPプロトコルにおいてはメールを廃棄するのではなくて受信拒否するようにします。送信元のMTAに対して配送時に5xx番のパーマネントエラーを返します。そうすることで、そのメールをあなたのシステムの側で保存したり後で拒否する義務を追うことなく、メールの配送を拒否した事を相手のサイトに伝える事ができます。これは配送の条件にポジティブなフィードバックをあたえ、重要なメールが廃棄されてしまうことを防ぎます。
インターネット上には単なる送信者や受信者の他に様々な役割をもったものが存在します。ですので、認証情報を最も有効にしたたままメールを配送するために、そうした中継点においてどのようにメールを扱うかについてはいくつかの方法があります。
メールの転送者や、メールの送信者からの要求でメールを元々の内容を保って再配送するサイトは、メッセージの変更を最小限にとどめる必要があります。それらのサイトにおいて、SRS （SPF認証されたメッセージの転送のための手法）や（Sender IDにおいての）PRAヘッダの追加など、IPベースの認証方式において推奨されている転送時の調整の実施を推奨しません。インターネット上での転送は不確定なため、SPFやSender IDの情報が100%確実であることは期待できませんので、転送者は暗号化によるend-to-endの認証方式と互換性のないこれらのメールの変更を実施しないことをお勧めします。
メーリングリストは、メッセージ上の認証情報を利用するように変更する必要があります。そして、参加者に配送するアウトバウンドメールに認証情報を提供するようにします。 メールの受信において認証情報を活用することで、メーリングリストは、多くの参加者に再配送する前に、そのメールのオリジナルの送信者の正当性についてより確実に判断できます。もし、送信者がメールの受信時に認証されていれば、メーリングリストはその結果を再配送するメールのヘッダに追加するべきです。
メールがリストの参加者に送信されるとき、配送ソフトウェアはメールがそのリストから来たものとして認証されるように、エンベロープのFromアドレスを正しく設定するとともに、メッセージが"list-owner@list-domain.com"から送信されたことをしめすために、"Sender"ヘッダを追加します。 これによってもともとの投稿者を"From"ヘッダによって表示しながら、リスト自体の正当な認証を受信者に提供することができます。そして、受信者は、投稿者のひとりひとりを許可リストに追加しなくても、リスト自体を許可リストに入れたり、また、リスト自体の評判などをもとに判断できます。メッセージに再署名する以外のこれらの対策はすでにほとんどのメーリングリストマネージャでの常識な手法になっています。
新しい標準の常として、電子メール認証の世界ではこれからも多くの変更や推奨がこれからの１年、いや１ヶ月の間に現れてくるでしょう。 Sendmailはこれまでの18ヶ月間にこの技術に深く関わってきました。この文書はSendmailが自身のカスタマーのために、送信者認証がもたらす新しい可能性をよりよく利用できるように開発したベストプラクティスやレコメンデーションを反映しています。
電子メールの送信者認証は、この文書を作成した時点では予想もしなかった短い期間で広く適用されてきています。100,000以上の多くのドメインがSPF/Sender IDレコードを公開しており、その20%以上のドメインが送信時にアウトバウンドメールが認証できるようにしているという事を示唆する数値が報告されています。 暗号化認証方式についても同じような急速な拡大がみられ、主要なISPやWeb mailサイトが2004年の終わりまでに、彼らのメールに署名を開始するように計画しています。
すでに、多くのISPや商用やオープンソースのソフトウェアなどではSPFやSender ID、そしてDomainKeysなどの認証情報の存在が、受信を決定する要素になっています。 今年の夏の予測では、送信者は2004年の年末までに送出メールを認証可能にしたいと考え、2005年の終わりにはほとんどのサイトで配送に高い信頼性を得るため送信者認証が必要になるであろうと言われていました。この意見はその時点では少々アグレッシブであると思われましたが、現在では、大規模ISPなどが認証情報をもっていないメールを嫌い始めているという兆候をみるにあたって、少々悲観的な予想であると考えられます。
送信したメールが確実に配送されることを願う、また、自身のブランドやドメイン名の評判を守りたいと考えるすべてのサイトや企業等にとってこの新しい標準は非常に重要なものです。また、メールの送信者を確認したいという要求をもつすべての受信者に利用されるべきあり、メールのコンテンツフィルタリングといういままでのアプローチを利用する以外で、より信頼性の高いメールの受信方法を提供します。
メールの送信者認証を始めたい人を支援する多数のツールへのリンクをつぎにしめします。ツールやソフトウェアの最新のリストについては、http://sendmail.net/toolsをご覧ください。
本文書で解説した様々な認証方式についてのより詳しい情報についてつぎのWebサイトをご覧ください。
Sendmailではこれらの最先端の認証方式の実装をオープンソース、および商用版の sendmail MTAとともに利用できるオープンソースとしてリリースしております。Mailstream Content Managerの次期バージョンではこれらのプロトコルをサポートし、送信者認証の結果を利用しながら、複雑なメールの受信ポリシーを運用できる基盤ソフトウェアになります。
DNSにレコードを登録し、署名するソフトウェアをインストールすると、インバウンドとアウトバウンドの両方で実際にその動作を試験する必要があります。つぎのアドレスにメールを送信する事で試験できます。認証の状態のレポートが電子メールやWebページで提供されます。