RFC5068 日本語訳
5068 Email Submission Operations: Access and AccountabilityRequirements. C. Hutzler, D. Crocker, P. Resnick, E. Allman, T.Finch. November 2007. (Format: TXT=24481 bytes) (Also BCP0134) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
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
Hutzlerがコメントのために要求するワーキンググループC.をネットワークでつないでください: 5068BCP: 134D.医者カテゴリ: 最も良い現在の習慣ブランデンブルクインターネットワーキングP.レズニッククアルコムはコンピューターサービス2007年11月にケンブリッジのE.オールマンセンドメールInc.T.フィンチ大学を法人組織にしました。
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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
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.
メール認証技術はinternetworkedネットワークの間に保証と追随性を提供するのを目的とされます。 多くのメールサービスでは、保証のチェーンで最も弱いリンクはメッセージの初期の服従です。 このドキュメントはメール発信のこの第一歩、送電網へのメールの提出(または、任命)のための建設的な運用政策のために推薦を提供します。 リレーと配送は服従にその後で起こって、このドキュメントの範囲の外にある方針を伴います。
Hutzler, et al. Best Current Practice [Page 1] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[1ページ]RFC5068は服従2007年11月にメールします。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 服従、リレー(配送. . . . . . . . . . . . . . . . 4 3.1)。 服従操作. . . . . . . . . 5 3.2のための最も良い習慣。 服従ポート. . . . . . . . . . . . . 6 4に移行します。 外部の服従. . . . . . . . . . . . . . . . . . . . . 6 4.1。 外部の差出. . . . 7 5のサポートのための最も良い習慣。 メッセージ服従認証/認可技術. . . . . . . . . . . . . . . . . . . . . . . . . 8 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 9 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 9 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 9付録A.承認. . . . . . . . . . . . . . . . . . . 10
Hutzler, et al. Best Current Practice [Page 2] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[2ページ]RFC5068は服従2007年11月にメールします。
1. Introduction
1. 序論
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)から服従として知られているメールSubmissionエージェント(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.
これらの方針の採用だけがスパムと他の望ましくないメールの問題を解決しないことに注意するのは重要です。 しかしながら、これらの方針はオペレータの間で責任と相互運用性の線をはっきりさせるのに役に立つステップを提供します。 これは、虐待者に対して水準を上げるのを助けて、インターネットメールインフラストラクチャに関するユーティリティを保存する追加ツールの基礎を前提とします。
Hutzler, et al. Best Current Practice [Page 3] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[3ページ]RFC5068は服従2007年11月にメールします。
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.
以下に注意してください。 このドキュメントはメールの拒絶の規格などの他の反スパムの操作上の問題を調べません。 作者は、これが追求を引き受けて、奨励するための貴重な努力であるかもしれないことに注意します。
2. Terminology
2. 用語
The Internet email architecture distinguishes four message-handling components:
インターネットメール構造は4つのメッセージハンドリングコンポーネントを区別します:
o Mail User Agents (MUAs)
o メール・ユーザー・エージェント(MUAs)
o Mail Submission Agents (MSAs)
o 服従エージェントに郵送してください。(MSAs)
o Mail Transfer Agents (MTAs)
o メール配達エージェント(MTAs)
o Mail Delivery Agents (MDAs)
o メール配送エージェント(MDAs)
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.
創作終わりに、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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Submission, Relaying, Delivery
3. 服従、リレー、配送
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建築構成は単一の単位であると考えられました。 これはSMTP[RFC2821][RFC0821]と共にMSA、MTA、およびMDA転送をすべて実行させる習慣に反映されました、TCPポート25の上で。 インターネット・メールは、メールが先のアレンジメントなしで送付者認証なしで交換されることを許可します。 すなわち、メッセージの創始者の確認されたアイデンティティは必ずリレーしているMTAsかMDAによって知られているというわけではありません。
Hutzler, et al. Best Current Practice [Page 4] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[4ページ]RFC5068は服従2007年11月にメールします。
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.
MTAリレーに対してMUAからMSAへのメール提案を区別するのはMTAからMDAへの最終的な変遷に対して重要です。 服従はクライアントのユーザとサーバのオペレータとのプレ確立した関係を通常伴います。 等しく、MDAは、最終的な配送を実行していて、それには受取人との既存の関係があることを決定できます。 すなわち、MSAsとMDAsは、彼らの転送活動を抑制するのにユーザとの有の先の関係を利用できます。
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は、配送を実行するためにそれがアレンジメントを全く持っていない受取人にすべてのメールを拒絶するのを選ぶことができます。 本当に、これらの方針の両方が実際には通例の既にあります。
3.1. Best Practices for Submission Operation
3.1. 服従操作のための最も良い習慣
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.
外部の差出がすなわち、サイトの管理ドメインの外から支持されるなら、ドメインのMSAsはSUBMISSIONポート587[RFC4409]を支えなければなりません。 オペレータは両方における、外部のSUBMISSIONポートの上でAND LOCALユーザを標準化するかもしれません。 これは服従操作をかなり簡素化できます。
Submission Port Use:
服従ポート使用:
MUAs SHOULD use the SUBMISSION port for message submission.
MUAs SHOULDはメッセージ提案にSUBMISSIONポートを使用します。
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.
MSAsはSUBMISSIONポートにおけるすべてのメール取引の間に断言されたアイデンティティに認証を実行しなければなりません、地方の管理ドメインの外でリレーされるべきメッセージを引き起こさないRCPT TOアドレスを持っているメッセージのためにさえ。
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 MUSTのオペレータは、認証されたアイデンティティが提出実体とオペレータとの既存の関係に基づいてメールを提出するのが認可されるのを保証します。 この要件はすべてのメール服従メカニズム(MSAへのMUA)に適用されます。
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
服従、メッセージSHOULDの後のa適正な期間に、MSAオペレータはメッセージを送ったユーザの認証されたアイデンティティに起因させてください。 そのようなたどるのはそうです。
Hutzler, et al. Best Current Practice [Page 5] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[5ページ]RFC5068は服従2007年11月にメールします。
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.
ほかの場所に格納された監査データ、またはいかなる他のメカニズムに関するメッセージにもヘッダー(線などを受ける)か他の分野に格納された取引の識別子に基づいて、それは十分なポスト服従責任を支持します。 メッセージ提案の後の特定の長さの時に、追随性が支持されるのはここで指定されません。 しかしながら、トランジットに関する問題は服従の最大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]が服従時間の情報をReceivedヘッダーフィールドに記録する手段を定義することに注意してください。 この情報は、側を受け取っている分析ソフトウェアが送付MSAの責任を確立して、次に、処理に関する決定をメッセージにするのを助けることができます。
3.2. Transitioning to Submission Port
3.2. 服従ポートに移行します。
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.
587を移植するためにポート25から初期のメッセージ提案の変遷を促進するために、MSAsはデフォルトでポート587の上で聴かなければなりません、そして、SHOULDには、他のポートの上で聴く能力があります。 MSAsはポート587の上で認証を必要としなければなりません、そして、SHOULDは服従に使用されるいかなる他のポートの上でも認証を必要とします。 また、MSAsは他のポートの上で聴くかもしれません。 メッセージが受け入れられるポートにかかわらず、MSAsは、非認証されたメッセージが他のドメインにリレーされるのを可能にしてはいけません。 すなわち、それらはオープンリレーであるはずがありません。
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 SHOULDは、代替手段のリストから可能な限り良い服従がポートであることがわかるのを試みます。 SUBMISSIONは置かれた最初のコネがリストであったなら587SHOULDを移植します。 今日利用可能なほとんどのMUAsが、ポートを交替するために後ろへ下がるのを可能にしないので、SHOULDが、あらかじめ構成するか、または彼らのユーザがSUBMISSIONに接続するよう奨励するサイトは587を移植します、サイトがそのポートを支えると仮定して。
4. External Submission
4. 外部の服従
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が多くのインターネットユーザに影響する問題に参加するとき、プロバイダーは、療法に作用すると予想されて、そのような発生を防ぐとしばしば予想されます。
Hutzler, et al. Best Current Practice [Page 6] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[6ページ]RFC5068は服従2007年11月にメールします。
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.
プロバイダーがすべての使用を妨げることになっているいくつかによって使用される先を見越すテクニックはメールのために25SMTPを移植します。送るのが外国行きです、またはホスト以外の地元のSMTPプロキシを通して自動的にこの交通を向け直すために、それは明らかに認可されます。 何人かのユーザにとって、これが問題が多い場合がある、それらのユーザが既に雇用正統の状態で試みるかもしれませんが、彼らの「家」MSAを使用するのを試みる著しく正統の可動のユーザが25ベースの認証を移植します。
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].
このドキュメントは制御するための25か同様の習慣が誤用する標準の匿名の郵便為替ポートのSMTPポートのブロッキングに関して推薦を全く提供しません。 むしろ、それは公式のSUBMISSIONポート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交通のプロキシを含んでいます。 作者は、この話題の別々のドキュメントがメール操作共同体のためになると示唆します。
4.1. Best Practices for Support of External Submissions
4.1. 外部の差出のサポートのための最も良い習慣
Open Submission Port:
服従ポートを開けてください:
Access Providers MUST NOT block users from accessing the external
Internet using the SUBMISSION port 587 [RFC4409].
アクセスProvidersは、SUBMISSIONポート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.
地元の運用環境の外からメールを受け取るとき、サービスプロバイダーが見分けなければならないメールはどこでも記述できる服従関連の認証されたメール(MSA交通)に対して局所領域(MX交通)に記述されたメールを非認証しました。 これで、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
図1は、MSA(MSA)にメッセージを提出しながら、地方のユーザ(MUA.l)について表現します。 また、それはリモート・ユーザー(MUA.r)を示しています、彼らの認証されたポートを通した「家」MSA587取引にメッセージを提出して。()が、「ホットスポット」ワイヤレス・アクセスを提供しながら、喫茶店にあるかもしれません)。 図はMSAのネットワークの中でポート587かポート25を使用する代替手段を示しています。 このドキュメントは使用に関して推薦状を全くしません。
Hutzler, et al. Best Current Practice [Page 7] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[7ページ]RFC5068は服従2007年11月にメールします。
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.
服従のためのポート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
ホームネットワークの目的地+-------+ | MUA.l| +---+---+ ポート| ポートポートポート587/25V25 25-------- 25 +-----+ +-----+ ****** / \ ****** +-----+ +-----+ | MSA|、-、>| MTA|->* AP*>| |->* AP*>| MTA|、-、>| MDA| +--^--+ +-----+ ****** | インターネット| ****** +-----+ +-----+ | | | +-------<、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、--+ | \ | / ---^---- | ****** APはアクセスプロバイダ*AP*******と等しいです。| ポート587+---+----+ | MUA.r| +--------+ ホットスポット
Figure 1: Example of Port 587 Usage via Internet
図1: インターネットを通したPort587Usageに関する例
5. Message Submission Authentication/Authorization Technologies
5. メッセージ服従認証/認可技術
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]を含んでいます。 環境によって、異なったメカニズムは、多少有効であって、便利である場合があります。 また、メカニズムは、互いと組み合わせて安全なシステムを作るのに使用されなければならないかもしれません。 組織SHOULDは実用的な最も安全なアプローチを選びます。
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.
このドキュメントは特定のセキュリティ実現のときに推薦を提供しません。 それは単に、これが攻撃者がこの交通の聞こうとして、アカウント・データを盗むことができて不安定なネットワークSHOULDの上のクリアテキストのユーザ信任状を伝えるのがすべてのシナリオで避けられるという警告を提供します。 これらの場合では、強く適切なセキュリティー技術を使用しなければならないことが提案されます。
Hutzler, et al. Best Current Practice [Page 8] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[8ページ]RFC5068は服従2007年11月にメールします。
6. Security Considerations
6. セキュリティ問題
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.
受取人のシステムを攻撃するように設計された悪意がある内容を含んでいて、独立している政権の間のメール転送は、迷惑メールの大きいボリュームの源であり、メールされることができます。 このドキュメントは、悪意があるメールが伝えられるという見込みを減少させている間、そのような交換を可能にするために要件と手順を記述します。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006.
[RFC4409] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
7.2. Informative References
7.2. 有益な参照
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC0821] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[RFC3207]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC3848] Newman, C., "ESMTP and LMTP Transmission Types
Registration", RFC 3848, July 2005.
[RFC3848] ニューマン、C.、「ESMTPとLMTPトランスミッションは登録をタイプする」RFC3848、2005年7月。
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954, July 2007.
エド[RFC4954]Siemborski、R.、A.メリニコフ、エド、「認証のためのSMTPサービス拡張子」、RFC4954、7月2007日
Hutzler, et al. Best Current Practice [Page 9] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[9ページ]RFC5068は服従2007年11月にメールします。
Appendix A. Acknowledgments
付録A.承認
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).
これらの推薦は最初に、四角ばらない意見の交換の間、Anti-スパムTechnical Alliance(アスタ)のメンバーと何人かの関係者の中でインターネットResearch Task ForceのAnti-スパムResearch Group(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。 オールマン、L.H.Aestrand、N.Borenstein、S.Bortzmeyer、K.Chon、R.クレイトン、B.コール、W.Dnes、V.Duchovni、E.エーデルスタイン、F.Ellermann、M.エルビ、J.D.フォーク、解放されたN.J.Glube、A.ハーズバーグ、J.Klensin、J.レヴィン、S.Moonesamy、K.ムーア、R.ネルソン、C.ニューマン、C.オマリー、S.Ramasubramanian、R.Rognlie、J.通りSauver、W.Schlitt、B.Shein(B.サリバン)。
Authors' Addresses
作者のアドレス
Carl Hutzler 2512 Freetown Drive Reston, VA 20191
カールHutzler2512フリータウンDriveレストン、ヴァージニア 20191
Phone: 703-915-6862 EMail: cdhutzler@aol.com URI: http://carlhutzler.com/blog/
以下に電話をしてください。 703-915-6862 メールしてください: cdhutzler@aol.com ユリ: http://carlhutzler.com/blog/
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
デーヴ医者ブランデンブルクインターネットワーキング675はサニーベルカリフォルニア94086博士(米国)を小綺麗にします。
Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net URI: http://bbiw.net
以下に電話をしてください。 +1.408 .246 .8253 メール: dcrocker@bbiw.net ユリ: http://bbiw.net
Peter Resnick QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-1714 USA
ピーター・レズニック・クアルコムの法人組織の5775モアハウス・Driveカリフォルニア92121-1714サンディエゴ(米国)
Phone: +1 858 651 4478 EMail: presnick@qualcomm.com URI: http://www.qualcomm.com/~presnick/
以下に電話をしてください。 +1 4478年の858 651メール: presnick@qualcomm.com ユリ: http://www.qualcomm.com/~presnick/
Hutzler, et al. Best Current Practice [Page 10] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[10ページ]RFC5068は服従2007年11月にメールします。
Eric Allman Sendmail, Inc. 6745 Christie Ave., Suite 350 Emeryville, CA USA
エリックオールマンセンドメールInc.6745クリスティAve、Suite350カリフォルニアエマリービル(米国)
Phone: +1 510 594 5501 EMail: eric+ietf-smtp@sendmail.org
以下に電話をしてください。 +1 5501年の510 594メール: eric+ ietf-smtp@sendmail.org
Tony Finch University of Cambridge Computing Service New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND
新しいケンブリッジのSiteペンブルック通りケンブリッジCB2 3QH Computing Service Museumsイギリスのトニーフィンチ大学
Phone: +44 797 040 1426 EMail: dot@dotat.at URI: http://dotat.at/
以下に電話をしてください。 +44 1426年の797 040メール: dot@dotat.at ユリ: http://dotat.at/
Hutzler, et al. Best Current Practice [Page 11] RFC 5068 Email Submission November 2007
Hutzler、他 最も良い現在の習慣[11ページ]RFC5068は服従2007年11月にメールします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Hutzler, et al. Best Current Practice [Page 12]
Hutzler、他 最も良い現在の習慣[12ページ]
一覧
スポンサーリンク
