[要約] RFC 6647は、SMTPにおけるメールグレイリスティングの適用性に関する要約と目的を提供しています。このRFCは、メールサーバーが一時的なエラーを返し、再試行を要求することでスパムメールをフィルタリングする手法であるグレイリスティングの利点と制約を説明しています。
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 6647 Cloudmark
Category: Standards Track D. Crocker
ISSN: 2070-1721 Brandenburg InternetWorking
June 2012
Email Greylisting: An Applicability Statement for SMTP
メールのグレイリスト：SMTPの適用に関する声明
Abstract
概要
This document describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism.
このドキュメントでは、不正使用防止メカニズムとして、一時的に機能が低下したサービスを未知のメールクライアントに提供する方法である、メールのグレーリストの技術について説明します。
Greylisting is an established mechanism deemed essential to the repertoire of current anti-abuse email filtering systems.
グレイリストは確立されたメカニズムであり、現在の乱用防止メールフィルタリングシステムのレパートリーに不可欠と見なされています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6647.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6647で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Background .................................................3
1.2. Definitions ................................................4
2. Types of Greylisting ............................................4
2.1. Connection-Level Greylisting ...............................4
2.2. SMTP HELO/EHLO Greylisting .................................5
2.3. SMTP MAIL Greylisting ......................................5
2.4. SMTP RCPT Greylisting ......................................5
2.5. SMTP DATA Greylisting ......................................6
2.6. Additional Heuristics ......................................7
2.7. Exceptions .................................................7
3. Benefits and Costs ..............................................8
4. Unintended Consequences .........................................9
4.1. Unintended Mail Delivery Failures ..........................9
4.2. Unintended SMTP Client Failures ...........................10
4.3. Address Space Saturation ..................................11
5. Recommendations ................................................12
6. Measuring Effectiveness ........................................13
7. IPv6 Applicability .............................................14
8. Security Considerations ........................................14
8.1. Trade-Offs ................................................14
8.2. Database ..................................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................15
Appendix A. Acknowledgments ......................................17
Preferred techniques for handling email abuse explicitly identify good actors and bad actors, giving each significantly different service quality. In some cases, an actor does not have a known reputation; this can justify providing degraded service, until there is a basis for providing better service. This latter approach is known as "greylisting". Broadly, the term refers to any degradation of service for an unknown or suspect source, over a period of time (typically measured in minutes or a small number of hours). The narrow use of the term refers to generation of an SMTP temporary failure reply code for traffic from such sources. There are diverse implementations of this basic concept and predictably, therefore, some blurred terminology.
電子メールの悪用を処理するための推奨される手法は、良いアクターと悪いアクターを明確に識別し、それぞれ著しく異なるサービス品質を提供します。場合によっては、俳優に既知の評判がないことがあります。これは、より良いサービスを提供するための基礎ができるまで、低下したサービスを提供することを正当化できます。この後者のアプローチは「グレーリスト」として知られています。大まかに言えば、この用語は、ある期間（通常、分単位または数時間単位で測定）にわたる、不明または疑わしいソースのサービスの低下を指します。この用語の狭義の使用は、そのようなソースからのトラフィックに対するSMTP一時障害応答コードの生成を指します。この基本概念にはさまざまな実装があり、予測可能なため、用語がぼやけています。
Absent a perfect abuse-detection mechanism that incurs no cost, the current requirement is for an array of techniques to be used by each filtering system. They range in cost, effectiveness, and types of abuse techniques they target.
費用のかからない完全な乱用検出メカニズムがない場合、現在の要件は、各フィルタリングシステムで使用される一連の技術に対するものです。対象となるのは、費用、有効性、対象とする虐待手法の種類です。
Greylisting happens to be a technique that is cheap and early (in terms of its application in the SMTP sequence) and surprisingly remains useful. Some spamware does indeed route around this technique, but much does not.
グレイリストはたまたま（SMTPシーケンスでのアプリケーションの点で）安価で早い手法であり、驚くほど有用なままです。一部のスパムウェアは実際にこの手法を迂回していますが、多くはそうではありません。
The firehose of spam over the Internet represents a wide range of sophistication. Greylisting is useful for removing a large amount of simplistic-but-significant traffic.
インターネットを介したスパムのファイアホースは、さまざまな高度化を表しています。グレイリストは、単純であるが重要な大量のトラフィックを削除する場合に役立ちます。
This memo documents common greylisting techniques and discusses their benefits and costs. It also defines terminology to enable clear distinction and discussion of these techniques.
このメモは、一般的なグレイリスト手法を文書化し、それらの利点とコストについて説明しています。また、これらの技術を明確に区別して説明できるように用語を定義しています。
There is some confusion in the industry that conflates greylisting with an SMTP temporary failure for any reason. The purpose of this memo is also to dispel such confusion.
何らかの理由で、グレーリストをSMTPの一時的な障害で混乱させる業界の混乱があります。このメモの目的は、そのような混乱を払拭することでもあります。
For many years, large amounts of spam have been sent through purpose-built software, or "spamware", that supports only a constrained version of SMTP. In particular, such software does not perform retransmission attempts after receiving an SMTP temporary failure. That is, if the spamware cannot deliver a message, it just goes on to the next address in its list since, in spamming, volume counts for far more than reliability. Greylisting exploits this by rejecting mail from unfamiliar sources with a "transient (soft) fail" (4xx) [SMTP] error code. Another application of greylisting is to delay
長年にわたり、SMTPの制約されたバージョンのみをサポートする専用のソフトウェア、つまり「スパムウェア」を通じて大量のスパムが送信されてきました。特に、このようなソフトウェアは、SMTPの一時的な障害を受信した後、再送信を試みません。つまり、スパムウェアはメッセージを配信できない場合、リストの次のアドレスに移動します。スパムでは、ボリュームは信頼性よりもはるかに重要です。グレイリストはこれを悪用して、見慣れないソースからのメールを「一時的な（ソフト）失敗」（4xx）[SMTP]エラーコードで拒否します。グレーリストのもう1つの用途は遅延です。
mail from newly seen IP addresses on the theory that, if it's a spam source, then by the time it retries, it will appear in a list of sources to be filtered, and the mail will not be accepted.
理論上、新しく見られたIPアドレスからのメール。スパムの送信元である場合、再試行するまでに、フィルターの対象となる送信元のリストに表示され、メールは受け入れられません。
Early references for greylisting descriptions and implementations can be found at [SAUCE] and [PUREMAGIC].
グレイリストの説明と実装に関する初期のリファレンスは、[SAUCE]と[PUREMAGIC]にあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
Readers need to be familiar with the material and terminology discussed in [MAIL], [EMAIL-ARCH], and [SMTP].
読者は、[MAIL]、[EMAIL-ARCH]、および[SMTP]で説明されている資料と用語に精通している必要があります。
Greylisting is primarily performed at some phase during an SMTP session. A set of attributes about the client-side SMTP server are used for assessing whether to perform greylisting. At its simplest, the attribute is the IP address of the client, and the assessment is whether it has previously connected recently. More elaborate attribute combinations and more sophisticated assessments can be performed. The following discussion covers the most common combinations and relies on knowledge of [SMTP], its commands, and the distinction between envelope and content.
グレイリストは主に、SMTPセッション中のあるフェーズで実行されます。クライアント側のSMTPサーバーに関する一連の属性は、グレイリストを実行するかどうかを評価するために使用されます。最も単純な場合、属性はクライアントのIPアドレスであり、評価は以前に最近接続したかどうかです。より複雑な属性の組み合わせとより高度な評価を実行できます。次の説明では、最も一般的な組み合わせについて説明し、[SMTP]、そのコマンド、およびエンベロープとコンテンツの違いに関する知識に依存しています。
Connection-level greylisting decides whether to accept the TCP connection from a "new" [SMTP] client. At this point in the communication between the client and the server, the only information known to the receiving server is the incoming IP address. This, of course, is often (but not always) translatable into a host name.
接続レベルのグレーリストは、「新しい」[SMTP]クライアントからのTCP接続を受け入れるかどうかを決定します。クライアントとサーバー間の通信のこの時点で、受信サーバーに認識される唯一の情報は、着信IPアドレスです。もちろん、これは多くの場合（常にではありませんが）ホスト名に変換できます。
The typical application of greylisting here is to keep a record of SMTP client IP addresses and/or host names (collectively, "sources") that have been seen. Such a database acts as a cache of known senders and might or might not expire records after some period. If the source is not in the database, or the record of the source has not reached some required minimum age (such as 30 minutes since the initial connection attempt), the server does one of the following, inviting a later retry: o returns a 421 SMTP reply and closes the connection, or
ここでのグレーリストの典型的なアプリケーションは、SMTPクライアントのIPアドレスやホスト名（まとめて「ソース」）の記録を保持することです。このようなデータベースは、既知の送信者のキャッシュとして機能し、一定期間後にレコードを期限切れにする場合としない場合があります。ソースがデータベースにない場合、またはソースのレコードが必要な最小経過時間（最初の接続試行から30分など）に達していない場合、サーバーは次のいずれかを実行し、後で再試行します。oは、 421 SMTP応答で接続を閉じる、または
o returns a different 4yz SMTP reply to all further commands in this SMTP session.
o このSMTPセッションの以降のすべてのコマンドに対して、異なる4yz SMTP応答を返します。
A useful variant of the basic known/unknown policy is to limit greylisting to those addresses that are on some list of IP addresses known to be affiliated with bad actors. Whereas the simpler policy affects all new connections, including those from good actors, the constrained policy applies greylisting actions only to sites that already have a negative reputation.
基本的な既知/未知のポリシーの便利な変形は、グレイアクターを、悪意のある人物に関係していることがわかっているIPアドレスのリストにあるアドレスに制限することです。単純なポリシーは、優れたアクターからの接続を含むすべての新しい接続に影響しますが、制約付きポリシーは、すでに否定的な評判のあるサイトにのみグレーリストアクションを適用します。
HELO/EHLO greylisting refers to the first command verb in an SMTP session. It includes a single, required parameter that is supposed to contain the client's fully qualified host name or its literal IP address.
HELO / EHLOグレイリストは、SMTPセッションの最初のコマンド動詞を指します。これには、クライアントの完全修飾ホスト名またはそのリテラルIPアドレスを含むことになっている単一の必須パラメーターが含まれています。
Greylisting implemented at this phase retains a record of sources coupled with HELO/EHLO parameters. It returns 4yz SMTP replies to all commands until the end of the SMTP session if that tuple has not previously been recorded or if the record exists but has not reached some configured minimum age.
このフェーズで実装されたグレイリストは、HELO / EHLOパラメータと組み合わされたソースの記録を保持します。そのタプルが以前に記録されていない場合、またはレコードが存在するが構成された最小経過時間に達していない場合、SMTPセッションが終了するまで、4yz SMTP応答を返します。
MAIL command greylisting refers to the command verb in an SMTP session that initiates a new transaction. It includes at least one required parameter that indicates the return email address (RFC5321.MailFrom) of the message being relayed from the client to the server.
MAILコマンドのグレーリストは、新しいトランザクションを開始するSMTPセッションのコマンド動詞を指します。これには、クライアントからサーバーにリレーされるメッセージの返信電子メールアドレス（RFC5321.MailFrom）を示す少なくとも1つの必須パラメーターが含まれています。
Greylisting implemented at this phase retains a record of sources coupled with return email addresses. It returns 4yz SMTP replies to all commands for the remainder of the SMTP session if that tuple has not previously been recorded or if the record exists but has not met some configured minimum age.
この段階で実装されたグレイリストは、送信元の記録と返信用メールアドレスを保持します。そのタプルが以前に記録されていない場合、またはレコードが存在するが構成された最小経過時間に達していない場合、SMTPセッションの残りのすべてのコマンドに対して4yz SMTP応答を返します。
RCPT greylisting refers to the command verb in an SMTP session that specifies intended recipients of an email transaction. It includes at least one required parameter that indicates the email address of an intended recipient of the message being relayed from the client to the server.
RCPTグレイリストは、電子メールトランザクションの対象受信者を指定するSMTPセッションのコマンド動詞を指します。これには、クライアントからサーバーにリレーされるメッセージの対象となる受信者の電子メールアドレスを示す必須パラメーターが少なくとも1つ含まれています。
Greylisting implemented at this phase retains a record of tuples that combines the provided recipient address with any combination of the following:
このフェーズで実装されたグレイリストは、提供された受信者アドレスと以下の任意の組み合わせを組み合わせたタプルのレコードを保持します。
o the source, as described above;
o 上記のソース。
o the return email address; and
o 返信メールアドレス;そして
o the other recipient addresses of the message (if any).
o メッセージの他の受信者アドレス（存在する場合）。
If the selected tuple is not found in the database, or if the record is present but has not reached some configured minimum age, the greylisting Mail Transfer Agent (MTA) [EMAIL-ARCH] returns 4yz SMTP replies to all commands for the remainder of the SMTP session.
選択したタプルがデータベースに見つからない場合、またはレコードは存在するが、構成された最小経過時間に達していない場合、グレイリストのメール転送エージェント（MTA）[EMAIL-ARCH]は、残りのすべてのコマンドに対して4yz SMTP応答を返しますSMTPセッション。
Note that often a match on a tuple involving the first valid RCPT is sufficient to identify a retry correctly, and further checks can be omitted.
多くの場合、最初の有効なRCPTを含むタプルの一致は、再試行を正しく識別するのに十分であり、それ以上のチェックは省略できます。
DATA greylisting refers to the command verb in an SMTP session that transmits the actual message content, as opposed to its envelope details.
DATAグレーリストは、エンベロープの詳細ではなく、実際のメッセージコンテンツを送信するSMTPセッションのコマンド動詞を指します。
This type of greylisting can be performed at two places in the SMTP sequence:
このタイプのグレーリストは、SMTPシーケンスの2つの場所で実行できます。
1. on receipt of the DATA command, because at that point the entire envelope has been received (i.e., all MAIL and RCPT commands have been issued); or
1. DATAコマンドの受信時。これは、その時点でエンベロープ全体が受信されているためです（つまり、すべてのMAILコマンドとRCPTコマンドが発行されています）。または
2. on completion of the DATA command, i.e., after the "." that terminates transmission of the message body, since at that point a digest or other analysis of the message could be performed.
2. DATAコマンドの完了時、つまり「。」の後その時点でメッセージのダイジェストまたは他の分析を実行できるため、メッセージ本文の送信を終了します。
Some implementations do filtering here because there are clients that don't bother checking SMTP reply codes to commands other than DATA. Hence, it can be useful to add greylisting capability at that point in an SMTP session.
DATA以外のコマンドへのSMTP応答コードのチェックを行わないクライアントが存在するため、一部の実装はここでフィルタリングを行います。したがって、SMTPセッションのその時点でグレーリスト機能を追加すると便利です。
Numerous greylisting policies are possible at this point. All of them retain a record of tuples that combine the various parts of the SMTP transaction in some combination, including:
この時点で、多数のグレーリストポリシーが可能です。それらのすべては、SMTPトランザクションのさまざまな部分をいくつかの組み合わせで組み合わせたタプルの記録を保持しています。
o the source, as described above;
o 上記のソース。
o the return email address;
o 返信メールアドレス;
o the recipients of the message, as a set or individually;
o メッセージの受信者（セットまたは個別）。
o identifiers in the message header, such as the contents of the RFC5322.From or RFC5322.To fields;
o RFC5322.FromまたはRFC5322.Toフィールドの内容など、メッセージヘッダー内の識別子。
o other prominent parts of the content, such as the RFC5322.Subject field;
o RFC5322.Subjectフィールドなど、コンテンツの他の主要な部分。
o a digest of some or all of the message content, as a test for uniqueness; and
o 一意性のテストとしての、メッセージコンテンツの一部またはすべてのダイジェスト。そして
o analysis of arbitrary portions of the message body.
o メッセージ本文の任意の部分の分析。
(The last four items in the list above are only possible at the end of DATA, not on receipt of the DATA command.)
（上記のリストの最後の4つの項目は、DATAコマンドの受信時ではなく、DATAの最後でのみ可能です。）
If the selected tuple is not found in the database, or if the record exists but has not reached some configured minimum age, the greylisting MTA returns 4yz SMTP replies to all commands for the remainder of the SMTP session.
選択したタプルがデータベースに見つからない場合、またはレコードは存在するが、構成された最小経過時間に達していない場合、グレイリストMTAは、SMTPセッションの残りのすべてのコマンドに対して4yz SMTP応答を返します。
Since greylisting seeks to target spam senders, it follows that being able to identify spamware within the SMTP context beyond the simple notion of "not seen before" would be desirable. A more targeted approach might also include in its selection heuristics such as the following:
グレイリストはスパムの送信者をターゲットにすることを目的としているため、「以前に見られない」という単純な概念を超えて、SMTPコンテキスト内でスパムウェアを識別できることが望ましいでしょう。より対象を絞ったアプローチには、次のようなヒューリスティックの選択も含まれます。
o If a DNS blacklist [DNSBL] lists an IP address but the implementer wishes to be cautious with mitigation actions rather than blocking traffic from the IP address outright, then subject it to greylisting.
o DNSブラックリスト[DNSBL]にIPアドレスがリストされているが、実装者がIPアドレスからのトラフィックを完全にブロックするのではなく、軽減アクションに注意したい場合は、グレーリストの対象にします。
o If the value found in a PTR record follows common naming patterns for dynamic IP addresses, then subject it to greylisting.
o PTRレコードで見つかった値が動的IPアドレスの一般的な命名パターンに従っている場合は、それをグレーリストの対象にします。
Most greylisting systems provide for an exception mechanism, allowing one to specify IP addresses, IP address Classless Inter-Domain Routing (CIDR) [CIDR] blocks, host names, or domain names that are exempt from greylisting checks and thus whose SMTP client sessions are not subject to such interference.
ほとんどのグレーリストシステムは例外メカニズムを備えており、IPアドレス、IPアドレスのクラスレスドメイン間ルーティング（CIDR）[CIDR]ブロック、ホスト名、またはグレーリストチェックから除外され、SMTPクライアントセッションがあるドメイン名を指定できますそのような干渉を受けません。
Likely candidates to be excepted from greylisting include those known not to retry according to a pattern that will be observed as legitimate and those that send so rarely that they will age out of the database. In both cases, the excepted source is known not to be an abusive one by the site implementing greylisting. Otherwise, typical non-abusive senders will enter the exception list on the first proper retry and remain there permanently.
グレイリストから除外される可能性が高い候補には、正当なものとして観察されるパターンに従って再試行しないことがわかっている候補、および送信が非常に少ないためデータベースから期限切れになる候補が含まれます。どちらの場合も、グレイリストを実装しているサイトでは、除外されたソースが悪用されていないことがわかっています。それ以外の場合、一般的な不正行為を行わない送信者は、最初の適切な再試行で例外リストに入り、永続的にそこに留まります。
One could also use a [DNSBL] that lists known good hosts as a greylisting exception set.
既知の適切なホストをグレーリストの例外セットとしてリストする[DNSBL]を使用することもできます。
The most obvious benefit with any of the above techniques is that spamware generally does not retry and is therefore less likely to succeed, absent a record of a previous delivery attempts.
上記のテクニックの最も明白な利点は、スパムウェアが通常再試行しないため、以前の配信試行の記録がないと成功する可能性が低いことです。
The most obvious detriment to implementing greylisting is the imposition of delay on legitimate mail. Some popular MTAs do not retry failed delivery attempts for an hour or more, which can cause expensive delays when delivery of mail is time critical. Worse, some legitimate MTAs do not retry at all. (Note, however, that non-retrying clients are not fully SMTP-capable, per Section 2.1 of [SMTP]. A client does not know, nor is it entitled to know, the reason for the temporary failure status code being returned; greylisting could be in effect, or it could be caused by a local resource issue at the server. A client therefore needs to be equipped to retry in order to be considered fully capable.)
グレイリストを実装する際の最も明らかな不利益は、正当なメールに遅延を課すことです。一部の一般的なMTAは、失敗した配信の試行を1時間以上再試行しないため、メールの配信に時間がかかる場合に、コストのかかる遅延が発生する可能性があります。さらに悪いことに、一部の正当なMTAはまったく再試行しません。 （ただし、[SMTP]のセクション2.1に従って、再試行しないクライアントは完全にSMTP対応ではないことに注意してください。クライアントは、一時的なエラーステータスコードが返される理由を知りませんし、知る資格もありません。が有効であるか、サーバーのローカルリソースの問題が原因である可能性があります。したがって、クライアントは、完全に機能していると見なされるように、再試行できるように装備する必要があります。
The counterargument to this "false positive" problem is that email has always been a "best-effort" mechanism; thus, this cost is ultimately low in comparison to the cost of dealing with high volumes of unwanted mail. Still, the actual effect of such delays can be significant, such as altering the tone or flow of a multi-participant discussion to a mailing list.
この「誤検知」問題に対する反論は、電子メールが常に「ベストエフォート」メカニズムであったということです。したがって、このコストは、大量の不要なメールを処理するコストと比較して、最終的には低くなります。それでも、このような遅延の実際の影響は、メーリングリストへの複数の参加者によるディスカッションのトーンやフローを変更するなど、重大な場合があります。
When the clients are subjected to any kind of reconfiguration, especially network renumbering, the cache of information stored about SMTP client history does not benefit legitimate clients that are already listed for acceptance. To the greylisting implementation, such clients are once again unknown, and they will once again be subjected to the delay.
クライアントが何らかの種類の再構成、特にネットワークの再番号付けを受けている場合、SMTPクライアントの履歴について保存されている情報のキャッシュは、承認のために既にリストされている正当なクライアントにはメリットがありません。グレイリストの実装では、そのようなクライアントは再び不明であり、再び遅延の影響を受けます。
Another obvious cost is for the required database. It has to be large enough to keep the necessary history and fast enough to avoid excessive inefficiencies in the server's operations. The primary consideration is the maximum age of records in the database. If records age out too soon, then hosts that do retry per [SMTP] will be periodically subjected to greylisting even though they are well- behaved; if records age out after too long a period, then eventually spamware that launches a new campaign will not be identified as "unknown" in this manner and will not be required to retry.
もう1つの明らかなコストは、必要なデータベースのコストです。これは、必要な履歴を保持するのに十分な大きさと、サーバーの操作の過度の非効率を回避するのに十分な速度でなければなりません。主な考慮事項は、データベース内のレコードの最大経過時間です。レコードが期限切れになるのが早すぎる場合、[SMTP]ごとに再試行を行うホストは、正常に動作していても定期的にグレーリストの対象になります。長期間経過してレコードが古くなると、最終的に新しいキャンペーンを開始するスパムウェアはこの方法で「不明」と識別されず、再試行する必要がなくなります。
Presuming that known friendly senders will be manually configured as exceptions to the greylisting check, a steady state will eventually be reached wherein the only mail that is delayed is mail from an IP address that has never sent mail before. Experience suggests that the vast majority of mail comes from places on a developed exception list, so after a training period, only a small proportion of mail is actually affected. The training period could be replaced by processing a history of email traffic and adding the IP addresses from which most traffic arrives to the exception list.
既知の友好的な送信者がグレイリストチェックの例外として手動で設定されると想定すると、最終的に安定した状態になり、遅延するメールは、これまでメールを送信したことがないIPアドレスからのメールのみになります。経験上、メールの大部分は開発された例外リストの場所から送信されていることが示唆されているため、トレーニング期間後、実際に影響を受けるのはごく一部のメールのみです。トレーニング期間は、電子メールトラフィックの履歴を処理し、ほとんどのトラフィックの送信元のIPアドレスを例外リストに追加することで置き換えることができます。
Applying greylisting based on actual message content (i.e., post-DATA) is substantially more expensive than any of the other alternatives both in terms of the resources required to accept and temporarily store a complete message body (which can be quite substantial) and any processing that is done on that content. As a consequence, such methods incur more cost during the session and thus are not typical practice.
実際のメッセージコンテンツ（つまり、DATA後）に基づくグレーリストの適用は、完全なメッセージ本文（かなりの量になる可能性があります）を受け入れて一時的に保存するために必要なリソースと処理の両方の点で、他のどの方法よりもかなり高価ですそれはそのコンテンツで行われます。結果として、このような方法はセッション中にコストがかかるため、一般的な方法ではありません。
There are a few failure modes of greylisting that are worth considering. For example, consider an email message intended for user@example.com. The example.com domain is served by two receiving mail servers, one called mail1.example.com and one called mail2.example.com. On the first delivery attempt, mail1.example.com greylists the client, and thus the client places the message in its outgoing queue for later retry. Later, when a retry is attempted, mail2.example.com is selected for the delivery, either because mail1.example.com is unavailable or because a round-robin [DNS] evaluation produces that result. However, the two example.com hosts do not share greylisting databases, so the second host again denies the attempt. Thus, although example.com has sought to improve its email throughput by having two servers, it has, in fact, amplified the problem of legitimate mail delay introduced by greylisting.
検討に値するグレイリストのいくつかの失敗モードがあります。たとえば、user @ example.com宛の電子メールメッセージを考えてみます。 example.comドメインは、2つの受信メールサーバー（mail1.example.comとmail2.example.comの1つ）によって処理されます。最初の配信の試行時に、mail1.example.comはクライアントをグレーリストに登録するため、クライアントは後で再試行するためにメッセージを送信キューに配置します。後で再試行が試行されると、mail1.example.comが使用できないか、ラウンドロビン[DNS]評価でその結果が生成されるため、配信にmail2.example.comが選択されます。ただし、2つのexample.comホストはグレーリストデータベースを共有しないため、2番目のホストは再び試みを拒否します。したがって、example.comは2台のサーバーを設置して電子メールのスループットを向上させることを目指してきましたが、実際には、グレーリストによって導入される正当なメール遅延の問題を増幅させています。
Similarly, consider a site with multiple outbound MTAs that share a common queue. On a first outbound delivery attempt to example.com, the attempt is greylisted. On a later retry, a different outbound MTA is selected, which means example.com sees a different source, and once again greylisting occurs on the same message. The same effect can result from the use of [DHCP], where the IP address of an outbound MTA changes between attempts.
同様に、共通のキューを共有する複数のアウトバウンドMTAを持つサイトについて考えます。 example.comへの最初のアウトバウンド配信試行では、試行はグレーリストに登録されます。後で再試行すると、別の送信MTAが選択されます。つまり、example.comは別のソースを参照し、同じメッセージで再びグレーリストが発生します。 [DHCP]を使用しても、同じ結果が得られます。この場合、送信MTAのIPアドレスが試行間で変化します。
For systems that do DATA-level greylisting, if any part of the message has changed since the first attempt, the tuple constructed might be different than the one for the first attempt, and the delivery is again greylisted. Some MTAs do reformulate portions of the message at submission time, and this can produce visible differences for each attempt.
DATAレベルのグレーリストを行うシステムの場合、最初の試行以降にメッセージの一部が変更された場合、構築されるタプルは最初の試行のものとは異なる可能性があり、配信は再びグレーリストに登録されます。一部のMTAは、送信時にメッセージの一部を再構成するため、試行ごとに目に見える違いが生じる可能性があります。
A host that sends mail to a particular destination infrequently might not remain "known" in the receiving server's database and will therefore be greylisted for a high percentage of mail despite possibly being a legitimate sender.
特定の宛先にまれにメールを送信するホストは、受信側サーバーのデータベースで「既知」のままではない可能性があるため、正当な送信者である可能性があるにもかかわらず、メールの割合が高いグレーリストに登録されます。
All of these and other similar cases can cause greylisting to be applied improperly to legitimate MTAs multiple times, leading to long delays in delivery or ultimately the return of the message to its sender. Other side effects include out-of-order delivery of related sequenced messages.
これらのケースやその他の同様のケースでは、正当なMTAに複数回グレーリストが不適切に適用され、配信に長い遅延が生じ、最終的にはメッセージが送信者に返される可能性があります。その他の副作用には、関連する順序付けされたメッセージの順不同の配信が含まれます。
Address translation technologies such as [NAT] cause distinct MTAs to appear to come from a common IP address. This can cause greylisting to be applied only to the first connection attempt from the shared IP address, meaning future MTAs connecting for the first time will be exempted from the protection greylisting provides.
[NAT]などのアドレス変換テクノロジーにより、異なるMTAが共通のIPアドレスから送信されているように見えます。これにより、グレイリストが共有IPアドレスからの最初の接続試行のみに適用される可能性があります。つまり、初めて接続する将来のMTAは、グレイリストが提供する保護から除外されます。
Atypical SMTP client behaviors also need to be considered when deploying greylisting.
グレイリストを展開する際には、SMTPクライアントの非典型的な振る舞いも考慮する必要があります。
Some clients do not retry messages for very long periods. Popular open source MTAs implement increasing backoff times when messages receive temporary failure messages and/or degrade queue priority for very large messages. This means greylisting introduces even more delay for MTAs implementing such schemes, and the delay can become large enough to become a nuisance to users.
一部のクライアントは、非常に長い期間メッセージを再試行しません。一般的なオープンソースMTAは、メッセージが一時的な障害メッセージを受信したり、非常に大きなメッセージのキューの優先度を下げたりする場合のバックオフ時間の増加を実装しています。これは、グレーリストを使用すると、そのようなスキームを実装するMTAにさらに多くの遅延が発生し、遅延がユーザーにとって迷惑になるほど大きくなる可能性があることを意味します。
Some clients do not retry messages at all, in violation of [SMTP]. This means greylisting will cause outright delivery failure right away for sources, envelopes, or messages that it has not seen before, regardless of the client attempting the delivery, essentially treating legitimate mail and spam the same.
[SMTP]に違反して、一部のクライアントはメッセージをまったく再試行しません。つまり、グレーリストを作成すると、配信を試みているクライアントに関係なく、ソース、エンベロープ、またはメッセージが今まで見たことのない完全な配信エラーがすぐに発生し、正当なメールとスパムを本質的に扱います。
If a greylisting scheme requires a database record to have reached a certain age rather than merely testing for the presence of the record in the database, and the client has a retry schedule that is too aggressive, the client could be subjected to rate limiting by the MTA independent of the restrictions imposed by greylisting.
グレイリストスキームで、データベースレコードの存在を単にテストするのではなく、データベースレコードが特定の年齢に達している必要があり、クライアントのリトライスケジュールが厳しすぎる場合、クライアントはグレイリストによる制限とは無関係のMTA。
Some SMTP implementations make the error of treating all error codes as fatal, contrary to [SMTP]; that is, a 4yz response is treated as if it were a 5yz response, and the message is returned to the sender as undeliverable. This can result in such things as inadvertent removal from mailing lists in response to the perceived rejections.
一部のSMTP実装では、[SMTP]とは異なり、すべてのエラーコードを致命的なものとして処理するというエラーが発生します。つまり、4yz応答は5yz応答であるかのように扱われ、メッセージは配信不能として送信者に返されます。これにより、拒否の認識に応じて、不注意でメーリングリストから削除されるなどの結果になる可能性があります。
Some clients encode message-specific details in the address parameter to the [SMTP] MAIL command. If doing so causes the parameter to change between retry attempts, a greylisting implementation could see it as a new delivery rather than a retry and disallow the delivery. In such cases, the mail will never be delivered and will be returned to the sender after the retry timeout expires.
一部のクライアントは、アドレス固有のメッセージ固有の詳細を[SMTP] MAILコマンドにエンコードします。そうすることでパラメーターが再試行の試行の間に変化する場合、グレイリストの実装はそれを再試行ではなく新しい配信と見なし、配信を許可しない可能性があります。このような場合、メールは配信されず、再試行タイムアウトの期限が切れると送信者に返されます。
A client subjected to greylisting might move to the next host found in the ordered [DNS] MX record set for the destination domain and re-attempt delivery. This has several considerations of its own:
グレーリストの対象となったクライアントは、宛先ドメインの順序付けられた[DNS] MXレコードセットにある次のホストに移動して、配信を再試行する場合があります。これには独自の考慮事項がいくつかあります。
o Traffic to those alternate servers increases merely as a result of greylisting.
o これらの代替サーバーへのトラフィックは、単にグレーリストの結果として増加します。
o Alternate (MX) servers SHOULD share the same greylisting database. When they do not -- as is often true when the servers occupy different Administrative Management Domains (ADMDs) -- SMTP clients can see variable treatment if they try to send to different MX hosts.
o 代替（MX）サーバーは、同じグレーリストデータベースを共有する必要があります（SHOULD）。サーバーが異なる管理管理ドメイン（ADMD）を占有している場合はよくあることですが、そうでない場合、SMTPクライアントは、異なるMXホストに送信しようとすると、変数の扱いを確認できます。
o When alternate MX servers relay mail back to the "primary" MX server, the latter SHOULD be configured to permit the other servers to relay mail without being subjected to greylisting.
o 代替MXサーバーがメールを「プライマリ」MXサーバーにリレーする場合、後者は、他のサーバーがグレイリストの対象になることなくメールをリレーできるように構成する必要があります（SHOULD）。
There are some applications that connect to an SMTP server and simulate a transaction up to the point of sending the RCPT command in an attempt to confirm that an address is valid. Some of these are legitimate applications (e.g., mailing list servers), and others are automated programs that attempt to ascertain valid addresses to which to send spam (a "directory harvesting" attack). Greylisting can interfere with both instances, with harmful effects on the former.
SMTPサーバーに接続し、アドレスが有効であることを確認するためにRCPTコマンドを送信するまでのトランザクションをシミュレートするアプリケーションがいくつかあります。これらの一部は正当なアプリケーション（メーリングリストサーバーなど）であり、その他はスパムを送信する有効なアドレスを確認しようとする自動プログラム（「ディレクトリ獲得」攻撃）です。グレイリストは両方のインスタンスに干渉する可能性があり、前者に悪影響を及ぼします。
Greylisting is obviously not a foolproof solution to avoiding abusive traffic. Bad actors that send mail with just enough frequency to avoid having their records expire will never be caught by this mechanism after the first instance.
グレイリストは明らかに、不正なトラフィックを回避するための絶対的な解決策ではありません。レコードが期限切れになるのを回避するのに十分な頻度でメールを送信する悪いアクターは、最初のインスタンスの後でこのメカニズムによって決してキャッチされません。
Where this is a concern, combining greylisting with some form of reputation service that estimates the likely behavior for IP addresses that are not intercepted by the greylisting function would be a good choice.
これが問題になる場合は、グレーリストと、グレーリスト機能によってインターセプトされないIPアドレスの可能性のある動作を推定するある種のレピュテーションサービスを組み合わせることは、適切な選択です。
The following practices are RECOMMENDED based on collected experience:
以下のプラクティスは、収集された経験に基づいて推奨されます。
1. Implement greylisting based on a tuple consisting of (IP address, RFC5321.MailFrom, and the first RFC5321.RcptTo). It is sufficient to use only the first RFC5321.RcptTo as legitimate MTAs appear not to reorder recipients between retries. Including RFC5321.MailFrom improves accuracy where the IP address is being matched in clusters (e.g., CIDR blocks) rather than precisely (see below). After a successful retry, allow all further [SMTP] traffic from the IP address in that tuple regardless of envelope information.
1. （IPアドレス、RFC5321.MailFrom、および最初のRFC5321.RcptTo）で構成されるタプルに基づいてグレーリストを実装します。最初のRFC5321.RcptToを使用するだけで十分です。正当なMTAは再試行の間に受信者を並べ替えないように見えるからです。 RFC5321.MailFromを含めると、正確にではなく、クラスター（CIDRブロックなど）でIPアドレスが一致する場合の精度が向上します（以下を参照）。再試行が成功したら、エンベロープ情報に関係なく、そのタプル内のIPアドレスからの[SMTP]トラフィックをすべて許可します。
2. Include a configurable range of time within which a retry from a greylisted host is considered and outside of which it is otherwise ignored. The range needs to cover typical retry times of common MTA configurations, thus anticipating that a fully capable MTA will retry sometime after the beginning of the range and before the end of it. The default range SHOULD be from one minute to 24 hours. Retries within the range are permitted and satisfy the greylisting test, and the client is thus no longer likely to be a sender of spam. Retries after the end of the range SHOULD be considered to be a new message for the purposes of greylisting evaluation (i.e., reset the "first seen" timestamp for that IP address). Some sites use a higher time value for the low end of the time range to match common legitimate MTA retry timeouts, but additional benefit from doing so appears unlikely.
2. グレーリストに記載されたホストからの再試行が考慮され、それ以外の場合は無視される構成可能な時間範囲を含めます。範囲は、一般的なMTA構成の典型的な再試行時間をカバーする必要があるため、完全に機能するMTAは、範囲の開始後から終了までの間に再試行することが予想されます。デフォルトの範囲は1分から24時間である必要があります（SHOULD）。範囲内の再試行は許可され、グレイリストテストを満たしているため、クライアントはスパムの送信者である可能性が低くなります。範囲の終了後の再試行は、グレイリストの評価の目的で新しいメッセージと見なされる必要があります（つまり、そのIPアドレスの「最初に検出された」タイムスタンプをリセットします）。一部のサイトでは、時間範囲の下限に高い時間値を使用して、一般的な正当なMTA再試行タイムアウトに一致させていますが、そうすることによる追加の利点はほとんどありません。
3. Include a timeout for database entries, after which records for IP addresses that have generated no recent traffic are deleted. This step is intended to re-enable greylisting for an IP address in the event that it has changed "owners" and will subject the client to another round of greylisting. The default SHOULD be at least one week.
3. 最近のトラフィックを生成していないIPアドレスのレコードが削除された後、データベースエントリのタイムアウトを含めます。このステップは、「所有者」が変更された場合にIPアドレスのグレーリストを再度有効にし、クライアントに別のラウンドのグレーリストを適用することを目的としています。デフォルトは少なくとも1週間である必要があります。
4. For an Administrative Management Domain (ADMD), all inbound border MTAs listed in the [DNS] SHOULD share a common greylisting database and common greylisting policies. This handles sequences in which a client's retry goes to a different server after the first 4yz reply, and it lets all servers share the list of hosts that did retry successfully.
4. 管理管理ドメイン（ADMD）の場合、[DNS]にリストされているすべてのインバウンド境界MTAは、共通のグレーリストデータベースと共通のグレーリストポリシーを共有する必要があります（SHOULD）。これは、最初の4yz応答の後でクライアントの再試行が別のサーバーに送られるシーケンスを処理し、すべてのサーバーが正常に再試行したホストのリストを共有できるようにします。
5. To accommodate those senders that have clusters of outgoing mail servers, greylisting servers MAY track CIDR blocks of a size of its own choosing, such as /24, rather than the full IPv4 address. (Note, however, that this heuristic will not work for clusters having machines on different networks.) A similar grouping capability MAY be established based on the domain name of the mail server if one can be determined.
5. 送信メールサーバーのクラスターを持つ送信者に対応するために、グレイリストサーバーは、完全なIPv4アドレスではなく、独自に選択したサイズ（/ 24など）のCIDRブロックを追跡できます（MAY）。 （ただし、このヒューリスティックは、異なるネットワーク上にマシンがあるクラスターでは機能しません。）メールサーバーのドメイン名が判別できる場合は、それに基づいて同様のグループ化機能を確立できます（MAY）。
6. Include a manual override capability for adding specific IP addresses or network blocks that always bypass checks. There are legitimate senders that simply don't respond well to greylisting for a variety of reasons, most of which do not conflict with [SMTP]. There are also some highly visible online entities such as email service providers that will be certain to retry; thus, those that are known SHOULD be allowed to bypass the filter.
6. 常にチェックをバイパスする特定のIPアドレスまたはネットワークブロックを追加するための手動オーバーライド機能を含めます。正当な送信者には、さまざまな理由でグレイリストにうまく応答しないものがあり、そのほとんどは[SMTP]と競合しません。また、メールサービスプロバイダーなど、確実に再試行できるオンラインエンティティもいくつかあります。したがって、知られているものはフィルターをバイパスすることが許可されるべきです。
7. Greylisting SHOULD NOT be applied by an ADMD's submission service (see [SUBMISSION]) for authenticated client hosts. It also SHOULD not be applied against any authenticated ADMD session. Authentication can include whatever mechanisms are deemed appropriate for the ADMD, such as known internal IP addresses, protocol-level client authentication, or the like.
7. グレイリストは、認証されたクライアントホストに対してADMDの提出サービス（[提出]を参照）によって適用されるべきではありません（SHOULD NOT）。また、認証されたADMDセッションには適用しないでください。認証には、既知の内部IPアドレス、プロトコルレベルのクライアント認証など、ADMDに適切と見なされるメカニズムを含めることができます。
There is no specific recommendation as to the specific choice of 4yz code to be returned as a result of a greylisting delay. Per [SMTP], however, the only two reasonable choices are 421 if the implementation wishes to terminate the connection immediately and 450 otherwise. It is possible that some clients treat different 4yz codes differently, but no data is available on whether using 421 versus some other 4yz code is particularly advantageous.
グレーリストの遅延の結果として返される4yzコードの特定の選択に関して、特定の推奨事項はありません。ただし、[SMTP]ごとに、実装が接続をすぐに終了したい場合は421、それ以外の場合は450しか選択できません。一部のクライアントは異なる4yzコードを異なる方法で処理する可能性がありますが、421を使用するか、他の4yzコードを使用することが特に有利かどうかに関するデータはありません。
There is also no specific recommendation as to the choice of text to include in the SMTP reply, if any. Some implementers argue that indicating that greylisting is in effect can give spamware a hint as to when to try again for successful delivery, while others suspect that it won't matter to spamware and thus the more likely audience is legitimate senders seeking to understand why their mail is being delayed.
また、SMTP応答に含めるテキストがある場合、その選択に関して特定の推奨事項はありません。一部の実装者は、グレーリストが有効であることを示すことで、スパムウェアに配信の成功をいつ再試行するかについてのヒントを与えることができると主張します。メールが遅れています。
A few techniques are common when measuring the effectiveness of greylisting in a particular installation:
特定のインストールでグレイリストの有効性を測定する場合、いくつかの手法が一般的です。
o Arrange to log the spam versus legitimate determinations of messages and what the greylisting decision would have been if enabled; then determine whether there is a correlation (and, of course, whether too much legitimate email would also be affected).
o スパム対メッセージの正当な判断と、有効にした場合のグレーリストの決定をログに記録するように手配します。次に、相関関係があるかどうか（そしてもちろん、正当な電子メールが多すぎても影響を受けるかどうか）を判断します。
o Continuing from the previous point, query the set of IP addresses subjected to greylisting in any popular [DNSBL] to see if there is a strong correlation.
o 前のポイントから続けて、人気のある[DNSBL]でグレーリストの対象となるIPアドレスのセットをクエリして、強い相関関係があるかどうかを確認します。
The descriptions and recommendations presented in this memo are based on many years of experience with greylisting in the IPv4 Internet environment, so they clearly pertain to IPv4 deployments only.
このメモに示されている説明と推奨事項は、IPv4インターネット環境でのグレーリストに関する長年の経験に基づいているため、IPv4の展開のみに明確に関係しています。
The greater size of an IPv6 address seems likely to permit differences in behaviors by bad actors, and this could well mean needing to alter the details for applying greylisting; it might even negate any benefits in using greylisting at all. At a minimum, it is likely to call for different specific choices for any greylisting algorithm variables.
IPv6アドレスのサイズが大きいと、悪意のある行為者による動作の違いが許容される可能性が高く、これは、グレーリストを適用するための詳細を変更する必要があることを意味する可能性があります。グレイリストを使用するメリットをすべて否定することもできます。少なくとも、グレーリストアルゴリズム変数には異なる特定の選択肢が必要になる可能性があります。
In addition, an obvious consideration is that the size of the database required to store records of all of the IP addresses seen will likely be substantially larger in the IPv6 environment.
さらに、明らかな考慮事項として、IPv6環境では、表示されるすべてのIPアドレスのレコードを保存するために必要なデータベースのサイズがかなり大きくなる可能性があります。
This section discusses potential security issues related to greylisting.
このセクションでは、グレーリストに関連する潜在的なセキュリティ問題について説明します。
The discussion above highlights the fact that, although greylisting provides some obvious and valuable defenses, it can introduce unintentional and detrimental consequences for delivery of legitimate mail. Where timely delivery of email is essential, especially for financial, transactional, or security-related applications, the possible consequences of such systems need to be carefully considered.
上記の議論は、グレーリストは明白で価値のある防御策を提供しますが、正当なメールの配信に意図的でなく有害な結果をもたらす可能性があるという事実を強調しています。電子メールのタイムリーな配信が不可欠である場合、特に金融、トランザクション、またはセキュリティ関連のアプリケーションでは、そのようなシステムの考えられる結果を慎重に検討する必要があります。
Specific sources can be exempted from greylisting, but, of course, that means they have elevated privilege in terms of access to the mailboxes on the greylisting system, and malefactors can seek to exploit this.
特定のソースをグレーリストから除外することはできますが、もちろん、それらはグレーリストシステム上のメールボックスへのアクセスに関して高い特権を持っていることを意味し、悪意のある者はこれを悪用しようとする可能性があります。
The database that has to be maintained as part of any greylisting system will grow as the diversity of its SMTP clients' hosts grows and, of course, is larger in general depending on the nature of the tuple stored about each delivery attempt. Even with a record aging policy in place, such a database could grow large enough to interfere with the system hosting it, or at least to a point at which greylisting service is degraded. Moreover, an attacker knowing which greylisting scheme is in use could rotate parameters of SMTP clients under its control, in an attempt to inflate the database to the point of denial-of-service.
グレイリストシステムの一部として維持する必要があるデータベースは、SMTPクライアントのホストの多様性が大きくなるにつれて大きくなり、もちろん、各配信試行について保存されているタプルの性質によっては、一般的に大きくなります。レコードエージングポリシーが導入されていても、そのようなデータベースは、それをホストしているシステムを妨害するほど、または少なくともグレーリストサービスが低下するほど大きくなる可能性があります。さらに、どのグレーリストスキームが使用されているかを知っている攻撃者は、制御下にあるSMTPクライアントのパラメータをローテーションさせて、データベースをサービス拒否のポイントまで膨らませようとする可能性があります。
Implementers could consider configuring an appropriate failure policy so that something locally acceptable happens when the database is attacked or otherwise unavailable.
実装者は、データベースが攻撃された場合やその他の方法で利用できない場合にローカルで受け入れ可能な何かが発生するように、適切な障害ポリシーの構成を検討できます。
In practice, this has not appeared as a serious concern, because any reasonable aging policy successfully moderates database growth. It is nevertheless identified here as a consideration as there may be implementations in some environments where this is indeed an issue.
実際には、これは深刻な問題とは見なされていません。合理的なエージングポリシーによってデータベースの成長が適切に緩和されるためです。それでも、これが実際に問題となる一部の環境では実装が存在する可能性があるため、これは考慮事項としてここで識別されます。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーク]クロッカーD.、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011.
[提出] Gellens、R。およびJ. Klensin、「メールのメッセージ送信」、STD 72、RFC 6409、2011年11月。
[CIDR] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[CIDR] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[DNSBL] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010.
[DNSBL] Levine、J。、「DNS Blacklists and Whitelists」、RFC 5782、2010年2月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[NAT] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
[PUREMAGIC] Harris, E., "The Next Step in the Spam Control War: Greylisting", August 2003, <http://projects.puremagic.com/greylisting/ whitepaper.html>.
[PUREMAGIC] Harris、E。、「スパム制御戦争の次のステップ：グレイリスト」、2003年8月、<http://projects.puremagic.com/greylisting/ whitepaper.html>。
[SAUCE] Jackson, I., "GNU SAUCE", 2001, <http://www.gnu.org/software/sauce>.
[ソース]ジャクソン、I。、「GNU SAUCE」、2001、<http://www.gnu.org/software/sauce>。
The authors wish to acknowledge Mike Adkins, Steve Atkins, Mihai Costea, Derek Diget, Peter J. Holzer, John Levine, Chris Lewis, Jose-Marcio Martins da Cruz, John Klensin, S. Moonesamy, Suresh Ramasubramanian, Mark Risher, Jordan Rosenwald, Gregory Shapiro, Joe Sniderman, Roland Turner, and Michael Wise for their contributions to this memo. The various participants of the MAAWG Open Sessions about greylisting were also valued contributors.
著者は、マイク・アドキンス、スティーブ・アトキンス、ミハイ・コステア、デレク・ディゲット、ピーター・J・ホルツァー、ジョン・レバイン、クリス・ルイス、ホセ・マルシオ・マルティンス・ダ・クルス、ジョン・クレンシン、S・ムーネサミー、スレシュ・ラマスブラマニアン、マーク・リシャー、ジョーダン・ローゼンヴァルド、Gregory Shapiro、Joe Sniderman、Roland Turner、Michael Wiseによるこのメモへの貢献。グレイリストに関するMAAWGオープンセッションのさまざまな参加者も、貢献者として高く評価されました。
Authors' Addresses
著者のアドレス
Murray S. Kucherawy Cloudmark 128 King St., 2nd Floor San Francisco, CA 94107 US
マレーS.クチェラウィCloudmark 128 King St.、2nd Floor San Francisco、CA 94107 US
Phone: +1 415 946 3800
EMail: superuser@gmail.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net