[要約] RFC 2505は、SMTPのメール転送エージェント（MTA）におけるスパム対策の推奨事項をまとめています。リレーの制限、送信元アドレスの検証、不適切な利用の防止などの技術的な対策を提案しています。ネットワーク管理者が自身のサーバーがスパムの送信元や中継点になるのを防ぐための指針を提供することを目的としています。
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). All Rights Reserved.
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.
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にどのような「スパム対策用設定項目」が期待されるかを、システム管理者や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にも実費がかかります。あるISPのホストにメールボックスを持つ10,000人に、10 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 スパム送信者の多くは不誠実です。たとえば、偽の返信先アドレスを使って身元を隠したり、二人の間の私信に見えるよう意図的に書いて、受信者に誤配だと思わせたりします。また、受信者が頼んでいないのに「ご希望の資料」と称することもあります。
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%を見つけて利用します。または、接続先を切り替え、各受信者のホストに直接接続するでしょう。その場合、スパム送信者の費用は増えますが、十分に起こり得ます。
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]:
本メモでは、RFC 2119 [4] の用語を使用します。
o "MUST"
o "MUST"
This word or the adjective "REQUIRED" means that the item is an absolute requirement.
この語または形容詞「REQUIRED」は、その項目が絶対に満たさなければならない要件であることを意味します (MUST)。
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.
この語または形容詞「RECOMMENDED」は、特定の状況ではこの項目を適用しない正当な理由があり得ることを意味します。ただし、別の方針を選ぶ前に、その影響を十分に理解し、慎重に判断する必要があります。
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.
この語または形容詞「OPTIONAL」は、その項目が任意であることを意味します。たとえば、特定の市場で求められる、または製品価値を高めるという理由で、あるベンダーはその項目を実装し、別のベンダーは実装しないことがあります。
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レコードが関連付けられた名前を指します（RFC 1034 [5]、RFC 1035 [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アドレスよりFQDNの利用を推奨するのは、一般にFQDNのほうが扱いやすいためです。ただし、その利用はDNSおよび.IN-ADDR.ARPA（PTR）の情報に大きく依存します。DNSサーバーに偽のキャッシュ情報を注入したり、スパム送信者が偽情報を登録したDNSを運用したりすれば、情報は容易に偽造できます。そのためホスト名やドメイン名は慎重に使い、たとえばアドレスから名前への変換結果と名前からアドレスへの変換結果が対応することを確認してください。セキュアDNS（RFC 2065 [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:
推奨事項の一つは、DNSを使って「MAIL From:」のドメイン（エンベロープ送信者ドメイン）を検証し、そのドメインに適切な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の「MAIL From:」に含まれるアドレスのFQDN妥当性検査を行うサイトだと知られている場合、攻撃者は否定応答を利用して、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.
スパム用プログラムの初期の版に対しては、FQDN検査がかなり有効です。そうしたプログラムは、DNSで検証するとシステムに受け入れられない、完全にでたらめな「MAIL From:」を使うためです。この検査は現在、多くのサイトで実施されており、スパムを減らしています。
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接続が不安定なサイトでは、受信側が「MAIL From:」を検証する際の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 From:」の検査が役立つ可能性は大きく下がります。その利用が合法かどうかは本メモの対象外です。それでも、この検査には、入力ミスや設定を誤った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層で行い、メッセージを拒否すると決めた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レコードと予期しない形で相互作用する場合があります。受信ドメインに複数の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 From:」）の受信を拒否します。問題のメールを送信者のホストに留めてキュー用ディスクを満杯にするつもりが、次に優先度の高い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.
2xx応答を返しながらスパムメールを転送も受信もしない方法も提案されています。典型的には別の場所（例: /dev/null）に保存します。これはRFC 821の意図に反するため、慎重な検討なしに行うべきではありません。メールを盲目的に破棄する代わりにキューへ戻し、スパムか正当なメールか、破棄すべきか転送すべきかを手動または自動で調べられます。
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) 許可されていない使用をメールリレーとして制限できなければなりません (MUST)。
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コマンドなどで偽のホスト名を使っていても、メール経路を追跡できるだけの情報を含む「Received:」行を出力できなければなりません (MUST)。
3) MUST be able to provide local log information that makes it possible to trace the event afterwards.
3) その後、イベントを追跡できるようにするローカルログ情報を提供できなければなりません (MUST)。
4) SHOULD be able to log all occurrences of anti-relay/anti-spam actions.
4) 不正中継対策やスパム対策の処理を行ったすべての事例をログに記録できるべきです (SHOULD)。
5) SHOULD be able to refuse mail from a host or a group of hosts.
5) 特定のホストまたはホスト群からのメールを拒否できるべきです (SHOULD)。
6a) MUST NOT refuse "MAIL From: <>".
6a) 「MAIL From: <>」を拒否してはなりません (MUST NOT)。
6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
6b) 「MAIL From: <user@my.local.dom.ain>」を拒否してはなりません (MUST NOT)。
7a) SHOULD be able to refuse mail from a specific "MAIL From:" user, <foo@domain.example>.
7a) 特定の「MAIL From:」ユーザー（<foo@domain.example>）からのメールを拒否できるべきです (SHOULD)。
7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
7b) 「MAIL From:」のドメイン全体（<.*@domain.example>）からのメールを拒否できるべきです (SHOULD)。
8) SHOULD be able to limit ("Rate Control") mail flow.
8) メールの流量（レート）を制限できるべきです (SHOULD)。
9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).
9) DNSなどを使って「MAIL From:」のドメインを検証できるべきです (SHOULD)。
10) SHOULD be able to verify <local-part> in outgoing mail.
10) 送信メールの<local-part>を検証できるべきです (SHOULD)。
11) SHOULD be able to control SMTP VRFY and EXPN.
11) SMTPのVRFYとEXPNを制御できるべきです (SHOULD)。
12) SHOULD be able to control SMTP ETRN.
12) SMTPのETRNを制御できるべきです (SHOULD)。
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恒久エラー）を設定できなければなりません (MUST)。
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の外部から提供できることが推奨されます (SHOULD)。また、柔軟性を高めるため、外部ファイルの照合規則で正規表現を使えることも推奨されます (SHOULD)。
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.
ドメイン名・ホスト名の文字列照合では、大文字と小文字を区別してはなりません (MUST NOT)。<local-part>では区別するのが自然かもしれません。しかし、<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はそのようなリレーの使用を制御/拒否できなければなりません (MUST)。
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.
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は以下の組み合わせに基づいて、メールリレーの使用を許可できなければなりません (MUST)。
o "RCPT To:" address (domain).
o SMTP_Caller FQDN hostname.
o SMTP_Caller IP address.
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:」が自組織のドメイン（ローカルドメイン、または転送を受け付ける代替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アドレスまたはFQDNが許可されているなら、中継を受け入れます（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)の判定では、公式形式の[@a,@b:u@c]、「%」ハック、UUCP形式の「!」パスを含む、あらゆるSMTPソースルーティングを、判定前に完全に削除するか、少なくとも判定に反映してください。
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.
どの構成でも、FQDNとクラスフルIPアドレスのワイルドカードをサポートしなければなりません (MUST)。クラスレスIPアドレスでは「アドレス/マスク」形式もサポートすべきです (SHOULD)。例: 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データベースなどの外部ソースから提供できるべきです (SHOULD)。判定用データやテンプレートでは正規表現も使用できるべきです (SHOULD)。
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は、メールに「Received:」行を先頭追加しなければなりません (MUST)（RFC 822 [2]に記載され、RFC 1123 [3]で要求されています）。この行には、メール経路を送信者まで追跡できるだけの情報を含めなければなりません (MUST)。ここでは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も含め、「Received:」行を先頭に追加しなければなりません (MUST)。この行には、次の情報を含めます。
It MUST contain:
含めなければなりません (MUST)：
o The IP address of the caller.
o 接続元のIPアドレス。
o The 'date-time' as described in RFC822, [2], pp 18.
o RFC 822 [2] 18ページに記載されたdate-time。
It SHOULD contain:
次の情報を含めるべきです (SHOULD)。
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.
RFC 822に記載された他の「Received:」フィールドの大部分も、この行に含めることを推奨します。
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
基本的に、メッセージの追跡に役立つ情報は「Received:」行に追加できますし、追加すべきです。最初の投稿が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アドレスを「Received:」行に記録し、その接続を特定できます。
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.
これらの推奨事項はRFC 1123 [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が追加する「Received:」行に含める情報を大幅に制限するか、行自体を追加しません。その後、ファイアウォールやゲートウェイを経由してメールを外部へ送ります。RFC 1123 [3] の要件に従い、独自の「Received:」行を追加する前に内部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.
このように構成する組織は、組織内から送信するスパム送信者を追跡する責任を全面的に負うか、その活動に対する責任を問われることを受け入れます。外部へ送るメールには、必要な追跡を行うのに十分な情報を含めることが必須です (MUST)。
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.
組織に着信するメールの場合、内部でメールを受信するユーザーが着信メッセージを発信元まで追跡するのに必要な情報を提供できるように、「Received:」行はそのまま保持しなければなりません (MUST)。
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.
一般に、セキュリティ上の要件がない限り、ゲートウェイは「Received:」行を変更または削除すべきではありません (SHOULD NOT)。ゲートウェイを通過する際に既存の行を「意味が通る」ように書き換えると、追跡に必要な情報が失われることがよくあります。メッセージ本体、受信者に届くメール、またはそれが不可能ならログファイルに、「Received:」行の情報を確実に保持してください。
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は、事象を追跡できるだけのローカルログ情報を提供できなければなりません (MUST)。上記の「Received:」行に記録する情報の大部分も対象です。
The MTA SHOULD be able to log all anti-relay/anti-spam actions. The log entries SHOULD contain at least:
MTAは、不正中継対策やスパム対策の処理をすべてログに記録できるべきです (SHOULD)。ログには少なくとも次の情報を含めるべきです (SHOULD)。
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 Denied」、「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 To:」がまだ不明なので、記録できません。）
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 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は、特定のホストまたはホスト群からのメールを受け入れるか拒否できるべきです (SHOULD)。ここでいうホストは、IP.srcアドレス、またはそのアドレスを.IN-ADDR.ARPAで逆引きしたFQDNを指します（DNSを信頼するかどうかによります）。この機能はファイアウォールでも実装できますが、MTA自身が防御できるよう、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ホスト名（host.domain.example）、ワイルドカード付きドメイン名（*.domain.example）、個別のIPアドレス（10.11.12.13）、またはプレフィックス長付きIPアドレス（10.0.0.0/8、192.168.1.0/24）に基づいて判定できることが推奨されます (SHOULD)。
It is also RECOMMENDED that these decision rules can be combined to form a flexible list of accept/refuse/accept/refuse, e.g:
受け入れと拒否を交互に指定するなど、判定規則を組み合わせて柔軟なリストを作れることも推奨されます (SHOULD)。例:
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アドレス/プレフィックス長形式をサポートすることが推奨されます (SHOULD)。ただし、ワイルドカード（例: 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.
スパマー対策は重要ですが、既存のメール標準に違反する方法で行ってはなりません。スパマーは「MAIL From:」アドレスを偽造することが多いため、特に一見あやしいアドレスに一般的な制限を設けたくなります。しかし、そのような制限はスパム以上にメールコミュニティへ混乱を招くおそれがあります。
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.
特定のホストやサイトからのメールを拒否する必要がある場合は、「MAIL From:」の値にかかわらず、SMTP_Callerのアドレスまたは名前に基づいて拒否するなど、本メモで述べる別の方法を使うことを推奨します。
The MTA MUST NOT refuse to receive "MAIL From: <>".
MTAは「MAIL From: <>」の受信を拒否してはなりません (MUST NOT)。
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.
「MAIL From: <>」はメールシステム自身が生成するエラーメッセージに使います。たとえば、正当なメール中継がエラーを受け取り、ユーザーへ返す場合です。このメールを拒否すると、送信したメールの「User unknown」などのエラーがユーザーに届かなくなり、スパム以上の混乱を招きかねません。
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.
この形式の正当な「MAIL From: <>」で最も一般的なのは、単一の受信者へ返すエラーメッセージです。スパマーがこれを複数宛先への送信に使ったため、メール全体、または最初の受信者以外を拒否したくなるかもしれません。しかし、複数の受信者へ送る正当なエラーメールもあります。たとえば、同じリモートサイトにいる複数のメーリングリスト管理者へ送る場合です。そのため、この場合もMTAは「MAIL From: <>」を拒否してはなりません (MUST NOT)。
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 To:」が複数ある場合、MTAはTCP接続の読み取り頻度（read()の頻度）を落としてもかまいません (MAY)。これにより「MAIL From: <>」を使うスパマーを遅らせられます。
The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
MTAは「MAIL From: <user@my.local.dom.ain>」を拒否してはなりません (MUST NOT)。
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」とは、ローカルとして扱われ、ローカル配送されるドメイン名を指します。一見、他者がこのドメインを送信元に使う必要はなく、利用者を制限すれば詐欺とスパムを減らせるように思えます。ごく短期的にはそうかもしれませんが、少なくとも次の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へ移転してexternal.exampleに.forwardファイルを残しているために、<user2@my.local.dom.ain>へ転送される場合があります。
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 メーリングリスト。RFC 1123 [3] は、メーリングリストから送るメールの「MAIL From:」に個々の送信者ではなくリストの管理者を指定するよう求めています。リストの管理者がリストホストと別のドメインにいる場合もあります。そのため、別ドメインを担当するホストから、管理者のローカルドメインを「MAIL From:」に指定したメールが届くことがあります。
If "MAIL From: <user@my.local.dom.ain>" is rejected, both these cases will result in failure to deliver legitimate mail.
「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は、特定の「MAIL From:」ユーザー（foo@domain.example）または「MAIL From:」ドメイン全体（domain.example）からのメールを拒否できるべきです (SHOULD)。この種の規則は、スパム送信者が「MAIL From:」を定期的に変更すれば簡単に回避できますが、攻撃を発見して対応している間、特定のユーザーやドメインをブロックできると大いに役立ちます。
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アドレスが明示的に拒否されたネットワークに属する場合）を除き、拒否してはなりません (MUST NOT)。
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は、メールホストがメールの送信速度や受信速度を制御するためのツールを提供すべきです (SHOULD)。目的は次の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応答コードを返せます。こうした措置を取るかどうかは、「MAIL From:」のユーザーやドメイン、SMTP_Caller（名前またはアドレス）、「RCPT To:」、またはこれらの組み合わせに基づいて判断することが推奨されます (SHOULD)。
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は、「MAIL From:」のドメインが存在するか（MXレコードまたはAレコードに解決されるか）を簡単に検査し、存在しなければ受信を拒否できるべきです (SHOULD)。DNSエラーが一時的なTempFailなら、4xx応答コード（一時エラー）を返さなければなりません (MUST)。権威サーバーからNXDOMAIN（ホストまたはドメインが不明）が返された場合も、プライマリDNSとセカンダリDNSの不整合かもしれないため、4xx応答コードを返すべきです (SHOULD)。ただし、システム管理者が設定していれば、5xx応答コードを返してもかまいません (MAY)。
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>を検証し、送信者名が実在ユーザーまたは登録済みエイリアスであることを確認できるべきです (SHOULD)。これは主に、次のような「入力ミス」
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はこれらのコマンドを誰に許可するか制御すべきです (SHOULD)。制御方法は有効・無効の切り替えでも、前述のようなアクセスリストでもかまいません。
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.
RFC 821 [1] では「VRFY」コマンドが必須である点に注意してください。ただし、無効化する場合やアクセスリストで遮断する場合は、「252 Argument not checked」と応答できます。これを既定値にしてください。
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コマンドを誰に許可するか制御すべきです (SHOULD)。制御方法は有効・無効の切り替えでも、前述のようなアクセスリストでもかまいません。既定値は無効にしてください。
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）を返すよう構成できなければなりません (MUST)。ただし、先頭の数字（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問い合わせの結果がTempFail（一時エラー）なら、MTAはその結果を反映し、4xx応答コードを返さなければなりません (MUST)。DNS応答が権威サーバーからのNXDOMAIN（ホストまたはドメインが不明）なら、MTAは5xx応答コードでその結果を反映してもかまいません (MAY)。
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.
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からのSMTP接続を受け入れる必要があります。後期のスパム用プログラムは、この仕組みを利用し、常にmail.chalmers.seを経由してサブドメインへメールを届けます。結果として、メール中継を悪用しながら、受信側ホストが送信ホストのFQDNやIPアドレスに基づいてSMTP接続を拒否することを回避します。
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応答コード）。これは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.
つまり、この対応を可能にしたのは、(1) 中継認証の仕組みと (2) 応答コードの割り当ての両方に十分な柔軟性があったためです。応答コードが5xxに固定されたMTAでは、これはまったく実現できませんでした。
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が上記のような不正中継フィルターを導入すると、携帯型ノートPCのUAが「Relaying Denied」という応答を受けることがあります。接続に使ったIPアドレスが未知の範囲にある、または未知のFQDNへ逆引きされるだけで拒否される可能性があります。
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.
この「Relaying Denied」の典型的な被害者は、出張中にノートPCを使う営業担当者や、会議開催中のホテルにいるIETF参加者です。営業担当者は近隣のISPへダイヤルアップ接続し、その接続プールからIPアドレスを割り当てられるでしょう。IETF参加者は会議室のネットワークのIPアドレスを使います。どちらの場合も、ノートPCのメールソフト（UA。例: pine、Netscape、Eudora）は自宅のMTA（例: SMTP-SERVER=mail.home.example）経由でメールを送ろうとします。しかし、mail.home.exampleが一時的なIPアドレスを受け入れるよう設定されていなければ、「Relaying Denied」と応答して拒否します。
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を指定すれば、スパマーも中継を許可されるためです。ただし、その可能性は高くありません。常時、全世界に中継を開放することを避け、ログを注意深く監視し、悪用が見つかったら直ちに中継を止めれば、この方法で十分でしょう。
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のプロファイルである「Message Submission」仕様 [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 Authenticated」であれば、中継を受け入れます。
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 Denied」のどちらか一方だけを選ばせることもできます。しかし、通常のユーザーが「MAIL From: <.*@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 偽造した「MAIL From:」や「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、ログ機能、ローカルユーザー一覧を持つデータベース、認証機構などの支援システムにも負荷をかけます。そのため、これらの方法を導入すると、サイトにスパムを送り付けることで支援システムを狙うサービス拒否攻撃のリスクが高まります。たとえば、ログ機能は記録量の増加を処理できる必要があります（ログファイルがディスクを満杯にした場合はどうなるでしょうか）。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）を返してはなりません (MUST NOT)。
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.
貴重な意見や提案を寄せてくださった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.
最後に、有益なコメントをくださり、IETFの手続きを通じて支援と助言をしてくださったHarald AlvestrandとPatrik Faltstromに深く感謝します。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[8] sendmail Home Page. http://www.sendmail.org
[9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
[9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
* 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（先頭を大文字にした「Spam」）は、Hormel社の食肉製品の登録商標です。インターネットコミュニティで小文字の「spam」を使うようになったのは、Monty Pythonのコントがきっかけで、ほぼインターネットの民間伝承となっています。「spam」は通常、軽蔑的な意味で使われますが、Hormel社の製品を指す意図はありません。
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). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
上記の著作権表示とこの段落をすべての複製物および派生物に含めることを条件として、本書およびその翻訳を複製して他者に提供できます。また、本書について論評・説明する派生著作物や、本書の実装を支援する派生著作物を、全部または一部、いかなる制限もなく作成、複製、公開、配布できます。ただし、本書自体は、著作権表示やInternet Societyその他のインターネット組織への言及を削除するなど、いかなる方法でも変更してはなりません。例外は、インターネット標準の策定に必要な場合（その場合はインターネット標準化手続きの著作権規則に従います）と、英語以外の言語へ翻訳する場合です。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で許諾した限定的な権利は永続し、Internet Society、その後継者または譲受人によって取り消されることはありません。
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.
本書および本書に含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、明示的または黙示的を問わず、あらゆる保証を否認します。これには、本情報の利用がいかなる権利も侵害しないことの保証、および商品性や特定目的への適合性に関する黙示的保証が含まれますが、これらに限定されません。