|
ネットワーク WG Request for Comments： 2505 BCP： 30 分類： ベストカレントプラクティス |
G. Lindberg Chalmers University of Technology 1999年2月 |
(準備中)
この文書は、 インターネットの「現時点における最善の実践(BCP：ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (1999). All Rights Reserved.
このメモは、SMTP [1] とMTA (Mail Transfer Agents 例：sendmail [8])をspamの影響を減らすことができるようにするために、 これらについての数多くの実装推奨事項を提供します。
この意図は、「これらの推奨事項は、 インターネット上の十分なSMTP MTA上に適用された場合、 spam状況を一掃するのを助けること」と、「推奨事項は、 様々なMTAベンダーのためのガイドラインとして使われる必要があること」です。 我々は、「これは最終的な解決策ではないこと」を確かに認識していますが、 これらの推奨事項がすべてのインターネットSMTP MTA上に含められ、 使われた場合、物事は相当に向上し、 より長期的な解決策を設計するための時間を与えます。 「将来の作業」の章では、 このような長期的な解決策の一部である可能性があるいくつかのアイディアを示唆します。 しかし、「究極の解決策は、性格上技術的ではなく、社会的、 政治的もしくは法的である」可能性が高いです。
実装者は、 提案した手法のいくつかがもたらす可能性がある「増加したサービス妨害攻撃のリスク」について認識する必要があります。 例えば、DNSサーバーへの問い合わせ回数の増加や、 ログファイルの拡大は、攻撃時において、 システム過負荷とシステムクラッシュの両方を招く可能性があります。
このメモの簡潔な要約は、以下のとおり。：
このメモは、 BCP(Best Current Practice)のRFCです。 それゆえ、これは、SMTP MTAの実装者のために、 その製品をよりspamを予防／対処できるようにするガイドラインとして使われる必要があります。 これが主要な目的ではありますが、意図した副次的影響のひとつには、 システム管理者／ポストマスターのコミュニティに対して、 SMTP MTAが「spam対策手段」をもつことが期待されているので、 それを示唆することがあります。
しかし、このメモは、 「どのようにSMTP MTAを運用管理するか (どの「ノブ」を操作し、どのように設定するか)」 についての記述として、一般的に意図したものではありません。 示唆が提供された場合、それらには、明確に印を付けてあるので、 そのように読まれる必要があります。
しばしばspamと呼ばれるUBE(迷惑メール)は、短期間に相当、増加しており、 インターネット電子メールのコミュニティ全体の深刻な脅威となっています。 何かが、相当、速やかに行われる必要があります。
この問題には、いくつかのコンポーネントがあります。：
このメモは、spam問題に対する最終解決策であることを意図していません。
しかし、十分な数のインターネットMTAが下記のルール(特に、 Non-Relayルール)を十分に実施した場合、我々は、 スパマー達を衆目にさらされる表に出すことになります。 純粋に法的な行為が役立つか、あるいは、 我々が下記の他のルールを使うかのいずれにせよ、技術的に、 それらをブロックすることができます。 (なぜなら、Non-Relayルールは、今や彼らのホストやドメインについて、 表に見せるので、我々は、 様々なアクセスフィルターを彼らに対して適用できるので。) 実際、 法的手法と技術的手法の組み合わせが最善の結果をもたらす傾向があります。
このように、spam問題は、 インターネットコミュニティが現実の一般的な状況を設計し、 配備できるまで十分に低減できる可能性があります。
しかし、以下について注意してください。：
Non-Relayルール自体は、spamを止めるためには十分ではありません。 たとえ99%のSMTP MTAがそれらを1日で実装した場合でも、スパマーは、 なおも、残りの1%を見つけて、それらを使うことでしょう。 あるいは、スパマーは、ギアを切り替えて、 各すべての受信ホスト宛てに直接接続してしまうだけです。 このようにすることは、スパマーにとっては、 より高い費用となりますが、可能性は十分にあります。
IPv6の採用が近い可能性があるとはいえ、spam問題は既にここにあり、 それゆえ、このメモは、現行IPv4に限定します。
このメモを通じて、 我々は、RFC2119 [4] の用語法を使います。：
このメモにおいて、我々は、しばしば、 「ホスト名(host name)」もしくは「ドメイン名(domain name)」という用語を使います。 これは、FQDN (Fully Qualified Domain Name)として解釈される必要があります。 これによって、我々は、そのDNSからPTR query (.IN-ADDR.ARPA)に対応して返された名前を意味します。 (すなわち、IPアドレスが名前に変換されるとき。) あるいは、我々は、 それに関連づけられたDNSのAもしくはMXレコードについての名前を意味します。 (RFC1034 [5] および RFC1035 [6])
我々がIPアドレスではなく、FQDNの利用を示唆するとき、これは、FQDNが、 直感的に、はるかに使い易いからです。 しかし、このような用法すべては、DNSと.IN-ADDR.ARPA (PTR)情報に重く依存します。 それを偽装するのは相当に容易であるので(DNSサーバーに投入された偽のキャッシュ情報によるか、 あるいは、スパマーが偽の情報をもつ自身のDNSを動作させることのいずれかによって)、 ホスト名やドメイン名は、注意深く使われなければなりません。 (例：アドレス→名前の変換が、 名前→アドレスの変換に対応するように検証される。) Secure DNS (RFC2065 [7])を使えば、 物事は、向上します。 なぜなら、.IN-ADDR.ARPAのなりすましは、もはや不可能となるからです。
推奨事項のひとつは、 (適切なDNS情報が当該ドメインについて存在すると想定して)"MAIL From:" (デジタル封筒の発信)ドメインをDNSで検証することについてです。 この機能を利用するとき、考慮すべき事項がいくつかあります。：
一方、弱いDNS接続性しかもたないサイトは、 「サイトの正規のメールには、 受信者がその"MAIL From:" を検証するとき、 DNSタイムアウトに起因して、 宛先に到達しない問題があること 」を発見する可能性があります。 しかし、DNS情報は、非同期的に扱われ、 たとえ最初の要求者が諦めたとしてもキャッシュされるので、 後で試すときには必要不可欠な情報がそこにある可能性は高いといえます。
最近のspamソフトウェアについて、"MAIL From:" のチェックは、 さらに役に立ちません。 なぜなら、spamソフトウェアも、進化し、 存在するメールアドレスを使い始めるからです。 (これが合法的であるか否かは、このメモの範囲外です。) しかし、少なくとも、インターネットは、 「このテストがUAについての誤記や誤設定を止めること」から副次的効果の恩恵を受けることができます。
我々の基本的な想定は、棄却／許容は、SMTP層において扱われ、
あるメッセージの拒否を決定するMTAは、
SMTP対話中にそのようにする必要があるということです。
まず、これは、我々は、後でメッセージの拒否を決定するために、
そのコピーを蓄える必要がないということ、また、
第2に我々のそのメッセージに対する責任は低いかまたはないことを意味します。
- 我々は、まだそのメッセージを読んでいないので、
そのエラー処理を送信者に任せます。
SMTPは、戻りコードについて、いくつかのクラスをもっています。 検討のためには、[1] を参照してください。：
このメモ中に記述されたオプション「ノブ」を利用するとき、 考慮すべき事項がいくつかあります。：
「拒否 - あなたは、スパマーのリストにあります。」このような、
いくつかのイベントについて、5xxは、
正しい戻りコードである可能性があります。
なぜなら、そのコードはセッションを直ちに終了させ、
われわれはそれ(そのセッション)を完了させるからです。
(そのスパマーは、そう決めたのではないかもしれませんが、
SMTPの規則に従うと想定します。
- 実際、スパマーは戻りコードにかかわらずメールを待ち行列に戻したり、
他のホストに送ったりすることができます。 )
しかし、設定中の5xxの誤りは、
正規のメールがはね返ることをもたらす可能性があり、これは、
極めて不幸なことでしょう。
それゆえ、我々は、大部分の場合についての戻りコードとして、
4xxを示唆します。
これは、致命的エラーではないので、
当該メールは、送信者側で再び待ち行列に入れられ、
我々はメールをはね返すのではなく、
設定エラーを発見し修正する余裕が少なくともできます。
(典型的には、これは、
我々がその(ドメインの)MXリストに載っているので実際には受け入れるべきドメインへの中継を拒否するときです。)
4xxレスポンスは、また、スパマーのホストに対し、
メールを再び待ち行列に入れさせます。
もし、これをやるのが本当にスパマー自身のホストであれば、
おそらく良いことでしょう。
- 彼自身のスパムで彼のディスクをいっぱいにすることになるから。
一方、彼が中継ホストとして誰か他の人を使っている場合、
待ち行列に入っているすべてのspamメールは、
「何か悪いことが行われており、
その中継ホストに注意すべきである」という相当に強い証拠です。
しかし、4xx Temporaryエラーは、 MXレコードと予期しなかった相互作用をもつ可能性があります。 受信するドメインがいくつかのMXレコードをもち、 最も優先順位が若いMXホストが"451"戻りコードをもつメールの受信を拒否する場合、 送信ホストは、 (しばしばそうしますが)MXリストの次のホストを使うことを選択する可能性があります。
その次のMXホストが同一の拒否リストをもたない場合、当然ながら、 そのホストは、そのメールを受け入れるでしょう。 そして、「最終ホストがまだメール("MAIL From:")の一部の受信を拒否している」ことに気づくだけです。 我々の意図は、違犯メールを違犯している送信者のホストに留め、 彼のメール待ち行列のディスクをいっぱいにすることですが、 そのメールは結局次に優先度の若いMXホストである我々の友人のところに行き着いてしまいます。
最後に、
「人は2xx戻りコードを使うことができますが、
それにもかかわらずspamメールを転送したり受信したりしない決定をすること
(典型的な代替手段は、他の場所(例： /dev/null)に保存することです。) 」
が示唆されてきました。
これは、明確に、RFC821の意図を侵害しているので、
注意深い考慮なしに行ってはなりません。
-やみくもにメールを落とす代わりに、それを再び待ち行列に入れ、
手動(または自動)でそれがspamか正規のメールか、
またそれが棄却されるべきか、あるいは、
転送されるべきかを検査することができます。
メーリングリストや、多数の受信者宛の拡張を使う能力ももつMTAは、 送信者を認可し、spamからリストを防護できる必要があります。 このためのメカニズムは、 通常のメールと通常のユーザのものとは大きく異なる可能性があり、 このメモ中では扱われていません。
ここで、我々は、まず、推奨事項の簡潔な一覧を提供し、次に、 それぞれについて、より完全な検討を提供します。 また、我々は、「すべからず」事項についての推奨事項を提供します。 この推奨事項は、 spamとの戦いにおいて自然であると考えられる (そして今までのところは有効であった)かもしれませんが、 インターネットメールに大混乱をもたらす可能性があり、それゆえ、 良いことよりも、より大きな被害をもたらす可能性があります。
| 1) | Mail Relayとしての認可されていない利用を制限できなければなりません(MUST)。 |
| 2) | スパマーたちがHELO文などにおいて偽造したホスト名を使うにかかわらず、 メールの経路を追跡可能にするために、 十分な情報をもつ"Received:"行を提供できなければなりません(MUST)。 |
| 3) | 事後的に、 イベントを追跡可能にるすサイト内のログ情報を提供できなければなりません(MUST)。 |
| 4) | 中継対策/スパム対策の活動の全ての出来事のログを記録できる必要があります(SHOULD)。 |
| 5) | ホストから、もしくは、 ホスト群からのメールを拒否できる必要があります(SHOULD)。 |
| 6a) | "MAIL From: <>"を拒否してはなりません(MUST NOT)。 |
| 6b) | "MAIL From: <user@my.local.dom.ain>"を拒否してはなりません(MUST NOT)。 |
| 7a) | 特定の"MAIL From:"ユーザ<foo@domain.example>からのメールを拒否できる必要があります(SHOULD)。 |
| 7b) | "MAIL From:"ドメイン<.*@domain.example>全体からのメールを拒否できる必要があります(SHOULD)。 |
| 8) | ("Rate Control")メールのフローを制限できる必要があります(SHOULD)。 |
| 9) | (DNS または 他の手段を使って) "MAIL From:"ドメインを検証できる必要があります(SHOULD)。 |
| 10) | 送信メール中の<local-part>を検証できる必要があります(SHOULD)。 |
| 11) | SMTP VRFYとEXPNを制御できる必要があります(SHOULD)。 |
| 12) | SMTP ETRNを制御できる必要があります(SHOULD)。 |
| 13) |
異なるルールについては、
異なる戻りコードを提供するように設定できなければなりません(MUST)
(例： 451 Temp Fail vs 550 Fatal エラー)。 |
下記の検討は、しばしば、 ドメイン名／ホスト名やIPアドレス／サブネットについて、 様々な形態のパターンマッチングを行うことの必要性で締めくくられます。
「それ(パターンマッチング)をするためのデータ/テンプレートは、
MTAの外に提供されること
(例：パターンマッチングルールはMTAに含まれるが、
実際のパターンは外部ファイルにおくことができる)」が推奨されます(RECOMMENDED)。
「当該パターンマッチングルール(外部ファイル)は、
最大限の柔軟性を与える正規表現を含むことができること」も推奨されます(RECOMMENDED)。
当然ながら、ドメイン名／ホスト名についての文字列マッチングは、 大文字／小文字の区別があってはなりません(MUST NOT)。 なぜなら、<local-part>は、 大文字／小文字の区別がある可能性があるので、ここでは、 それをそのままにすることが自然である可能性があるからです。 しかし、<sPAmMeR@domain.example>と<spammer@domain.example>は、 おそらく同一のユーザであり、比較する文字列は、 彼のメッセージを拒否するために使われるので、我々は、 「<local-part>の比較も、大文字／小文字を区別しない」と想定します。
これらすべての推奨事項に適用されるべき解釈は柔軟性です−我々が今日スパム対策ルールを如何にうまく設計したとしても、 スパマーは、それらをかいくぐる方法を発見するであろうし、 うまく設計されたMTAは、 それらの新しい脅威に適合するために十分に柔軟である必要があります。
メール中継器としてのホストの認可されていない利用は、 中継器の資源の盗用を意味し、 その中継器の所有者の評判をリスクにさらします。 これは、また、正規のメールをブロックするのと同時にspamをフィルタしたり、 あるいは、ブロックすることを不可能にします。
それゆえ、MTAは、 このような中継の用法を制御／棄却できなければなりません(MUST)。
SMTPセッションにおいて、我々は4つの要素をもち、各々は、 様々な程度の信頼性をもちます。：
(準備中)
1.および2.は、あまりに安易にかつ、しばしば偽装されるので、我々は、 メール中継としての我々のホストの利用法を認可するためには、 まったく、それらに依存することができません。
代わりに、MTAは、下記の組み合わせに基づいて、 メール中継の利用法を認証することができなければなりません(MUST)。：
示唆されるアルゴリズムは、以下のとおり。：
a. をする場合
あなたは、
全ての種類のSMTPソースルーティング(公式な[@a,@b:u@c]、
'%'区切りおよびuucp-style '!'パスすべて)
がテスト前に完全に削除されているか、
または少なくともそれが考慮されていることを確認しておかなければなりません。
この要件を実装しているサイトは、
「正しく宛てられたメッセージ、特に、
SMTP以外のメールシステムへのゲートウェイにおいて開始または終了するものをブロックしてしまう可能性があること」
も認識しておかなければなりません。
このようなポリシーを実施する前に、
他のメールシステムにおいて、
または一時的に使用されている全てのルーティングアルゴリズムを確実に知るために、
注意深い棚卸しが行われる必要があります。
このようなシステムの各々は、「場合に応じて」面倒をみなければなりません。
このようなメールシステムの例と、 それらのアドレッシングスキームは、 下記種別のアドレスをもったX.400です。：
"/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway
これ以外の例には、DECnet MAIL-11が含まれ、これは、 次の形式のアドレスをもつ可能性があります。：
"gateway::smtp%\"user@final\""@mail-11-gateway
すべての場合において、設定は、
FQDNとクラスフルIPアドレスについてワイルドカードをサポートしなければならず(MUST)、
クラスレスIPアドレスについて"address/mask"をサポートする必要があります(SHOULD)。
(例：domain.exampleと*.domain.example; 10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23)
この設定は、 判定／テンプレートのデータが外部ソース(例：テキストファイルまたはdbmデータベース)によって提供されることを許可する必要があります(SHOULD)。 判定／テンプレートは、 正規表現を含むことが許容される必要があります(SHOULD)。
MTAは、メール中に、(RFC822 [2] に記述され、 RFC1123 [3] で要求されているように) "Received:"行を前に付けなければなりません(MUST)。 この"Received:"行は、その送信者まで逆に、 そのメールのパスを追跡できるようにするために、 十分な情報を含まなければなりません(MUST)。 2つの場合があります。：
インターネットメールは、送信ホストが、 MXレコードによって記述されているように、 受信者に直接接続するように(重要度リスト(priority list)上にいくつかのMXホストがある可能性がある)設計されました。 送信ホスト(これは、後述するように、 ファイアウォール／ゲートウェイである可能性がある。) を逆に追跡できる可能性を確保するために、 経路上の各MTA(最後のMTAを含む)は、 "Received:"行を前に付けなければなりません(MUST)。 このような"Received:"行について、我々は、下記の事項をもちます。：
含まなければならない(MUST)もの。：
(準備中)
含む必要がある(SHOULD)もの。：
「RFC822に記述されたその他のほとんどの"Received:"フィールドは、 "Received:"行に含まれるべきであること」が示唆されます。
基本的に、メッセージを追跡するのに有用なあらゆる情報は、
"Received:"行に付加することができ、付加する必要があります。
「たとえ最初の送信がnon-SMTP(例えば、
クライアントとサーバ間通信にhttpが使われるwebベースのメールのクライアント 経由の送信)であるときでも、
"Received:"行は、メールが作成されたhttpサーバに接続するときに、
どのIPアドレスが使われたかを述べているコネクションを識別するために使えること」は事実です。
これらの推奨事項は、
RFC1123 [3] よりも意図的に強く、
「スパマーのホストから受信者宛に、直接、送信されたメールが、
十分な精度で追跡できること」を保証するためにあります。
典型例は、
「スパマーがダイアルアップのアカウントを使い、
当該ISPがスパマーに対するアクションをとることが出来るように、
'date-time'にあるスパマーのIPアドレスをもつことを必要とするとき」です。
内部ネットワーク構成を隠すポリシーをもつ組織体は、やはり、 そのようにすることが許され、そのようにできなければなりません。 その組織体は、通常、 その内部MTAがごく限られた量の情報と共に"Received:"行を前に付けるか、 あるいは、何も前に付けないようにします。 そして、かれらは、 そのメールをいくつかの種類のファイアウォール／ゲートウェイ装置を通して送信しますが、 ファイアウォール／ゲートウェイ装置は、 それ自身の"Received:"行を付ける前に、 (RFC1123 [3]に要求されるように)内部のMTAの"Received:"行全ての削除すらしてもかまいません。
そのようにすることによって、
かれらは組織体の内部から送信したスパマーたちを追跡することに完全責任を負うか、
またはそのようなスパマーの活動に責任を持たされることを受け入れます。
「彼らの送信メール中に提供される情報が、彼らにとって、
いかなる必要不可欠な追跡を行うためにも十分であること」が要求されます(REQUIRED)。
組織体宛に届くメールの場合、"Received:"行は、
「内部でメールを受信するユーザが、
到着メッセージを発信元まで追跡するのに必要な情報を与えることができること」
を確保するために無傷に保たれなければなりません(MUST)。
一般に、ゲートウェイは、
そのようにすることがセキュリティ要件でない限り、
"Received:"行を変更したり削除してはいけません(SHOULD NOT)。
いくつかの種類のメールゲートウェイを通過するときに、
既存の"Received:"行が意味をなすようにするために、
その内容を変更することは、大部分の場合、
メッセージを追跡可能にするのに必要な情報を破壊し、
削除してしまいます。
"Received:"行中の情報を保護するために、注意をしなければなりません。
"Received:"行中の情報は、メッセージ自体、または 受信者が得たメール、
またはそれが不可能な場合ログファイル中にあります。
MTAは、イベントを追跡できるように、 十分なローカルのログ情報を提供できなければなりません(MUST)。 これは、"Received:"行中に大部分の情報を含めます。上記参照。
MTAは、中継対策／spam対策のすべての活動を記録できる必要があります(SHOULD)。 ログの項目は、少なくとも以下のものを含む必要があります。：
「より多くのイベント(特に、 拒否された電子メール)を記録することによって、 サービス妨害攻撃の可能性(例えば、大量の"RCPT To:"コマンドを受けることによって、 ログを溢れさせることによる)を開いてしまうこと」に注意する必要があります。 この記述によって増加するログ記録を実装するものは、 「(特に攻撃の間)ログファイルの大きさが増大する」事実を認識していなければなりません。
MTAは、特定のホストからのメール、もしくは、 ホスト群からのメールを受容もしくは拒否できる必要があります(SHOULD)。 ここで、我々は、送信元IPアドレス、もしくは、 その.IN-ADDR.ARPAの解決先のFQDN(あなたがDNSを信頼するかどうかによりますが)を意味します。 この機能は、ファイアウォールに実装できますが、MTAは、 「自身を」防護できる必要があるので、我々は、 MTAも(この機能を)同様にできることを推奨します。
「MTAがFQDNホスト名(host.domain.example)、 ワイルドカードのドメイン名(*.domain.example)、 個別のIPアドレス(10.11.12.13)、 プリフィックス長を持ったIPアドレス (10.0.0.0/8, 192.168.1.0/24) に基づいて判断できること」が推奨されます(RECOMMENDED)。
「これらの判定ルールを組み合わせて受容／拒否／受容／拒否についての柔軟なリストを形成できること」も推奨されます(RECOMMENDED)。
例：
accept host.domain.example
refuse *.domain.example
accept 10.11.12.13
accept 192.168.1.0/24
refuse 10.0.0.0/8
そのリストは、最初の該当まで検索され、その受容／拒否の動作は、 それ(検索結果の該当行)に基づきます。
IPアドレス/長さが、推奨されます(RECOMMENDED)。 しかし、ワイルドカードをもつ実装(例：10.11.12.* (バイト境界のみにあるクラスフルネットワーク ))は、 当然ながら、それらをもたないものよりもはるかに良いです。
フィルタリングをさらに良くするために、MTAは、 ホスト名について使われる(潜在的には、 IPアドレスについても使える)完全な正規表現を提供することができます(MAY)。
スパマーとの戦いは重要ですが、これは、決して、 既存の電子メール標準を侵害する方法で行われてはなりません。 スパマーは、しばしば、 "MAIL From:"アドレスを偽装するので、 それ(特に、何らかの「明らかな」アドレス)に対して、 一般的な制限を設ける誘惑にかられます。 しかし、これは、 spamがするより大きな混乱をメールコミュニティにもたらす可能性があります。
特定のホスもしくはサイトからのメールを拒否する必要があるとき、
我々の推奨事項は、このメモ中に述べられた他の手法を使うことです。
(例： どの"MAIL From:"が使われていたかに関わらず、
SMTP_Callerアドレス(もしくは、名前)に基づいてメールを拒否する。)
MTAは、"MAIL From: <>" を受信することを拒否してはなりません(MUST NOT)。
"MAIL From: <>"アドレスは、 メールシステム自体からのエラーメッセージに使われます。 (例：正規のメール中継が使われており、 エラーメッセージを当該ユーザ宛に返送するとき。) このようなメールを受信することを拒否することは、 「ユーザが、その送信メールにおけるエラー(例："User unknown") について通知されない可能性があること」を意味します。 これは、間違いなく、 spamがするより大きな混乱をメールコミュニティにもたらします。
このような正規の"MAIL From: <>"の最も卑近な事例は、 ひとりの受信者宛てのものであり、すなわち、 ひとつのエラーメッセージが、ひとりの個人宛に返される場合です。 スパマーは、多くの受信者宛に送るのに"MAIL From: <>"を使っているので、 そのようなメールは完全に拒否するか、 または最初の受信者以外は全て拒否する気にさせられます。 しかし、エラーメールが複数の受信者(例：同じリモートのサイトにある、 いくつかのリストオーナーを持つリスト(ではエラーメールが複数のリストオーナーに届くことがある：訳注)に届くのには、 正当な理由があり、それゆえ、MTAは、 この場合でも"MAIL From: <>"を拒否してはなりません(MUST NOT)。
しかし、MTAは、複数の"RCPT To:"がある場合、 当該TCPコネクション("read()"の頻度)を押さえても構いません(MAY)。 そして、 その方法によりスパマーが"MAIL From: <>"を使うのを低減します。
MTAは、"MAIL From: <user@my.local.dom.ain>"を拒否してはなりません(MUST NOT)。
(準備中)
"my.local.dom.ain"は、localとして扱われ、 ローカル配信をもたらすドメイン名を意味するものとします。 一見、「誰も"MAIL From: <user@my.local.dom.ain>"を使う必要がない」ように見えるかもしれません。 それ(MAIL From: <user@my.local.dom.ain>)を使うかもしれない人を制限することは、 詐欺のリスクを低減し、ひいては、spamを低減する可能性があります。 これは、(超)短期的には真であるかもしれませんが、 少なくとも(次の)2つの正規の利用法を捨てることにもなります。
"MAIL From: <user@my.local.dom.ain>"が棄却された場合、 これらの両方の場合、正規のメールの配信失敗に陥ります。
MTAは、特定の"MAIL From:"ユーザ(foo@domain.example)からのメール、 もしくは、"MAIL From:"ドメイン(domain.example)全体からのメールを受信することを拒否できる必要があります(SHOULD)。 一般に、この種のルールは、あまりに頻繁に、 "MAIL From:"を書き換えるスパマーによって乗り越えられてしまいますが、 一定のユーザ、もしくは、一定のドメインをブロックする能力は、 攻撃がちょうど発見され、継続中であるときに極めて有用です。
"MAIL From: <>"
と
"MAIL From: <user@my.local.dom.ain>"
は、他のポリシーが当該コネクションをブロックするときを除いて、
拒否されてはならない(MUST NOT)こと(上記参照)に注意してください。
(例：そのピアのSMTP_Caller IPアドレスが、
意図的に拒否されているネットワークに属するとき。)
MTAは、 メールホストにメールが送受信されるレートを制御するためのツールを提供する必要があります(SHOULD)。 このアイディアは、2つの事項から成ります。：
メール送信について、これは、 許容可能なデータ出力レートを設定するために、 そのTCPコネクションを調節することによって行われなければなりません。 (例：write()の頻度を減らす。)
メール受信について、我々は、 基本的に同様のテクニック(例：read()の頻度を低減する)を使うことができ、 あるいは、 我々が受信できないという信号を4xx戻りコードで送ることができます。 「そのような動作をする判断は、"MAIL From:"ユーザ、 "MAIL From:"ドメイン、SMTP_Caller(名前／アドレス)、 "RCPT TO:"、もしくは、 これらすべての組み合わせに基づくこと」が推奨されます(RECOMMENDED)。
MTAは、"MAIL From:"ドメインのシンプルな"sanity check"を行い、 そのドメインが存在しない場合(すなわち、 MXレコードもしくはAレコードをもつように解決しない場合)、 メールの受信を拒否できる必要があります(SHOULD)。 そのDNSエラーが暫定的(TempFail)である場合、MTAは、 戻りコード4xx (Temporaryエラー)を返さなければなりません(MUST)。 そのDNSエラーがAuthoritative NXdomain (host/domain unknown)である場合、MTAは、なおも、 4xx戻りコードを返す必要があります(SHOULD)。 (なぜなら、これは、単に、 同期されていないプライマリDNSやセカンダリDNSである可能性があるからです。) しかし、これは、 (システム管理者によって設定されるように)5xx戻りコードを許容する可能性があります(MAY)。
MTAは、送信メールの<local-part>の送信者名が実在するユーザもしくは既存のエイリアスであるように、 検証されるようにすることを許可する必要があります(SHOULD)。 これは、基本的に、インターネットの他の部分を、多様な「誤記(typos)」
MAIL From: <fo0bar@domain.example>
および／または、悪意あるユーザ
MAIL From: <I.am.unknown.to.you.he.he@domain.example>
からまもるためのものです。 いつものように、これは、 熱心なスパマーによって乗り越えられてしまう可能性がありますが、 中継について、より厳密なルールがあるとき、これは、より難しくなります。 事実、 最初の(かつ公式な)メール中継において「誤記」を補足すること自体は、 この推奨事項の動機として十分なものです。
SMTP VRFYとEXPNの両者は、 潜在的スパマーに「スパマーのリスト上のアドレスが、 正規のものであるか否か？(VRFY)」をテストし、 より多くのアドレスを得る手段(EXPN)さえも提供します。 それゆえ、MTAは、「誰が、 これらのコマンドを発行することを許可されているか？」を制御する必要があります(SHOULD)。 これは、"on/off"である可能性があり、あるいは、 以前に述べたものと同様なアクセスリストを使う可能性があります。
「"VRFY"コマンドは、 RFC821 [1] に従って要求されること」に注意してください。 しかし、そのレスポンスは、 "off"もしくは「アクセスリストによってブロックされたこと」を表現するために、 "252 Argument not checked"である可能性があります。 これは、デフォルトである必要があります。
"EXPN"コマンドについてのデフォルトは、"off" である必要があります。
SMTP ETRNは、「MTAが、 そのメールの待ち行列を再実行すること」を意味し、これは、 極めて高価であり、 サービス妨害攻撃について無防備である可能性があります。 それゆえ、MTAは、 「誰がETRNコマンドを発行することを許可されているか？」を制御する必要があります(SHOULD)。 これは、"on/off"である可能性があり、あるいは、 以前に述べたものと同様なアクセスリストを使う可能性があります。 デフォルトは、"off"である必要があります。
ここにおける主要な論点は、柔軟性です。 (「5xxを返して設定の誤りの理由で正規のメールを直ちに失敗させることと、 4xx を返し、 ログファイルの調査を通じてそのような設定の誤りを見つけることができるようにすることの二律背反のバランスをどのようにとるか？」を文書中に規定することは、 単純に無理です。)
それゆえ、MTAは、異なるルールもしくはポリシーについて、"Success" (2xx)、"Temporary Failure" (4xx)、もしくは、"Permanent Failure" (5xx)を提供する設定をされなければなりません(MUST)。 しかし、最初の数字 (2, 4, 5)以外の正確な戻りコードは、 設定可能であってはいけません。 その理由は、 当該ソフトウェアを誤ったやり方に設定することを容易にしてしまうためと、 「『具体的に、どのエラーコードを使うか？』についての選択は、 非常に微妙であり、多くのソフトウェア実装は、 戻りコードの最初の数字(2, 4, 5)以上のチェックをする」という事実によります。
しかし、レスポンスがDNSルックアップの結果であり、 DNSシステムがTempFail (temporaryエラー)を返したとき、 MTAは、これを反映して、 戻りコード4xxを提供しなければなりません(MUST)。 DNSレスポンスがAuthoritative NXdomain (host or domain unknown)である場合、 MTAは、これを戻りコード5xxによって反映することができます(MAY)。
追加的情報については、 SMTP戻りコードについての以前の議論を参照してください。
(準備中)
Chalmers University of Technologyにおいて、我々のDNSは、
cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se.
IN MX 100 mail.chalmers.se.
を含み、 大部分のサブドメインについても同様です。 すなわち、 各サブドメインへのメールを格納するための第2ホストは、 それらのメールホストを下にするべきです。 これは、「mail.chalmers.seは、 それが提供するサブドメイン("RCPT To:")のためのメール中継として振る舞うことを準備をしなければならないこと」と、 「それらのサブドメインのメールホストは、 mail.chalmers.seからのSMTPコネクションを受容しなければならないこと」を意味します。 最近のバージョンのspamソフトウェアは、 それらのメールがわれわれのサブドメインに配信されるように常にmail.chalmers.seを使うことによって、 この事実を利用しています。 また、そのようにすることによって、彼らは、 まだメール中継が彼らのために行われるようにし、 受信ホストが、 送信ホストのFQDNもしくはIPアドレスに基づいたSMTP接続拒否をすることを妨げます。
我々がセカンダリMXホストを持つ設計を保つ限り、我々は、少なくとも、 5xx戻りコードをもってしてでないと、 本当にmail.chalmers.seにメール中継を拒否させることはできません。 しかし、この可能性を利用するホスト／ドメイン／ネットワークを識別し、 それらのために、 そしてそれらのためだけにメール中継器として活動することを拒否する(4xx戻りコードでそうする)ことは、 かなり直線的でした。
それらからの正規のメールは、最終的な受信ホストがダウンしていたら、 遅延するかもしれません。 しかし、再起動されたときに(4xx 戻りコードなので)結局配信されるでしょう。
そして、これは我々のMX設計を変更しても悪くなることはありません。 spamは、今や、"Denied"レスポンスに直面し、 (その)SMTPコネクションを拒否することを決めている可能性がある、 すべての各受信者宛てに接続しなければなりません。
最低限(の要件)は、
「これが、
1) the Relay Authorization コードにおける十分な柔軟性と
2) Return コードの割り当てにおける十分な柔軟性
によって可能とされていること」です。
(いつも5xx戻りコードを返すMTAは、これを完全に不可能にしてしまいます。)
このメモは、 MTAと、それらの推奨事項についてのものではありますが、 個々で行われることには、 UA (User Agents：通常のメールプログラム)にも影響を与えるものがあります。
UAは、2つのことを行います。：
MTAが、今や、上述の様々な中継対策フィルタを実装し始めたとき、 ノートPC上のUAは、 "Relaying Denied"のようなレスポンスを得る可能性があります。 それは、単に、たまたま、未知の範囲内のアドレス、あるいは、 未知のFQDNに解決されるIPアドレスを使うことになることに起因します。
この"Relaying Denied"レスポンスの典型的な被害者は、 出張にノートPCを携帯するセールスマン、あるいは、 IETFの会場ホテルに居る参加者でしょう。 そのセールスマンは、おそらく、一番近いISPの番号にダイアルし、 そのダイアルアップのプールからIPアドレスを得ます。 IETFの参加者は、ターミナルルームからIPアドレスを使います。 両方の場合において、彼らのクライアントメーラー(UA； 例： pine, Netscape, Eudora)は、 メールを自らもつMTA (例：SMTP-SERVER=mail.home.example)経由で送信することを試みますが、 mail.home.exampleが、 その(一時的な)IPアドレスを受容するように更新されていない限り、 それは、"Relaying Denied"を返し、拒否します。
この問題に対応するために、我々は、単に、 ターミナルルームもしくはダイアルアッププールのIPネットワークをmail.home.exampleにおいて許容されたネットワークのリストに追加することができます。 これは、 スパマーたちがそのホストをメール中継器として使ういくつかの最小のリスクを開けます。： スパマーが同一のISPのダイアルアップを使い、 われわれのセールスマンが出張しているのと同じときにmail.home.exampleを使うように設定する場合、 彼らは、mail.home.exampleを通じて彼らのspamを中継することが認可されます。 しかし、これは、非常に起こりやすいことではありません。 われわれがすべての世界を常にオープンにするのではなく、 ログファイルを常に詳細に観察し、 使われていることを見つけたら直ちに中継を中止するかぎり、 この解決策は、おそらく、十分に良いものです。
その他の解決策は、我々のセールスマンが、 現在のダイアルアップISPにメール中継サービスがある場合、 そのメール中継をつかうことです。 そのようにするために、彼は、適当であろうとなかろうと、 UAのSMTP-SERVER=を変更しなければなりません。
しかし、この状況を扱う正しいやり方は、 UAとMTA間において何らかの他のメール送信プロトコルによることです。
分離された送信(submission)プロトコルは存在しませんが、 このためのSMTPのプロファイル「メッセージの送信(Submission)」仕様[9] が、 最近、規定されました。
あるいは、(我々は、) 「SMTP認証作業 [10] がすべて機能したときには、 認証されたSMTPは、 UAとhome MTA間のプロトコルを提供することを許可されるであろう(ここでは、 それが新しいプロトコルか、 それとも"古いSMTPと同じもの"と考えられるか否かに関係なく)」と記すことができます。
これは、2.1 節において示唆された中継アルゴリズムに、 ひとつの要素を追加します。：
+ "SMTP認証済"の場合、中継することを許容する。
すべてのユーザは、個人であるので、 「あらゆる中央集権的spam対策行為が、彼ら全員に適する」という希望は、 ほとんどありません。 (事実、何らかのspam対策ルールの中心的なセットがユーザの承認なしに強要された場合、 人々は、言論の自由の侵害について論じることができ、またそうします。 (当然ながら、人は、 spamが本当に誰にでも何かを加えるのかについても論じることができます。 しかし、それは中央で決定されるより、個々のユーザが決めるべきことです。)
それゆえ、唯一の合理的な拡張は、 個人向けspam対策フィルター(すなわち、 このメモに既述のもののようなspam対策フィルター)を許容しつつ、 ユーザ単位で入手可能、設定可能とすることです。 大部分のユーザは、 (spam 避けたいと思う以外)強い意見をもたないでしょうから、 メールシステムは、システムのデフォルトを提供し、各ユーザに、 それを上書きしたり変更できるようにすべきです。 「UNIX に基づく環境において、 人は
/etc/mail/rc.spam
~/.spamrc
」
のようなもの、および「どのように後者は、
前者を妨げることができるか」についてのルールをを持つことができます。
これらすべては、極めて多くの未解決の論点を提起します。
例：「各ユーザ自身は、本当に、
SMTP戻りコードを決めることを認められる必要があるか否か？」、
(ユーザが意味を十分理解するために、それはどのように記述されるべきか)、
「どのように既存のメールシステムがユーザ毎に異なるレスポンスを扱うか？」,
特に、「どのように、それらが 5xx と 4xx コードの混在を扱うか？」：
C MAIL From: <usr@spam.example>
S 250 <usr@spam.example>... Sender ok
C RCPT To: <usr@domain.example>
S 250 <usr@domain.example>... Recipient ok
C RCPT To: <foo@domain.example>
S 451 <foo@domain.example>... Denied due to spam list
C RCPT To: <bar@domain.example>
S 550 <bar@domain.example>... Denied due to spam list
当然ながら、人は、個人ユーザに対する他の代替策なしに"250
OK"または"550 Denied"を決定できますが、これも、
「通常のユーザは、"Refuse 'MAIL From:
<.*@spam.example>'" の意味を理解すること」と、
「実際に欲しかったメールを、
捨てるまたはブロックすることができること」
が十分に説明されなければなりません。
SMTP認証 [10] については、既に、 メール中継を認可する手法として言及しましたが、当然ながら、 それ以上に沢山のことがあります。 そのインフラストラクチャや機能が、すべてあるとき、スパマーは、 アドレスを偽装して隠れるのに、より苦労することになります。
NAT (Network Address Translators)の利用の増加に伴って、 ログファイル中の追加的な情報が必要となる可能性があります。 NAT内のアドレスと、その外のアドレスの間に「1対1対応」がある限り、 まったく問題ありませんが、そのNATボックスが、 (多くの内部ホストを1つの外部アドレスに結びつけるために)ポート番号も変換する場合、 我々は、spamホストのIPアドレスのみならず、 ポート番号も記録する必要があります。 そうしなければ、我々は、NATの内側の個々のホストを識別できません。
草が茂るかのようなspamの増加は、 実際にインターネットメールのコミュニティ全体をリスクにさらす、 いくつかのセキュリティ論点を提起します。：
本書中に記述されたいくつかの手法は、電子メールシステム自体の、 いくつかのサポートシステム上の負荷を増加します。 それらのサポートシステムは、DNS、ログ記録、 ローカルユーザのリストをもつデータベース、 認証メカニズム等である可能性があります。 本書中に記述された手法の実装は、それに起因して、 当該サポートを行っているシステムに対してspamを送りつけることによるサービス妨害攻撃のリスクを増加させます。 ログ記録を行う設備は、例えば、 より多くのログ記録を扱うことができなければなりません。 (そのログファイルがディスクを満杯にするとき、何が起きるか？) DNSサーバーと認証メカニズムは、 より頻繁なルックアップ等の負荷に耐えることができなければなりません。
高負荷において、そのサポートシステムの機能は、 本書中に記述された手法を実装する前に、注意深く調査される必要があります。
メールシステムは、注意深く調べられる必要があります。 (例：特定の手法について必要とされるサポートシステムのひとつ、 もしくは、複数が失敗するとき、どのように、それは、 ふるまうか？) そのサポートシステムのひとつに一時的な問題がある場合、 メールサーバーは、"Permanent Failure" (5xx) で応答してはなりません(MUST NOT)。
このメモは、
スウェーデンのISPや大学のアドホックグループにおける検討の結果です。
全員について言及することは絶望的ですので、我々は、単に、
そのドメイン名をここに掲げます。：
algonet.se, global-ip.net, pi.se, swip.net, telia.net, udac.se,
chalmers.se, sunet.se, umu.se, uu.se
我々は、Andras Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol, Donald Eastlake, Ned Freed, Keith Moore, Paul Hoffmanからの有用な入力と示唆に感謝したいと考えます。
最後に、有用なコメントをしてくださり、 IETF標準化過程を通じてサポートして導いてくださったHarald AlvestrandとPatrik Faltstrom の両名に深く感謝します。
| [1] |
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1982年4月. |
| [2] |
Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, 1982年8月. |
| [3] |
Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, 1989年10月. |
| [4] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
| [5] |
Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, 1987年11月. |
| [6] |
Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, 1987年11月. |
| [7] |
Eastlake, D. and C. Kaufman, 「DNSセキュリティ拡張(Domain Name System Security Extensions)」, RFC 2065(English), 1997年1月. |
| [8] |
sendmail Home Page. http://www.sendmail.org |
| [9] |
Gellens, R. and J. Klensin "Message Submission", RFC 2476, 1998年9月. |
| [10] |
Myers, J., "SMTP Service Extension for Authentication", 作業中. |
Gunnar Lindberg
Computer Communications Group
Chalmers University of Technology
SE-412 96 Gothenburg, SWEDEN,
電話： +46 31 772 5913
FAX： +46 31 772 5922
EMail： lindberg＠cdg.chalmers.se
(準備中)
独立行政法人 情報処理推進機構
セキュリティセンター
EMail：
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.