ネットワーク WG
Request for Comments: 2505
BCP: 30 
分類: ベストカレントプラクティス

G. Lindberg
 Chalmers University of Technology
1999年 2月
 

English

(準備中)

SMTP MTA についての spam 対策推奨事項
(Anti-Spam Recommendations for SMTP MTAs)

このメモの位置付け

この文書は、インターネットの「現時点における最善の実践(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 サーバーへの問い合わせ回数の増加や、ログファイルの拡大は、攻撃時において、システム過負荷とシステムクラッシュの両方を招く可能性があります。

このメモの簡潔な要約は、以下のとおり。:

 

1. はじめに English

このメモは、BCP(Best Current Practice)の RFC です。それゆえ、これは、 SMTP MTA の実装者のために、その製品をより spam を予防/対処できるようにするガイドラインとして使われる必要があります。これが主要な目的ではありますが、意図した副次的影響のひとつには、 システム管理者/ポストマスターのコミュニティに対して、SMTP MTA が「spam 対策手段」をもつことが期待されているので、それを示唆することがあります。

しかし、このメモは、 「どのように SMTP MTA を運用管理するか (どの「ノブ」を操作し、どのように設定するか)」 についての記述として、一般的に意図したものではありません。示唆が提供された場合、それらには、明確に印を付けてあるので、そのように読まれる必要があります。

1.1. 背景 English

しばしば spam と呼ばれる UBE (迷惑メール)は、短期間に相当、増加しており、インターネット電子メールのコミュニティ全体の深刻な脅威となっています。何かが、相当、速やかに行われる必要があります。

この問題には、いくつかのコンポーネントがあります。:

1.2. 範囲 English

このメモは、spam 問題に対する最終解決策であることを意図していません。

しかし、十分な数のインターネット MTA が下記のルール(特に、Non-Relay ルール)を十分に実施した場合、我々は、スパマー達を衆目にさらされる表に出すことになります。純粋に法的な行為が役立つか、あるいは、我々が下記の他のルールを使うかのいずれにせよ、技術的に、それらをブロックすることができます。(なぜなら、Non-Relay ルールは、今や彼らのホストやドメインについて、表に見せるので、我々は、様々なアクセスフィルターを彼らに対して適用できるので。)実際、法的手法と技術的手法の組み合わせが最善の結果をもたらす傾向があります。

このように、spam 問題は、インターネットコミュニティが現実の一般的な状況を設計し、配備できるまで十分に低減できる可能性があります。

しかし、以下について注意してください。:

Non-Relay ルール自体は、spam を止めるためには十分ではありません。たとえ 99% の SMTP MTA がそれらを 1 日で実装した場合でも、スパマーは、なおも、残りの 1% を見つけて、それらを使うことでしょう。あるいは、スパマーは、ギアを切り替えて、各すべての受信ホスト宛てに直接接続してしまうだけです。このようにすることは、スパマーにとっては、より高い費用となりますが、可能性は十分にあります。

IPv6 の採用が近い可能性があるとはいえ、spam 問題は既にここにあり、それゆえ、このメモは、現行 IPv4 に限定します。

1.3. 用語 English

このメモを通じて、我々は、RFC2119 [4] の用語法を使います。:

この単語、もしくは、相当する形容詞である REQUIRED は、 「この要素は、必須要件であること」を意味します。

この単語、もしくは、相当する形容詞である RECOMMENDED は、「この要素を無視する特定の状況において、正当な理由が在る可能性があるが、その趣旨は完全に理解される必要があり、その場合は、異なる選択をする前に注意深く重み付けられる必要があること」を意味します。

この単語、もしくは、相当する形容詞である OPTIONAL は、「この要素は、真にオプションとしてのものであること」を意味します。ベンダーによっては、「特定の市場が、それを要求する」あるいは「それは、当該製品を拡張する」の理由で、この要素を含めることを選択する可能性があり、例えば、別のベンダーは、同一の要素を無視する可能性があります。

1.4. DNS 情報を使う English

このメモにおいて、我々は、しばしば、「ホスト名(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 で検証することについてです。この機能を利用するとき、考慮すべき事項がいくつかあります。:

(1) 増加する DNS クエリーの量のこと忘れてはなりません。これは、DNS サーバー自体が負荷を扱うことについて問題をもたらす可能性があります。これ自体が、単にあるサイト宛てに電子メールを送信することによって、当該 DNS サーバーに対してサービス妨害攻撃をもたらす可能性があります。
 
(2) 「DNS における逆引きで、偽造された DNS レスポンスが、サービス妨害攻撃をしかけるのに使われる可能性があること」に注意する必要があります。例えば、あるサイトが SMTP "MAIL From:" コマンド中のアドレスについての FQDN 妥当性チェックを実装していることが知られている場合、攻撃者は、ひとつもしくは複数の発信元からのメールの受信を効果的にブロックするために、ネガティブ DNS レスポンスを使うことができる可能性があります。この理由によって、注意深く使われている DNS サーバーをチェックする必要があります。(例: どのように DNS サーバーは、このような攻撃についてのリスクを最小化するために、出方向のクエリーに対応する入方向のレスポンスを検証するか?)
 
(3) 初期の spam ソフトウェアについて、FQDN チェックは、かなりの安心を提供します。なぜなら、そのソフトウェアは、完全に偽の"MAIL From:" をもつメールを生成しますが、それはDNS を用いて検証された場合に決してシステム中に入ることがありえないからです。これは、今日、多くの状況において使われており、 spam を低減しています。

一方、弱い DNS 接続性しかもたないサイトは、「サイトの正規のメールには、受信者がその"MAIL From:" を検証するとき、DNS タイムアウトに起因して、宛先に到達しない問題があること 」を発見する可能性があります。しかし、DNS 情報は、非同期的に扱われ、たとえ最初の要求者が諦めたとしてもキャッシュされるので、後で試すときには必要不可欠な情報がそこにある可能性は高いといえます。

最近の spam ソフトウェアについて、"MAIL From:" のチェックは、さらに役に立ちません。なぜなら、spam ソフトウェアも、進化し、存在するメールアドレスを使い始めるからです。(これが合法的であるか否かは、このメモの範囲外です。)しかし、少なくとも、インターネットは、「このテストが UA についての誤記や誤設定を止めること」から副次的効果の恩恵を受けることができます。

1.5. どこで spam をブロックするか(SMTP/RFC822/UA) English

我々の基本的な想定は、棄却/許容は、SMTP 層において扱われ、あるメッセージの拒否を決定する MTA は、SMTP対話中に そのようにする必要があるということです。まず、これは、我々は、後でメッセージの拒否を決定するために、そのコピーを蓄える必要がないということ、また、第2に我々のそのメッセージに対する責任は低いかまたはないことを意味します。
-我々は、まだそのメッセージを読んでいないので、そのエラー処理を送信者に任せます。

1.6. SMTP 戻りコード English

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か正規のメールか、またそれが棄却されるべきか、あるいは、転送されるべきかを検査することができます。

1.7. メーリングリスト English

メーリングリストや、多数の受信者宛の拡張を使う能力ももつ MTA は、送信者を認可し、spam からリストを防護できる必要があります。このためのメカニズムは、通常のメールと通常のユーザのものとは大きく異なる可能性があり、このメモ中では扱われていません。

 

2. 推奨事項 English

ここで、我々は、まず、推奨事項の簡潔な一覧を提供し、次に、それぞれについて、より完全な検討を提供します。また、我々は、「すべからず」事項についての推奨事項を提供します。この推奨事項は、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 は、それらの新しい脅威に適合するために十分に柔軟である必要があります。

2.1. 認可されていないメール中継の利用を制限する English

メール中継器としてのホスト の認可されていない利用は、中継器の資源の盗用を意味し、その中継器の所有者の評判をリスクにさらします。これは、また、正規のメールをブロックするのと同時に spam をフィルタしたり、あるいは、ブロックすることを不可能にします。

それゆえ、MTA は、このような中継の用法を制御/棄却できなければなりません(MUST)

SMTP セッションにおいて、我々は 4 つの要素をもち、各々は、様々な程度の信頼性をもちます。:

(準備中)

1)  "HELO Hostname"          容易にしばしば偽装される。
2)  "MAIL From:"                  容易にしばしば偽装される。
3)  "RCPT To:"                     正しい, またはそのように意図されている。
4)  SMTP_Caller (host)         送信元IPアドレスはOK, FQDN は、おそらく OK。

1) および 2) は、あまりに安易にかつ、しばしば偽装されるので、我々は、メール中継としての我々のホストの利用法を認可するためには、まったく、それらに依存することができません。

代わりに、MTA は、下記の組み合わせに基づいて、メール中継の利用法を認証することができなければなりません(MUST)。:

示唆されるアルゴリズムは、以下のとおり。:

a)  "RCPT To:" が "our" ドメインのひとつである場合、すなわちローカルまたは我々が転送先として受け入れるドメイン(代替MX)の場合、中継を受け入れる。
b)  SMTP_Caller(その送信元IPアドレスまたはFQDN) が認可されている (あなたがDNSを信頼するかに依存するが) 場合、
中継を受け入れる。
 
c)  それ以外の場合、中継を拒否する。

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)

2.2. Received: 行 English

MTA は、メール中に、(RFC822 [2], に記述され、RFC1123 [3] で要求されているように)"Received:" 行 を前に付けなければなりません(MUST)。この "Received:" 行は、その送信者まで逆に、そのメールのパスを追跡できるようにするために、十分な情報を含まなければなりません(MUST)。2 つの場合があります。:

2.2.1. 直接的な「MTA to MTA」コネクション English

インターネットメールは、送信ホストが、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 アドレスをもつことを必要とするとき」です。

2.2.2. ファイアウォール/ゲートウェイ型デバイス English

内部ネットワーク構成を隠すポリシーをもつ組織体は、やはり、そのようにすることが許され、そのようにできなければなりません。その組織体は、通常、その内部 MTA がごく限られた量の情報と共に "Received:" 行 を前に付けるか、あるいは、何も前に付けないようにします。そして、かれらは、そのメールをいくつかの種類のファイアウォール/ゲートウェイ装置を通して送信しますが、
ファイアウォール/ゲートウェイ装置は、 それ自身の"Received:" 行を付ける前に、(RFC1123 [3]に要求されるように)内部の MTA の "Received:" 行全ての削除すらしてもかまいません。

そのようにすることによって、かれらは組織体の内部から送信したスパマーたちを追跡することに完全責任を負う、かまたは
そのようなスパマーの活動に責任を持たされることを受け入れます。
「彼らの送信メール中に提供される情報が、彼らにとって、いかなる必要不可欠な追跡を行うためにも十分であること」が要求されます(REQUIRED)

組織体宛に届くメールの場合、"Received:" 行は、
「内部でメールを受信するユーザが、到着メッセージを発信元まで追跡するのに必要な情報を与えることができること」
を確保するために無傷に保たれなければなりません(MUST)

一般に、ゲートウェイは、そのようにすることがセキュリティ要件でない限り、"Received:" 行を変更したり削除してはいけません(SHOULD NOT)
いくつかの種類のメールゲートウェイを通過するときに、既存の "Received:" 行が意味をなすようにするために、その内容を変更することは、大部分の場合、メッセージを追跡可能にするのに必要な情報を破壊し、削除してしまいます。"Received:" 行中の情報を保護するために、注意をしなければなりません。"Received:" 行中の情報は、メッセージ自体、または 受信者が得たメール、またはそれが不可能な場合ログファイル中にあります。

2.3. イベントログ English

MTA は、イベントを追跡できるように、十分なローカルのログ情報を提供できなければなりません(MUST)。これは、"Received:" 行中に大部分の情報を含めます。上記参照。

2.4. 中継対策/spam 対策の活動を記録する English

MTA は、中継対策/spam 対策のすべての活動を記録できる必要があります(SHOULD)。ログの項目は、少なくとも以下のものを含む必要があります。:

「より多くのイベント(特に、拒否された電子メール)を記録することによって、サービス妨害攻撃の可能性(例えば、大量の"RCPT To:" コマンドを受けることによって、ログを溢れさせることによる)を開いてしまうこと」に注意する必要があります。この記述によって増加するログ記録を実装するものは、「(特に攻撃の間)ログファイルの大きさが増大する」事実を認識していなければなりません 。

2.5. SMTP_Caller アドレスに基づいてメールを拒否する English

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)

2.6. "MAIL From: <>" と"MAIL From: <user@my.local.dom.ain>" English

スパマーとの戦いは重要ですが、これは、決して、既存の電子メール標準を侵害する方法で行われてはなりません。スパマーは、しばしば、 "MAIL From:" アドレスを偽装するので、それ(特に、何らかの「明らかな」アドレス)に対して、一般的な制限を設ける誘惑にかられます。しかし、これは、spam がするより大きな混乱をメールコミュニティに もたらす可能性があります。

特定のホスもしくはサイトからのメールを拒否する必要があるとき、我々の推奨事項は、このメモ中に述べられた他の手法を使うことです。
(例: どの"MAIL From:" が使われていたかに関わらず、SMTP_Caller アドレス(もしくは、名前)に基づいてメールを拒否する。)

2.6.1. "MAIL From: <>" English

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: <>" を使うのを低減します。

2.6.2. "MAIL From: <user@my.local.dom.ain>" English

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>" が棄却された場合、これらの両方の場合、正規のメールの配信失敗に陥ります。

2.7. "MAIL From:" に基づいた拒否English

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 アドレスが、意図的に拒否されているネットワークに属するとき。)

2.8. レート制御English

MTA は、メールホストに メールが送受信されるレートを制御するためのツールを提供する必要があります(SHOULD)。このアイディアは、2つの事項から成ります。:

1)  我々が既存の正規のアカウントをもつ正規のメールユーザをもち、このユーザが spam を送ることになった場合、我々は、彼が送信するスピードを低減することを望む可能性があります。これは、議論の余地がなく、十分な注意を払って使われなければなりませんが、これによって、インターネットの他の部分を彼から防ぐことができます。
 
2)  我々が spam 攻撃を受けている場合、これは、その特定のユーザ/ホストについての入り方向のメールのレートを遅くすることができるので、相当に有用である可能性があります。

メール送信について、これは、許容可能なデータ出力レートを設定するために、その TCP コネクションを調節することによって行われなければなりません。(例: write() の頻度を減らす。)

メール受信について、我々は、基本的に同様のテクニック(例: read() の頻度を低減する)を使うことができ、あるいは、我々が受信できないという信号を4xx 戻りコードで送ることができます。「そのような動作をする判断は、"MAIL From:" ユーザ、"MAIL From:" ドメイン、SMTP_Caller(名前/アドレス)、 "RCPT TO:"、もしくは、これらすべての組み合わせに基づくこと」が推奨されます(RECOMMENDED)

2.9. "MAIL From:" を検証する English

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)

2.10. Verify <local-part> English

MTA は、送信メールの <local-part> の送信者名が実在するユーザもしくは既存のエイリアスであるように、検証されるようにすることを許可する必要があります(SHOULD)。これは、基本的に、インターネットの他の部分を、多様な「誤記(typos)」

MAIL From: <fo0bar@domain.example>

および/または、悪意あるユーザ

MAIL From: <I.am.unknown.to.you.he.he@domain.example>

からまもるためのものです。いつものように、これは、熱心なスパマーによって乗り越えられてしまう可能性がありますが、中継について、より厳密なルールがあるとき、これは、より難しくなります。事実、最初の(かつ公式な)メール中継において「誤記」を補足すること自体は、この推奨事項の動機として十分なものです。

2.11. SMTP VRFY と EXPN English

SMTP VRFY と EXPN の両者は、潜在的スパマーに「スパマーのリスト上のアドレスが、正規のものであるか否か?(VRFY)」をテストし、
より多くのアドレスを得る手段(EXPN)さえも提供します。それゆえ、MTA は、「誰が、これらのコマンドを発行することを許可されているか?」を制御する必要があります(SHOULD)。これは、"on/off" である可能性があり、あるいは、以前に述べたものと同様なアクセスリストを使う可能性があります。

「"VRFY" コマンドは、RFC821 [1] に従って要求されること」に注意してください。しかし、そのレスポンスは、"off" もしくは「アクセスリストによってブロックされたこと」を表現するために、"252 Argument not checked" である可能性があります。これは、デフォルトである必要があります。

"EXPN" コマンドについてのデフォルトは、"off" である必要があります。

2.12. SMTP ETRN English

SMTP ETRN は、「MTA が、そのメールの待ち行列を再実行すること」を意味し、これは、極めて高価であり、サービス妨害攻撃について無防備である可能性があります。それゆえ、MTA は、「誰が ETRN コマンドを発行することを許可されているか?」を制御する必要があります(SHOULD)。これは、"on/off" である可能性があり、あるいは、以前に述べたものと同様なアクセスリストを使う可能性があります。デフォルトは、"off" である必要があります。

2.13. 戻りコード English

ここにおける主要な論点は、柔軟性です。(「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 戻りコードについての以前の議論を参照してください。

2.13.1. 柔軟性の重要性 - その一例 English

(準備中)

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 は、これを完全に不可能にしてしまいます。)

 

3. 将来の作業 English

3.1. SMTP ユーザエージェントとエンドユーザにおける影響 English

このメモは、 MTA と、それらの推奨事項についてのものではありますが、個々で行われることには、UA(User Agents: 通常のメールプログラム)にも影響を与えるものがあります。

UA は、2 つのことを行います。:

1)  メールボックスからメールを読み、画面に表示します。これは、典型的には、POP、IMAP もしくは NFS のようなプロトコルを使います。
2) 

キーボードからのテキストを読み、それをメールの一部として配信するために、メールボックス MTA に渡します。これは、典型的には、SMTP プロトコル(すなわち、MTA 間で使われるのと同じプロトコル)を使います。

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 認証済" の場合、中継することを許容する。

3.2. 個人的な spam 対策フィルタ English

すべてのユーザは、個人であるので、「あらゆる中央集権的 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>'" の意味を理解すること」と、
「実際に欲しかったメールを、捨てるまたはブロックすることができること」
が十分に説明されなければなりません。

3.3. SMTP 認証 English

SMTP 認証 [10] については、既に、メール中継を認可する手法として言及しましたが、当然ながら、それ以上に沢山のことがあります。そのインフラストラクチャや機能が、すべてあるとき、スパマーは、アドレスを偽装して隠れるのに、より苦労することになります。

3.4. Spam と NAT English

NAT(Network Address Translators)の利用の増加に伴って、ログファイル中の追加的な情報が必要となる可能性があります。NAT 内のアドレスと、その外のアドレスの間に「1 対 1 対応」がある限り、まったく問題ありませんが、その NAT ボックスが、(多くの内部ホストを 1 つの外部アドレスに結びつけるために)ポート番号も変換する場合、我々は、spam ホストの IP アドレスのみならず、ポート番号も記録する必要があります。そうしなければ、我々は、NAT の内側の個々のホスト を識別できません。

 

4. セキュリティについての考慮事項 English

草が茂るかのような spam の増加は、実際にインターネットメールのコミュニティ全体をリスクにさらす、いくつかのセキュリティ論点を提起します。:

本書中に記述されたいくつかの手法は、電子メールシステム自体の、いくつかのサポートシステム上の負荷を増加します。それらのサポートシステムは、DNS、ログ記録、ローカルユーザのリストをもつデータベース、認証メカニズム等である可能性があります。本書中に記述された手法の実装は、それに起因して、当該サポートを行っているシステムに対して spam を送りつけることによるサービス妨害攻撃のリスクを増加させます。ログ記録を行う設備は、例えば、より多くのログ記録を扱うことができなければなりません。(そのログファイルがディスクを満杯にするとき、何が起きるか?)DNS サーバーと認証メカニズムは、より頻繁なルックアップ等の負荷に耐えることができなければなりません。

高負荷において、そのサポートシステムの機能は、本書中に記述された手法を実装する前に、注意深く調査される必要があります。

メールシステムは、注意深く調べられる必要があります。(例: 特定の手法について必要とされるサポートシステムのひとつ、もしくは、複数が失敗するとき、どのように、それは、ふるまうか?)そのサポートシステムのひとつに一時的な問題がある場合、メールサーバーは、"Permanent Failure" (5xx) で応答してはなりません(MUST NOT)

 

5. 謝辞 English

このメモは、スウェーデンの 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 の両名に深く感謝します。

 

6. 参考文献

[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.