[要約] RFC 5068は、電子メールの送信操作に関するアクセスと説明責任の要件についてのガイドラインです。その目的は、電子メールの送信プロセスにおけるアクセス制御と監査の要件を定義し、セキュリティと信頼性を向上させることです。
Network Working Group C. Hutzler
Request for Comments: 5068
BCP: 134 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
P. Resnick
QUALCOMM Incorporated
E. Allman
Sendmail, Inc.
T. Finch
University of Cambridge Computing Service
November 2007
Email Submission Operations: Access and Accountability Requirements
メールの提出操作：アクセスおよび説明責任の要件
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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Abstract
概要
Email has become a popular distribution service for a variety of socially unacceptable, mass-effect purposes. The most obvious ones include spam and worms. This note recommends conventions for the operation of email submission and transport services between independent operators, such as enterprises and Internet Service Providers. Its goal is to improve lines of accountability for controlling abusive uses of the Internet mail service. To this end, this document offers recommendations for constructive operational policies between independent operators of email submission and transmission services.
電子メールは、さまざまな社会的に受け入れられない大量効果の目的のための一般的な流通サービスになりました。最も明白なものには、スパムとワームが含まれます。このメモは、エンタープライズやインターネットサービスプロバイダーなどの独立したオペレーター間の電子メール提出および輸送サービスの運用に関する規則を推奨しています。その目標は、インターネットメールサービスの虐待的な使用を制御するための説明責任を向上させることです。この目的のために、このドキュメントは、電子メールの提出サービスと送信サービスの独立したオペレーター間の建設的な運用ポリシーに関する推奨事項を提供します。
Email authentication technologies are aimed at providing assurances and traceability between internetworked networks. In many email services, the weakest link in the chain of assurances is initial submission of a message. This document offers recommendations for constructive operational policies for this first step of email sending, the submission (or posting) of email into the transmission network. Relaying and delivery entail policies that occur subsequent to submission and are outside the scope of this document.
電子メール認証テクノロジーは、インターネットワークのネットワーク間で保証とトレーサビリティを提供することを目的としています。多くの電子メールサービスでは、保証チェーンの最も弱いリンクは、メッセージの初期提出です。このドキュメントは、電子メール送信のこの最初のステップ、送信ネットワークへの電子メールの提出（または投稿）のための建設的な運用ポリシーに関する推奨事項を提供します。中継と配信には、提出後に発生し、このドキュメントの範囲外であるポリシーが含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 4
3.1. Best Practices for Submission Operation . . . . . . . . . 5
3.2. Transitioning to Submission Port . . . . . . . . . . . . . 6
4. External Submission . . . . . . . . . . . . . . . . . . . . . 6
4.1. Best Practices for Support of External Submissions . . . . 7
5. Message Submission Authentication/Authorization
Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10
The very characteristics that make email such a convenient communications medium -- its near ubiquity, rapid delivery, low cost, and support for exchanges without prior arrangement -- have made it a fertile ground for the distribution of unwanted or malicious content. Spam, fraud, and worms have become a serious problem, threatening the viability of email and costing end users and providers millions of dollars in damages and lost productivity. In recent years, independent operators including enterprises and ISPs have turned to a number of different technologies and procedures, in an attempt to combat these problems. The results have been mixed, at best.
このような便利なコミュニケーション媒体に電子メールを作成するまさにその特性 - その遍在性、迅速な配信、低コスト、および事前の取り決めのない交換のサポート - は、望ましくないまたは悪意のあるコンテンツを分配するための肥沃な根拠になりました。スパム、詐欺、ワームは深刻な問題になり、電子メールの実行可能性を脅かし、エンドユーザーとプロバイダーに数百万ドルの損害と生産性の低下を脅かしています。近年、企業やISPを含む独立したオペレーターは、これらの問題と戦うために、さまざまな技術と手順の多くに変わりました。結果はせいぜい混合されています。
En route to its final destination, email will often travel between multiple independent providers of email transmission services. These services will generally have no prior arrangement with one another and may employ different rules on the transmission. It is therefore difficult both to debug problems that occur in mail transmission and to assign accountability if undesired or malicious mail is injected into the Internet mail infrastructure.
最終目的地への途中で、電子メールは、電子メール伝送サービスの複数の独立したプロバイダー間を移動することがよくあります。これらのサービスは一般に、互いに事前の配置を持たず、送信に異なるルールを使用する場合があります。したがって、メール送信で発生する問題をデバッグすることと、望ましくないまたは悪意のあるメールがインターネットメールインフラストラクチャに注入された場合は説明責任を割り当てることは困難です。
Many email authentication technologies exist. They provide some accountability and traceability between disparate networks. This document aims to build upon the availability of these technologies by exploring best practices for authenticating and authorizing the first step of an email's delivery, from a Mail User Agent (MUA) to a Mail Submission Agent (MSA), known as submission. Without strong practices on email submission, the use of authentication technologies elsewhere in the service provides limited benefit.
多くの電子メール認証テクノロジーが存在します。それらは、異なるネットワーク間である程度の説明責任とトレーサビリティを提供します。このドキュメントの目的は、メールユーザーエージェント（MUA）からメール提出エージェント（MSA）までのメール配信の最初のステップを認証および承認するためのベストプラクティスを調査することにより、これらのテクノロジーの可用性に基づいて構築することを目的としています。電子メールの提出に関する強力な慣行がなければ、サービスの他の場所で認証技術を使用することで、限られた利益が得られます。
This document specifies operational policies to be used for the first step of email sending, the submission -- or posting from an MUA to an MSA as defined below -- of email into the transmission service. These policies will permit continued, smooth operation of Internet email, with controls added to improve accountability. Relaying and delivering employ policies that occur after submission and are outside the scope of this document. The policies listed here are appropriate for operators of all sizes of networks and may be implemented by operators independently, without regard for whether the other side of an email exchange has implemented them.
このドキュメントは、電子メールの送信の最初のステップ、提出、またはMUAからMSAへの投稿を以下に定義するように、送信サービスへの電子メールへの投稿に使用する運用ポリシーを指定します。これらのポリシーでは、説明責任を向上させるためにコントロールが追加されたインターネットメールの継続的なスムーズな操作が可能になります。提出後に発生し、このドキュメントの範囲外にある雇用ポリシーを中継および配信します。ここにリストされているポリシーは、あらゆるサイズのネットワークのオペレーターに適しており、電子メール交換の反対側がそれらを実装したかどうかを考慮せずに、オペレーターによって独立して実装される場合があります。
It is important to note that the adoption of these policies alone will not solve the problems of spam and other undesirable email. However, these policies provide a useful step in clarifying lines of accountability and interoperability between operators. This helps raise the bar against abusers and provides a foundation for additional tools to preserve the utility of the Internet email infrastructure.
これらのポリシーの採用だけでは、スパムや他の望ましくない電子メールの問題は解決されないことに注意することが重要です。ただし、これらのポリシーは、オペレーター間の説明責任と相互運用性のラインを明確にするための有用なステップを提供します。これにより、虐待者に対する水準の上昇に役立ち、インターネットメールインフラストラクチャのユーティリティを保存するための追加ツールの基盤を提供します。
NOTE: This document does not delve into other anti-spam operational issues such as standards for rejection of email. The authors note that this could be a valuable effort to undertake and encourage its pursuit.
注：このドキュメントは、電子メールの拒否基準など、他のスパム防止運用上の問題を掘り下げていません。著者は、これがその追求を引き受けて奨励するための貴重な努力である可能性があると指摘しています。
The Internet email architecture distinguishes four message-handling components:
インターネットメールアーキテクチャは、4つのメッセージ処理コンポーネントを区別します。
o Mail User Agents (MUAs)
o メールユーザーエージェント（MUAS）
o Mail Submission Agents (MSAs)
o メール提出エージェント（MSA）
o Mail Transfer Agents (MTAs)
o メール転送エージェント（MTA）
o Mail Delivery Agents (MDAs)
o メール配送エージェント（MDA）
At the origination end, an MUA works on behalf of end users to create a message and perform initial "submission" into the transmission infrastructure, via an MSA. An MSA accepts the message submission, performs any necessary preprocessing on the message, and relays the message to an MTA for transmission. MTAs 'relay' messages to other MTAs, in a sequence reaching a destination MDA that, in turn, 'delivers' the email to the recipient's inbox. The inbox is part of the recipient-side MUA that works on behalf of the end user to process received mail.
Origination Endでは、MUAがエンドユーザーに代わって動作し、メッセージを作成し、MSAを介して送信インフラストラクチャに最初の「提出」を実行します。MSAはメッセージの送信を受け入れ、メッセージに必要な前処理を実行し、伝送のためにメッセージをMTAにリレーします。MTAS「リレー」メッセージは、他のMTASへの「リレー」メッセージで、宛先MDAに到達し、その結果、受信者の受信トレイに電子メールを「配信」します。受信トレイは、受信したメールを処理するためにエンドユーザーに代わって動作する受信者側MUAの一部です。
These architectural components are often compressed, such as having the same software do MSA, MTA and MDA functions. However the requirements for each of these components of the architecture are becoming more extensive, so that their software and even physical platform separation is increasingly common.
これらのアーキテクチャコンポーネントは、MSA、MTA、MDA機能と同じソフトウェアを使用するなど、多くの場合圧縮されます。ただし、アーキテクチャのこれらの各コンポーネントの要件はより広範囲になっているため、ソフトウェアや物理的なプラットフォームの分離さえますます一般的になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Originally the MSA, MTA, and MDA architectural components were considered to be a single unit. This was reflected in the practice of having MSA, MTA, and MDA transfers all be performed with SMTP [RFC2821] [RFC0821], over TCP port 25. Internet mail permits email to be exchanged without prior arrangement and without sender authentication. That is, the confirmed identity of the originator of the message is not necessarily known by the relaying MTAs or the MDA.
もともとは、MSA、MTA、およびMDAの建築コンポーネントが単一のユニットと見なされていました。これは、MSA、MTA、およびMDA転送をすべてTCPポート25を介してSMTP [RFC2821] [RFC0821]で実行する実践に反映されていました。つまり、メッセージの発信者の確認されたアイデンティティは、リレーするMTAまたはMDAによって必ずしもわかっているわけではありません。
It is important to distinguish MUA-to-MSA email submission, versus MTA relaying, versus the final MTA-to-MDA transition. Submission typically does entail a pre-established relationship between the user of the client and operator of the server; equally, the MDA is performing final delivery and can determine that it has an existing relationship with the recipient. That is, MSAs and MDAs can take advantage of having prior relationships with users in order to constrain their transfer activities.
MUAからMSAへの電子メールの送信と、最終的なMTAからMDAへの遷移と比較して、MTAリレーを区別することが重要です。通常、提出は、クライアントのユーザーとサーバーのオペレーターとの間に事前に確立された関係を伴います。同様に、MDAは最終配達を実行しており、受信者と既存の関係があると判断できます。つまり、MSAとMDAは、移籍活動を制約するためにユーザーと以前の関係を持つことを利用できます。
Specifically, an MSA can choose to reject all postings from MUAs for which it has no existing relationship. Similarly, an MDA can choose to reject all mail to recipients for which it has no arrangement to perform delivery. Indeed, both of these policies are already in common practice.
具体的には、MSAは、既存の関係がないMUASからすべての投稿を拒否することを選択できます。同様に、MDAは、配信を実行するための取り決めがない受信者にすべてのメールを拒否することを選択できます。実際、これらのポリシーは両方ともすでに一般的な慣行にあります。
Submission Port Availability:
提出ポートの可用性：
If external submissions are supported -- that is, from outside a site's administrative domain -- then the domain's MSAs MUST support the SUBMISSION port 587 [RFC4409]. Operators MAY standardize on the SUBMISSION port for both external AND LOCAL users; this can significantly simplify submission operations.
外部提出がサポートされている場合、つまりサイトの管理ドメインの外部から - ドメインのMSAは、提出ポート587 [RFC4409]をサポートする必要があります。オペレーターは、外部ユーザーとローカルユーザーの両方の提出ポートを標準化する場合があります。これにより、提出操作を大幅に簡素化できます。
Submission Port Use:
提出ポートの使用：
MUAs SHOULD use the SUBMISSION port for message submission.
MUASは、メッセージ送信に送信ポートを使用する必要があります。
Submission Authentication:
提出認証：
MSAs MUST perform authentication on the identity asserted during all mail transactions on the SUBMISSION port, even for a message having a RCPT TO address that would not cause the message to be relayed outside of the local administrative domain.
MSAは、送信ポート上のすべてのメールトランザクション中に主張されたIDの認証を実行する必要があります。これは、ローカル管理ドメインの外部でメッセージを中継することのないRCPTを備えているメッセージを持っている場合でもありません。
Submission Authorization:
提出承認：
An operator of an MSA MUST ensure that the authenticated identity is authorized to submit email, based on an existing relationship between the submitting entity and the operator. This requirement applies to all mail submission mechanisms (MUA to MSA).
MSAのオペレーターは、提出エンティティとオペレーターの間の既存の関係に基づいて、認証されたIDが電子メールの送信を許可されることを確認する必要があります。この要件は、すべてのメール提出メカニズム（MUAからMSA）に適用されます。
Submission Accountability after Submission:
提出後の説明責任：提出：
For a reasonable period of time after submission, the message SHOULD be traceable by the MSA operator to the authenticated identity of the user who sent the message. Such tracing MAY be based on transactional identifiers stored in the headers (received lines, etc.) or other fields in the message, on audit data stored elsewhere, or on any other mechanism that supports sufficient post-submission accountability. The specific length of time, after message submission, that traceability is supported is not specified here. However, issues regarding transit often occur as much as one week after submission.
提出後は妥当な期間、メッセージを送信したユーザーの認証されたアイデンティティまで、メッセージはMSAオペレーターによって追跡可能でなければなりません。このようなトレースは、ヘッダーに保存されているトランザクション識別子（受信した行など）またはメッセージ内の他のフィールド、他の場所に保存されている監査データ、または十分な補給後の説明責任をサポートするその他のメカニズムに基づいている場合があります。メッセージの提出後、トレーサビリティがサポートされるという特定の時間は、ここでは指定されていません。ただし、輸送に関する問題は、提出後1週間も経ちます。
Note that [RFC3848] defines a means of recording submission-time information in Received header fields. This information can help receive-side analysis software establish a sending MSA's accountability and then make decisions about processing the message.
[RFC3848]は、受信されたヘッダーフィールドに送信時間情報を記録する手段を定義することに注意してください。この情報は、受信側の分析ソフトウェアが送信MSAの説明責任を確立し、メッセージの処理に関する決定を下すのに役立ちます。
In order to promote transition of initial message submission from port 25 to port 587, MSAs MUST listen on port 587 by default and SHOULD have the ability to listen on other ports. MSAs MUST require authentication on port 587 and SHOULD require authentication on any other port used for submission. MSAs MAY also listen on other ports. Regardless of the ports on which messages are accepted, MSAs MUST NOT permit relaying of unauthenticated messages to other domains. That is, they must not be open relays.
ポート25からポート587への初期メッセージの提出の移行を促進するために、MSAはデフォルトでポート587でリスニングする必要があり、他のポートでリスニングする機能を持つ必要があります。MSAはポート587で認証を必要とする必要があり、提出に使用される他のポートで認証が必要です。MSAは他のポートでも聴くことができます。メッセージが受け入れられるポートに関係なく、MSAは他のドメインに認定されていないメッセージを中継することを許可してはなりません。つまり、彼らはオープンなリレーであってはなりません。
As a default, MUAs SHOULD attempt to find the best possible submission port from a list of alternatives. The SUBMISSION port 587 SHOULD be placed first in the list. Since most MUAs available today do not permit falling back to alternate ports, sites SHOULD pre-configure or encourage their users to connect on the SUBMISSION port 587, assuming that site supports that port.
デフォルトとして、MUASは、代替案のリストから可能な限り最高の提出ポートを見つけようとする必要があります。提出ポート587は、最初にリストに配置する必要があります。今日入手可能なほとんどのMUAは、代替ポートに戻ることを許可していないため、サイトは、サイトがそのポートをサポートしていると仮定して、ユーザーが提出ポート587で接続するようにユーザーを奨励する必要があります。
An MUA might need to submit mail across the Internet, rather than to a local MSA, in order to obtain particular services from its home site. Examples include active privacy protection against third-party content monitoring, timely processing, and being subject to the most appropriate authentication and accountability protocols. Further, the privacy requirement might reasonably include protection against monitoring by the operator of the MUA's access network. This requirement creates a challenge for the provider operating the IP network through which the MUA gains access. It makes that provider an involuntary recruit to the task of solving mass-effect email problems: When the MUA participates in a problem that affects large numbers of Internet users, the provider is expected to effect remedies and is often expected to prevent such occurrences.
MUAは、ホームサイトから特定のサービスを取得するために、地元のMSAではなく、インターネット全体にメールを送信する必要がある場合があります。例には、サードパーティのコンテンツモニタリングに対する積極的なプライバシー保護、タイムリーな処理、および最も適切な認証および説明責任プロトコルの対象となります。さらに、プライバシー要件には、MUAのアクセスネットワークのオペレーターによる監視に対する保護が合理的に含まれる場合があります。この要件は、MUAがアクセスするIPネットワークを操作するプロバイダーにとって課題を生み出します。そのプロバイダーは、大量効果電子メールの問題を解決するタスクに不本意な採用を行います。MUAが多数のインターネットユーザーに影響を与える問題に参加すると、プロバイダーは救済策を講じることが期待され、そのような発生を防ぐことがよくあります。
A proactive technique used by some providers is to block all use of port 25 SMTP for mail that is being sent outbound, or to automatically redirect this traffic through a local SMTP proxy, except for hosts that are explicitly authorized. This can be problematic for some users, notably legitimate mobile users attempting to use their "home" MSA, even though those users might already employ legitimate, port 25-based authentication.
一部のプロバイダーが使用するプロアクティブな手法は、送信されているメールでポート25 SMTPのすべての使用をブロックするか、明示的に承認されたホストを除き、ローカルSMTPプロキシを介してこのトラフィックを自動的にリダイレクトすることです。これは、一部のユーザー、特に「ホーム」MSAを使用しようとする合法的なモバイルユーザーにとって問題になる可能性があります。
This document offers no recommendation concerning the blocking of SMTP port 25 or similar practices for controlling abuse of the standard anonymous mail transfer port. Rather, it pursues the mutually constructive benefit of using the official SUBMISSION port 587 [RFC4409].
このドキュメントは、標準の匿名のメール転送ポートの悪用を制御するためのSMTPポート25または同様のプラクティスのブロッキングに関する推奨事項を提供しません。むしろ、公式提出ポート587 [RFC4409]を使用することの相互に建設的な利点を追求します。
NOTE: Many established practices for controlling abuse of port 25, for mail that is being sent outbound, currently do exist. These include the proxy of SMTP traffic to local hosts for screening, combined with various forms of rate limits. The authors suggest that a separate document on this topic would benefit the email operations community.
注：ポート25の乱用を制御するための多くの確立された慣行は、現在存在しています。これらには、スクリーニングのためにローカルホストへのSMTPトラフィックのプロキシが含まれ、さまざまな形式のレート制限が組み合わされています。著者は、このトピックに関する個別のドキュメントが電子メール運用コミュニティに利益をもたらすことを示唆しています。
Open Submission Port:
提出ポートを開く：
Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587 [RFC4409].
アクセスプロバイダーは、提出ポート587 [RFC4409]を使用して、ユーザーが外部インターネットにアクセスするのをブロックしてはなりません。
Traffic Identification -- External Posting (MSA) Versus Relaying (MX):
トラフィック識別 - 外部投稿（MSA）対中継（MX）：
When receiving email from outside their local operational environment, email service providers MUST distinguish between unauthenticated email addressed to local domains (MX traffic) versus submission-related authenticated email that can be addressed anywhere (MSA traffic). This allows the MTA to restrict relaying operations, and thereby prevent "open" relays. Note that there are situations where this may not apply, such as secondary MXs and related implementations internal to an operator's network and within their control.
ローカル運用環境の外部から電子メールを受信する場合、電子メールサービスプロバイダーは、ローカルドメイン（MXトラフィック）と、どこでもアドレス指定できる提出関連の認証電子メール（MSAトラフィック）に宛てた認証されていない電子メールを区別する必要があります。これにより、MTAは中継操作を制限し、それにより「オープン」リレーを防ぐことができます。セカンダリMXSやオペレーターのネットワーク内およびその制御内の関連する実装など、これが適用されない状況があることに注意してください。
Figure 1 depicts a local user (MUA.l) submitting a message to an MSA (MSA). It also shows a remote user (MUA.r), such as might be in a coffee shop offering "hotspot" wireless access, submitting a message to their "home" MSA via an authenticated port 587 transaction. The figure shows the alternative of using port 587 or port 25 within the MSA's network. This document makes no recommendations about the use of port 25 for submission. The diagram merely seeks to note that it is in common use and to acknowledge that port 25 can be used with sufficient accountability within an organization's network.
図1は、MSA（MSA）にメッセージを送信するローカルユーザー（MUA.L）を示しています。また、「Hotspot」ワイヤレスアクセスを提供するコーヒーショップにある可能性のあるリモートユーザー（MUA.R）が表示され、認証されたポート587トランザクションを介して「ホーム」MSAにメッセージを送信します。この図は、MSAのネットワーク内でポート587またはポート25を使用する代替手段を示しています。このドキュメントは、提出のためにポート25の使用に関する推奨事項を作成しません。この図は、それが一般的に使用されていることに注意し、ポート25を組織のネットワーク内で十分な説明責任で使用できることを認めようとするだけです。
HOME NETWORK DESTINATION
+-------+
| MUA.l |
+---+---+
port | port port port
587/25 V 25 25 -------- 25
+-----+ +-----+ ****** / \ ****** +-----+ +-----+
| MSA |->| MTA |->* AP *->| |->* AP *->| MTA |->| MDA |
+--^--+ +-----+ ****** | INTERNET | ****** +-----+ +-----+
| | |
+-------<--------------|----+ |
\ | /
---^----
|
******
AP = Access Provider * AP *
******
| port 587
+---+----+
| MUA.r |
+--------+
HOTSPOT
Figure 1: Example of Port 587 Usage via Internet
図1：インターネットを介したポート587の使用例
There are many competent technologies and standards for authenticating message submissions. Two component mechanisms that have been standardized include SMTP AUTH [RFC4954] and TLS [RFC3207]. Depending upon the environment, different mechanisms can be more or less effective and convenient. Mechanisms might also have to be used in combination with each other to make a secure system. Organizations SHOULD choose the most secure approaches that are practical.
メッセージ提出を認証するための多くの有能なテクノロジーと標準があります。標準化された2つのコンポーネントメカニズムには、SMTP AUTH [RFC4954]とTLS [RFC3207]が含まれます。環境によっては、さまざまなメカニズムが多かれ少なかれ効果的で便利な場合があります。また、メカニズムは、安全なシステムを作成するために互いに組み合わせて使用する必要がある場合があります。組織は、実用的な最も安全なアプローチを選択する必要があります。
This document does not provide recommendations on specific security implementations. It simply provides a warning that transmitting user credentials in clear text over insecure networks SHOULD be avoided in all scenarios as this could allow attackers to listen for this traffic and steal account data. In these cases, it is strongly suggested that an appropriate security technology MUST be used.
このドキュメントでは、特定のセキュリティ実装に関する推奨事項は提供されていません。攻撃者がこのトラフィックを聞いてアカウントデータを盗むことができるため、すべてのシナリオで、安全でないネットワークを介してクリアテキストでユーザー資格情報を送信することを避ける必要があるという警告を提供します。これらの場合、適切なセキュリティ技術を使用する必要があることが強く提案されています。
Email transfer between independent administrations can be the source of large volumes of unwanted email and email containing malicious content designed to attack the recipient's system. This document addresses the requirements and procedures to permit such exchanges while reducing the likelihood that malicious mail will be transmitted.
独立した管理者間の電子メール転送は、受信者のシステムを攻撃するために設計された悪意のあるコンテンツを含む不要な電子メールと電子メールの大量のソースになります。このドキュメントでは、悪意のあるメールが送信される可能性を減らしながら、そのような交換を許可する要件と手順に対処します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[RFC0821] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types Registration", RFC 3848, July 2005.
[RFC3848] Newman、C。、「ESMTPおよびLMTP送信タイプの登録」、RFC 3848、2005年7月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[RFC4954] Siemborski、R.、ed。and A. Melnikov編、「認証のためのSMTPサービス拡張」、RFC 4954、2007年7月。
These recommendations were first formulated during informal discussions among members of Anti-Spam Technical Alliance (ASTA) and some participants from the Internet Research Task Force's Anti-Spam Research Group (ASRG).
これらの推奨事項は、最初に反スパム技術同盟（ASTA）のメンバーとインターネット研究タスクフォースの反スパム研究グループ（ASRG）の参加者の間での非公式の議論の中で策定されました。
Later reviews and suggestions were provided by: M. Allman, L.H. Aestrand, N. Borenstein, S. Bortzmeyer, K. Chon, R. Clayton, B. Cole, W. Dnes, V. Duchovni, E. Edelstein, F. Ellermann, M. Elvey, J.D. Falk, N. Freed, J. Glube, A. Herzberg, J. Klensin, J. Levine, S. Moonesamy, K. Moore, R. Nelson, C. Newman, C. O'Malley, S. Ramasubramanian, R. Rognlie, J. St. Sauver, W. Schlitt, B. Shein, B. Sullivan.
後のレビューと提案は、M。Allman、L.H。Aestrand、N。Borenstein、S。Bortzmeyer、K。Chon、R。Clayton、B。Cole、W。Dnes、V。Duchovni、E。Edelstein、F。Ellermannann、M。エルビー、J.D。フォーク、N。フリード、J。グルーブ、A。ヘルツバーグ、J。クレンシン、J。レバイン、S。ムーネミー、K。ムーア、R。ネルソン、C。ニューマン、C。オマリー、S.ラマスブラマニアン、R。ログリー、J。セントソーバー、W。シュリット、B。シーン、B。サリバン。
Authors' Addresses
著者のアドレス
Carl Hutzler 2512 Freetown Drive Reston, VA 20191
Carl Hutzler 2512 Freetown Drive Reston、VA 20191
Phone: 703-915-6862
EMail: cdhutzler@aol.com
URI: http://carlhutzler.com/blog/
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Peter Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA
Peter Resnick Qualcomm Incorporated 5775 Morehouse Drive San Diego、CA 92121-1714 USA
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/ Eric Allman Sendmail, Inc. 6745 Christie Ave., Suite 350 Emeryville, CA USA
電話：1 858 651 4478メール：presnick@qualcomm.com URI：http：//www.qualcomm.com/~presnick/ eric allman sendmail、Inc。6745 Christie Ave.
Phone: +1 510 594 5501
EMail: eric+ietf-smtp@sendmail.org
Tony Finch University of Cambridge Computing Service New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND
トニーフィンチケンブリッジ大学コンピューティングサービス新しい博物館サイトペンブロークストリートケンブリッジCB2 3QHイングランド
Phone: +44 797 040 1426
EMail: dot@dotat.at
URI: http://dotat.at/
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。