[要約] RFC 2505は、SMTPメール転送エージェント（MTA）におけるスパムメールの問題に対処するための推奨事項を提供します。この文書の目的は、スパムの量を減らし、メールシステムの管理者がスパムに効果的に対処できるようにすることです。利用場面としては、メールサーバーの設定やポリシー策定時に参照されます。関連するRFCには、RFC 2821（SMTPの仕様を定義）やRFC 7208（SPF: Sender Policy Frameworkの定義）などがあります。これらの文書と合わせて、スパム対策のための包括的なガイドラインを提供します。
Network Working Group G. Lindberg
Request for Comments: 2505 Chalmers University of Technology
BCP: 30 February 1999
Category: Best Current Practice
Anti-Spam Recommendations for SMTP MTAs
SMTP MTAのスパム防止推奨事項
Status of this Memo
本文書の位置付け
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*).
このメモは、SMTP、[1]、MTAS（メール転送エージェントなど、SendMailなど[8]）に関する多くの実装推奨事項を提供し、SPAM（*）の影響を減らすことができるようにします。
The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.
意図は、これらの推奨事項が、インターネット上の十分なSMTP MTAに適用される場合、スパムの状況をクリーンアップするのに役立ち、さまざまなMTAベンダーのガイドラインとして使用する必要があることです。これが最終的なソリューションではないことを完全に認識していますが、これらの推奨事項が含まれ、すべてのインターネットSMTP MTAで使用された場合、事態は大幅に改善され、より長期的なソリューションを設計する時間が与えられます。将来の作業セクションは、このような長期的な解決策の一部である可能性のあるいくつかのアイデアを示唆しています。しかし、究極の解決策は、本質的に技術的なものではなく、社会的、政治的、または合法であることが非常によくあるかもしれません。
The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.
実装者は、提案された方法のいくつかが導く可能性のあるサービス拒否攻撃のリスクの増加を認識する必要があります。たとえば、DNSサーバーへのクエリの数の増加とログファイルのサイズの増加は、攻撃中に過負荷のシステムとシステムのクラッシュにつながる可能性があります。
A brief summary of this memo is:
このメモの簡単な要約は次のとおりです。
o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam.
o 許可されていないメールリレーを停止します。oスパマーは、オープンで操作する必要があります。それらに対処します。oスパムを処理できるメールシステムを設計します。
This memo is a Best Current Practice (BCP) RFC. As such it should be used as a guideline for SMTP MTA implementors to make their products more capable of preventing/handling spam. Despite this being its primary goal, an intended side effect is to suggest to the sysadmin/Postmaster community which "anti spam knobs" an SMTP MTA is expected to have.
このメモは、最高の現在のプラクティス（BCP）RFCです。そのため、SMTP MTA実装者のガイドラインとして使用して、製品をよりスパムの防止/処理できるようにする必要があります。これが主要な目標であるにもかかわらず、意図された副作用は、SMTP MTAが「アンチスパムノブ」と予想されるSysadmin/Postmasterコミュニティに提案することです。
However, this memo is not generally intended as a description on how to operate an SMTP MTA - which "knobs" to turn and how to configure the options. If suggestions are provided, they will be clearly marked and they should be read as such.
ただし、このメモは一般に、SMTP MTAの操作方法に関する説明として意図されていません。これは、ターンする「ノブ」とオプションの構成方法です。提案が提供された場合、それらは明確にマークされ、そのように読む必要があります。
Mass unsolicited electronic mail, often known as spam(*), has increased considerably during a short period of time and has become a serious threat to the Internet email community as a whole. Something needs to be done fairly quickly.
多くの場合、スパム（*）として知られる大量の未承諾の電子メールは、短期間に大幅に増加し、インターネットメールコミュニティ全体にとって深刻な脅威になりました。何かをかなり迅速に行う必要があります。
The problem has several components:
問題にはいくつかのコンポーネントがあります。
o It is high volume, i.e. people get a lot of such mail in their mailboxes.
o それは大量です。つまり、人々はメールボックスでそのようなメールをたくさん受け取ります。
o It is completely "blind", i.e. there is no correlation between the receivers' areas of interest and the actual mail sent out (at least if one assumes that not everybody on the Internet is interested in porno pictures and spam programs...).
o それは完全に「盲目」です。つまり、受信機の関心領域と実際のメールが送信される実際のメールとの間に相関関係はありません（少なくとも、インターネット上のすべての人がポルノの写真やスパムプログラムに興味がないと想定している場合）。
o It costs real money for the receivers. Since many receivers pay for the time to transfer the mailbox from the (dialup) ISP to their computer they in reality pay real money for this.
o レシーバーにとっては本当のお金がかかります。多くのレシーバーは、（ダイヤルアップ）ISPからコンピューターにメールボックスを転送する時間を支払うため、実際には実際のお金を支払います。
o It costs real money for the ISPs. Assume one 10 Kbyte message sent to 10 000 users with their mailboxes at one ISP host; that means an unsolicited, unexpected, storage of 100 Mbytes. State of the art disks, 4 Gbyte, can take 40 such message floods before they are filled. It is almost impossible to plan ahead for such "storms".
o ISPには本当のお金がかかります。1つのISPホストでメールボックスを持つ10,000人のユーザーに送信された10 k kbyteメッセージを1つ想定しています。つまり、100 mbytesの未承諾の予期せぬ保管を意味します。最先端のディスク、4 GBYTEは、満たされる前に40のそのようなメッセージの洪水を取ることができます。そのような「嵐」を事前に計画することはほとんど不可能です。
o Many of the senders of spam are dishonest, e.g. hide behind false return addresses, deliberately write messages to look like they were between two individuals so the spam recipient will think it was just misdelivered to them, say the message is "material you
o スパムの送信者の多くは不正直です。誤った返品アドレスの後ろに隠れて、2人の個人の間にあるように見えるように故意にメッセージを書くので、スパムの受信者はそれが彼らに誤って削除されたと思うでしょう、とメッセージは「あなたが
requested" when you never asked for it, and generally do everything they can without regard to honesty or ethics, to try to get a few more people to look at their message.
「あなたがそれを求めたことがないとき、そして一般的に誠実さや倫理に関係なく彼らができることをすべて行い、彼らのメッセージを見てもらうようにしようとするとき。
In fact some of the spam-programs take a pride in adding false info that will "make the ISPs scratch their heads".
実際、スパムプログラムの一部は、「ISPが頭を傷つける」誤った情報を追加することに誇りを持っています。
It is usually the case that people who send in protests (often according to the instructions in the mail) find their mail addresses added to more lists and sold to other parties.
通常、抗議を送る人々（多くの場合、メールの指示に従って）を送っている人は、メールアドレスがより多くのリストに追加され、他の関係者に販売されます。
o It is quite common practice to make use of third party hosts as relays to get the spam mail sent out to the receivers. This theft of service is illegal in most - if not all - countries (at least in the US spammers have been successfully sued). However, with the original sender in the US, the (innocent) relay in Sweden and the list of receivers back in the US, the legal process of getting damages from the spammers becomes extremely difficult.
o スパムメールを受信機に送信するためのリレーとしてサードパーティのホストを使用することは非常に一般的な慣行です。このサービスの盗難は、すべてではないにしても、ほとんどの国では違法です（少なくとも米国では、スパマーは首尾よく訴えられました）。しかし、米国の元の送信者、スウェーデンの（罪のない）リレー、および米国に戻ったレシーバーのリストにより、スパマーからの損害を得る法的プロセスは非常に困難になります。
This memo has no intention of being the final solution to the spam problem.
このメモは、スパム問題の最終的な解決策になるつもりはありません。
If, however, enough Internet MTAs did implement enough of the rules described below (especially the Non-Relay rules), we would get the spammers out in the open, where they could be taken care of. Either pure legal actions would help, or we can block them technically using other rules described below (since the Non-Relay rules now make them appear openly, with their own hosts and domains, we can apply various access filters against them). In reality, a combination of legal and technical methods is likely to give the best result.
ただし、十分なインターネットMTAが以下に説明するルールの十分なルールを実装した場合（特に非関連規則）、スパマーをオープンに配置し、そこで世話をすることができます。純粋な法的措置が役立つか、以下に説明する他のルールを技術的にブロックすることができます（非関連ルールは、独自のホストとドメインを使用して、それらに対してさまざまなアクセスフィルターを適用することができます）。実際には、法的方法と技術的方法の組み合わせが最良の結果をもたらす可能性があります。
This way, the spam problem could be reduced enough to allow the Internet community to design and deploy a real and general solution.
このようにして、スパムの問題は、インターネットコミュニティが実際のソリューションと一般的なソリューションを設計および展開できるように十分に削減できます。
But, please note:
しかし、注意してください：
The Non-Relay rules are not in themselves enough to stop spam. Even if 99% of the SMTP MTAs implemented them from Day 1, spammers would still find the remaining 1% and use them. Or spammers would just switch gear and connect directly to each and every recipient host; that will be to a higher cost for the spammer, but is still quite likely.
非関連規則は、スパムを止めるほど十分ではありません。SMTP MTAの99％が1日目からそれらを実装したとしても、スパマーは残りの1％を見つけて使用します。または、スパマーはギアを切り替えて、すべての受信者ホストに直接接続するだけです。それはスパマーにとってより高いコストになりますが、それでも非常に可能性があります。
Even though IPv6 deployment may be near, the spam problem is here already and thus this memo restricts itself to the current IPv4.
IPv6の展開は近くにある可能性がありますが、スパムの問題はすでにここにあり、したがってこのメモは現在のIPv4に制限されています。
Throughout this memo we will use the terminology of RFC2119, [4]:
このメモを通して、RFC2119の用語を使用します[4]：
o "MUST"
o "しなければならない"
This word or the adjective "REQUIRED" means that the item is an absolute requirement.
この単語または形容詞「必須」は、アイテムが絶対的な要件であることを意味します。
o "SHOULD"
o "したほうがいい"
This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
この単語または形容詞「推奨」とは、この項目を無視するために特定の状況に正当な理由が存在する可能性があることを意味しますが、完全な意味を理解する必要があり、別のコースを選択する前にケースを慎重に検討する必要があります。
o "MAY"
o "五月"
This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
この単語または形容詞「オプション」は、このアイテムが本当にオプションであることを意味します。1人のベンダーは、特定の市場に必要なものを必要とするため、またはそれが製品を強化するため、アイテムを含めることを選択できます。別のベンダーは同じアイテムを省略する場合があります。
In the memo we sometimes use the term "host name" or "domain name" which should be interpreted as a Fully Qualified Domain Name, FQDN. By this we mean the name returned from the DNS in response to a PTR query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a name, or we mean a name with a DNS A or MX record associated to it RFC1034, [5], and RFC1035, [6].
メモでは、「ホスト名」または「ドメイン名」という用語を使用することがあります。これらは、完全に適格なドメイン名FQDNとして解釈される必要があります。これにより、PTRクエリ（.in-addr.arpa）に応じてDNSから返された名前、つまりIPアドレスが名前に変換される場合、またはDNS AまたはMXレコードが関連付けられている名前の名前を意味する場合IT RFC1034、[5]、およびRFC1035、[6]。
When we suggest use of FQDNs rather than IP addresses this is because FQDNs are intuitively much easier to use. However, all such usage depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it is fairly easy to forge that, either by false cache information injected in DNS servers or spammers running their own DNS with false information in them, host and domain names must be used with care, e.g. verified so that the translation address->name corresponds to name->address. With Secure DNS, RFC2065, [7], things will improve, since spoofing of .IN-ADDR.ARPA will no longer be possible.
IPアドレスではなくFQDNSの使用を提案する場合、これはFQDNが直感的にはるかに使いやすいためです。ただし、そのような使用はすべて、DNSおよび.in-addr.arpa（PTR）情報に大きく依存します。DNSサーバーに挿入された誤ったキャッシュ情報または誤った情報を使用して独自のDNSを実行しているスパマーのいずれかで、誤って断言するのはかなり簡単であるため、ホストとドメイン名は注意して使用する必要があります。翻訳アドレス - >名前がname-> addressに対応するように確認されました。安全なDNS、RFC2065 [7]では、.in-addr.arpaのスプーフィングが不可能になるため、状況は改善されます。
One of the recommendations is about verifying "MAIL From:" (envelope originator) domains with the DNS (assure that appropriate DNS information exists for the domain). When making use of this capability there are a few things to consider:
推奨事項の1つは、「from：」（envelope originator）ドメインをDNSで確認することです（ドメインに適切なDNS情報が存在することを保証します）。この機能を利用するとき、考慮すべきいくつかのことがあります：
(1) One must not forget the increased amount of DNS queries which might result in problems for the DNS server itself to cope with the load. This itself can result in a denial of service attack against the DNS server just by sending email to a site.
(1) DNSサーバー自体が負荷に対処するための問題をもたらす可能性のあるDNSクエリの量の増加を忘れてはなりません。これ自体は、サイトに電子メールを送信するだけで、DNSサーバーに対するサービス拒否攻撃をもたらす可能性があります。
(2) It should be noted that with negative caching in the DNS, forged DNS responses can be used to mount denial of service attacks. For example, if a site is known to implement a FQDN validity check on addresses in SMTP "MAIL From:" commands, an attacker may be able to use negative DNS responses to effectively block acceptance of mail from one or more origins. Because of this, one should carefully check the DNS server in use, e.g. how it verifies that incoming responses correspond to outstanding queries, to minimize the risk for such attacks.
(2) DNSで負のキャッシュを使用すると、鍛造DNS応答を使用して、サービス拒否攻撃を実施できることに注意してください。たとえば、サイトがSMTPのアドレスにFQDN有効性チェックを実装することが知られている場合、 "Mail From："コマンド、攻撃者は否定的なDNS応答を使用して、1つ以上の起源からのメールの受け入れを効果的にブロックできる場合があります。このため、使用中のDNSサーバーを慎重に確認する必要があります。そのような攻撃のリスクを最小限に抑えるために、着信回答が未解決のクエリに対応することをどのように検証するか。
(3) For early versions of spam software FQDN checks provide quite some relief, since that software generates mail with completely bogus "MAIL From:" that will never get into the system if verified with the DNS. This is in active use at many installations today and it does reduce spam.
(3) SPAMソフトウェアの初期バージョンの場合、FQDNチェックはかなりの軽減を提供します。そのソフトウェアは、DNSで確認された場合、システムに完全に偽物の「メール」でメールを生成するためです。これは、今日の多くのインストールで積極的に使用されており、スパムを減らします。
On the other hand, sites with weak DNS connectivity may find their legitimate mail having problems reaching destinations due to DNS timeouts when the receivers verify their "MAIL From:". However, since DNS information is handled asynchronously and is cached even though the initial requester has given up, chances are high that the necessary information is there at a later attempt.
一方、DNS接続が弱いサイトでは、受信者が「メールからのメール」を確認したときにDNSタイムアウトのために宛先に到達するために、正当なメールが宛先に到達していることがわかります。ただし、DNS情報は非同期に処理され、最初のリクエスト担当者があきらめたとしてもキャッシュされるため、必要な情報が後の試みである可能性が高いです。
For later versions of spam software, a check of "MAIL From:" is much less likely to help, since spam software evolves too and will start using existing mail addresses (whether or not that is legal is beyond the scope of this memo). But, at least the Internet will benefit from the side effect that this test stops typos and misconfigured UAs.
スパムソフトウェアの後のバージョンでは、「メールからのメール」のチェックは、Spamソフトウェアも進化し、既存のメールアドレスの使用を開始するため、役立つ可能性がはるかに低くなります（法的であるかどうかは、このメモの範囲を超えています）。しかし、少なくともインターネットは、このテストがタイプミスを停止し、誤ったUASを停止するという副作用の恩恵を受けるでしょう。
Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it in, we leave it to the sender to handle the error.
私たちの基本的な仮定は、ごみ目/受け入れはSMTPレイヤーで処理され、メッセージを拒否することを決定するMTAは、SMTPダイアログ中にまだそうする必要があることです。第一に、これは、後で拒否することを決定したメッセージのコピーを保存する必要がないことを意味し、次に、そのメッセージに対する責任は低いか何もありません。エラーを処理します。
SMTP has several classes of Return Codes, see [1] for a discussion:
SMTPには、いくつかのクラスのリターンコードがあります。ディスカッションについては[1]を参照してください。
o 5xx is a Permanent Negative Completion reply (Fatal Error) and results in the mail transfer being terminated and the mail returned to sender.
o 5XXは永続的なネガティブ完了応答（致命的なエラー）であり、メール転送が終了し、メールが送信者に返されます。
o 4xx is a Transient Negative Completion reply (Temporary Error) and results in the mail transfer being put back on queue again and a new attempt being made later.
o 4XXは一時的な負の完了応答（一時的なエラー）であり、メール転送が再びキューに戻され、後で新しい試みが行われます。
o 2xx is a Positive Completion reply and indicates that the MTA now has taken responsibility for the delivery of the mail.
o 2XXは正の完了返信であり、MTAが現在メールの配信に責任を負っていることを示しています。
When making use of the options/"knobs" described in this memo there are a few things to consider:
このメモに記載されているオプション/「ノブ」を使用するとき、考慮すべきいくつかのことがあります。
For some events, like "Denied - you're on the spammer's list", 5xx may be the correct Return Code, since it terminates the session at once and we are done with it (assuming that the spammer plays by the SMTP rules, which he may decide not to do - in fact he can put the mail back on queue or turn to some other host, regardless of Return Code). However, a 5xx mistake in a configuration may cause legitimate mail to bounce, which may be quite unfortunate.
「拒否された - スパマーのリストに載っている」などのいくつかのイベントでは、5xxがセッションを一度に終了し、私たちが完了しているため、正しい返品コードになる可能性があります（スパマーがSMTPルールによって再生されると仮定します。彼はそうしないことを決定するかもしれません - 実際、彼はメールをキューに戻すか、返品コードに関係なく他のホストに頼ることができます）。ただし、構成の5xxの間違いにより、正当なメールがバウンスする可能性がありますが、これは非常に残念なことです。
Therefore, we suggest 4xx as the Return Code for most cases. Since that is a non fatal error, the mail gets re-queued at the sender and we have at least some time to discover and correct configuration errors, rather than have mail bounce (typically this is when we refuse to Relay for domains that we actually should accept since we are on their MX list).
したがって、ほとんどの場合、返品コードとして4xxをお勧めします。それは非致命的なエラーであるため、メールは送信者に再び登場し、メールバウンスを持っているのではなく、少なくともある程度の構成エラーを発見して修正する時間があります（通常、これは実際にドメインのリレーを拒否するときです私たちは彼らのMXリストに載っているので、受け入れるべきです）。
A 4xx response also makes the spammer's host re-queue the mail and if it really is his own host who gets to do this it is probably a good thing - fill up his disks with his own spam. If, on the other hand, he is using someone else as Relay Host, all the spam mail being queued is a fairly strong evidence that something bad is going on and should cause attention at that Relay Host.
4xxの応答により、スパマーのホストがメールを再び繰り返します。これを行うのが本当に彼自身のホストである場合、おそらくそれは良いことです - 彼自身のスパムで彼のディスクを埋めてください。一方、彼が他の誰かをリレーのホストとして使用している場合、キューに登録されているスパムメールはすべて、何か悪いことが起こっており、そのリレーホストに注意を払うべきであるというかなり強力な証拠です。
However, 4xx Temporary Errors may have unexpected interaction with MX-records. If the receiving domain has several MX records and the lowest preference MX-host refuses to receive mail with a "451" Response Code, the sending host may choose to - and often will - use the next host on the MX list.
ただし、4XXの一時的なエラーは、MX-Recordとの予期しない相互作用がある場合があります。受信ドメインにいくつかのMXレコードがあり、最低の優先権MX -HOSTが「451」応答コードでメールを受信することを拒否した場合、送信ホストはMXリストで次のホストを使用することを選択します。
If that next MX host does not have the same refuse-list, it will of course accept the mail, only to find that the final host still refuses to receive that piece of mail ("MAIL From:"). Our intent was to make the offending mail stay at the offending sender's host and fill up his mqueue disk, but it all ended up at our friend, the next lowest preference MX-host.
次のMXホストに同じRefuse-Listがない場合、もちろんメールを受け入れますが、最終ホストがまだそのメールを受け取ることを拒否していることがわかります（ "Mail From："）。私たちの意図は、問題のある送信者のホストに問題のあるメールを滞在させ、彼のmqueueディスクを埋めることでしたが、それはすべて私たちの友人であり、次に最低のMX-HOSTであることになりました。
Finally, it has been suggested that one may use a 2xx Return Code but nevertheless decide not to forward or receive the spam mail; typical alternatives are to store it elsewhere (e.g. /dev/null). This clearly violates the intent of RFC821 and should not be done without careful consideration - instead of blindly dropping the mail one could re-queue it and manually (or automagically) inspect whether it is spam or legitimate mail and whether it should be dropped or forwarded.
最後に、2xxの返品コードを使用することが示唆されていますが、それでもスパムメールを転送または受信しないことを決定します。典型的な代替品は、他の場所に保管することです（例： /dev /null）。これは明らかにRFC821の意図に違反しており、慎重に検討せずに行うべきではありません - 盲目的にメールをドロップする代わりに、それを再生し、スパムまたは合法的なメールであるかどうか、およびドロップするか転送するかどうかを手動で（または自動的に）検査することができます。
An MTA that also has the ability to handle mailing lists and expand that to a number of recipients, needs to be able to authorize senders and protect its lists from spam. The mechanisms for this may be very different from those for ordinary mail and ordinary users and are not covered in this memo.
メーリングリストを処理し、それを多くの受信者に拡張する機能もあるMTAは、送信者を承認し、そのリストをスパムから保護できる必要があります。これのメカニズムは、通常のメールや通常のユーザーのメカニズムとは大きく異なる場合があり、このメモではカバーされていません。
Here we first give a brief list of recommendations, followed by a more thorough discussion of each of them. We will also give recommendations on things NOT to do, things that may seem natural in the spam fight (and might even work so far) but that might wreak havoc on Internet mail and thus may cause more damage than good.
ここでは、最初に推奨事項の簡単なリストを示し、次にそれらのそれぞれについてより徹底的な議論を行います。また、スパムの戦いでは自然に見えるかもしれないこと（そしてこれまでのところうまくいくかもしれない）についての推奨事項を提供しますが、それはインターネットメールに大混乱をもたらす可能性があり、したがって、良いよりも多くのダメージを引き起こす可能性があります。
1) MUST be able to restrict unauthorized use as Mail Relay.
1) 許可されていない使用をメールリレーとして制限できる必要があります。
2) MUST be able to provide "Received:" lines with enough information to make it possible to trace the mail path, despite spammers use forged host names in HELO statements etc.
2) スパマーがHELOステートメントなどで偽造されたホスト名を使用しているにもかかわらず、メールパスを追跡できるようにするのに十分な情報を「受信： "ラインを提供できる必要があります。
3) MUST be able to provide local log information that makes it possible to trace the event afterwards.
3) その後、イベントを追跡できるようにするローカルログ情報を提供できる必要があります。
4) SHOULD be able to log all occurrences of anti-relay/anti-spam actions.
4) 反関連/スパムアンチスパムアクションのすべての発生を記録できるはずです。
5) SHOULD be able to refuse mail from a host or a group of hosts.
5) ホストまたはホストのグループからメールを拒否できるはずです。
6a) MUST NOT refuse "MAIL From: <>".
6a）「メール：<>」を拒否してはなりません。
6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
6b）「メール：<user@my.local.domain>」から「メール」を拒否してはなりません。
7a) SHOULD be able to refuse mail from a specific "MAIL From:" user, <foo@domain.example>.
7a）特定の「メールからのメールからメールを拒否できるはずです。ユーザー、<foo@domain.example>。
7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
7b）「domain <。*@domain.example>」から「メール全体からメールを拒否できる必要があります。
8) SHOULD be able to limit ("Rate Control") mail flow.
8) メールフローを制限できるはずです。
9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).
9) 「from：」ドメイン（DNSまたはその他の手段を使用）を確認できるはずです。
10) SHOULD be able to verify <local-part> in outgoing mail.
10）送信メールで<Local-Part>を確認できるはずです。
11) SHOULD be able to control SMTP VRFY and EXPN.
11）SMTP VRFYおよびEXPNを制御できるはずです。
12) SHOULD be able to control SMTP ETRN.
12）SMTP ETRNを制御できるはずです。
13) MUST be able to configure to provide different Return Codes for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).
13）異なるルールに対して異なるリターンコードを提供するように設定できる必要があります（例：451 TEMP障害対550致命的なエラー）。
The discussion below often ends up with a need to do various forms of pattern matching on domain/host names and IP addresses/subnets. It is RECOMMENDED that the data/template for doing so may be supplied outside of the MTA, e.g. that the pattern matching rules be included in the MTA but that the actual patterns may be in an external file. It is also RECOMMENDED that the pattern matching rules (external file) may contain regular expressions, to give maximum flexibility.
以下の議論は、多くの場合、ドメイン/ホスト名とIPアドレス/サブネットでさまざまな形式のパターンマッチングを行う必要があることになります。そうするためのデータ/テンプレートは、MTAの外部で提供されることをお勧めします。パターンマッチングルールはMTAに含まれているが、実際のパターンが外部ファイルにある可能性があること。また、パターンマッチングルール（外部ファイル）には、最大限の柔軟性を与えるために正規表現を含めることもお勧めします。
Of course string matching on domain/host names MUST NOT be case sensitive. Since <local-part> may be case sensitive it may be natural to keep that here. However, since <sPAmMeR@domain.example> and <spammer@domain.example> is most probably the same user and since the string compares are used to refuse his messages, we suggest that <local-part> comparisons be case insensitive too.
もちろん、ドメイン/ホスト名での文字列マッチングは、ケースに敏感であってはなりません。<ローカルパート>はケースに敏感かもしれないので、ここでそれを維持するのは自然なことかもしれません。ただし、<spammer@domain.example>および<spammer@domain.example>はおそらく同じユーザーであり、文字列の比較は彼のメッセージを拒否するために使用されるため、<local-part>比較も症例の鈍感であることをお勧めします。
The interpretation that should apply to all these recommendations is flexibility - regardless of how well we design anti-spam rules today, spammers will find ways around them and a well designed MTA should be flexible enough to meet those new threats.
これらすべての推奨事項に適用されるべき解釈は柔軟性です - 今日のスパムアンチスパムルールをどれだけうまく設計するかに関係なく、スパマーはそれらの周りの方法を見つけ、適切に設計されたMTAはそれらの新しい脅威を満たすのに十分柔軟でなければなりません。
Unauthorized usage of a host as Mail Relay means theft of the relay's resources and puts the relay owner's reputation at risk. It also makes it impossible to filter out or block spam without at the same time blocking legitimate mail.
メールリレーとしてのホストの不正使用は、リレーのリソースの盗難を意味し、リレーの所有者の評判を危険にさらします。また、合法的なメールをブロックせずにスパムをフィルタリングまたはブロックすることも不可能になります。
Therefore, the MTA MUST be able to control/refuse such Relay usage.
したがって、MTAはそのようなリレーの使用を制御/拒否できる必要があります。
In an SMTP session we have 4 elements, each with a varying degree of trust:
SMTPセッションでは、4つの要素があり、それぞれがさまざまな信頼度を持っています。
1) "HELO Hostname" Easily and often forged. 2) "MAIL From:" Easily and often forged. 3) "RCPT To:" Correct, or at least intended. 4) SMTP_Caller (host) IP.src addr OK, FQDN may be OK.
1) 「helo hostname」は簡単かつしばしば偽造されました。2）「メール：」簡単に頻繁に偽造されます。3） "rcpt to："修正、または少なくとも意図されています。4）smtp_caller（host）ip.src addr ok、fqdnはOKである可能性があります。
Since 1) and 2) are so easily and often forged, we cannot depend on them at all to authorize usage of our host as Mail Relay.
1）および2）は非常に簡単かつ頻繁に偽造されているため、ホストの使用をメールリレーとして許可するために、それらに依存することはできません。
Instead, the MTA MUST be able to authorize Mail Relay usage based on a combination of:
代わりに、MTAは以下の組み合わせに基づいて、メールリレーの使用を許可できる必要があります。
o "RCPT To:" address (domain). o SMTP_Caller FQDN hostname. o SMTP_Caller IP address.
o 「rcpt to：」アドレス（ドメイン）。o smtp_caller fqdn hostname。o SMTP_CALLER IPアドレス。
The suggested algorithm is:
推奨されるアルゴリズムは次のとおりです。
a) If "RCPT To:" is one of "our" domains, local or a domain that we accept to forward to (alternate MX), then accept to Relay.
a) 「rcpt to：」が「私たちの」ドメインの1つである場合、ローカルまたはドメイン（代替MX）に転送することを受け入れ、リレーに受け入れます。
b) If SMTP_Caller is authorized, either its IP.src or its FQDN (depending on if you trust the DNS), then accept to Relay.
b) SMTP_CALLERがIP.SRCまたはFQDNのいずれか（DNSを信頼するかどうかによって異なります）のいずれかが許可されている場合、リレーに受け入れます。
c) Else refuse to Relay.
c) そうでなければ、中継を拒否します。
When doing a) you have to make sure all kinds of SMTP source routing (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path) is either removed completely before the test, or at least is taken into account.
a）を行う場合、あらゆる種類のSMTPソースルーティング（公式[@a、@b：u@c]、「％」ハック、uucpスタイル '！'パスの両方）が完全に削除されることを確認する必要があります。テスト、または少なくとも考慮されます。
A site implementing this requirement must also be aware that they might block correctly addressed messages, especially such originating or terminating in a gateway to a different mail system than SMTP. Before implementing such a policy, a careful inventory should be done to make sure all routing algorithms used, either by other mail systems or ad-hoc, are known. Each one of such systems must be taken care of on a case-by-case basis.
この要件を実装するサイトは、特にSMTPとは異なるメールシステムへのゲートウェイでそのような発信または終了している、正しくアドレス指定されたメッセージをブロックする可能性があることに注意する必要があります。このようなポリシーを実装する前に、他のメールシステムまたはアドホックによって使用されるすべてのルーティングアルゴリズムが既知であることを確認するために、慎重な在庫を実行する必要があります。そのようなシステムのそれぞれは、ケースバイケースで世話をする必要があります。
Examples of such mail systems, and their addressing schemes are X.400 with an address of the type:
そのようなメールシステムの例とそれらのアドレス指定スキームは、タイプのアドレスを持つX.400です。
"/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway
Another example involves DECnet MAIL-11, which can have addresses in the form:
別の例には、フォームのアドレスを持つことができるdecnet mail-11が含まれます。
"gateway::smtp%\"user@final\""@mail-11-gateway
In all cases the configuration MUST support wild cards for FQDNs and classful IP addresses and SHOULD support "address/mask" for classless IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.
すべての場合において、構成はFQDNSおよびクラスフルIPアドレスのワイルドカードをサポートする必要があり、クラスレスIPアドレスの「アドレス/マスク」をサポートする必要があります。domain.example and *.domain.example;10.11。*。*、192.168.1。*、192.168.2。*、10.0.0.0/13、192.168.1.0/23。
The configuration SHOULD allow for the decision/template data to be supplied by an external source, e.g. text file or dbm database. The decision/template SHOULD be allowed to contain regular expressions.
構成は、外部ソース、例えばテキストファイルまたはDBMデータベース。決定/テンプレートは、正規表現を含めることを許可する必要があります。
The MTA MUST prepend a "Received:" line in the mail (as described in RFC822, [2], and required in RFC1123, [3]). This "Received:" line MUST contain enough information to make it possible to trace the mail path back to the sender. We have two cases:
MTAは、「RFC822、[2]に記載されており、RFC1123、[3]で必要な」「受信：受信」ライン（[2]に記載されている）を準備する必要があります。この「受信：」行には、メールパスを送信者に戻すことができるようにするのに十分な情報が含まれている必要があります。2つのケースがあります。
Internet mail was designed such that the sending host connects directly to the recipient as described by MX records (there may be several MX hosts on a priority list). To assure traceability back to the sending host (which may be a firewall/gateway, as described later) each MTA along the path, including the final MTA, MUST prepend a "Received:" line. For such a "Received:" line we have:
インターネットメールは、送信ホストがMXレコードで説明されているように、受信者に直接接続するように設計されています（優先リストに複数のMXホストがある場合があります）。最終的なMTAを含むパスに沿った各MTAを送信ホスト（これは、後で説明したように、これはファイアウォール/ゲートウェイである可能性があります）に戻るために、「受信：」ラインを準備する必要があります。そのような「受信」：私たちが持っているライン：
It MUST contain:
含める必要があります：
o The IP address of the caller.
o 発信者のIPアドレス。
o The 'date-time' as described in RFC822, [2], pp 18.
o RFC822、[2]、pp 18に記載されている「日付時間」。
It SHOULD contain:
含める必要があります：
o The FQDN corresponding to the callers IP address.
o 発信者IPアドレスに対応するFQDN。
o The argument given in the "HELO" statement.
o 「helo」ステートメントに記載されている議論。
o Authentication information, if an authenticated connection was used for the transmission / submission.
o 認証情報、伝送 /提出に認証された接続が使用された場合。
It is suggested that most other "Received:" fields described in RFC822 be included in the "Received:" lines.
他のほとんどの「受信：RFC822に記載されているフィールドは、「受信」に含まれることが示唆されています。
Basically, any information that can help tracing the message can and should be added to the "Received:" line. It is true even when the initial submission is non-SMTP, for example submission via a web-based
基本的に、メッセージの追跡に役立つ情報は、「受信」ラインに追加することができます。初期提出が非SMTPである場合でも、Webベースの送信などがあります。
mail client where http is used between the web client and server, a "Received:" line can be used to identify that connection stating what IP-address was used when connecting to the http server where the mail was created.
Webクライアントとサーバーの間でHTTPが使用されているクライアントは、「受信：」行を使用して、メールが作成されたHTTPサーバーに接続するときにIPアドレスが使用されたものを示す接続を識別できます。
These recommendations are deliberately stronger than RFC1123, [3], and are there to assure that mail sent directly from a spammer's host to a recipient can be traced with enough accuracy; a typical example is when a spammer uses a dialup account and the ISP needs to have his IP address at the 'date-time' to be able to take action against him.
これらの推奨事項は、RFC1123 [3]よりも意図的に強力であり、スパマーのホストから受信者に直接送信されるメールが十分な正確さでトレースできることを保証するためにあります。典型的な例は、スパマーがダイヤルアップアカウントを使用し、ISPが「日付時刻」にIPアドレスを使用して彼に対して行動を起こすことができる場合です。
Organizations with a policy of hiding their internal network structure must still be allowed and able to do so. They usually make their internal MTAs prepend "Received:" lines with a very limited amount of information, or prepend none at all. Then they send out the mail through some kind of firewall/gateway device, which may even remove all the internal MTAs' "Received:" lines before it prepends its own "Received:" line (as required in RFC1123, [3]).
内部ネットワーク構造を隠すポリシーを持つ組織は、まだ許可され、そうすることができなければなりません。彼らは通常、内部のMTAをPrepend "受信：非常に限られた量の情報を備えたラインを作成します。次に、何らかの種類のファイアウォール/ゲートウェイデバイスを介してメールを送信します。これは、すべての内部MTAの「受信」をすべて削除することさえあります。
By doing so they take on the full responsibility to trace spammers that send from inside their organization or they accept to be held responsible for those spammers' activities. It is REQUIRED that the information provided in their outgoing mail is sufficient for them to perform any necessary traces.
そうすることで、彼らは組織内から送るスパマーを追跡するか、それらのスパマーの活動に対して責任を負うことを受け入れる完全な責任を引き受けます。発信郵便で提供される情報は、必要な痕跡を実行するのに十分であることが必要です。
In the case of incoming mail to an organization, the "Received:" lines MUST be kept intact to make sure that users receiving mail on the inside can give information needed to trace incoming messages to their origin.
組織への郵便物の着信の場合、「受信：受信」は、内側でメールを受け取るユーザーが、その起源に着信メッセージを追跡するために必要な情報を提供できることを確認するために、無傷に保つ必要があります。
Generally, a gateway SHOULD NOT change or delete "Received:" lines unless it is a security requirement to do so. Changing the content of existing "Received:" lines to make sure they "make sense" when passing a mail gateway of some kind most often destroys and deletes information needed to make a message traceable. Care must be taken to preserve the information in "Received:" lines, either in the message itself, the mail that the receiver gets, or if that is impossible, in logfiles.
一般に、ゲートウェイは、「受信：」を変更したり削除したりしないでください。既存の「受信」のコンテンツを変更すると、何らかの種類のメールゲートウェイを渡すときに「意味がある」ことを確認するための行は、メッセージを追跡可能にするために必要な情報を破壊し、削除します。「受信：受信：メッセージ自体、レシーバーが取得するメール、またはそれが不可能な場合、ログファイルのいずれかに情報を保存するように注意する必要があります。
The MTA MUST be able to provide enough local log information to make it possible to trace the event. This includes most of the information put into the "Received:" lines; see above.
MTAは、イベントを追跡できるようにするために十分なローカルログ情報を提供できる必要があります。これには、「受信：」行に入れられる情報のほとんどが含まれます。上記を参照。
The MTA SHOULD be able to log all anti-relay/anti-spam actions. The log entries SHOULD contain at least:
MTAは、すべての反関連/スパムアンチスパムアクションを記録できるはずです。ログエントリには少なくとも：
o Time information.
o 時間情報。
o Refusal information, i.e. why the request was refused ("Mail From", "Relaying Denied", "Spam User", "Spam Host", etc).
o 拒否情報、つまり、リクエストが拒否された理由（ "Mail from"、 "Relaying Dened"、 "Spam user"、 "Spam Host"など）。
o "RCPT To:" addresses (domains). (If the connection was disallowed at an earlier stage, e.g. by checking the SMTP_Caller IP address, the "RCPT To:" address is unknown and therefore cannot be logged).
o 「rcpt to：」アドレス（ドメイン）。（SMTP_Caller IPアドレスをチェックすることにより、以前の段階で接続が許可されていない場合、「RCPTから」アドレスは不明であるため、記録できません）。
o Offending host's IP address.
o 違反ホストのIPアドレス。
o Offending host's FQDN hostname.
o 違反ホストのFQDNホスト名。
o Other relevant information (e.g. given during the SMTP dialogue, before we decided to refuse the request).
o その他の関連情報（例：SMTPの対話中に、リクエストを拒否することを決定する前）。
It should be noted that by logging more events, especially denied email, one opens the possibility for denial of service attacks, for example by filling logs by having a very large amount of "RCPT To:" commands. An implementation that implements increased logging according to this description must be aware of the fact that the size of the logfiles increases, especially during attacks.
より多くのイベント、特に拒否された電子メールを記録することにより、たとえば非常に大量の「RCPTから次のような」を使用することにより、サービス拒否攻撃の可能性を開くことに注意する必要があります。この説明に従ってロギングが増加する実装は、特に攻撃中にログファイルのサイズが増加するという事実を認識している必要があります。
The MTA SHOULD be able to accept or refuse mail from a specific host or from a group of hosts. Here we mean the IP.src address or the FQDN that its .IN-ADDR.ARPA resolves to (depending on whether you trust the DNS). This functionality could be implemented at a firewall, but since the MTA should be able to "defend itself" we recommend it be able to as well.
MTAは、特定のホストまたはホストのグループからメールを受け入れるか拒否できるはずです。ここでは、.in-addr.arpaが解決するIP.SRCアドレスまたはFQDNを意味します（DNSを信頼するかどうかに応じて）。この機能はファイアウォールで実装できますが、MTAは「自らを防御する」ことができるはずなので、同様にできることをお勧めします。
It is RECOMMENDED that the MTA be able to decide based on FQDN hostnames (host.domain.example), on wild card domain names (*.domain.example), on individual IP addresses (10.11.12.13) or on IP addresses with a prefix length (10.0.0.0/8, 192.168.1.0/24).
MTAは、FQDN HOSTNAMES（host.domain.example）、ワイルドカードドメイン名（*.domain.example）、個々のIPアドレス（10.11.12.13）、またはIPアドレスのIPアドレスに基づいて決定できることをお勧めします。プレフィックスの長さ（10.0.0.0/8、192.168.1.0/24）。
It is also RECOMMENDED that these decision rules can be combined to form a flexible list of accept/refuse/accept/refuse, e.g:
また、これらの決定ルールを組み合わせて、受け入れ/拒否/受け入れ/ごみの柔軟なリストを形成できることもお勧めします。
accept host.domain.example refuse *.domain.example accept 10.11.12.13 accept 192.168.1.0/24 refuse 10.0.0.0/8
host.domain.example reduse *.domain.example Accept 10.11.12.13 Accept 192.168.1.0/24 Refuse 10.0.0.0/8
The list is searched until first match and the accept/refuse action is based on that.
リストは最初の一致まで検索され、Accept/Reduseアクションはそれに基づいています。
IP-address/length is RECOMMENDED. However, implementations with wild cards, e.g. 10.11.12.* (classful networks on byte boundaries only) are of course much better than those without.
IPアドレス/長さをお勧めします。ただし、ワイルドカードを使用した実装、例えば10.11.12。*（バイト境界のみのクラスフルネットワークのみ）もちろん、ないものよりもはるかに優れています。
To improve filtering even more, the MTA MAY provide complete regular expressions to be used for hostnames; possibly also for IP addresses.
フィルタリングをさらに改善するために、MTAはホスト名に使用する完全な正規表現を提供する場合があります。おそらくIPアドレス用。
Although the fight against spammers is important it must never be done in a way that violates existing email standards. Since spammers often forge "MAIL From:" addresses it is tempting to put general restrictions on that, especially for some "obvious" addresses. This may, however, wreak more havoc to the mail community than spam does.
スパマーとの戦いは重要ですが、既存の電子メール基準に違反する方法で決して行われてはなりません。スパマーはしばしば「メールからのメール」を偽造するので、特にいくつかの「明白な」アドレスのために、一般的な制限をそれに置くのは魅力的です。ただし、これは、Spamよりも多くの大混乱をメールコミュニティにもたらす可能性があります。
When there is a need to refuse mail from a particular host or site our recommendation is to use other methods mentioned in this memo, e.g. refuse mail based on SMTP_Caller address (or name), regardless of what "MAIL From:" was used.
特定のホストまたはサイトからメールを拒否する必要がある場合、このメモに記載されている他の方法を使用することです。「メールからのメール」に関係なく、smtp_callerアドレス（または名前）に基づいてメールを拒否します。
The MTA MUST NOT refuse to receive "MAIL From: <>".
MTAは、「<>」からの「メール」の受け取りを拒否してはなりません。
The "MAIL From: <>" address is used in error messages from the mail system itself, e.g. when a legitimate mail relay is used and forwards an error message back to the user. Refusing to receive such mail means that users may not be notified of errors in their outgong mail, e.g. "User unknown", which will no doubt wreak more havoc to the mail community than spam does.
「メール：<>」アドレスは、メールシステム自体からのエラーメッセージで使用されます。正当なメールリレーが使用され、エラーメッセージをユーザーに転送する場合。そのようなメールの受信を拒否するということは、ユーザーにOutgongメールのエラーが通知されない可能性があることを意味します。「ユーザー不明」は、スパムよりも多くの大混乱をメールコミュニティにもたらすことは間違いありません。
The most common case of such legitimate "MAIL From: <>" is to one recipient, i.e. an error message returned to one single individual. Since spammers have used "MAIL From: <>" to send to many recipients, it is tempting to either reject such mail completely or to reject all but the first recipient. However, there are legitimate causes for an error mail to go to multiple recipients, e.g. a list with several list owners, all located at the same remote site, and thus the MTA MUST NOT refuse "MAIL From: <>" even in this case.
このような合法的な「メールからのメール：<>」の最も一般的なケースは、1人の受信者、つまり1人の個人に返されるエラーメッセージです。スパマーは「from：<>」を使用して多くの受信者に送信したため、そのようなメールを完全に拒否するか、最初の受信者以外のすべてを拒否することは魅力的です。ただし、エラーメールが複数の受信者に移動する正当な原因があります。いくつかのリスト所有者がいるリスト、すべて同じリモートサイトにあるため、MTAは「<>」を拒否してはなりません。この場合でも。
However, the MTA MAY throttle down the TCP connection ("read()" frequency) if there are more than one "RCPT To:" and that way slow down spammers using "MAIL From: <>".
ただし、MTAは、複数の「RCPT」がある場合、TCP接続（ "read（）" frequence）をスロットルする可能性があります。
The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
MTAは「<user@my.local.domain>」から「メール：<user@my.local.domain>」を拒否してはなりません。
By "my.local.dom.ain" we mean the domain name(s) that are treated as local and result in local delivery. At first thought it may seem like noone else will need to use "MAIL From: <user@my.local.dom.ain>" and that restrictions on who may use that would reduce the risk of fraud and thus reduce spam. While this may be true in the (very) short term, it also does away with at least two legitimate usages:
「my.local.dom.ain」とは、ローカルとして扱われ、ローカル配信をもたらすドメイン名を意味します。最初は、他の誰も「メール：<user@my.local.dom.ain>」を使用する必要がないように思われるかもしれないと考え、誰が詐欺のリスクを減らしてスパムを減らすことができるかについての制限があります。これは（非常に）短期的には当てはまるかもしれませんが、少なくとも2つの正当な使用法も廃止します。
o Aliases (.forward files). <user1@my.local.dom.ain> sends to <user2@external.example> and that mail gets forwarded back to <user2@my.local.dom.ain>, e.g. since <user2> has moved to my.local.dom.ain and has a .forward file at external.example.
o エイリアス（.Forwardファイル）。<user1@my.local.dom.ain> <user2@external.example>に送信し、そのメールは<user2@my.local.dom.ain>に転送されます。<user2>がmy.local.dom.ainに移動し、external.exampleで.forwardファイルを持っているため。
o Mailing lists. RFC1123, [3], gives a clear requirement that "MAIL From:" for mail from a mailing list should reflect the owner of the list, rather than the individual sender. Because of this fact, and the fact that the owner of the list might not be in the same domain as the list (list host) itself, mail may arrive to the list owner's domain (mail host) from a foreign domain (from a host serving a foreign domain) with the list owner's local domain in the "Mail From:" command.
o メーリングリスト。RFC1123 [3]は、「メールからのメール：」のメールは、個々の送信者ではなく、リストの所有者を反映する必要があるという明確な要件を示しています。この事実のため、およびリストの所有者がリスト（リストホスト）自体と同じドメインにない可能性があるという事実は、メールが外国のドメインから（ホストから）リスト所有者のドメイン（メールホスト）に届くことがあります外国のドメインにサービスを提供する）リスト所有者のローカルドメインは、「Mail From：」コマンドにあります。
If "MAIL From: <user@my.local.dom.ain>" is rejected, both these cases will result in failure to deliver legitimate mail.
「from：<user@my.local.dom.ain>」が拒否された場合、これらのケースはどちらも正当なメールの配信に失敗します。
The MTA SHOULD be able to refuse to receive mail from a specific "MAIL From:" user (foo@domain.example) or from an entire "MAIL From:" domain (domain.example). In general these kinds of rules are easily overcome by the spammers changing "MAIL From:" every so often, but the ability to block a certain user or a certain domain is quite helpful while an attack has just been discovered and is ongoing.
MTAは、特定の「メールからのメール：foo@domain.example）または「domain（domain.example）」全体からメールを受信することを拒否できるはずです。一般に、これらの種類のルールは、スパマーが「メールからのメール」を変更することで簡単に克服されますが、攻撃が発見されていて進行中である間、特定のユーザーまたは特定のドメインをブロックする能力は非常に役立ちます。
Please note that
その点に注意してください
"MAIL From: <>"
and
"MAIL From: <user@my.local.dom.ain>"
MUST NOT be refused (see above), except when other policies block the connection, for example when the SMTP_Caller IP address of the peer belongs to a network which is deliberately refused.
他のポリシーが接続をブロックした場合を除き、拒否してはなりません（上記を参照）、たとえばピアのSMTP_Caller IPアドレスが意図的に拒否されたネットワークに属している場合を除きます。
The MTA SHOULD provide tools for the mail host to control the rate with which mail is sent or received. The idea is twofold:
MTAは、メールホストが送信または受信したレートを制御するためのツールを提供する必要があります。アイデアは2つあります：
1) If we happen to have an legitimate mail user with an existing legitimate account and this user sends out spam, we may want to reduce the speed with which he sends it out. This is not without controversy and must be used with extreme care, but it may protect the rest of the Internet from him.
1) 既存の正当なアカウントを持つ合法的なメールユーザーがいる場合、このユーザーがスパムを送信する場合、彼がそれを送信する速度を減らすことをお勧めします。これには論争がないわけではなく、非常に注意して使用する必要がありますが、インターネットの残りの部分を彼から保護する必要があります。
2) If we are under a spam attack it may help us considerably just being able to slow down the incoming mail rate for that particular user/host.
2) スパム攻撃を受けている場合、その特定のユーザー/ホストの入ってくるメールレートを遅くすることができるだけで、かなり役立つかもしれません。
For sending mail, this has to be done by throttling the TCP connection to set the acceptable output data rate, e.g. reduce the "write()" frequency.
メールを送信するには、これをTCP接続を調整して許容可能な出力データレートを設定することで実行する必要があります。「write（）」頻度を減らします。
For receiving mail, we could use basically the same technique, e.g. reduce the "read()" frequency, or we could signal with a 4xx Return Code that we cannot receive. It is RECOMMENDED that the decision to take such action be based on "MAIL From:" user, "MAIL From:" domain, SMTP_Caller (name/address), "RCPT TO:", or a combination of all these.
メールを受信するには、基本的に同じ手法を使用できます。「read（）」の頻度を減らすか、受信できない4xx戻りコードで信号を送信できます。そのようなアクションを取る決定は、「ユーザー」、「user」、「domain、smtp_caller（name/address）」、 "rcpt to："、またはこれらすべての組み合わせに基づいていることをお勧めします。
The MTA SHOULD be able to perform a simple "sanity check" of the "MAIL From:" domain and refuse to receive mail if that domain is nonexistent (i.e. does not resolve to having an MX or an A record). If the DNS error is temporary, TempFail, the MTA MUST return a 4xx Return Code (Temporary Error). If the DNS error is an Authoritative NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx Return Code (since this may just be primary and secondary DNS not being in sync) but it MAY allow for an 5xx Return Code (as configured by the sysadmin).
MTAは、「ドメイン」からのメールの単純な「正気チェック」を実行できるはずです。ドメインとそのドメインが存在しない場合は、メールを受信することを拒否します（つまり、MXまたはAレコードを持つことは決まりません）。DNSエラーが一時的なものである場合、MTAは4XX戻りコード（一時的なエラー）を返す必要があります。DNSエラーが権威あるnxDomain（ホスト/ドメイン不明）である場合、MTAは4xx戻りコードを返す必要があります（これは単なるプライマリおよびセカンダリDNSが同期されていない可能性があるため）が、5xxの返信コードが可能になる場合があります（設定されている場合は設定されていますsysadminによって）。
The MTA SHOULD allow outgoing mail to have its <local-part> verified so that the sender name is a real user or an existing alias. This is basically to protect the rest of the Internet from various "typos"
MTAは、送信者名が実際のユーザーまたは既存のエイリアスになるように、発信メールを<Local-Part>に確認できるようにする必要があります。これは基本的に、他のインターネットをさまざまな「タイプミス」から保護するためです
MAIL From: <fo0bar@domain.example>
and/or malicious users
および/または悪意のあるユーザー
MAIL From: <I.am.unknown.to.you.he.he@domain.example>
As always this can be overcome by spammers really wanting to do so, but with more strict rules for relaying it becomes harder and harder. In fact, catching "typos" at the initial (and official) mail relay is in itself enough motivation for this recommendation.
いつものように、これは本当にそうしたいスパマーによって克服できますが、それを中継するためのより厳格なルールでは、より厳しく、より困難になります。実際、最初の（および公式）メールリレーで「タイプミス」をキャッチすること自体が、この推奨事項に対する十分な動機です。
Both SMTP VRFY and EXPN provide means for a potential spammer to test whether the addresses on his list are valid (VRFY) and even get more addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed to issue these commands. This may be "on/off" or it may use access lists similar to those mentioned previously.
SMTP VRFYとEXPNはどちらも、潜在的なスパマーが彼のリストのアドレスが有効（VRFY）であり、より多くのアドレス（EXPN）を取得するかどうかをテストする手段を提供します。したがって、MTAは、これらのコマンドを発行することが許可されている人を制御する必要があります。これは「オン/オフ」であるか、前述のものと同様のアクセスリストを使用する場合があります。
Note that the "VRFY" command is required according to RFC821, [1]. The response can, though, be "252 Argument not checked" to represent "off" or blocked via an access list. This should be the default.
RFC821 [1]に従って「VRFY」コマンドが必要であることに注意してください。ただし、応答は、「252の引数がチェックされていない」と、「オフ」を表すか、アクセスリストを介してブロックされます。これがデフォルトである必要があります。
Default for the "EXPN" command should be "off".
「expn」コマンドのデフォルトは「オフ」にする必要があります。
SMTP ETRN means that the MTA will re-run its mail queue, which may be quite costly and open for Denial of Service attacks. Therefore, the MTA SHOULD control who is is allowed to issue the ETRN command. This may be "on/off" or it may use access lists similar to those mentioned previously. Default should be "off".
SMTP ETRNとは、MTAがメールキューを再実行することを意味します。これは非常に費用がかかり、サービス攻撃の拒否のために開かれている可能性があります。したがって、MTAは、ETRNコマンドの発行を許可されている人を制御する必要があります。これは「オン/オフ」であるか、前述のものと同様のアクセスリストを使用する場合があります。デフォルトは「オフ」にする必要があります。
The primary issue here is flexibility - it is simply not possible to define in a document how to make tradeoffs between returning 5xx and make legitimate mail fail at once due to a configuration mistake and returning 4xx and be able to catch such configuration mistakes via log file inspection.
ここでの主な問題は柔軟性です - 5xxを返すことの間にトレードオフを行う方法をドキュメントで定義し、構成の誤りと4xxを返すために正当なメールを一度に失敗させる方法を定義することはできません。検査。
Therefore, the MTA MUST be configurable to provide "Success" (2xx), "Temporary Failure" (4xx) or "Permanent Failure" (5xx) for different rules or policies. The exact return codes, other than the first digit (2, 4 or 5) should, however, not be configurable. This is because of the ease of configuring the software in the wrong way, and the fact
したがって、MTAは、さまざまなルールまたはポリシーに対して「成功」（2xx）、「一時的な失敗」（4xx）または「永続的な障害」（5xx）を提供するために構成可能でなければなりません。ただし、最初の数字（2、4、または5）以外の正確な返品コードは、構成できないはずです。これは、ソフトウェアを間違った方法で構成しやすく、事実のためです
that the selection of exactly what error code to use is very subtle and that many software implementations do check more than the first digit (2, 4 or 5) in the return code.
使用するエラーコードの正確な選択が非常に微妙であり、多くのソフトウェアの実装が戻りコードの最初の数字（2、4、または5）よりも多くをチェックすること。
However, when the response is the result of a DNS lookup and the DNS system returned TempFail, a temporary error, the MTA MUST reflect this and provide a 4xx return code. If the DNS response is an Authoritative NXdomain (host or domain unknown) the MTA MAY reflect this by a 5xx Return Code.
ただし、応答がDNSルックアップの結果であり、DNSシステムが一時的なエラーを返した場合、MTAはこれを反映し、4XXリターンコードを提供する必要があります。DNS応答が権威あるnxDomain（ホストまたはドメイン不明）である場合、MTAは5xx返品コードによってこれを反映する可能性があります。
Please refer to the previous discussion on SMTP Return Codes for additional information.
追加情報については、SMTP戻りコードに関する以前の議論を参照してください。
At Chalmers University of Technology our DNS contains
Chalmers University of Technologyには、DNSが含まれています
cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se. IN MX 100 mail.chalmers.se.
cdg.chalmers.se。mx 0 mail.cdg.chalmers.se。MX 100 Mail.Chalmers.se。
and similarly for most subdomains, i.e. a second host to store mail to each subdomain, should their mail host be down. This means that mail.chalmers.se must be prepared to act as Mail Relay for the subdomains ("RCPT To:") it serves and that those subdomains' mail hosts have to accept SMTP connections from mail.chalmers.se. Late versions of spam software make use of this fact by always using mail.chalmers.se to get their mail delivered to our subdomains and by doing so they still get Mail Relaying done for them and they prevent recipient hosts from refusing SMTP connections based on the sending host's FQDN or IP-address.
同様に、ほとんどのサブドメイン、つまり、メールホストがダウンした場合、各サブドメインにメールを保存する2番目のホストです。これは、mail.chalmers.seがサブドメインのメールリレーとして機能するように準備する必要があります（ "rcpt to："）。スパムソフトウェアの後期バージョンは、常にmail.chalmers.seを使用してメールをサブドメインに配信することにより、この事実を利用します。ホストのFQDNまたはIPアドレスを送信します。
As long as we keep our design with a secondary MX host we cannot really have mail.chalmers.se refuse Mail Relay, at least not with a 5xx return code. However, it has been fairly straight forward to identify the hosts/domains/networks that make use of this possibility and refuse to act as Mail Relay for them them - and only them - and do so with a 4xx return code. Legitimate mail from them may be delayed if the final recipient host is down but will eventually be delivered when it gets up again (4xx Return Code) and this is no worse then if we changed our MX design. Spam now faces a "Denied" response and have to connect to each and every one of the recipients, who may decide to refuse the SMTP connection.
セカンダリMXホストを使用して設計を保持している限り、Mail.Chalmers.seは、少なくとも5xxリターンコードを使用しないことはできません。ただし、この可能性を利用し、それらのメールリレーとして機能することを拒否するホスト/ドメイン/ネットワークを特定することはかなり簡単です - そして、それらのみ - そして、4XXリターンコードでそうします。最終的な受信者のホストがダウンしている場合、それらからの正当なメールが遅れる可能性がありますが、再び起きたときに最終的に配信されます（4xx戻りコード）。スパムは「拒否された」応答に直面し、SMTP接続を拒否することを決定する可能性のある受信者の一人一人に接続する必要があります。
The bottom line is that this is made possible because of 1) enough flexibility in the Relay Authorization code and 2) enough flexibility in assigning Return Codes - an MTA with a 5xx Return Code carved in stone would have made this absolutely impossible.
一番下の行は、これが1）リレー認証コードの十分な柔軟性と2）リターンコードの割り当てに十分な柔軟性のために可能になったことです。
Even though this memo is about MTAs and recommendations for them, some of what is done here also impacts UAs (User Agents, the "ordinary mail programs").
このメモはMTAと彼らの推奨事項に関するものですが、ここで行われていることのいくつかは、UAS（ユーザーエージェント、「通常のメールプログラム」）にも影響します。
A UA does two things:
UAは2つのことをします。
1) Reads mail from a mailbox and prints on the screen. This typically uses a protocol like POP, IMAP or NFS.
1) メールボックスからメールを読み取り、画面に印刷します。これは通常、POP、IMAP、NFSなどのプロトコルを使用します。
2) Reads text from the keyboard and hands that over to the mailbox MTA for delivery as a piece of mail. This typically uses the SMTP protocol, i.e. the same protocol that is used between MTAs.
2) キーボードからテキストを読み取り、メールボックスMTAに送り、メールとして配達します。これは通常、SMTPプロトコル、つまりMTA間で使用される同じプロトコルを使用します。
When MTAs now start to implement various anti-relay filters as described above, a UA on a portable laptop host may get a response like "Relaying Denied" just because it happens to use IP addresses within an unknown range or that resolve to unknown FQDNs.
MTAが上記のようにさまざまな反関連フィルターの実装を開始すると、ポータブルラップトップホストのUAは、未知の範囲内でIPアドレスを使用したり、不明なFQDNSに解決したりするという理由だけで「拒否された」などの応答を得ることができます。
The typical victim of this "Relaying Denied" response is a salesman carrying a laptop on a business trip, or even an IETF delegate at a meeting hotel. The salesman will probably dial his nearest ISP and will get an IP address from that dialup pool; the IETF delegate will use an IP address from the terminal room. In both cases their laptop mail program (the UA; e.g. pine, Netscape, Eudora) will try to send out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but unless mail.home.example has been updated to accept that (temporary) IP address it will respond "Relaying Denied" and refuse.
この「拒否された」応答の典型的な犠牲者は、出張でラップトップを運ぶセールスマン、またはミーティングホテルでのIETFの代表者でさえあります。セールスマンはおそらく最寄りのISPにダイヤルし、そのダイヤルアッププールからIPアドレスを取得します。IETFデリゲートは、ターミナルルームのIPアドレスを使用します。どちらの場合も、ラップトップメールプログラム（UA; Pine、Netscape、Eudoraなど）は、自宅MTAを介してメールを送信しようとします。smtp-server = mail.home.exampleですが、mail.home.exampleが更新されていない限り、（一時的な）IPアドレスが「拒否された」と拒否することを受け入れます。
To get around this problem we could simply add the terminal room's or the dialup pool's IP network to the list of accepted networks at mail.home.example. This does open up some minimal risk of spammers using that host as their Mail Relay: If they use the same ISP's dialup pool and they configure to use mail.home.example at the same time as our salesman is on his trip, then the spammers will be authorized to relay their spam through mail.home.example. However, this is not extremely likely and as long as we do not open up for the entire world all the time and we keep the log files under close observation and we stop relaying at once we find we're being used, this solution is probably good enough.
この問題を回避するために、ターミナルルームまたはダイヤルアッププールのIPネットワークを、Mail.home.exampleで受け入れられているネットワークのリストに追加できます。これにより、そのホストをメールリレーとして使用するスパマーのリスクが最小限に抑えられます。同じISPのダイヤルアッププールを使用し、Mail.home.exampleを使用すると同時に、セールスマンが旅行中に、スパマーがmail.home.exampleを介してスパムを中継する権限があります。ただし、これはそれほど可能性がありません。常に全世界に開かれていない限り、ログファイルを密接に観察しておきます。十分です。
Another way around is that our salesman uses a Mail Relay provided by the current dialup ISP, if that service exists. To do so he has to modify SMTP-SERVER= in his UA, which may or may not be reasonable.
もう1つの方法は、そのサービスが存在する場合、セールスマンが現在のDialup ISPによって提供されるメールリレーを使用することです。そのためには、彼はUAでsmtp-server =を変更する必要があります。
The correct way to handle this situation, though, is by some other mail-sending protocol between the UA and the MTA.
ただし、この状況を処理する正しい方法は、UAとMTAの間の他のメール配信プロトコルによるものです。
Although a separate submission protocol does not exist, a profile of SMTP for this, the "Message Submission" specification, [9], has recently been defined.
個別の提出プロトコルは存在しませんが、このためのSMTPのプロファイルが最近定義されています。
Or, we could note that when the SMTP Authentication work, [10], is all in place, it will allow for Authenticated SMTP to serve as The Protocol between the UAs and the home MTA (whether that should be considered a new protocol or "the same old SMTP" is irrelevant here).
または、SMTP認証作業[10]がすべて整っている場合、認証されたSMTPがUASとHome MTAの間のプロトコルとして機能することを可能にすることに注意することができます（それが新しいプロトコルと見なされるか、または新しいプロトコルと見なされるべきかにかかわらず」同じ古いSMTPはここでは無関係です）。
This adds one item to the suggested Relay algorithm in section 2.1:
これにより、セクション2.1の提案されたリレーアルゴリズムに1つのアイテムが追加されます。
+ If "SMTP Authenticated" then accept to Relay.
+ 「SMTP認証」の場合、リレーを受け入れます。
Since all users are individuals, there is little hope that any central anti-spam action will suit them all - in fact people can and do argue about Freedom of Speech infringement if some central set of anti-spam rules is enforced without the users' approval. (One could of course also argue whether spam really adds anything to anyone, but that must be up to each individual user to decide, rather than being centrally decided).
すべてのユーザーは個人であるため、中心的なスパムの行動がすべてに合うことをほとんど希望しません。実際、ユーザーの承認なしに中央のスパム規則の中心セットが施行されている場合、人々は言論の自由の自由について議論することができます。。（もちろん、スパムが実際に誰かに何かを追加するかどうかも議論することもできますが、それは中心的に決定されるのではなく、各ユーザーに決定する必要があります）。
Therefore the only reasonable extension is to allow for personal anti-spam filters, i.e. anti-spam filters like the ones described earlier in this memo, but available and configurable on a per user basis. Since most users will not have a strong opinion (except that they want to avoid spam) the mail system should provide a system default and give each user the ability to override or modify that. In a UNIX based environment one could have something like
したがって、唯一の合理的な拡張機能は、個人的なスパムフィルター、つまりこのメモで前述したようなアンチスパムフィルターを許可することですが、ユーザーごとに利用可能で構成可能です。ほとんどのユーザーは強力な意見を持っていないため（スパムを避けたいことを除いて）、メールシステムはシステムのデフォルトを提供し、各ユーザーにそれをオーバーライドまたは変更する機能を提供する必要があります。UNIXベースの環境では、
/etc/mail/rc.spam
~/.spamrc
and rules on how the latter can interfere with the former.
そして、後者が前者をどのように妨害するかについてのルール。
All of this opens up quite a number of unresolved issues, e.g. whether each user himself really should be allowed to decide on SMTP Return Codes (and how it should be described so he understands enough of the implications) and how existing mail systems will deal with different per user responses, especially how they will deal with a mix of 5xx and 4xx codes:
これはすべて、かなりの数の未解決の問題を開きます。各ユーザー自身が本当に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
Of course one could decide on either "250 OK" or "550 Denied" with no other alternatives for the individual user, but this too has to be explained enough that an ordinary user understands the implications of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away with, or block out, mail he actually wanted.
もちろん、個々のユーザーに他の選択肢がない「250 OK」または「550拒否」のいずれかを決定できますが、これも通常のユーザーが「拒否」メールの意味を理解していることを十分に説明する必要があります。@spam.example> '"そして、彼が実際に望んでいたメールを廃止したり、ブロックしたりできること。
SMTP Authentication, [10], has already been mentioned as a method to authorize Mail Relaying, but of course there is much more to it than that. When that infrastructure and functionality is all in place, spammers will have a much harder time forging addresses and hiding.
SMTP認証[10]は、すでにメールリレーを承認する方法として言及されていますが、もちろんそれ以上のものがあります。そのインフラストラクチャと機能がすべて整っている場合、スパマーは住所を偽造して隠すのにはるかに困難になります。
With the increased use of Network Address Translators (NATs) may come a need for additional information in log files. As long as there is a 1:1 mapping between the addresses inside the NAT and the addresses used outside it everything is OK, but if the NAT box also translates port numbers (to combine many internal hosts into one external address) we will need to log not only the IP addresses of spam hosts but also the port numbers. Otherwise we will not be able to identify the individual host inside the NAT.
ネットワークアドレス翻訳者（NAT）の使用が増加すると、ログファイルの追加情報が必要になる場合があります。NAT内のアドレスとその外部で使用されるアドレスの間に1：1のマッピングがある限り、すべては問題ありませんが、NATボックスがポート番号を翻訳する場合（多くの内部ホストを1つの外部アドレスに組み合わせるため）。スパムホストのIPアドレスだけでなく、ポート番号も記録します。それ以外の場合は、NAT内の個々のホストを識別できません。
The grassfire-like increase of spam raises several security issues which, in fact, puts the entire Internet mail community at risk:
グラスファイヤーのようなスパムのような増加は、実際にはインターネットメールコミュニティ全体を危険にさらすいくつかのセキュリティ問題を引き起こします。
o People may fail to find important mail in their flooded mailboxes. Or, they may delete it while cleaning up.
o 人々は、浸水したメールボックスで重要なメールを見つけることができない場合があります。または、クリーンアップ中に削除する場合があります。
o ISPs get overloaded mailbox hosts and filled disk. Cleaning up and helping customers requires a lot of human resources. In fact, ISP mail servers have crashed by too much mail.
o ISPは、メールボックスのホストと充填ディスクを過負荷にします。顧客を掃除して支援するには、多くの人事が必要です。実際、ISPメールサーバーはあまりにも多くのメールでクラッシュしています。
o While disks are unaccessible, either due to being filled or due to "mail quota", important mail may be delayed or lost. Normally this would not happen without notice, but if both the sender and
o ディスクは、満たされているため、または「メールクォータ」のために説明できませんが、重要なメールが遅れたり紛失したりする可能性があります。通常、これは予告なしには発生しませんが、送信者と
receiver hosts have their disk flooded, the mail being returned may also fail, i.e. the email service may become less trustworthy than before.
レシーバーのホストはディスクを浸水させ、返されるメールも失敗する可能性があります。つまり、電子メールサービスが以前よりも信頼できなくなる場合があります。
o Hosts used as unauthorized Mail Relays become overloaded. Besides the technical implications, this too requires a lot of human resources, cleaning up mail queues and taking care of furious external users that were spammed through the Relay.
o 不正なメールリレーとして使用されるホストは過負荷になります。技術的な意味に加えて、これにも多くの人的資源が必要です。メールのキューを掃除し、リレーを通してスパムされた猛烈な外部ユーザーの世話をします。
o The fight against spammers includes blocking their hosts (which is described in this memo). However, there is a great risk that Mail Relay hosts may be blocked too, even though they are also victims. In the long run, this may cause Internet mail service to deteriorate.
o スパマーとの戦いには、ホストをブロックすることが含まれます（このメモで説明されています）。ただし、犠牲者でもあるにもかかわらず、メールリレーのホストもブロックされる可能性があるという大きなリスクがあります。長期的には、これによりインターネットメールサービスが悪化する可能性があります。
o The common use of forged "MAIL From:" and "From:" addresses puts the blame on innocent persons/hosts/organizations. This is bad for reputations and may affect business relations.
o Forged "Mail from：" and "from："の一般的な使用は、罪のない人/ホスト/組織に責任を負わせます。これは評判に悪いことであり、ビジネス関係に影響を与える可能性があります。
Several of the methods described in this document increases the load on several support systems to the email system itself. Those support systems can be DNS, logging, databases with lists of local users, authentication mechanisms and others. Implementing the methods described in this document will, because of that, increase the risk of a denial of service attack against the support system by sending spam to a site. Logging facilities must for example be able to handle more logging (what happens when the logfiles fills the disk?). DNS servers and authentication mechanisms must be able to stand the load of more lookups etc.
このドキュメントで説明されているいくつかの方法により、電子メールシステム自体へのいくつかのサポートシステムの負荷が増加します。これらのサポートシステムは、DNS、ロギング、ローカルユーザーのリストを含むデータベース、認証メカニズムなどです。このドキュメントで説明されている方法を実装すると、そのため、SPAMをサイトに送信することにより、サポートシステムに対するサービス拒否攻撃のリスクが高まります。伐採設備は、たとえば、より多くのロギングを処理できる必要があります（ログファイルがディスクを埋めるとどうなりますか？）。DNSサーバーと認証メカニズムは、より多くのルックアップなどの負荷に耐えることができなければなりません。
The functionality of the support systems during high load should be carefully studied before implementing the methods described in this document.
このドキュメントで説明されている方法を実装する前に、高負荷中のサポートシステムの機能を慎重に研究する必要があります。
The mail system should be carefully studied, e.g. how it behaves when one or more of the support systems needed for a specific method fails. A mail server MUST NOT respond with "Permanent Failure" (5xx) if there is a temporary problem with one of its support systems.
メールシステムは慎重に研究する必要があります。特定のメソッドに必要なサポートシステムの1つ以上が失敗した場合にどのように動作するか。サポートシステムのいずれかに一時的な問題がある場合、メールサーバーは「永続的な障害」（5xx）で応答してはなりません。
This memo is the result of discussions in an ad hoc group of Swedish ISPs and Universities. Without any hope on mentioning everyone we simply give the domain names here: algonet.se, global-ip.net, pi.se, swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and uu.se.
このメモは、スウェーデンのISPSおよび大学のアドホックグループでの議論の結果です。すべての人に言及することを期待することなく、ここでドメイン名をここに与えるだけです：algonet.se、global-ip.net、pi.se、swip.net、telia.net、udac.se;chalmers.se、sunet.se、umu.se、およびuu.se.
We want to acknowledge valuable input and suggestions from Andras Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol, Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman.
Andras Salamon、John Myers、Bob Flandrena、Dave Presotto、Dave Kristol、Donald Eastlake、Ned Freed、Keith Moore、Paul Hoffmanからの貴重な意見と提案を認めたいと思います。
Finally many thanks to Harald Alvestrand and Patrik Faltstrom, both for useful comments and for their support and guidance through the IETF process.
最後に、Harald AlvestrandとPatrik Faltstromに感謝します。これは、有用なコメントとIETFプロセスによるサポートとガイダンスの両方についてです。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden、R。、「インターネットホストの要件 - アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[5] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[6] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[7] Eastlake、D。and C. Kaufman、「ドメイン名システムセキュリティ拡張機能」、RFC 2065、1997年1月。
[8] sendmail Home Page. http://www.sendmail.org
[9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
[9] Gellens、R。およびJ. Klensin "Mession Submission"、RFC 2476、1998年9月。
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
[10] マイヤーズ、J。、「認証用のSMTPサービス拡張」、進行中の作業。
* Spam (R) (capitalized) is a registered trademark of a meat product made by Hormel. Use of the term spam (uncapitalized) in the Internet community comes from a Monty Python sketch and is almost Internet folklore. The term spam is usually pejorative, however this is not in any way intended to describe the Hormel product.
* Spam（R）（Capitized）は、Hormelが作った肉製品の登録商標です。インターネットコミュニティでのスパムという用語の使用（未資本）の使用は、モンティパイソンのスケッチから来ており、ほとんどインターネットの民間伝承です。スパムという用語は通常軽jor的ですが、これはホーマル製品を説明することを意図したものではありません。
Editor's Address
編集者のアドレス
Gunnar Lindberg Computer Communications Group Chalmers University of Technology SE-412 96 Gothenburg, SWEDEN,
Gunnar Lindberg Computer Communications Group Chalmers University of Technology SE-412 96 Gothenburg、Sweden、
Phone: +46 31 772 5913
FAX: +46 31 772 5922
EMail: lindberg@cdg.chalmers.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。