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
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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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]のMTA（メール転送エージェント、例えばsendmailを、[8]）スパム（*）の影響を減少させるそれらをより可能にするために。
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が持つことが期待されている「アンチスパムノブ」システム管理者/ポストマスターのコミュニティに提案することです。
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それは完全に「ブラインド」である、すなわち関心と実際のメールの受信者の領域との間に相関がない（... 1は、インターネット上ではない誰もがポルノ写真やスパムプログラムに興味があることを前提とし、少なくとも場合）送り出さ。
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のユーザに送ら1つの10キロバイトのメッセージを想定。それは、100Mバイトの迷惑、予期しない、ストレージを意味します。それらが満たされる前に芸術ディスクの状態、4ギガバイトは、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 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.
Oスパムの送信者の多くは、例えば、不誠実です、スパムの受信者は、それがちょうどそれらに誤配達されたと思われますので、彼らは二人の個人間であったように見えるようにメッセージを書き込む故意に、虚偽のリターンアドレスの後ろに隠れるメッセージは、あなたがそれを求めていない、と一般的に全力を尽くすんとき「あなたが要求した材料」であると言います彼らは正直や倫理に関係なく、いくつかのより多くの人々が彼らのメッセージを見て取得しようとすることができます。
In fact some of the spam-programs take a pride in adding false
info that will "make the ISPs scratch their heads".
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.
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 "MUST"
This word or the adjective "REQUIRED" means that the item is an
absolute requirement.
o "SHOULD"
O "SHOULD"
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 "MAY"
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.
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と解釈されるべきであり、「ドメイン名」を使用します。これにより、我々は、IPアドレスが名前に変換されたときに名前がすなわちPTRクエリ（.IN-ADDR.ARPA）に応答して、DNSから返された、または我々は関連するDNS AまたはMXレコードに名前を意味する意味しますそれ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.
我々はのFQDNを使用することを示唆するとIPは、FQDNでは、直感的に使用する方がはるかに簡単であるため、これはアドレスではなく。しかし、そのようなすべての用法はDNSと.IN-ADDR.ARPA（PTR）情報に大きく依存します。どちらか、それを偽造することはかなり容易である彼らに虚偽の情報を、独自のDNSを実行しているDNSサーバーやスパマーに注入された偽のキャッシュ情報により、ホスト名とドメイン名は、例えば、注意して使用する必要がありますので、翻訳アドレス - >名前>はアドレスを名 - に対応するように検証しました。 .IN-ADDR.ARPAのスプーフィングができなくなりますので、セキュアなDNS、RFC2065では、[7]、物事は、改善されます。
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) 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.
DNSと（エンベロープ発信元）ドメイン（適切なDNS情報がドメインのために存在していることを保証する）：勧告の一つは、「からのメールを」検証についてです。この機能を利用する際に考慮すべきいくつかあります：（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の妥当性チェックを実施することが知られている場合は「からのメール：」コマンドは、攻撃者が効果的に一つ以上の起源からのメールの受け入れを阻止するために、負のDNS応答を使用することができます。このため、一つは、慎重に、例えば、使用中の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）そのソフトウェアが完全に偽「からのメール：」とメールを生成するので、スパムソフトウェア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.
スパムソフトウェアのそれ以降のバージョンについては、「からMAIL：」のチェックは、スパムソフトウェアがあまりにも進化しているので、助けてはるかに少ない可能性があり、既存のメールアドレスを使用して開始します（それが合法であるかどうか、このメモの範囲を超えています）。しかし、少なくとも、インターネットは、このテストはタイプミスや誤設定のUAを停止副作用の恩恵を受ける。
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レイヤで処理され、まだSMTP対話におけるながらメッセージを拒否することを決定したMTAがそうすべきであるということです。まず、これは、我々は2回目以降拒否とすることを決定したメッセージのコピーを保存する必要はありませんが、そのメッセージのための私たちの責任が低いまたはnoneであることを意味します - 我々はまだそれを読んでいないので、我々はに送信者にそれを残しますエラーを処理します。
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レコードとの予想外の相互作用を有することができます。受信ドメインは、いくつかのMXレコードとMX-ホストは「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ホストが同じゴミリストを持っていない場合、それはもちろん、メールを受け入れるだけで、最終的なホストはまだ（「MAILから：」）メールのその部分を受け取ることを拒否することを発見します。私たちの目的は、問題のある送信者のホストで問題のメールの滞在を作り、彼のmqueueをディスクを埋めることでしたが、それはすべて私たちの友人、次に低い優先順位MX-ホストで終わりました。
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.
最後に、1つが2xxのリターンコードを使用するが、それにもかかわらず、迷惑メールを転送または受信しないように決定することが示唆されています。典型的な代替物（例えばを/ dev / null）他の場所に格納することです。これは明らかに、RFC821の意図に違反し、安易に行うべきではありません - 代わりに盲目的にメール1がそれを再キューイングおよび手動（または自動的に）それがスパムまたは正当なメールであるかどうかを検査し、それがドロップまたは転送する必要があるかどうかができ落とします。
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.
スパマーはHELO文などで偽造ホスト名を使用しているにもかかわらず、十分な情報を持つ行がメールパスをトレースすることを可能にする：2）「受信」を提供できなければなりません
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>.
ユーザー、<foo@domain.example>：7A）「からのメール」の特定からのメールを拒否することができるべきです。
7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
図7b）「からのメール：」全体からのメールを拒否することができるべきである<。* @ 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).
DNSまたは他の手段を使用してドメイン（）：9）「からのメールを」確認することができるべきです。
10) SHOULD be able to verify <local-part> in outgoing mail.
10）送信メールの<ローカル部分>を確認することができるべきです。
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温度）は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>は、おそらく同じユーザーであるため、文字列は、彼のメッセージを拒否するために使用されている比較しかし、我々は<ローカル部分>比較はあまりにも大文字と小文字を区別しないことを示唆しています。
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ホスト名は、」簡単に、しばしば鍛造します。 2）「からのメール：」簡単に、しばしば鍛造。正しい、または少なくとも意図：3）「にRCPT」。 4）SMTP_Caller（ホスト）IP.src OK ADDR、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"。 SMTP_Caller FQDNホスト名O。 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は：」リレーするために受け入れた後、「私たち」ドメイン、ローカルまたは我々は（代替MX）に転送する受け入れるドメインの1つです。
b) If SMTP_Caller is authorized, either its IP.src or its FQDN (depending on if you trust the DNS), then accept to Relay.
SMTP_Callerは、そのIP.srcまたはそのFQDNのどちらかが（）あなたがDNSを信頼している場合に応じて、許可された場合b）に、[中継し受け入れます。
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.
（あなたはSMTPソースルーティングのすべての種類を確認する必要があります）公式[@、@の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
「/ 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
"ゲートウェイ:: SMTP％\" ユーザーの最終\ "" @メール-11-ゲートウェイ@
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.
全ての場合において、構成はのFQDNとクラスフルIPアドレスのワイルドカードをサポートしなければならないし、例えば、クラスレスIPアドレスは、「アドレス/マスク」をサポートすべきですdomain.exampleと* .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:
（RFC822に記載されているように、[2]、およびRFC1123に必要な、[3]）、メールの行：MTAは、 "受信" を先頭に追加しなければなりません。これは、「受信：」行は送信者にメールパスをトレースすることを可能にするために十分な情報を含まなければなりません。我々は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.
発信元のIPアドレス、O。
o The 'date-time' as described in RFC822, [2], pp 18.
RFC822に記載されているように '日時' O、[2]、頁18。
It SHOULD contain:
これは、含まれている必要があります。
o The FQDN corresponding to the callers IP address.
O FQDNは、発信者のIPアドレスに対応します。
o The argument given in the "HELO" statement.
「HELO」文で与えられた引数を、O。
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 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.
ライン：基本的には、メッセージを追跡することができます任意の情報は、および「受信」に追加する必要がありますすることができます。ライン何IPを述べ、その接続を識別するために使用することができます：httpはWebクライアントとサーバー間で使用されているWebベースのメールクライアントを経由して例の提出のために、「受信」は、初期の提出が非SMTPであっても真でありますメールが作成されたHTTPサーバーへの接続時に-addressを使用しました。
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を作るプリペンド「受信：」情報の非常に限られた量のライン、またはまったくプリペンドなし。それは、独自の 『受信：』前に付加する前の行：次に、彼らも、すべての内部のMTA 『受信』を削除することができ、ファイアウォール/ゲートウェイデバイスのいくつかの種類、経由してメールを送信ライン（RFC1123に必要に応じて、[3]）。
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拒否情報要求を拒否した理由、すなわち（「拒否されました中継を」、「からのメール」、「スパムユーザー」、「スパムホスト」など）。
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 TO：」アドレスが不明であるため、ログインすることはできません）。
o Offending host's IP address.
O問題のあるホストのIPアドレス。
o Offending host's FQDN hostname.
問題のあるホストのFQDNホスト名O。
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.
コマンド：1つは「RCPT TO」の非常に大きな量を持つことで、ログを充填することによって、たとえば、サービス拒否攻撃の可能性を開いて、より多くのイベントをログに記録することで、特に電子メールを拒否ことに留意すべきです。この記述に応じて増加ロギングを実装実装は、特に攻撃の時に、ログファイルのサイズが増加するという事実を認識する必要があります。
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は（あなたがDNSを信頼するかどうかに依存する）に解決IP.srcアドレスまたはFQDNを意味します。この機能は、ファイアウォールで実装することができますが、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).
個々のIPアドレス（10.11.12.13）にまたはでIPアドレスに（.domain.example *）MTAは、ワイルドカードドメイン名で、FQDNホスト名（host.domain.example）に基づいて決定することができることが推奨されますプレフィックス長（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
The list is searched until first match and the accept/refuse action is based on that.
リストは、最初の一致が見つかるまで検索され、受け入れ/拒否アクションは、それに基づいています。
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は、ホスト名に使用する完全な正規表現を提供してもよい（MAY）。おそらくまた、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.
スパマーとの戦いが重要であるが、それは、既存の電子メールの規格に違反する方法で行われてはなりません。特に、いくつかの「明白な」アドレスのために、その上の一般的な制限を置くために誘惑されたアドレス：スパマーはしばしば「からのメールを」偽造以来。これは、しかし、スパムはよりもメールコミュニティに多くの大混乱をもたらすことがあります。
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.
そのような正規の最も一般的なケース「からメール：<>」の受信者である、即ち、エラーメッセージは、単一個体に戻されます。スパマーは「からのメール：<>」を使用しておりますので、多くの受信者に送信すると、それは完全に、このようなメールを拒否するか、最初の受信者が、全てを拒絶するかのいずれかに魅力的です。しかし、エラーメールが複数の受信者に行くための合法的な原因は、例えば、ありますいくつかのリストの所有者とのリストは、すべて同じリモートサイトに配置され、したがって、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: <>".
そしてそのように「：<>からのメール」を使用してスパマーを遅く：複数の「へRCPT」がある場合は、MTAは、（周波数「（）を読んで」）TCPコネクションを下に絞るかもしれません。
The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
MTAは、「<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>からのメール」を使用する必要がありますようにそれが見えるかもしれませんと思いました。これは、（非常に）短期的には、真のかもしれないが、それはまた、少なくとも二つの合法的な使用法を廃止します：
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]、「からのメールが」という明確な要件を提供します。この事実、およびリストの所有者がリストとして同じドメイン内ではないかもしれないという事実（リストホスト）自体の、メールがホストから（外部ドメインからのリストの所有者のドメイン（メールホスト）に到着するかもしれませんコマンド：「からのメール」で、リストの所有者のローカルドメインと外部ドメイン）となります。
If "MAIL From: <user@my.local.dom.ain>" is rejected, both these cases will result in failure to deliver legitimate mail.
場合は、「メールから：<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.
ユーザー（foo@domain.example）または「からのメール：」全体からドメイン（domain.example）：MTAは、「からのメール」とは、特定のメールを受信することを拒否することができるべきです。一般に、ルールのこれらの種類を簡単に「からのメールを」変えるスパマーによって克服されている時々、しかし、特定のユーザーまたは特定のドメインをブロックする能力は、攻撃がちょうど発見してきたが、非常に便利ですし、進行中です。
Please note that
その点に注意してください
"MAIL From: <>" and "MAIL From: <user@my.local.dom.ain>"
"からのメール：<user@my.local.domain>" と "<>からのメール"
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接続を絞ることによって行われなければなりません「書き込み（）」頻度を減らします。
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.
メールを受信するために、我々は基本的に同じ技術を使用することができ、例えば「読んで（）」頻度を減らす、あるいは我々が受信できないの4xx戻りコードで知らせることができます。ユーザー、「メールから：」ドメイン、SMTP_Caller（名前/アドレス）、「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).
（すなわち、MXまたはレコードを持つには解決しません）ドメインおよびそのドメインが存在しない場合は、メールを受け取ることを拒否：MTAは、「からのメール」のシンプルな「健全性チェック」を実行することができるべきです。 DNSエラーが一時的なものであるならば、TEMPFAILは、MTAは4xxの戻りコード（一時的なエラー）を返さなければなりません。 DNSエラーが権威NXDOMAIN（未知のホスト/ドメイン）である場合に設定され（MTAはまだ4xxの戻りコード（これ以降、単にプライマリとセカンダリのDNS同期されていないかもしれ）を返すべきであるが、それは5xxのリターンコードを可能にしてもよいです）システム管理者によって。
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は、送信メールは送信者名が実際のユーザーまたは既存の別名があるように、その<ローカル部分>が検証持つことができるはずです。これは、様々な「タイプミス」から、インターネットの残りの部分を保護するために、基本的です
MAIL From: <fo0bar@domain.example>
MAIL：<fo0bar@domain.example>
and/or malicious users
および/または悪意のあるユーザー
MAIL From: <I.am.unknown.to.you.he.he@domain.example>
MAIL：<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.
[1]、「VRFY」コマンドはRFC821に従って必要であることに留意されたいです。応答は、しかし、「オフ」またはアクセスリストを経由してブロックさを表現するために、「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 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.
したがって、MTAは「成功」（2XX）、「一時的な障害」（4XX）または異なるルールやポリシーの「永続的なエラー」（5xxの）を提供するために構成可能でなければなりません。最初の数字（2,4又は5）以外の正確な戻りコードは、しかし、設定すべきではありません。これは間違った方法でソフトウェアの設定のしやすさのものであり、まさにエラーコードの選択は、使用するという事実は非常に微妙であり、多くのソフトウェア実装は、最初の数字よりもチェックしないと（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システムはTEMPFAIL、一時的なエラーを返したときただし、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
チャルマース工科大学で、私たちのDNSが含まれています
cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se.
IN 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からのSMTP接続を受け入れる必要があること：これはmail.chalmers.seは、サブドメインのメールリレー（「RCPT TO」）として動作するように準備しなければならないことを意味しています。スパムソフトウェアの後期バージョンは、常に自分のメールが私たちのサブドメインに配信を取得するmail.chalmers.seを使用して、この事実を活用し、そうすることによって、彼らはまだメールは彼らのために行わ中継を取得し、彼らはに基づいてSMTP接続を拒否から受信者のホストを防ぎますホストの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ホストと私たちのデザインを保つよう、私たちは本当に、少なくともではないの5xx戻りコードで、mail.chalmers.seはメールリレーを拒否することはできません。しかし、それはこの可能性を利用するホスト/ドメイン/ネットワークを識別し、それら彼らのためにメールリレーとして機能することを拒否することはかなりまっすぐ進むされている - とそれらだけ - との4xx戻りコードでそれを行います。それらからの正当なメールは、最終的な受信ホストがダウンしている場合は遅れることがありますが、それは（4xxのリターンコード）を再び起き上がる時に最終的に配信されますと、私たちはMXのデザインを変更した場合、これはその後、何も悪いことではありません。スパムは現在、「拒否されました」応答に面しており、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.
これは絶対に不可能作っただろうリターンコードが石に刻まれたの5xxとMTAを - 一番下の行は、これが理由リレー認証コードに十分な柔軟性とリターンコードを割り当てることで2）十分な柔軟性）1で可能になるということです。
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と推奨事項、影響を与えるのUA（ユーザーエージェント、「普通のメールプログラム」）もここで行われているもののいくつかについてですが。
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は、未知の範囲または未知のFQDNへの解決内のIPアドレスを使用するために起こるという理由だけで「拒否されました中継を」のような応答を得ることができます。
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;例えば松、ネットスケープ、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.
この問題を回避するために、我々は単にmail.home.exampleで受け入れられたネットワークのリストに端末部屋のやダイアルアッププールのIPネットワークを追加することができます。これはありませんが自分のメールリレーとしてそのホストを使用してスパマーのいくつかの最小限のリスクを開く：彼らは同じ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.
周りのもう一つの方法は、そのサービスが存在する場合、当社のセールスマンは、現在のダイアルアップ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のプロファイルは、「メッセージ提出」仕様は、[9]、最近定義されています。
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はUAとホームMTA間のプロトコルとして機能するために、それができるようになることに注意してください（つまり、新しいプロトコル考慮すべきかどうかができ同じ古いSMTP」）は、ここでは関係ありません。
This adds one item to the suggested Relay algorithm in section 2.1:
これは、2.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ベースの環境では1のようなものを持っている可能性があり
/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
C RCPT TO：<usr@domain.example> S 250 <usr@domain.example> ...受信者OK C RCPT TO：<foo@domain.example> S 451 <foo@domain.example> ...拒否されたため、スパムリストC RCPTにするには：<bar@domain.example> S 550 <bar@domain.example> ...スパムリストのために拒否されました
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）のアドレス、ログファイルに追加情報の必要性を来るかもしれません。限り1があるとして：それは外で使用NATの内側アドレスとアドレスの間に1のマッピングは、すべてがOKですが、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:
スパムのgrassfireのような増加は、実際には、リスクが全体のインターネットメールコミュニティを置き、複数のセキュリティ問題が発生します。
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 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、重要なメールが遅れたり、失われる可能性があります。通常、これは、予告なしに起こりませんが、送信者と受信者の両方のホストは、そのディスクが殺到している場合、メールはすなわち、電子メールサービスが以前より少なく信頼できるになることがあり、また失敗する可能性が返されます。
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.
「From：」アドレスは罪のない人/ホスト/組織上の責任を置く：「からのメール」偽造の一般的な使用、O。これが評判に悪いと取引関係に影響を及ぼす可能性があります。
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、ログ記録、ローカルユーザのリストを持つデータベース、認証メカニズムなどすることができます。この文書で説明する方法を実装することで、そのため、サイトにスパムを送信することによって、サポートシステムに対するサービス拒否攻撃のリスクを増加します。ロギング機能は、例えば（ログファイルがディスクを満たしたときに何が起こるか？）以上のログを処理できなければなりません。 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.
このメモはスウェーデンのISPや大学のアドホックグループでの議論の結果です。みんなに言及上の任意の希望がなければ、私たちは単にここにドメイン名を与える：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.
私たちは貴重な入力とアンドラス・サラモン、ジョン・マイヤーズ、ボブFlandrena、デイブPresotto、デイブ・クリストル、ドナルドイーストレイク、ネッドフリード、キースムーア、ポール・ホフマンからの提案を承認します。
Finally many thanks to Harald Alvestrand and Patrik Faltstrom, both for useful comments and for their support and guidance through the IETF process.
ハラルドAlvestrandとパトリックFaltstromに、両方の有益なコメントやIETFプロセスを通じて彼らの支援と指導のために最後に多くの感謝。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1]ポステル、J.、 "簡易メール転送プロトコル"、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]クロッカー、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]ブレーデン、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]ブラドナーの、S.、BCP 14、RFC 2119、1997マーチ "のRFCsにおける使用のためのレベルを示すために"。
[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]イーストレイク、D.およびC.カウフマン、 "ドメインネームシステムのセキュリティ拡張機能"、RFC 2065、1997年1月。
[8] sendmail Home Page. http://www.sendmail.org
[8] sendmailのホームページ。 http://www.sendmail.org
[9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
[9] Gellens、R.及びJ. Klensin "メッセージ送信"、RFC 2476、1998年9月。
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
[10]マイヤーズ、J.、 "認証のためのSMTPサービス拡張"、ProgressのWork。
* 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.
*スパム（R）（大文字）は、ホーメル製肉製品の登録商標です。インターネットコミュニティでの長期スパム（uncapitalized）の使用は、モンティパイソンのスケッチから来ていると、ほとんどのインターネット民間伝承です。用語のスパムは、しかし、これは、ホーメル製品を説明することを意図してどのような方法ではありませんが、通常は軽蔑的です。
Editor's Address
編集者の住所
Gunnar Lindberg Computer Communications Group Chalmers University of Technology SE-412 96 Gothenburg, SWEDEN,
テクノロジーのグンナー・リンドバーグコンピュータ通信グループチャルマーズ大学SE-412 96ヨーテボリ、スウェーデン、
Phone: +46 31 772 5913 FAX: +46 31 772 5922 EMail: lindberg@cdg.chalmers.se
電話：+46 31 772 5913 FAX：+46 31 772 5922 Eメール：lindberg@cdg.chalmers.se
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。