RFC4409 日本語訳
4409 Message Submission for Mail. R. Gellens, J. Klensin. April 2006. (Format: TXT=34911 bytes) (Obsoletes RFC2476) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 4409 QUALCOMM Obsoletes: 2476 J. Klensin Category: Standards Track April 2006
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4409 クアルコムは以下を時代遅れにします。 2476年のJ.Klensinカテゴリ: 標準化過程2006年4月
Message Submission for Mail
メールのためのメッセージ提案
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo splits message submission from message relay, allowing each service to operate according to its own rules (for security, policy, etc.), and specifies what actions are to be taken by a submission server.
このメモは、それ自身の規則に従って各サービスが作動するのを許容して(セキュリティ、方針などのために)、メッセージリレーからメッセージ提案を分けて、どんな動作が服従サーバによって取られるかことであるかと指定します。
Message relay and final delivery are unaffected, and continue to use SMTP over port 25.
メッセージリレーと最終的な配送は、影響を受けなく、ポート25の上でSMTPを使用し続けています。
When conforming to this document, message submission uses the protocol specified here, normally over port 587.
このドキュメントに従うとき、メッセージ提案は通常ポート587の上でここで指定されたプロトコルを使用します。
This separation of function offers a number of benefits, including the ability to apply specific security or policy requirements.
機能のこの分離は特定のセキュリティか方針要件を適用する能力を含む多くの利益を提供します。
Gellens & Klensin Standards Track [Page 1] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
2. Document Information ............................................4
2.1. Definitions of Terms Used in This Memo .....................4
2.2. Conventions Used in This Document ..........................5
3. Message Submission ..............................................5
3.1. Submission Identification ..................................5
3.2. Message Rejection and Bouncing .............................5
3.3. Authorized Submission ......................................6
4. Mandatory Actions ...............................................7
4.1. General Submission Rejection Code ..........................7
4.2. Ensure All Domains Are Fully-Qualified .....................7
4.3. Require Authentication .....................................8
5. Recommended Actions .............................................8
5.1. Enforce Address Syntax .....................................8
5.2. Log Errors .................................................8
6. Optional Actions ................................................9
6.1. Enforce Submission Rights ..................................9
6.2. Enforce Permissions ........................................9
6.3. Check Message Data .........................................9
6.4. Support for the Postmaster Address .........................9
7. Interaction with SMTP Extensions ...............................10
8. Message Modifications ..........................................11
8.1. Add 'Sender' ..............................................11
8.2. Add 'Date' ................................................11
8.3. Add 'Message-ID' ..........................................11
8.4. Transfer Encode ...........................................11
8.5. Sign the Message ..........................................11
8.6. Encrypt the Message .......................................12
8.7. Resolve Aliases ...........................................12
8.8. Header Rewriting ..........................................12
9. Security Considerations ........................................12
10. IANA Considerations ...........................................13
11. Acknowledgements ..............................................13
12. Normative References ..........................................14
13. Informative References ........................................14
1. 序論…3 2. 情報を記録してください…4 2.1. このメモで使用される用語の定義…4 2.2. このドキュメントで中古のコンベンション…5 3. メッセージ提案…5 3.1. 服従識別…5 3.2. メッセージ拒絶であって弾むこと…5 3.3. 服従を認可します…6 4. 義務的な動作…7 4.1. 一般服従拒絶コード…7 4.2. すべてのドメインが確実に完全に適切になるようにしてください…7 4.3. 認証を必要としてください…8 5. お勧めの動作…8 5.1. アドレス構文を実施してください…8 5.2. 誤りを登録してください…8 6. 任意の動作…9 6.1. 服従権利を実施してください…9 6.2. 許容を実施してください…9 6.3. メッセージデータをチェックしてください…9 6.4. 郵便局長には、アドレスをサポートしてください…9 7. SMTP拡張子との相互作用…10 8. メッセージ変更…11 8.1. '送付者'を加えてください…11 8.2. 'デートしてください'と言い足してください…11 8.3. 'Message ID'を加えてください…11 8.4. エンコードを移してください…11 8.5. メッセージに署名してください…11 8.6. メッセージを暗号化してください…12 8.7. 別名を決議してください…12 8.8. ヘッダーの書き直し…12 9. セキュリティ問題…12 10. IANA問題…13 11. 承認…13 12. 標準の参照…14 13. 有益な参照…14
Gellens & Klensin Standards Track [Page 2] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[2ページ]。
1. Introduction
1. 序論
SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages.
SMTPはメッセージ*転送*プロトコル(すなわち、終わっている(完全な)メッセージを発送して(必要であるなら)、提供する手段)と定義されました。
Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA].
メッセージTransferエージェント(MTAs)はメッセージ・テキストを変更するべきではありません、必要に応じて[SMTP-MTA]で'受け取られていてい'て、'リターン経路'の、そして、他のヘッダーフィールドを加えるのを除いて。
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
しかしながら、また、SMTPは現在、メッセージ*服従*プロトコル(すなわち、Message Userエージェント(MUAs)がMTAルーティングネットワークに新しいメッセージを取り入れる手段)として広く使用されます。 MUAsからメッセージ差出を受け入れるプロセスはMessage Submissionエージェント(MSA)と呼ばれます。
In order to permit unconstrained communications, SMTP is not often authenticated during message relay.
自由なコミュニケーションを可能にするために、SMTPはメッセージリレーの間、しばしば認証されるというわけではありません。
Authentication and authorization of initial submissions have become increasingly important, driven by changes in security requirements and rising expectations that submission servers take responsibility for the message traffic they originate.
初期の差出の認証と承認はますます重要になって、セキュリティ要件における変化でやる気満々の、そして、上昇している期待はサーバがそれらが溯源するメッセージトラフィックに責任を取るというその服従です。
For example, due to the prevalence of machines that have worms, viruses, or other malicious software that generate large amounts of spam, many sites now prohibit outbound traffic on the standard SMTP port (port 25), funneling all mail submissions through submission servers.
例えば、多量のスパムを生成するワームを持っているマシンの普及、ウイルス、または他の悪意があるソフトウェアのため、多くのサイトが現在標準のSMTPポートの上でアウトバウンドトラフィックを禁止します(25を移植してください)、服従サーバを通したすべてのメール差出を注いで。
In addition to authentication and authorization issues, messages being submitted are in some cases finished (complete) messages, and in other cases are unfinished (incomplete) in one or more aspects. Unfinished messages may need to be completed to ensure they conform to [MESSAGE-FORMAT], and later requirements. For example, the message may lack a proper 'Date' header field, and domains might not be fully qualified. In some cases, the MUA may be unable to generate finished messages (e.g., it might not know its time zone). Even when submitted messages are complete, local site policy may dictate that the message text be examined or modified in some way, e.g., to conceal local name or address spaces. Such completions or modifications have been shown to cause harm when performed by downstream MTAs -- that is, MTAs after the first-hop submission MTA -- and are in general considered to be outside the province of standardized MTA functionality.
認証と承認問題に加えて、提出されるメッセージは、いくつかの場合終わっている(完全な)メッセージであり、1つ以上の局面で他の場合で未完成です(不完全な)。 未完成のメッセージは、それらが[MESSAGE-FORMAT]、および後の要件に従うのを保証するために完成される必要があるかもしれません。 例えば、メッセージは適切な'日付'ヘッダーフィールドを欠くかもしれません、そして、ドメインは完全に資格があるかもしれないというわけではありません。 いくつかの場合、MUAは終わっているメッセージを生成することができないかもしれません(例えば、それは時間帯を知らないかもしれません)。 提出されたメッセージが完全であるときにさえ、ローカル・サイト方針は、メッセージ・テキストが例えば地方名かアドレス空間を隠すように何らかの方法で調べられるか、または変更されると決めるかもしれません。 そのような落成か変更が、川下のMTAs(すなわち、最初に、ホップ服従MTAの後のMTAs)によって実行されると害を引き起こすために示されて、一般に、標準化されたMTAの機能性の州の外にあると考えられました。
Separating messages into submissions and transfers allows developers and network administrators to more easily do the following:
差出と転送にメッセージを切り離すのに、開発者とネットワーク管理者は、より容易に以下ができます:
Gellens & Klensin Standards Track [Page 3] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[3ページ]。
* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail
* 求められていない料金別納郵便の権限のないメールリレーか注射に対して安全保障政策と警備を実装してください。
* Implement authenticated submission, including off-site submission
by authorized users such as travelers
* 旅行者などの認定ユーザによるオフサイト服従を含む認証された服従を実装してください。
* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for different
programs for relay and submission
* 関連ソフトウェアコード差を切り離してください、その結果、それぞれのコードベースをより簡単にして、リレーと服従のための異なったプログラムを考慮して
* Detect configuration problems with a site's mail clients
* サイトのメールクライアントに関する設定問題を検出してください。
* Provide a basis for adding enhanced submission services in the
future
* 将来高められた服従サービスを加える基礎を提供してください。
This memo describes a low-cost, deterministic means for messages to be identified as submissions, and specifies what actions are to be taken by a submission server.
このメモは、差出として特定されるべきメッセージのために安価の、そして、決定論的な手段を説明して、どんな動作が服従サーバによって取られるかことであるかと指定します。
2. Document Information
2. 文書情報
2.1. Definitions of Terms Used in This Memo
2.1. このメモで使用される用語の定義
Many of the concepts and terms used in this document are defined in [SMTP-MTA]; familiarity with those documents is assumed here.
本書では使用される概念と用語の多くが[SMTP-MTA]で定義されます。 それらのドキュメントへの親しみはここで想定されます。
Fully-Qualified
完全に資格を得ます。
Containing or consisting of a domain that can be globally resolved using the Domain Name Service; that is, not a local alias or partial specification.
Domain Name Serviceを使用することでグローバルに決議できるドメインから含んでいるか、または成ります。 すなわち、ローカルの別名でない部分的な仕様でない。
Message Submission Agent (MSA)
メッセージ服従エージェント(MSA)
A process that conforms to this specification. An MSA acts as a submission server to accept messages from MUAs, and either delivers them or acts as an SMTP client to relay them to an MTA.
この仕様に従うプロセス。 MSAは、MTAに彼らをリレーするためにSMTPクライアントとしてMUAsからメッセージを受け入れるために服従サーバとして機能して、彼らを提供するか、または機能します。
Message Transfer Agent (MTA)
メッセージ転送エージェント(MTA)
A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server to accept messages from an MSA or another MTA, and either delivers them or acts as an SMTP client to relay them to another MTA.
[SMTP-MTA]に従うプロセス。 MTAは、別のMTAにそれらをリレーするためにSMTPクライアントとしてMSAか別のMTAからメッセージを受け入れるためにSMTPサーバーとして機能して、それらを提供するか、または機能します。
Gellens & Klensin Standards Track [Page 4] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[4ページ]。
Message User Agent (MUA)
メッセージユーザエージェント(MUA)
A process that acts (often on behalf of a user and with a user interface) to compose and submit new messages, and process delivered messages.
新しいメッセージを構成して、提出するために行動する(しばしばユーザを代表したユーザーインタフェースで)プロセス、およびメッセージが提供されたプロセス。
For delivered messages, the receiving MUA may obtain and process the message according to local conventions or, in what is commonly referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, whereas the protocol defined here (or SMTP) is used to submit messages.
提供されたメッセージに関しては、地方のコンベンションによると、受信MUAがメッセージを得て、処理するかもしれませんか、一般的に分裂-MUAモデルと呼ばれることにポストオフィスプロトコル[POP3]かIMAP[IMAP4]がメッセージが提供されたアクセスに使用されますが、またはここで定義されたプロトコル(または、SMTP)は、メッセージを提出するのに使用されます。
2.2. Conventions Used in This Document
2.2. 本書では使用されるコンベンション
In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only.
例で「C:」 そして、クライアントによって送られた系列を示すのに使用される、「S:」 ものはサーバで発信しました。コマンドの例の中のラインブレイクが編集の目的だけのためのものであることを示します。
Examples use the 'example.net' domain.
例は'example.net'ドメインを使用します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は中[キーワード]で定義されるように本書では解釈されることになっているべきです。
3. Message Submission
3. メッセージ提案
3.1. Submission Identification
3.1. 服従識別
Port 587 is reserved for email message submission as specified in this document. Messages received on this port are defined to be submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions or allowances as specified here.
ポート587はこのドキュメントにおける指定されるとしてのメールメッセージ提案のために予約されます。 このポートの上に受け取られたメッセージは、差出になるように定義されます。 使用されるプロトコルがそうである、ESMTP、[SMTP-MTA、ESMTP]、ここで指定されるとしての追加制限か小遣いで。
Although most email clients and servers can be configured to use port 587 instead of 25, there are cases where this is not possible or convenient. A site MAY choose to use port 25 for message submission, by designating some hosts to be MSAs and others to be MTAs.
25の代わりにポート587を使用するためにほとんどのメールクライアントとサーバを構成できますが、ケースがこれが可能でもなくて、また便利でもないところにあります。 サイトは、MTAsになるようにメッセージ提案にMSAsと他のものになるように何人かのホストを任命することによってポート25を使用するのを選ぶかもしれません。
3.2. Message Rejection and Bouncing
3.2. メッセージ拒絶と弾み
MTAs and MSAs MAY implement message rejection rules that rely in part on whether the message is a submission or a relay.
MTAsとMSAsは、メッセージ拒絶がメッセージが服従であるか、そして、リレーに一部依存する規則であると実装するかもしれません。
For example, some sites might configure their MTAs to reject all RCPT commands for messages that do not reference local users, and configure their MSA to reject all message submissions that do not come from authorized users, with authorization based either on authenticated identity or the submitting endpoint being within a protected IP environment.
例えば、いくつかのサイトが、地元のユーザを参照でないのにするメッセージのためのすべてのRCPTコマンドを拒絶するためにそれらのMTAsを構成して、認定ユーザから来ないすべてのメッセージ差出を拒絶するために彼らのMSAを構成するかもしれません、承認が保護されたIP環境の中にある認証されたアイデンティティか提出している終点に基づいていて。
Gellens & Klensin Standards Track [Page 5] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[5ページ]。
NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that are correctable by the MUA, for example, an invalid 'From' field.
以下に注意してください。 破損しているものを送る危険を冒すよりメッセージを拒絶するのは良いです。 MUAで修正可能な問題、例えば、無効の'From'分野に、これは特に本当です。
If an MSA is not able to determine a return path to the submitting user, from a valid MAIL FROM, a valid source IP address, or based on authenticated identity, then the MSA SHOULD immediately reject the message. A message can be immediately rejected by returning a 550 code to the MAIL command.
MSAがリターンパスを有効なMAIL FROM、有効なソースIPアドレスから提出しているユーザに決定できないで、認証されたアイデンティティに基づかないなら、MSA SHOULDはすぐに、メッセージを拒絶します。 すぐに、550コードをメールコマンドに返すことによって、メッセージを拒絶できます。
Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST NOT in itself be cause for rejecting a message. (MUAs need to generate null return-path messages for a variety of reasons, including disposition notifications.)
ヌルリターンパス(すなわち、メールFROM:<>)が受入れられて、本来メッセージを拒絶する原因であるはずがないことに注意してください。 (気質通知を含んで、MUAsは、さまざまな理由でヌルリターンパスメッセージを生成する必要があります。)
Except in the case where the MSA is unable to determine a valid return path for the message being submitted, text in this specification that instructs an MSA to issue a rejection code MAY be complied with by accepting the message and subsequently generating a bounce message. (That is, if the MSA is going to reject a message for any reason except being unable to determine a return path, it can optionally do an immediate rejection or accept the message and then mail a bounce.)
MSAが提出されるメッセージのために有効なリターンパスを決定できないケースの中を除いて、メッセージを受け入れて、次に弾みのメッセージを生成することによって、拒絶コードを発行するようMSAに命令するこの仕様によるテキストは従われるかもしれません。 (すなわち、MSAがリターンパスを決定できないのを除いたどんな理由でもメッセージを拒絶するなら、それは、任意に即座の拒絶をするか、メッセージを受け入れて、または次に、弾みを郵送できます。)
NOTE: In the normal case of message submission, immediately rejecting the message is preferred, as it gives the user and MUA direct feedback. To properly handle delayed bounces, the client MUA needs to maintain a queue of messages it has submitted, and match bounces to them. Note that many contemporary MUAs do not have this capability.
以下に注意してください。 メッセージ提案の正常な場合では、すぐにメッセージを拒絶するのは好まれます、ダイレクトフィードバックをユーザとMUAに与えるとき。 適切に遅れた弾みを扱うために、クライアントMUAはそれが提出したメッセージの待ち行列を維持して、それらへの弾みを合わせる必要があります。 多くの現代のMUAsにはこの能力がないことに注意してください。
3.3. Authorized Submission
3.3. 認可された服従
Numerous methods have been used to ensure that only authorized users are able to submit messages. These methods include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication.
多数のメソッドは、認定ユーザだけがメッセージを提出できるのを保証するのに使用されました。 これらのメソッドは認証されたSMTP、IPアドレス制限、安全なIP、他のトンネル、および先のPOP認証を含んでいます。
Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It allows the MSA to determine an authorization identity for the message submission, one that is not tied to other protocols.
認証されたSMTP[SMTP-AUTH]は広範囲の展開を見ました。 それで、MSAはメッセージ提案(他のプロトコルに結ばれないもの)のために承認のアイデンティティを決定できます。
IP address restrictions are very widely implemented, but do not allow for travelers and similar situations, and can be easily spoofed unless all transport paths between the MUA and MSA are trustworthy.
IPアドレス制限は非常に広く実装されます、旅行者と同様の状況を考慮しないで、MUAとMSAの間のすべての輸送経路が信頼できるというわけではないなら容易に偽造することができるのを除いて。
Gellens & Klensin Standards Track [Page 6] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[6ページ]。
Secure IP [IPSEC], and other encrypted and authenticated tunneling techniques, can also be used and provide additional benefits of protection against eavesdropping and traffic analysis.
安全なIP[IPSEC]、および他の暗号化されて認証されたトンネリングのテクニックは、盗聴とトラヒック分析に対してまた、使用されて、保護の付加的な利益を提供できます。
Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (e.g., 20 minutes) prior to the start of a message submission session has also been used, but this does impose restrictions on clients as well as servers, which may cause difficulties. Specifically, the client must do a POP authentication before an SMTP submission session, and not all clients are capable and configured for this. Also, the MSA must coordinate with the POP server, which may be difficult. There is also a window during which an unauthorized user can submit messages and appear to be a previously authorized user. Since it is dependent on the MUA's IP addresses, this technique is substantially as subject to IP address spoofing as validation based on known IP addresses alone (see above).
また、メッセージ服従セッションの始まりの(例えば、20分)前にいつかの時間以内にPOP[POP3]認証(同じIPアドレスからの)を必要とするのは使用されましたが、これはサーバと同様にクライアントに制限を課します。サーバは困難を引き起こすかもしれません。 明確に、すべてのクライアントではなく、SMTP服従セッションができるのとこれのために構成するようになる前にクライアントはPOP認証をしなければなりません。 また、MSAはPOPサーバで調整しなければなりません。(それは、難しいかもしれません)。 また、権限のないユーザがメッセージを提出して、以前に認可されたユーザであるように見えることができる窓があります。 それがMUAのIPアドレスに依存しているので、このテクニックは合法化が知られているIPアドレスに単独で基づかせたのとIPを実質的同じくらい受けることがあるアドレススプーフィング(上を見る)です。
4. Mandatory Actions
4. 義務的な動作
An MSA MUST do all of the following:
MSA MUSTは以下のすべてをします:
4.1. General Submission Rejection Code
4.1. 一般服従拒絶コード
Unless covered by a more precise response code, response code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains something improper.
より正確な応答コードでカバーされない場合、応答コード554は不適当な何かを含むメール、RCPT、またはDATAコマンドを拒絶するのに使用されることです。
4.2. Ensure All Domains Are Fully-Qualified
4.2. すべてのドメインが確実に完全に適切になるようにしてください。
The MSA MUST ensure that all domains in the SMTP envelope are fully- qualified.
MSA MUSTは、SMTP封筒のすべてのドメインが完全に資格があるのを確実にします。
If the MSA examines or alters the message text in any way, except to add trace header fields [SMTP-MTA], it MUST ensure that all domains in address header fields are fully-qualified.
MSAが何らかの方法でメッセージ・テキストを調べるか、または変更するなら、跡のヘッダーフィールド[SMTP-MTA]を加えるのを除いて、それはアドレスヘッダーフィールドにおけるすべてのドメインが確実に完全に適切になるようにしなければなりません。
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command that contains improper domain references.
回答コード554は不適当なドメイン参照を含むメール、RCPT、またはDATAコマンドを拒絶するのに使用されることです。
A frequent local convention is to accept single-level domains (e.g., 'sales') and then to expand the reference by adding the remaining portion of the domain name (e.g., to 'sales.example.net'). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), since such expansion is particularly risky.
頻繁な地方のコンベンションは、ただ一つのレベルドメイン(例えば、'販売')を受け入れて、そして、ドメイン名(例えば、'sales.example.net'への)の残存部分を加えることによって、参照を広げることになっています。 ただ一つのレベルドメインSHOULDを可能にする地方のコンベンションが広げるよりむしろ、不完全なマルチレベルドメイン(例えば、'squeaky.sales')を拒絶します、そのような拡張が特に危険であるので。
Gellens & Klensin Standards Track [Page 7] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[7ページ]。
4.3. Require Authentication
4.3. 認証を必要としてください。
The MSA MUST by default issue an error response to the MAIL command if the session has not been authenticated using [SMTP-AUTH], unless it has already independently established authentication or authorization (such as being within a protected subnetwork).
セッションが[SMTP-AUTH]を使用することで認証されていないなら、MSA MUSTはデフォルトでメールコマンドへの誤り応答を発行します、既に、独自に、認証か承認(保護されたサブネットワークの中にあることなどの)を確立していない場合。
Section 3.3 discusses authentication mechanisms.
セクション3.3は認証機構について論じます。
Reply code 530 [SMTP-AUTH] is used for this purpose.
回答コード530[SMTP-AUTH]はこのために使用されます。
5. Recommended Actions
5. お勧めの動作
The MSA SHOULD do all of the following:
MSA SHOULDは以下のすべてをします:
5.1. Enforce Address Syntax
5.1. アドレス構文を実施してください。
An MSA SHOULD reject messages with illegal syntax in a sender or recipient SMTP envelope address.
不法な構文が送付者か受取人SMTP封筒にあるメッセージが扱うMSA SHOULD廃棄物。
If the MSA examines or alters the message text in way, except to add trace header fields, it SHOULD reject messages with illegal address syntax in address header fields.
MSAが方法でメッセージ・テキストを調べるか、または変更する加えるのを除いて、ヘッダーフィールドをたどってください、それ。SHOULDはアドレスヘッダーフィールドにおける不法なアドレス構文でメッセージを拒絶します。
Reply code 501 is to be used to reject a MAIL or RCPT command that contains a detectably improper address.
回答コード501はdetectablyに不適当なアドレスを含むメールかRCPTコマンドを拒絶するのに使用されることです。
When addresses are resolved after submission of the message body, reply code 554 (with a suitable enhanced status code from [SMTP-CODES]) is used after end-of-data, if the message contains invalid addresses in the header.
アドレスがデータの終わり以降メッセージ本体の服従の後に決議されているとき、回答コード554([SMTP-CODES]からの適当な高められたステータスコードがある)は使用されます、メッセージがヘッダーに無効のアドレスを含んでいるなら。
5.2. Log Errors
5.2. ログ誤り
The MSA SHOULD log message errors, especially apparent misconfigurations of client software.
MSA SHOULDはメッセージ誤り、クライアントソフトウェアの特に見かけのmisconfigurationsを登録します。
It can be very helpful to notify the administrator when problems are detected with local mail clients. This is another advantage of distinguishing submission from relay: system administrators might be interested in local configuration problems, but not in client problems at other sites.
問題が地元のメールクライアントと共に検出されるとき、管理者に通知するのは非常に役立っている場合があります。 これはリレーと服従を区別する別の利点です: システム管理者は、他のサイトでローカルの設定問題に関心がありますが、クライアント問題では興味を持たないかもしれません。
Note that it is important to impose limits on such logging to prevent certain forms of denial of service (DoS) attacks.
ある形式のサービス(DoS)攻撃の否定を防ぐためにそのような伐採に限界を課すのが重要であることに注意してください。
Gellens & Klensin Standards Track [Page 8] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[8ページ]。
6. Optional Actions
6. 任意の動作
The MSA MAY do any of the following:
MSA MAYは以下のどれかをします:
6.1. Enforce Submission Rights
6.1. 服従権利を実施してください。
The MSA MAY issue an error response to a MAIL command if the address in MAIL FROM appears to have insufficient submission rights, or is not authorized with the authentication used (if the session has been authenticated).
MAIL FROMのアドレスが不十分な服従権利を持っているように見えるか、または認証が使用されている状態で認可されないなら(セッションが認証されたなら)、MSA MAYはメールコマンドへの誤り応答を発行します。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
回答は、適切な高められたステータスコードがある[SMTP-CODES]、5.7としてのそのようなものあたり550に.1をコード化して、このために使用されます。
6.2. Enforce Permissions
6.2. 許容を実施してください。
The MSA MAY issue an error response to a RCPT command if inconsistent with the permissions given to the user (if the session has been authenticated).
ユーザに与える許容に矛盾しているなら(セッションが認証されたなら)、MSA MAYはRCPTコマンドへの誤り応答を発行します。
Reply code 550 with an appropriate enhanced status code per [SMTP-CODES], such as 5.7.1, is used for this purpose.
回答は、適切な高められたステータスコードがある[SMTP-CODES]、5.7としてのそのようなものあたり550に.1をコード化して、このために使用されます。
6.3. Check Message Data
6.3. メッセージデータをチェックしてください。
The MSA MAY issue an error response to the DATA command or send a failure result after end-of-data if the submitted message is syntactically invalid, or seems inconsistent with permissions given to the user (if known), or violates site policy in some way.
提出されたメッセージがシンタクス上無効であるか、ユーザ(知られているなら)に与える許容に矛盾しているように見えるか、または何らかの方法でサイト方針に違反するなら、MSA MAYはDATAコマンドへの誤り応答を発行するか、またはデータの終わりの後に失敗結果を送ります。
Reply code 554 is used for syntactic problems in the data. Reply code 501 is used if the command itself is not syntactically valid. Reply code 550 with an appropriate enhanced status code per [SMTP-CODES] (such as 5.7.1) is used to reject based on the submitting user. Reply code 550 with an appropriate enhanced status code (such as 5.7.0) is used if the message violates site policy.
回答コード554はデータの構文の問題に使用されます。 コマンド自体がシンタクス上有効でないなら、回答コード501は使用されています。 回答は[SMTP-CODES]あたり1つの適切な高められたステータスコードで550をコード化します。(.1が)拒絶するのにおいて5.7に使用されているので、そのようなものは提出ユーザを基礎づけました。 回答は適切な高められたステータスコードで550をコード化します。(.0が)メッセージであるなら5.7に使用されているので、そのようなものはサイト方針に違反します。
6.4. Support for the Postmaster Address
6.4. 郵便局長アドレスのサポート
If appropriate under local conditions and to facilitate conformance with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit a reduced degree of authentication for mail addressed to the "postmaster" (or one of its alternate spelling forms, see [SMTP-MTA]), in one or more domains, as compared to requirements enforced for other addresses. Among other benefits, this provides an address of last resort that can be used by authorized users to report problems that otherwise prevent them from submitting mail.
地方の下で状態を当ててください。そうすれば、MSA MAYが[SMTP-MTA]の「郵便局長」要件で順応を容易にするために「郵便局長」に扱われたメールのための減少している度合いの認証を可能にする([SMTP-MTA]は、代替のスペルの1つが形成されるのを見ます)1つ以上のドメイン他のアドレスのために励行される要件と比べて。 諸手当では、これは認定ユーザがそうでなければそれらがメールを提出するのを防ぐ問題を報告するのに使用できる切り札のアドレスを提供します。
Gellens & Klensin Standards Track [Page 9] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[9ページ]。
7. Interaction with SMTP Extensions
7. SMTP拡張子との相互作用
The following table lists the current standards-track and Experimental SMTP extensions. Listed are the EHLO keyword, name, an indication as to the use of the extension on the submit port, and a reference:
以下のテーブルは現在の標準化過程とExperimental SMTP拡張子を記載します。 記載されていて、EHLOキーワード、名前、拡張子の使用に関する指示が進行中、ポート、および参照を提出してください:
Keyword Name Submission Reference ---------- -------------------------- ---------- ---------------- PIPELINING Pipelining SHOULD [PIPELINING] ENHANCEDSTATUSCODES Enhanced Status Codes SHOULD [CODES-EXTENSION] ETRN Extended Turn MUST NOT [ETRN] ... Extended Codes SHOULD [SMTP-CODES] DSN Delivery Status Notification SHOULD [DSN] SIZE Message size MAY [SIZE] ... 521 reply code MUST NOT [521REPLY] CHECKPOINT Checkpoint/Restart MAY [CHECKPOINT] BINARYMIME Binary MIME MAY [CHUNKING] CHUNKING Chunking MAY [CHUNKING] 8BITMIME Use 8-bit data SHOULD [8BITMIME] AUTH Authentication MUST [SMTP-AUTH] STARTTLS Start TLS MAY [Start-TLS] NO-SOLICITING Notification of no soliciting MAY [Msg-Track] MTRK Message Tracking MAY [Msg-Track]
キーワード名前服従参照---------- -------------------------- ---------- ---------------- パイプライン処理パイプライン処理は広げられた[拡大をコード化します]のETRNがターンするなら高められた状態がコード化するENHANCEDSTATUSCODESがそうしてはいけない[パイプライン処理][ETRN]がそうするべきです。 拡張Codes SHOULD[SMTP-CODES]DSN Delivery Status Notification SHOULD[DSN]SIZE Messageサイズは[SIZE]がそうするかもしれません。 [521REPLY]CHECKPOINT Checkpoint/ではなく、コードがそうしなければならない521回答が5月[エムエスジー道]のMTRK Message Tracking5月に請求しないSHOULD[8BITMIME]AUTH Authenticationがそうしなければならない5月[CHECKPOINT]のBINARYMIME Binary MIME5月[CHUNKING]のCHUNKING Chunking5月[CHUNKING]の8BITMIME Useの8ビットのデータ[SMTP-AUTH]STARTTLS Start TLS5月[始め-TLS]のSOLICITING Notificationを全く再開しません。[エムエスジー道]
Future SMTP extensions SHOULD explicitly specify if they are valid on the Submission port.
将来のSMTP拡大SHOULDは、それらがSubmissionポートで有効であるかどうか明らかに指定します。
Some SMTP extensions are especially useful for message submission:
いくつかのSMTP拡張子が特にメッセージ提案の役に立ちます:
Extended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION]. This permits the MSA to notify the client of specific configuration or other problems in more detail than the response codes listed in this memo. Because some rejections are related to a site's security policy, care should be used not to expose more detail to unauthenticated senders than is needed
[CODES-EXTENSION]に従って、サポートされて、使用される拡張Status Codes[SMTP-CODES]SHOULD。 これは、MSAが特定の構成かさらに詳細に応答コードがこのメモに記載したこと以外の問題についてクライアントに通知することを許可します。 いくつかの拒絶がサイトの安全保障政策に関連するので、注意は非認証された送付者にその他の詳細を暴露しないように必要とされるより働くべきです。
[PIPELINING] SHOULD be supported by the MSA.
[PIPELINING]SHOULD、MSAによってサポートされてください。
[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user and MUST be supported by the MSA.
[SMTP-AUTH]をMSAが権威を有効にして、提出しているユーザのアイデンティティを決定するのを許容して、MSAはサポートしなければなりません。
Any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING].
また、このメモにおけるDATAコマンドのどんな参照もDATAのどんな代用品についても言及します、[CHUNKING]と共に使用されるBDATコマンドなどのように。
Gellens & Klensin Standards Track [Page 10] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[10ページ]。
8. Message Modifications
8. メッセージ変更
Sites MAY modify submissions to ensure compliance with standards and site policy. This section describes a number of such modifications that are often considered useful.
サイトは、規格とサイト方針へのコンプライアンスを確実にするように差出を変更するかもしれません。 このセクションは役に立つとしばしば考えられるそのような多くの変更について説明します。
NOTE: As a matter of guidance for local decisions to implement message modification, a paramount rule is to limit such actions to remedies for specific problems that have clear solutions. This is especially true with address elements. For example, indiscriminately appending a domain to an address or element that lacks one typically results in more broken addresses. An unqualified address must be verified to be a valid local part in the domain before the domain can be safely added.
以下に注意してください。 メッセージ変更を実装するというローカルの決定のための指導の問題として、最高の規則はそのような動作を明確なソリューションを持っている特定の問題のための療法に制限することです。 これはアドレス要素で特に本当です。 例えば、無差別に1つを欠いているアドレスか要素にドメインを追加すると、より壊れているアドレスは通常もたらされます。 安全にドメインを加えることができる前のそのドメインの有効な地方の部分になるように資格のないアドレスについて確かめなければなりません。
Any message forwarded or delivered by the MSA MUST conform to the requirements of [SMTP-MTA] and [MESSAGE-FORMAT].
MSA MUSTが転送したか、または提供したどんなメッセージも[SMTP-MTA]と[MESSAGE-FORMAT]の要件に従います。
8.1. Add 'Sender'
8.1. '送付者'を加えてください。
The MSA MAY add or replace the 'Sender' field, if the identity of the sender is known and this is not given in the 'From' field.
MSA MAYは'送付者'野原を加えるか、または取り替えます、送付者のアイデンティティが知られていて、これが'From'分野で与えられないなら。
The MSA MUST ensure that any address it places in a 'Sender' field is in fact a valid mail address.
MSA MUSTは、事実上、それが'送付者'分野に置くどんなアドレスも有効な郵便の宛先であることを確実にします。
8.2. Add 'Date'
8.2. 'デートしてください'と言い足してください。
The MSA MAY add a 'Date' field to the submitted message, if it lacks it, or correct the 'Date' field if it does not conform to [MESSAGE-FORMAT] syntax.
MSA MAYはそれを欠いているなら'日付'分野を提出されたメッセージに追加するか、または[MESSAGE-FORMAT]構文に従わないなら、'日付'分野を修正します。
8.3. Add 'Message-ID'
8.3. 'Message ID'を加えてください。
The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note that a number of clients still do not generate Message-ID fields.
MSA SHOULDは'Message ID'野原を加えるか、または取り替えます、それを欠いているか、それが有効な構文([MESSAGE-FORMAT]によって定義されるように)でないなら。 多くのクライアントが、Message-IDが分野であるとまだ生成していないことに注意してください。
8.4. Transfer Encode
8.4. 転送エンコード
The MSA MAY apply transfer encoding to the message according to MIME conventions, if needed and not harmful to the MIME type.
MIMEコンベンションによると、MSA MAYはメッセージへの転送コード化を適用します、MIMEの種類に必要であって、有害でないなら。
8.5. Sign the Message
8.5. メッセージに署名してください。
The MSA MAY (digitally) sign or otherwise add authentication information to the message.
MSA MAYは認証情報をメッセージに署名するか、またはそうでなければ、(デジタルに)追加します。
Gellens & Klensin Standards Track [Page 11] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[11ページ]。
8.6. Encrypt the Message
8.6. メッセージを暗号化してください。
The MSA MAY encrypt the message for transport to reflect organizational policies.
MSA MAYは輸送が組織的な方針を反映するメッセージを暗号化します。
NOTE: To be useful, the addition of a signature and/or encryption by the MSA generally implies that the connection between the MUA and MSA must itself be secured in some other way, for example, by operating inside of a secure environment, by securing the submission connection at the transport layer, or by using an [SMTP-AUTH] mechanism that provides for session integrity.
以下に注意してください。 役に立ちます、一般に、MSAによる署名、そして/または、暗号化の追加自体がMUAとMSAとの接続がそうしなければならないのを含意するということになるように、例えば、安全な環境の内部を操作するか、トランスポート層で服従接続を保証するか、またはセッション保全に備える[SMTP-AUTH]メカニズムを使用することによって、ある他の方法で機密保護されてください。
8.7. Resolve Aliases
8.7. 別名を決議してください。
The MSA MAY resolve aliases (CNAME records) for domain names, in the SMTP envelope and optionally in address fields of the header, subject to local policy.
MSA MAYはヘッダーのアドレス・フィールドでSMTP封筒に任意に、ローカルの方針を条件としてドメイン名のための別名(CNAME記録)を決議します。
NOTE: Unconditionally resolving aliases could be harmful. For example, if www.example.net and ftp.example.net are both aliases for mail.example.net, rewriting them could lose useful information.
以下に注意してください。 無条件に別名を決議するのは有害であるかもしれません。 例えば、www.example.netとftp.example.netがmail.example.netのための両方の別名であるなら、それらを書き直すと、役に立つ情報は失われるかもしれません。
8.8. Header Rewriting
8.8. ヘッダーの書き直し
The MSA MAY rewrite local parts and/or domains in the SMTP envelope, and optionally in address fields of the header, according to local policy. For example, a site may prefer to rewrite 'JRU' as 'J.Random.User' in order to hide login names, and/or to rewrite 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine names and make it easier to move users.
MSA MAYはヘッダーのアドレス・フィールドでSMTP封筒に、任意に地方の部分、そして/または、ドメインを書き直します、ローカルの方針によると。 例えば、サイトは、ログイン名を隠すために'J.Random.User'として'JRU'を書き直して、マシン名を隠して、ユーザを動かすのをより簡単にするように'zyx.example.net'として'squeaky.sales.example.net'を書き直すのを好むかもしれません。
However, only addresses, local-parts, or domains which match specific local MSA configuration settings should be altered. It would be very dangerous for the MSA to apply data-independent rewriting rules, such as always deleting the first element of a domain name. So, for example, a rule that strips the left-most element of the domain, if the complete domain matches '*.foo.example.net', would be acceptable.
しかしながら、アドレス、地方の部分、または特定の地方のMSA構成設定に合っているドメインだけが変更されるべきです。 MSAがデータから独立している書換規則を適用するのは、非常に危険でしょう、いつもドメイン名の最初の要素を削除するのなどように。 'そのように、例えば、完全なドメインが'*.foo.example.net'に合っているなら最も左の要素からドメインを奪い取る規則は許容できるでしょう。
The MSA MUST NOT rewrite a forward-pointing (destination) address in a way that violates the constraints of [SMTP-MTA] on modifications of local-parts.
MSA MUST NOTは地方の部分の変更の[SMTP-MTA]の規制に違反する方法で前方に指している(目的地)アドレスを書き直します。
9. Security Considerations
9. セキュリティ問題
Separation of submission and relay of messages allows a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. It can do this in a way which is simpler, both technically and
サイトは服従の分離とメッセージのリレーで2つのタイプのサービスのための異なった政策を実施できます、追加担保メカニズムの1か両方の使用を必要とするのを含んでいて。 そしてそれが、より簡単な方法でこれができる、両方、技術的である。
Gellens & Klensin Standards Track [Page 12] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[12ページ]。
administratively. This increases the likelihood that policies will be applied correctly.
行政上。 これは方針が正しく適用される可能性を広げます。
Separation also can aid in tracking and preventing unsolicited bulk email.
分離も求められていない大量のメールを追跡して、防ぐ際に支援されることができます。
For example, a site could configure its mail servers such that the MSA requires authentication before accepting a message, and the MTA rejects all RCPT commands for non-local users. This can be an important element in a site's total email security policy.
例えば、サイトがメールサーバを構成するかもしれないので、メッセージを受け入れる前にMSAは認証を必要とします、そして、MTAは非地元のユーザのためにすべてのRCPTコマンドを拒絶します。 サイトの総メール安全保障政策でこれは重要な要素であるかもしれません。
If a site fails to require any form of authorization for message submissions (see section 3.3 for discussion), it is allowing open use of its resources and name; unsolicited bulk email can be injected using its facilities.
サイトがメッセージ差出のためのどんな形式の認可も必要としないなら(議論に関してセクション3.3を見てください)、そのリソースと名前の開いている使用を許しています。 施設を使用することで求められていない大量のメールを注入できます。
Section 3 includes further discussion of issues with some authentication methods.
セクション3はいくつかの認証方法の問題のさらなる議論を含めます。
Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial of service attacks.
セクション5.2は無制限な伐採が、ある形式のサービス不能攻撃を可能にすることができるという警告的なメモを含めます。
10. IANA Considerations
10. IANA問題
The registration for port 587 has been updated to refer to this memo rather than RFC 2476.
RFC2476よりむしろこのメモを参照するためにポート587のための登録をアップデートしました。
11. Acknowledgements
11. 承認
Nathaniel Borenstein and Barry Leiba were instrumental in the development of this update to RFC 2476.
ナザニエルBorensteinとバリーLeibaはこのアップデートの開発でRFC2476に手段になっていました。
The original memo (RFC 2476) was developed in part based on comments and discussions which took place on and off the IETF-Submit mailing list. The help of those who took the time to review that document and make suggestions is appreciated, especially that of Dave Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
オリジナルのメモ(RFC2476)はコメントに基づいて一部開発されました、そして、取った議論は時々IETF提出しているメーリングリストを置きます。 そのドキュメントを再検討して、提案をするのに感謝するとき取った人の助け、特にデーヴ・クロッカーのもの、ネッド・フリード、キース・ムーア、ジョン・マイアーズ、およびクリス・ニューマン。
Special thanks to Harald Alvestrand, who got this effort started.
ハラルドAlvestrandのおかげで、特別です。Alvestrandはこの努力を開始させました。
Gellens & Klensin Standards Track [Page 13] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[13ページ]。
12. Normative References
12. 引用規格
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
and D. Crocker, "SMTP Service Extensions", STD 10,
RFC 1869, November 1995.
[ESMTP]KlensinとJ. N.と解放されて、ローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」、STD10、RFC1869、1995年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD
10, RFC 821, August 1982.
[SMTP-MTA] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
Partridge, C., "Mail routing and the domain
system", STD 10, RFC 974, January 1986.
ヤマウズラ、C.が「ルーティングとドメインシステムを郵送する」、STD10、RFC974、1月1986日
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
Klensin, J., "Simple Mail Transfer Protocol", RFC
2821, April 2001.
Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
13. Informative References
13. 有益な参照
[521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
RFC 1846, September 1995.
[521REPLY] ジュランドとA.とF.デュポン、「SMTP521回答コード」、RFC1846、1995年9月。
[8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E.,
and D. Crocker, "SMTP Service Extension for 8bit-
MIMEtransport", RFC 1652, July 1994.
[8BITMIME]Klensin、J.、解放されています、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、「SMTPは8ビット-MIMEtransportのために拡大を修理します」、RFC1652、1994年7月。
[CHECKPOINT] Crocker, D., Freed, N., and A. Cargille, "SMTP
Service Extension for Checkpoint/Restart", RFC
1845, September 1995.
クロッカー(D.)が解放した[チェックポイント]、N.、およびA.Cargille、「チェックポイント/再開のためのSMTPサービス拡張子」、RFC1845、1995年9月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for
Transmission of Large and Binary MIME Messages",
RFC 3030, December 2000.
[分魂化] ボードルイ、G.、「大きくて2進のMIMEメッセージの伝達のためのSMTPサービス拡張子」、RFC3030、2000年12月。
[CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning
Enhanced Error Codes", RFC 2034, October 1996.
解放された[コード拡大]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP)
Service Extension for Delivery Status Notifications
(DSNs)", RFC 3461, January 2003.
[DSN]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[ETRN] De Winter, J., "SMTP Service Extension for Remote
Message Queue Starting", RFC 1985, August 1996.
[ETRN] De冬、J.、「リモートメッセージキュー始めのためのSMTPサービス拡張子」、RFC1985、1996年8月。
Gellens & Klensin Standards Track [Page 14] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[14ページ]。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture
for the Internet Protocol", RFC 2401, November
1998.
[IPSEC] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982.
[MESSAGE-FORMAT] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, October
1989.
ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[Msg-Track] Allman, E. and T. Hansen, "SMTP Service Extension
for Message Tracking", RFC 3885, September 2004.
[エムエスジー道] オールマンとE.とT.ハンセン、「メッセージ追跡のためのSMTPサービス拡張子」、RFC3885、2004年9月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
解放された[パイプライン処理]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、STD60、RFC2920、2000年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol -
Version 3", STD 53, RFC 1939, May 1996.
[POP3] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10,
RFC 1870, November 1995.
Klensin(J.)が解放した[サイズ]、N.、およびK.ムーア、「SMTPはメッセージサイズ宣言のための拡大を修理します」、STD10、RFC1870、1995年11月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for
Authentication", RFC 2554, March 1999.
[SMTP-AUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, January 2003.
「高められたメールシステム状態はコード化する」[SMTP-コード]ボードルイ、G.、RFC3463、2003年1月。
[Start-TLS] Hoffman, P., "SMTP Service Extension for Secure
SMTP over Transport Layer Security", RFC 3207,
February 2002.
[始め-TLS]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
Gellens & Klensin Standards Track [Page 15] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[15ページ]。
Authors' Addresses
作者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121-2779 USA
ランドルGellensのクアルコムの法人組織の5775モアハウス・Driveサンディエゴ、カリフォルニア92121-2779米国
EMail: rg+ietf@qualcomm.com
メール: rg+ ietf@qualcomm.com
John C. Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA
Ave、ジョンC.Klensin1770マサチューセッツ#322MA02140ケンブリッジ(米国)
EMail: john+ietf@jck.com
メール: john+ ietf@jck.com
Gellens & Klensin Standards Track [Page 16] RFC 4409 Message Submission for Mail April 2006
Gellens&Klensin規格はメール2006年4月にRFC4409メッセージ提案を追跡します[16ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Gellens & Klensin Standards Track [Page 17]
Gellens&Klensin標準化過程[17ページ]
一覧
スポンサーリンク
