RFC5321 日本語訳
5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Klensin Request for Comments: 5321 October 2008 Obsoletes: 2821 Updates: 1123 Category: Standards Track
Klensinがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 5321 2008年10月は以下を時代遅れにします。 2821のアップデート: 1123年のカテゴリ: 標準化過程
Simple Mail Transfer Protocol
シンプルメールトランスファプロトコル
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments.
このドキュメントはインターネット電子メール輸送のための基本プロトコルの仕様です。 それらの大部分のすべてか部品を時代遅れにして、それは、前のいくつかのドキュメントを統合して、アップデートして、はっきりさせます。 それは、SMTP拡大メカニズムと最も良い習慣を現代のインターネットにカバーしていますが、特定の拡大に関して詳細を明らかにしません。 メール輸送と配送が議定書を作るとき、SMTPは設計されましたが、また、この仕様は「分裂-UA」(ユーザエージェント)というシステムと変わりやすい環境を読む郵便配達人のための「メール提案」プロトコルとして使用に重要な情報を含んでいます。
Klensin Standards Track [Page 1] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5
1.2. History and Context for This Document . . . . . . . . . . 5
1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6
2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7
2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9
2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Definition and Registration of Extensions . . . . . . 10
2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11
2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11
2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11
2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12
2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12
2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13
2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14
2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14
2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15
2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15
2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15
2.4. General Syntax Principles and Transaction Model . . . . . 16
3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17
3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18
3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18
3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19
3.4. Forwarding for Address Correction or Updating . . . . . . 21
3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22
3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22
3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24
3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25
3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26
3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26
3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26
3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26
3.6.3. Message Submission Servers as Relays . . . . . . . . . 27
3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28
3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28
3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29
3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29
3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29
3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30
3.8. Terminating Sessions and Connections . . . . . . . . . . . 30
3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31
3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1。 電子メール. . . . . . . . . . . . . . . 5 1.2の輸送。 これのための歴史と文脈は.51.3を記録します。 コンベンション. . . . . . . . . . . . . . . . . . . 6 2を記録してください。 SMTPは.72.1をモデル化します。 基本構造. . . . . . . . . . . . . . . . . . . . . 7 2.2。 拡大モデル. . . . . . . . . . . . . . . . . . . 9 2.2.1。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . 9 2.2.2。 拡大. . . . . . 10 2.2.3の定義と登録。 拡大. . . . . . . . . . . . 11 2.3との増刊。 SMTP用語. . . . . . . . . . . . . . . . . . . . . 11 2.3.1。 .2に物. . . . . . . . . . . . . . . . . . . . . 11 2.3を郵送してください。 送付者と受信機. . . . . . . . . . . . . . . . 12 2.3.3。 .4にストア. . . . . . . . . . . . 12 2.3をエージェントとメッセージに郵送してください。 ホスト. . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.5。 ドメイン名. . . . . . . . . . . . . . . . . . . . . 13 2.3.6。 テーブル. . . . . . . . . . . . . . . . 14 2.3.7をバッファリングして、述べてください。 コマンドと回答. . . . . . . . . . . . . . . . . 14 2.3.8。 .9に.142.3を裏打ちします。 メッセージ内容とメールデータ. . . . . . . . . . . . 15 2.3.10。 創始者、配送、リレー、およびゲートウェイシステム. . . 15 2.3.11。 メールボックスとアドレス. . . . . . . . . . . . . . . . . 15 2.4。 一般構文プリンシプルズと取引は.163をモデル化します。 SMTP手順: 概観. . . . . . . . . . . . . . . 17 3.1。 セッション開始. . . . . . . . . . . . . . . . . . . . 18 3.2。 クライアント開始. . . . . . . . . . . . . . . . . . . . 18 3.3。 取引. . . . . . . . . . . . . . . . . . . . 19 3.4を郵送してください。 アドレスのために、修正かアップデート. . . . . . 21 3.5を進めます。 .1にアドレス. . . . . . . . . . . . . 22 3.5をデバッグするためのコマンド 概観. . . . . . . . . . . . . . . . . . . . . . . 22 3.5.2。 VRFYの通常の応答. . . . . . . . . . . . . . . . . 24 3.5.3。 VRFYの意味かEXPN成功応答. . . . . . . 25 3.5.4。 EXPN. . . . . . . . . . 26 3.6の意味論とアプリケーション。 リレーとメールルート設定. . . . . . . . . . . . . . . . 26 3.6.1。 送信元経路とリレー. . . . . . . . . . . . . . 26 3.6.2。 交換記録とリレー. . . . . . . . . . 26 3.6.3を郵送してください。 リレー. . . . . . . . . 27 3.7としてのメッセージ服従サーバ。 Gatewaying. . . . . . . . . . . . . . . . . . . . . 28 3.7.1を郵送してください。 Gatewaying. . . . . . . . . . . . . 28 3.7.2におけるヘッダーフィールド。 Gatewaying. . . . . . . . . . . . . 29 3.7.3における容認された線。 Gatewaying. . . . . . . . . . . . . . . 29 3.7.4では、記述します。 Gatewaying. . . . . . . . . . 29 3.7.5における他のヘッダーフィールド。 Gatewaying. . . . . . . . . . . . . . . 30 3.8の封筒。 セッションとコネクションズ. . . . . . . . . . . 30 3.9を終えます。 メーリングリストと別名. . . . . . . . . . . . . . . . 31 3.9.1。 別名. . . . . . . . . . . . . . . . . . . . . . . . 31
Klensin Standards Track [Page 2] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[2ページ]。
3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31
4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32
4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32
4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32
4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41
4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43
4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44
4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46
4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48
4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50
4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52
4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53
4.2.5. Reply Codes after DATA and the Subsequent
<CRLF>.<CRLF> . . . . . . . . . . . . . . . . . . . . 53
4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54
4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54
4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55
4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57
4.5. Additional Implementation Issues . . . . . . . . . . . . . 61
4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61
4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62
4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62
4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62
4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63
4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63
4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63
4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63
4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63
4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64
4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64
4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64
4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65
4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65
4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65
4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66
4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66
4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66
4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66
4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66
4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68
5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69
5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69
5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71
6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71
3.9.2. .314を記載してください。 SMTP仕様. . . . . . . . . . . . . . . . . . . 32 4.1。 SMTPは.1に.324.1を命令します。 意味論と構文. . . . . . . . . . . . . 32 4.1.2を命令してください。 議論構文. . . . . . . . . . . . . . . 41 4.1.3を命令してください。 誤字誤植. . . . . . . . . . . . . . . . . . . 43 4.1.4を記述してください。 コマンド. . . . . . . . . . . . . . . . . . 44 4.1.5の注文。 私用は.464.2を命令します。 SMTPは.464.2に.1に返答します。 回答コードの厳しさと理論. . . . . . . . . . . 48 4.2.2。 関数群. . . . . . . . . . . . 50 4.2.3の回答コード。 回答は数値でオーダー. . . . . . . . . . . . . 52 4.2.4をコード化します。 回答コード502. . . . . . . . . . . . . . . . . . . . 53 4.2.5。 回答はデータとその後の<CRLFの後に><CRLF>. . . . . . . . . . . . . . . . . . . . 53 4.3をコード化します。 コマンドと回答. . . . . . . . . . . . 54 4.3は.1に配列されること。 概観. . . . . . . . . . . . . . . . . 54 4.3.2を配列します。 コマンド回答系列. . . . . . . . . . . . . . . 55 4.4。 情報. . . . . . . . . . . . . . . . . . . . 57 4.5をたどってください。 追加導入問題. . . . . . . . . . . . . 61 4.5.1。 最小の実現. . . . . . . . . . . . . . . . 61 4.5.2。 透明. . . . . . . . . . . . . . . . . . . . . 62 4.5.3。 サイズとタイムアウト. . . . . . . . . . . . . . . . . . 62 4.5.3、.1 サイズ限界と最小限. . . . . . . . . . . . . 62 4.5.3.1、.1 ローカルと同じくらい離れてください。.634.5 .3 .1 .2。 ドメイン、.634.5 .3 .1 .3。 経路、.634.5 .3 .1 .4。 コマンドライン、.634.5 .3 .1 .5。 回答は立ち並んでいます。.634.5 .3 .1 .6。 テキストは立ち並んでいます。.634.5 .3 .1 .7。 内容. . . . . . . . . . . . . . . 63 4.5を通信させてください。.3 .1 .8。 受取人は.644.5をバッファリングします。.3 .1 .9。 限界であるときに、処理は.644.5を超えていました。.3 .1 .10。 あまりに多くの受取人コード. . . . . . . . . . . 64 4.5.3.2。 タイムアウト、.654.5 .3 .2 .1。 220メッセージに頭文字をつけてください: 5は.654.5を書き留めます。.3 .2 .2。 コマンドを郵送してください: 5は.654.5を書き留めます。.3 .2 .3。 RCPTは命令します: 5は.654.5を書き留めます。.3 .2 .4。 データ開始: 2は.664.5を書き留めます。.3 .2 .5。 データ・ブロック: 3は.664.5を書き留めます。.3 .2 .6。 データ終了: 10 書き留めます。 . . . . . . . . 66 4.5.3.2.7. サーバタイムアウト: 5 書き留めます。 . . . . . . . . . . 66 4.5.4. 戦略. . . . . . . . . . . . . . . . . . . 66 4.5.5を再試行してください。 ヌル逆経路.685があるメッセージ。 解決とメール取り扱. . . . . . . . . . . . . 69 5.1いを記述してください。 目標ホスト. . . . . . . . . . . . . . . . . 69 5.2の居場所を見つけます。 IPv6とMX記録. . . . . . . . . . . . . . . . . . . 71 6。 問題検出と取り扱. . . . . . . . . . . . . . . . 71い
Klensin Standards Track [Page 3] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[3ページ]。
6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71
6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72
6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73
6.4. Compensating for Irregularities . . . . . . . . . . . . . 73
7. Security Considerations . . . . . . . . . . . . . . . . . . . 75
7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75
7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76
7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76
7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77
7.5. Information Disclosure in Announcements . . . . . . . . . 77
7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78
7.7. Information Disclosure in Message Forwarding . . . . . . . 78
7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78
7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
10.1. Normative References . . . . . . . . . . . . . . . . . . . 81
10.2. Informative References . . . . . . . . . . . . . . . . . . 82
Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85
Appendix B. Generating SMTP Commands from RFC 822 Header
Fields . . . . . . . . . . . . . . . . . . . . . . . 85
Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86
Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87
D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88
D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89
D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90
D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92
Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92
Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93
F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93
F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94
F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94
F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94
6.1. メール. . . . . . . . . . 71 6.2による信頼できる配信と回答。 求められていない求められていない、そして、「攻撃」メッセージ.726.3 検出. . . . . . . . . . . . . . . . . . . . . . 73 6.4を輪にしてください。 不規則. . . . . . . . . . . . . 73 7を補います。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 75 7.1。 セキュリティとスプーフィング. . . . . . . . . . . . . . . . 75 7.2を郵送してください。 「盲目」のコピー. . . . . . . . . . . . . . . . . . . . . . 76 7.3。 VRFY、EXPN、およびセキュリティ. . . . . . . . . . . . . . . . . 76 7.4。 メールのコースを変更するのは応答コード. . 77 7.5を251と551に基礎づけました。 発表. . . . . . . . . 77 7.6における情報公開。 跡の分野. . . . . . . . . . 78 7.7での情報公開。 メッセージ推進. . . . . . . 78 7.8における情報公開。 攻撃. . . . . . . . . . . . . . . . . . 78 7.9への抵抗。 SMTPプロトコルのサーバ. . . . . . . . . . . . 78 8の操作の範囲。 IANA問題. . . . . . . . . . . . . . . . . . . . . 79 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 80 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 81 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 81 10.2。 SMTPを発生させる有益な参照. . . . . . . . . . . . . . . . . . 82付録A.TCP輸送サービス. . . . . . . . . . . . . . . . 85付録B.がRFC822ヘッダーフィールド. . . . . . . . . . . . . . . . . . . . . . . 85付録C.送信元経路. . . . . . . . . . . . . . . . . . . . 86付録D.シナリオから.87D.1を命令します。 典型的なSMTP取引シナリオ. . . . . . . . . . . 88D.2。 SMTP取引シナリオ. . . . . . . . . . . . 89D.3を中止しました。 メールシナリオ. . . . . . . . . . . . . . . . . . 90D.4をリレーしました。 他のシナリオ. . . . . . . . . . . . . . 92付録E.ゲートウェイを確かめて、送るとRFCの.92の付録のF.の推奨しない機能が発行される、821、.93F.1 .93F.2をターンしてください。 ソースルート設定. . . . . . . . . . . . . . . . . . . . . . 93F.3。 HELO. . . . . . . . . . . . . . . . . . . . . . . . . . . 93F.4。 #-誤字誤植. . . . . . . . . . . . . . . . . . . . . . . . 94F.5。 日付と何年. . . . . . . . . . . . . . . . . . . . . 94ものF.6。 郵送. . . . . . . . . . . . . . . . . . 94に対して発信します。
Klensin Standards Track [Page 4] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[4ページ]。
1. Introduction
1. 序論
1.1. Transport of Electronic Mail
1.1. 電子メールの輸送
The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.
シンプルメールトランスファプロトコル(SMTP)の目的は確かに効率的にメールを移すことです。
SMTP is independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. While this document specifically discusses transport over TCP, other transports are possible. Appendices to RFC 821 [1] describe some of them.
SMTPは特定のトランスミッションサブシステムから独立していて、高信頼の規則正しいデータストリーム・チャンネルだけを必要とします。 このドキュメントは明確にTCPの上の輸送について議論しますが、他の輸送は可能です。 RFC821[1]への付録はそれらのいくつかについて説明します。
An important feature of SMTP is its capability to transport mail across multiple networks, usually referred to as "SMTP mail relaying" (see Section 3.6). A network consists of the mutually-TCP-accessible hosts on the public Internet, the mutually-TCP-accessible hosts on a firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN environment utilizing a non-TCP transport-level protocol. Using SMTP, a process can transfer mail to another process on the same network or to some other network via a relay or gateway process accessible to both networks.
SMTPの重要な特徴は通常、「SMTPメールリレー」と呼ばれた複数のネットワークの向こう側にメールを輸送するその能力(セクション3.6を見る)です。 ネットワークが成る、互いにTCPアクセスしやすい、公共のインターネットのホスト、互いにTCPアクセスしやすい、ファイアウォールで孤立しているTCP/IPイントラネットのホスト、または非TCP輸送レベルプロトコルを利用するある他のLANかWAN環境におけるホスト。 SMTPを使用して、過程は両方のネットワークにアクセスしやすいリレーかゲートウェイの過程で同じネットワークの別の過程、または、ある他のネットワークにメールを移すことができます。
In this way, a mail message may pass through a number of intermediate relay or gateway hosts on its path from sender to ultimate recipient. The Mail eXchanger mechanisms of the domain name system (RFC 1035 [2], RFC 974 [12], and Section 5 of this document) are used to identify the appropriate next-hop destination for a message being transported.
このように、メール・メッセージは経路を送付者から究極の受取人まで多くの中間的リレーかゲートウェイホストを通り抜けるかもしれません。 ドメイン名システム(このドキュメントのRFC1035[2]、RFC974[12]、およびセクション5)のメールeXchangerメカニズムは、輸送されるメッセージのために適切な次のホップの目的地を特定するのに使用されます。
1.2. History and Context for This Document
1.2. このドキュメントのための歴史と文脈
This document is a specification of the basic protocol for the Internet electronic mail transport. It consolidates, updates and clarifies, but does not add new or change existing functionality of the following:
このドキュメントはインターネット電子メール輸送のための基本プロトコルの仕様です。 それは、以下の既存の機能性を統合するか、アップデートして、はっきりさせますが、新しく加えるか、または変えません:
o the original SMTP (Simple Mail Transfer Protocol) specification of
RFC 821 [1],
o RFC821[1]の当初のSMTP(シンプルメールトランスファプロトコル)仕様
o domain name system requirements and implications for mail
transport from RFC 1035 [2] and RFC 974 [12],
o メールのためのドメイン名システム要求と含意はRFCから1035[2]とRFC974[12]を輸送します。
o the clarifications and applicability statements in RFC 1123 [3],
and
o そしてRFC1123[3]の明確化と適用性証明。
o material drawn from the SMTP Extension mechanisms in RFC 1869
[13].
o RFC1869[13]でSMTP Extensionメカニズムから得られた材料。
Klensin Standards Track [Page 5] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[5ページ]。
o Editorial and clarification changes to RFC 2821 [14] to bring that
specification to Draft Standard.
o 社説とその仕様をDraft StandardにもたらすRFC2821[14]への明確化変化。
It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC 1123 (replacing the mail transport materials of RFC 1123). However, RFC 821 specifies some features that were not in significant use in the Internet by the mid-1990s and (in appendices) some additional transport models. Those sections are omitted here in the interest of clarity and brevity; readers needing them should refer to RFC 821.
それは、RFC821、RFC974、RFC1869、およびRFC2821を時代遅れにして、RFC1123をアップデートします(RFC1123のメール輸送の材料を取り替えて)。 しかしながら、RFC821は1990年代の半ばまでにインターネットで重要に使用中でなかったいくつかの特徴と何人かの(付録の)追加輸送モデルを指定します。 それらのセクションは明快と簡潔さのためにここで省略されます。 彼らを必要とする読者はRFC821を参照するべきです。
It also includes some additional material from RFC 1123 that required amplification. This material has been identified in multiple ways, mostly by tracking flaming on various lists and newsgroups and problems of unusual readings or interpretations that have appeared as the SMTP extensions have been deployed. Where this specification moves beyond consolidation and actually differs from earlier documents, it supersedes them technically as well as textually.
また、それは増幅を必要としたRFC1123からの何らかの追加材料を含んでいます。 この材料は複数の方法で特定されました、ほとんど様々なリスト、ニュースグループ、および珍しい読書の問題で燃えるような追跡かSMTP拡張子が配備されたとき現れた解釈で。 この仕様が強化を超えて動いて、実際に以前のドキュメントと異なっているところでは、それは技術的に原文にそれらに取って代わります。
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol, as recommended for Post Office Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501 [17]). In general, the separate mail submission protocol specified in RFC 4409 [18] is now preferred to direct use of SMTP; more discussion of that subject appears in that document.
メール輸送と配送が議定書を作るとき、SMTPは設計されましたが、また、この仕様は「メール提案」プロトコルとして使用に重要な情報を含んでいます、ポストオフィスプロトコル(POP)のために推薦されるように(RFC937[15]、RFC1939[16])、およびIMAP、(RFC3501[17])。 一般に、現在、RFC4409[18]で指定された別メール服従プロトコルがSMTPの使用を指示するのが好ましいです。 その対象の、より多くの議論がそのドキュメントに現れます。
Section 2.3 provides definitions of terms specific to this document. Except when the historical terminology is necessary for clarity, this document uses the current 'client' and 'server' terminology to identify the sending and receiving SMTP processes, respectively.
セクション2.3はこのドキュメントに特定の用語の定義を提供します。 歴史的な用語が明快に必要である時を除いて、このドキュメントは発信を特定するのに現在の'クライアント'と'サーバ'用語を使用します、そして、SMTPを受けるのはそれぞれ処理されます。
A companion document, RFC 5322 [4], discusses message header sections and bodies and specifies formats and structures for them.
仲間ドキュメント(RFC5322[4])は、メッセージヘッダー部分とボディーについて議論して、形式と構造をそれらに指定します。
1.3. Document Conventions
1.3. ドキュメントコンベンション
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 RFC 2119 [5]. As each of these terms was intentionally and carefully chosen to improve the interoperability of email, each use of these terms is to be treated as a conformance requirement.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[5]で説明されるように本書では解釈されることであるべきですか? それぞれのこれらの用語がメールの相互運用性を改良するために故意に、慎重に選ばれたとき、これらの用語の各使用は順応要件として扱われることです。
Because this document has a long history and to avoid the risk of various errors and of confusing readers and documents that point to this one, most examples and the domain names they contain are preserved from RFC 2821. Readers are cautioned that these are
このドキュメントは伝統があって、ほとんどの例とそれらが含むドメイン名が様々な誤りと読者とドキュメントを混乱させるというこれを示す危険を避けるためにRFC2821から保存されるので。 読者はこれらがそうであると警告されます。
Klensin Standards Track [Page 6] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[6ページ]。
illustrative examples that should not actually be used in either code or configuration files.
実際にコードか構成ファイルのどちらかで使用されるべきでない説明に役立つ実例。
2. The SMTP Model
2. SMTPモデル
2.1. Basic Structure
2.1. 基本構造
The SMTP design can be pictured as:
以下としてSMTPデザインについて描写できます。
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client- |Commands/Replies| Server- |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
+----------+ +----------+ +------+ | | | | | ユーザ| <-->、|、| SMTP| | +------+ | クライアント|コマンド/回答| サーバ| +------+ | SMTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| SMTP| +------+ | ファイル| <-->、|、| そして、メール| | <-->、| ファイル| |システム| | | | | |システム| +------+ +----------+ +----------+ +------+ SMTPクライアントSMTPサーバ
When an SMTP client has a message to transmit, it establishes a two- way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.
SMTPクライアントに伝わるメッセージがあるとき、それはトランスミッションがSMTPサーバーに向けられる2方法を確立します。SMTPクライアントの責任は、1つ以上のSMTPサーバーにメール・メッセージを移すか、またはそのがそうしないことを報告することです。
The means by which a mail message is presented to an SMTP client, and
how that client determines the identifier(s) ("names") of the
domain(s) to which mail messages are to be transferred, is a local
matter, and is not addressed by this document. In some cases, the
designated domain(s), or those determined by an SMTP client, will
identify the final destination(s) of the mail message. In other
cases, common with SMTP clients associated with implementations of
the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17])
protocols, or when the SMTP client is inside an isolated transport
service environment, the domain determined will identify an
intermediate destination through which all mail messages are to be
relayed. SMTP clients that transfer all traffic regardless of the
target domains associated with the individual messages, or that do
not maintain queues for retrying message transmissions that initially
cannot be completed, may otherwise conform to this specification but
are not considered fully-capable. Fully-capable SMTP
implementations, including the relays used by these less capable
ones, and their destinations, are expected to support all of the
queuing, retrying, and alternate address functions discussed in this
specification. In many situations and configurations, the less-
capable clients discussed above SHOULD be using the message
submission protocol (RFC 4409 [18]) rather than SMTP.
どれがSMTPクライアントにメール・メッセージを提示されるか、そして、そのクライアントがどのように、わたるメール・メッセージがことであるドメインに関する識別子(「名前」)を決定するかによる手段は、地域にかかわる事柄であり、このドキュメントによって記述されません。 いくつかの場合、指定されたドメイン、またはSMTPクライアントによって決定されたものがメール・メッセージの最終的な目的地を特定するでしょう。 POPの実現に関連しているSMTPクライアントについて一般的な他のケース、(RFC937[15]、RFC1939[16])またはIMAP、(RFC3501[17])プロトコルかそれともドメインが、いつSMTPクライアントが孤立している輸送サービス環境にいることを決定したかがリレーされるすべてのメール・メッセージがことである中間的目的地を特定するでしょう。 個々のメッセージに関連しているターゲット・ドメインにかかわらずすべての交通を移すか、またはそんなに初めはメッセージ送信を再試行するための待ち行列が終了できないと主張しないSMTPクライアントは、そうでなければ、この仕様に従うかもしれませんが、完全にできると考えられません。 これらのそれほどできないもの、およびそれらの目的地によって使用されるリレーを含む完全にできるSMTP実現が列を作り、再試行、およびこの仕様で議論した代替アドレス機能のすべてを支持すると予想されます。 多くの状況と構成では、SHOULDの上でメッセージ提案を使用することで議論したより少ない有能なクライアントが議定書を作ります。(SMTPよりむしろRFC4409[18])。
Klensin Standards Track [Page 7] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[7ページ]。
The means by which an SMTP client, once it has determined a target domain, determines the identity of an SMTP server to which a copy of a message is to be transferred, and then performs that transfer, is covered by this document. To effect a mail transfer to an SMTP server, an SMTP client establishes a two-way transmission channel to that SMTP server. An SMTP client determines the address of an appropriate host running an SMTP server by resolving a destination domain name to either an intermediate Mail eXchanger host or a final target host.
いったんターゲット・ドメインを決定して、わたるメッセージのコピーがことであるSMTPサーバーのアイデンティティを決定して、次に、その転送を実行するとSMTPクライアントがこのドキュメントで覆われている手段。 SMTPサーバーへの郵便為替に作用するように、SMTPクライアントは両用トランスミッションチャンネルをそのSMTPサーバーに確立します。SMTPクライアントは中間的メールeXchangerホストか最終的な目標ホストのどちらかに目的地ドメイン名を決議することによってSMTPサーバーを走らせている適切なホストのアドレスを決定します。
An SMTP server may be either the ultimate destination or an intermediate "relay" (that is, it may assume the role of an SMTP client after receiving the message) or "gateway" (that is, it may transport the message further using some protocol other than SMTP). SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP replies are sent from the SMTP server to the SMTP client in response to the commands.
SMTPサーバーは、最終仕向地か中間的「リレー」(メッセージを受け取った後に、すなわち、それはSMTPクライアントの役割を引き受けるかもしれない)か「ゲートウェイ」のどちらかであるかもしれません(すなわち、それはさらにSMTP以外の何らかのプロトコルを使用することでメッセージを輸送するかもしれません)。 SMTPコマンドをSMTPクライアントを発生させて、SMTPサーバーに送ります。コマンドに対応してSMTPサーバーからSMTPクライアントにSMTP回答を送ります。
In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8, below).
言い換えれば、メッセージ転送は、オリジナルのSMTP-送付者と最終的なSMTP-受取人の間に単独結合で起こることができるか、または仲介者システムを通して一連のホップに起こることができます。どちらの場合ではも、サーバがメールデータの終わりでいったん成功応答を発行するとメッセージへの責任の正式な移管は起こります: プロトコルは、サーバがメッセージを送るか、または適切にそうしないことを報告することへの責任を引き受けなければならないのを必要とします(以下でセクション6.1、6.2、および7.8を見てください)。
Once the transmission channel is established and initial handshaking is completed, the SMTP client normally initiates a mail transaction. Such a transaction consists of a series of commands to specify the originator and destination of the mail and transmission of the message content (including any lines in the header section or other structure) itself. When the same message is sent to multiple recipients, this protocol encourages the transmission of only one copy of the data for all recipients at the same destination (or intermediate relay) host.
いったんトランスミッションチャンネルが確立されて、初期のハンドシェイクが完成されると、通常、SMTPクライアントはメール取引を開始します。 そのような取引はメールの創始者と目的地を指定する一連のコマンドとメッセージ内容(ヘッダー部分か非重要構造のどんな線も含んでいる)自体の伝達から成ります。 同じメッセージを複数の受取人に送るとき、このプロトコルは同じ目的地(または、中間的リレー)ホストのすべての受取人のためにデータのコピー1部だけのトランスミッションを奨励します。
The server responds to each command with a reply; replies may indicate that the command was accepted, that additional commands are expected, or that a temporary or permanent error condition exists. Commands specifying the sender or recipients may include server- permitted SMTP service extension requests, as discussed in Section 2.2. The dialog is purposely lock-step, one-at-a-time, although this can be modified by mutually agreed upon extension requests such as command pipelining (RFC 2920 [19]).
サーバは回答で各コマンドに反応します。 回答は、コマンドを受け入れたか、追加コマンドが予想されるか、または一時的であるか永久的なエラー条件が存在するのを示すかもしれません。 送付者か受取人を指定するコマンドはSMTPサービス拡大要求がセクション2.2で議論するように受入れられたサーバを含むかもしれません。 対話はわざわざ堅苦しいです、一度に一つ、コマンド連続送信などの拡大要求に相談ずくでこれを変更できますが。(RFC2920[19])。
Once a given mail message has been transmitted, the client may either request that the connection be shut down or may initiate other mail
与えられたメール・メッセージがいったん伝えられると、クライアントは、接続が止められるよう要求するか、または他のメールに着手するかもしれません。
Klensin Standards Track [Page 8] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[8ページ]。
transactions. In addition, an SMTP client may use a connection to an SMTP server for ancillary services such as verification of email addresses or retrieval of mailing list subscriber addresses.
取引。 さらに、SMTPクライアントはEメールアドレスの検証かメーリングリスト加入者アドレスの検索などの付属のサービスにSMTPサーバーに接続を使用するかもしれません。
As suggested above, this protocol provides mechanisms for the transmission of mail. Historically, this transmission normally occurred directly from the sending user's host to the receiving user's host when the two hosts are connected to the same transport service. When they are not connected to the same transport service, transmission occurs via one or more relay SMTP servers. A very common case in the Internet today involves submission of the original message to an intermediate, "message submission" server, which is similar to a relay but has some additional properties; such servers are discussed in Section 2.3.10 and at some length in RFC 4409 [18]. An intermediate host that acts as either an SMTP relay or as a gateway into some other transmission environment is usually selected through the use of the domain name service (DNS) Mail eXchanger mechanism.
上に示されるように、このプロトコルはメールの伝達にメカニズムを提供します。 2人のホストが同じ輸送サービスに接続されるとき、通常、歴史的に、このトランスミッションは直接送付ユーザのホストから受信ユーザのホストまで起こりました。 それらが同じ輸送サービスに接続されないとき、トランスミッションは1つ以上のリレーSMTPプロトコルのサーバで起こります。 インターネットの非常に一般的なケースに、今日、中間的「メッセージ提案」サーバへのオリジナルのメッセージの服従にかかわりますが、いくつかの追加特性があります。サーバはリレーと同様です。 セクション2.3.10とRFC4409[18]の何らかの長さでそのようなサーバについて議論します。 通常、SMTPリレーとして、または、ゲートウェイとしてある他のトランスミッション環境に務める中間的ホストはドメイン名サービス(DNS)メールeXchangerメカニズムの使用で選ばれます。
Usually, intermediate hosts are determined via the DNS MX record, not by explicit "source" routing (see Section 5 and Appendix C and Appendix F.2).
通常、中間的ホストは明白な「ソース」ルーティングで断固としているのではなく、DNS MX記録で断固としています(セクション5、Appendix C、およびAppendix F.2を見てください)。
2.2. The Extension Model
2.2. 拡大モデル
2.2.1. Background
2.2.1. バックグラウンド
In an effort that started in 1990, approximately a decade after RFC 821 was completed, the protocol was modified with a "service extensions" model that permits the client and server to agree to utilize shared functionality beyond the original SMTP requirements. The SMTP extension mechanism defines a means whereby an extended SMTP client and server may recognize each other, and the server can inform the client as to the service extensions that it supports.
1990年からの努力、RFC821が完成した後におよそ10年間で、プロトコルはクライアントとサーバが、オリジナルのSMTP要件を超えて共有された機能性を利用するのに同意するのを可能にする「サービス拡大」モデルと共に変更されました。 SMTP拡大メカニズムは拡張SMTPクライアントとサーバが互いを見分けるかもしれなくて、サーバがそれが支持するサービス拡大に関してクライアントに知らせることができる手段を定義します。
Contemporary SMTP implementations MUST support the basic extension mechanisms. For instance, servers MUST support the EHLO command even if they do not implement any specific extensions and clients SHOULD preferentially utilize EHLO rather than HELO. (However, for compatibility with older conforming implementations, SMTP clients and servers MUST support the original HELO mechanisms as a fallback.) Unless the different characteristics of HELO must be identified for interoperability purposes, this document discusses only EHLO.
現代のSMTP実現は基本的な拡大メカニズムをサポートしなければなりません。例えば、少しの特定の拡大も実行しなく、クライアントSHOULDが優先的にHELOよりむしろEHLOを利用しても、サーバはEHLOコマンドをサポートしなければなりません。 (しかしながら、より古い従うとの互換性のために、実現、SMTPクライアント、およびサーバは後退としてオリジナルのHELOメカニズムをサポートしなければなりません。) 相互運用性目的のためにHELOの異なった特性を特定してはいけないなら、このドキュメントはEHLOだけについて議論します。
SMTP is widely deployed and high-quality implementations have proven to be very robust. However, the Internet community now considers some services to be important that were not anticipated when the protocol was first designed. If support for those services is to be
SMTPは広く配備されます、そして、高品質な実現は非常に強健であると判明しました。 しかしながら、インターネット共同体は、現在、重要であるプロトコルが1番目であったときに予期されなかったいくつかのサービスが設計されていると考えます。 サポートであるなら、サービスがあるそれらに関して、いてください。
Klensin Standards Track [Page 9] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[9ページ]。
added, it must be done in a way that permits older implementations to continue working acceptably. The extension framework consists of:
加えられて、より古い実装が、許容できて働き続けているのを許容する方法でそれをしなければなりません。 拡大フレームワークは以下から成ります。
o The SMTP command EHLO, superseding the earlier HELO,
o 以前のHELOに取って代わって、SMTPはEHLOを命令します。
o a registry of SMTP service extensions,
o SMTPサービス拡張子の登録
o additional parameters to the SMTP MAIL and RCPT commands, and
o そしてSMTP MAILとRCPTコマンドへの追加パラメタ。
o optional replacements for commands defined in this protocol, such
as for DATA in non-ASCII transmissions (RFC 3030 [20]).
o コマンドとの任意の交換は中で非ASCII送信でDATAなどのこのプロトコルを定義しました。(RFC3030[20])。
SMTP's strength comes primarily from its simplicity. Experience with many protocols has shown that protocols with few options tend towards ubiquity, whereas protocols with many options tend towards obscurity.
SMTPの強さは主として簡単さから来ます。 多くのプロトコルの経験は、わずかなオプションがあるプロトコルは偏在の傾向があるのを示しましたが、多くのオプションがあるプロトコルは不鮮明の傾向があります。
Each and every extension, regardless of its benefits, must be carefully scrutinized with respect to its implementation, deployment, and interoperability costs. In many cases, the cost of extending the SMTP service will likely outweigh the benefit.
利益にかかわらず、実装、展開、および相互運用性コストに関して慎重にありとあらゆる拡大を精査しなければなりません。 多くの場合、SMTPサービスを広げる費用はおそらく利益より重いでしょう。
2.2.2. Definition and Registration of Extensions
2.2.2. 拡大の定義と登録
The IANA maintains a registry of SMTP service extensions. A corresponding EHLO keyword value is associated with each extension. Each service extension registered with the IANA must be defined in a formal Standards-Track or IESG-approved Experimental protocol document. The definition must include:
IANAはSMTPサービス拡張子の登録を維持します。 対応するEHLOキーワード価値は各拡大に関連しています。 正式なStandards-道かIESGによって承認されたExperimentalプロトコルドキュメントでIANAに示されたそれぞれのサービス拡大を定義しなければなりません。 定義は以下を含まなければなりません。
o the textual name of the SMTP service extension;
o SMTPサービス拡張子の原文の名前。
o the EHLO keyword value associated with the extension;
o 拡大に関連しているEHLOキーワード価値。
o the syntax and possible values of parameters associated with the
EHLO keyword value;
o EHLOキーワード価値に関連しているパラメタの構文と可能な値。
o any additional SMTP verbs associated with the extension
(additional verbs will usually be, but are not required to be, the
same as the EHLO keyword value);
o 拡大(追加動詞は、通常ありますが、EHLOキーワード価値として同じようにあるのに必要でない)に関連しているどんな追加SMTP動詞も。
o any new parameters the extension associates with the MAIL or RCPT
verbs;
o 拡大がメールかRCPT動詞に関連づけるどんな新しいパラメタも。
o a description of how support for the extension affects the
behavior of a server and client SMTP; and
o 拡大のサポートがどうサーバとクライアントSMTPの動きに影響するかに関する記述。 そして
Klensin Standards Track [Page 10] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[10ページ]。
o the increment by which the extension is increasing the maximum
length of the commands MAIL and/or RCPT, over that specified in
this Standard.
o 拡大がそれの上でコマンドのメール、そして/または、RCPTの最大の長さを増強している増分はこのStandardで指定しました。
In addition, any EHLO keyword value starting with an upper or lower case "X" refers to a local SMTP service extension used exclusively through bilateral agreement. Keywords beginning with "X" MUST NOT be used in a registered service extension. Conversely, keyword values presented in the EHLO response that do not begin with "X" MUST correspond to a Standard, Standards-Track, or IESG-approved Experimental SMTP service extension registered with IANA. A conforming server MUST NOT offer non-"X"-prefixed keyword values that are not described in a registered extension.
さらに、上側の、または、低いケース「X」から始まるどんなEHLOキーワード価値も拡大が二国間条約を通して排他的に利用した地方のSMTPサービスについて言及します。 登録されたサービス拡大に「X」と共に始まるキーワードを使用してはいけません。 逆に、「X」と共に始まらないEHLO応答で提示されたキーワード値はIANAに示された規格、標準化過程、またはIESGによって承認された実験的なSMTPサービス拡張子に対応しなければなりません。 従うサーバは登録された拡大で説明されない非「X」前に置かれたキーワード値を提供してはいけません。
Additional verbs and parameter names are bound by the same rules as EHLO keywords; specifically, verbs beginning with "X" are local extensions that may not be registered or standardized. Conversely, verbs not beginning with "X" must always be registered.
追加動詞とパラメタ名はEHLOキーワードと同じ規則で縛られます。 明確に、「X」と共に始まる動詞は示されないかもしれないか、標準化されないかもしれない地方の拡大です。 逆に、いつも「X」と共に始まらない動詞を登録しなければなりません。
2.2.3. Special Issues with Extensions
2.2.3. 拡大との増刊
Extensions that change fairly basic properties of SMTP operation are permitted. The text in other sections of this document must be understood in that context. In particular, extensions can change the minimum limits specified in Section 4.5.3, can change the ASCII character set requirement as mentioned above, or can introduce some optional modes of message handling.
SMTP操作の基礎特性を公正に変える拡大が受入れられます。 その文脈でこのドキュメントの他のセクションのテキストを理解しなければなりません。 拡大は、特に、セクション4.5.3で指定された最小の限界を変えることができるか、以上のようのASCII文字の組要件を変えることができるか、またはメッセージハンドリングのいくつかの任意の方法を導入できます。
In particular, if an extension implies that the delivery path normally supports special features of that extension, and an intermediate SMTP system finds a next hop that does not support the required extension, it MAY choose, based on the specific extension and circumstances, to requeue the message and try later and/or try an alternate MX host. If this strategy is employed, the timeout to fall back to an unextended format (if one is available) SHOULD be less than the normal timeout for bouncing as undeliverable (e.g., if normal timeout is three days, the requeue timeout before attempting to transmit the mail without the extension might be one day).
拡大が、通常、配送経路がその拡大の特徴をサポートするのを含意して、中間的SMTPシステムが必要な拡大をサポートしない次のホップを見つけるなら、それは、代替のMXホストを特に、特定の拡大と事情に基づいて「再-待ち行列」にメッセージを選んで、後で試みる、そして/または、裁くかもしれません。 この戦略が採用しているなら、弾むための正常なタイムアウト以下が「非-提出物」だったので(例えば、正常なタイムアウトが3日間であるなら、ある日、拡大なしでメールを伝えるのを試みる前の「再-待ち行列」タイムアウトは日間です)「非-広げ」られた形式(1つが利用可能であるなら)SHOULDへ後ろへ下がるタイムアウトです。
2.3. SMTP Terminology
2.3. SMTP用語
2.3.1. Mail Objects
2.3.1. オブジェクトを郵送してください。
SMTP transports a mail object. A mail object contains an envelope and content.
SMTPはメールオブジェクトを輸送します。 メールオブジェクトは封筒と内容を含んでいます。
The SMTP envelope is sent as a series of SMTP protocol units (described in Section 3). It consists of an originator address (to
SMTPのシリーズがユニット(セクション3では、説明される)について議定書の中で述べるとき、SMTP封筒を送ります。 それが創始者アドレスから成る、(
Klensin Standards Track [Page 11] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[11ページ]。
which error reports should be directed), one or more recipient addresses, and optional protocol extension material. Historically, variations on the reverse-path (originator) address specification command (MAIL) could be used to specify alternate delivery modes, such as immediate display; those variations have now been deprecated (see Appendix F and Appendix F.6).
誤りが指示されるべきであると報告するもの) 1つ以上の受取人アドレスの、そして、任意のプロトコル拡大物質的です。 歴史的に、代替配送モードを指定するのに逆経路(創始者)アドレス指定コマンド(メール)の変化を使用できました、即座のディスプレイなどのように。 それらの変化は現在、推奨しないです(Appendix FとAppendix F.6を見てください)。
The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the header section and the body. If the content conforms to other contemporary standards, the header section consists of a collection of header fields, each consisting of a header name, a colon, and data, structured as in the message format specification (RFC 5322 [4]); the body, if structured, is defined according to MIME (RFC 2045 [21]). The content is textual in nature, expressed using the US-ASCII repertoire [6]. Although SMTP extensions (such as "8BITMIME", RFC 1652 [22]) may relax this restriction for the content body, the content header fields are always encoded using the US-ASCII repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24]) define an algorithm for representing header values outside the US- ASCII repertoire, while still encoding them using the US-ASCII repertoire.
SMTP内容は、SMTP DATAプロトコルユニットで送られて、2つの部品を持っています: ヘッダー部分とボディー。 内容が他の現代の規格に従うなら、ヘッダー部分がヘッダーフィールドの収集、ヘッダー名、コロン、およびデータのメッセージ書式仕様のように構造化された各成るのから成る、(RFC5322[4])。 構造化されるなら、MIMEに従って、ボディーは定義されます。(RFC2045[21])。 内容は米国-ASCIIレパートリー[6]を使用することで示された自然で原文です。 SMTP拡張子である、("8BITMIME"としてあれほどです、RFC1652[22])は満足しているボディーのためのこの規制を緩和するかもしれなくて、満足しているヘッダーフィールドは、米国-ASCIIレパートリーを使用することでいつもコード化されます。 2つのMIME拡大、(RFC2047[23]とRFC2231[24])は米国-ASCIIレパートリーを使用することでまだそれらをコード化している間、米国ASCIIレパートリーの外でヘッダー値を表すためのアルゴリズムを定義します。
2.3.2. Senders and Receivers
2.3.2. 送付者と受信機
In RFC 821, the two hosts participating in an SMTP transaction were described as the "SMTP-sender" and "SMTP-receiver". This document has been changed to reflect current industry terminology and hence refers to them as the "SMTP client" (or sometimes just "the client") and "SMTP server" (or just "the server"), respectively. Since a given host may act both as server and client in a relay situation, "receiver" and "sender" terminology is still used where needed for clarity.
RFC821では、SMTPトランザクションに参加する2人のホストが「SMTP-送付者」と「SMTP-受信機」として記述されました。 このドキュメントは、現在の産業用語を反映するために変えられて、したがって、それぞれ「SMTPクライアント」(または、まさしく時々「クライアント」)と「SMTPサーバー」(または、まさしく「サーバ」)とそれらを呼びます。 与えられたホストがサーバとクライアントとしてリレー状況で務めるかもしれないので、「受信機」と「送付者」用語は明快に必要であるところでまだ使用されています。
2.3.3. Mail Agents and Message Stores
2.3.3. メールエージェントとメッセージストア
Additional mail system terminology became common after RFC 821 was
published and, where convenient, is used in this specification. In
particular, SMTP servers and clients provide a mail transport service
and therefore act as "Mail Transfer Agents" (MTAs). "Mail User
Agents" (MUAs or UAs) are normally thought of as the sources and
targets of mail. At the source, an MUA might collect mail to be
transmitted from a user and hand it off to an MTA; the final
("delivery") MTA would be thought of as handing the mail off to an
MUA (or at least transferring responsibility to it, e.g., by
depositing the message in a "message store"). However, while these
terms are used with at least the appearance of great precision in
other environments, the implied boundaries between MUAs and MTAs
often do not accurately match common, and conforming, practices with
RFC821が発行されて、この仕様で便利であるところで使用された後に追加メールシステム用語は一般的になりました。 SMTPサーバーとクライアントは、特に、メール輸送サービスを提供して、したがって、「メール配達エージェント」(MTAs)として務めます。 通常、「メール・ユーザー・エージェント」(MUAsかUAs)はメールのソースと目標として考えられます。 ソースでは、MUAがユーザから伝えられて、それをMTAに渡すためにメールを集めるかもしれません。 最終的な(「配送」)MTAはメールをMUAに渡すと考えられるでしょう(それ、例えば、「メッセージ店」にメッセージを預けることによって責任を少なくとも移して)。 しかしながら、これらの用語は少なくとも他の環境における、かなりの精度の外観と共に使用されますが、MUAsとMTAsの間の暗示している境界はしばしば正確でなくコモン、および従うことが練習されるマッチをします。
Klensin Standards Track [Page 12] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[12ページ]。
Internet mail. Hence, the reader should be cautious about inferring the strong relationships and responsibilities that might be implied if these terms were used elsewhere.
インターネット・メール。 したがって、読者はこれらの用語がほかの場所で使用されたなら強い関係と暗示するかもしれない責任を推論することに関して用心深いはずです。
2.3.4. Host
2.3.4. ホスト
For the purposes of this specification, a host is a computer system attached to the Internet (or, in some cases, to a private TCP/IP network) and supporting the SMTP protocol. Hosts are known by names (see the next section); they SHOULD NOT be identified by numerical addresses, i.e., by address literals as described in Section 4.1.2.
この仕様の目的において、ホストはインターネット(または私設のTCP/IPネットワークへのいくつかの場合で)とSMTPプロトコルをサポートすることへの添付のコンピュータ・システムです。 ホストは名前によって知られています(次のセクションを見てください)。 それら、SHOULD NOTが数字のアドレスによって特定されて、すなわち、セクション4.1で.2に説明されるようにリテラルを扱ってください。
2.3.5. Domain Names
2.3.5. ドメイン名
A domain name (or often just a "domain") consists of one or more
components, separated by dots if more than one appears. In the case
of a top-level domain used by itself in an email address, a single
string is used without any dots. This makes the requirement,
described in more detail below, that only fully-qualified domain
names appear in SMTP transactions on the public Internet,
particularly important where top-level domains are involved. These
components ("labels" in DNS terminology, RFC 1035 [2]) are restricted
for SMTP purposes to consist of a sequence of letters, digits, and
hyphens drawn from the ASCII character set [6]. Domain names are
used as names of hosts and of other entities in the domain name
hierarchy. For example, a domain may refer to an alias (label of a
CNAME RR) or the label of Mail eXchanger records to be used to
deliver mail instead of representing a host name. See RFC 1035 [2]
and Section 5 of this specification.
ドメイン名(または、まさしくしばしば「ドメイン」)はより多くの人が現れるならドットによって切り離された1つ以上のコンポーネントから成ります。 Eメールアドレスでそれ自体で使用される最上位のドメインの場合では、一連は少しもドットなしで使用されます。 これで、最上位のドメインがかかわるところで完全修飾ドメイン名だけが公共のインターネットにSMTPトランザクションに特に現れるというさらに詳細に以下で説明された要件は重要になります。 これらのコンポーネント、(DNS用語、RFC1035[2])の「ラベル」は、SMTP目的がASCII文字の組[6]から得られた手紙、ケタ、およびハイフンの系列から成るように制限されます。 ドメイン名はホストと他の実体の名前としてドメイン名階層構造に使用されます。 例えば、ドメインは、ホスト名を表すことの代わりにメールを提供するのに使用されるために別名(CNAME RRのラベル)かメールeXchanger記録のラベルを示すかもしれません。 この仕様のRFC1035[2]とセクション5を見てください。
The domain name, as described in this document and in RFC 1035 [2], is the entire, fully-qualified name (often referred to as an "FQDN"). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.
本書では説明されてRFC1035[2]では、ドメイン名は全体です、完全に修飾された名前(しばしば"FQDN"と呼ばれます)。 FQDNフォームにないドメイン名はローカルの別名にすぎません。 ローカルの別名はどんなSMTPトランザクションにも現れてはいけません。
Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:
ドメイン名がSMTPで使用されるとき、溶解性であるだけであり、完全修飾ドメイン名(FQDNs)は受入れられます。 言い換えれば、MX RRsに決議できる名前かアドレス(すなわち、AかAAAA)RRs(セクション5で議論するように)が目標を決議できるCNAME RRsのように順番に受入れられます、MXかアドレスRRsに。 ローカルのあだ名か資格のない名前を使用してはいけません。 規則へのFQDNsを必要とする2つの例外があります:
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
o EHLOコマンドで与えられたドメイン名は、一次ホスト名(アドレスにRRを決議するドメイン名)かホストに名前が全くないなら、アドレスリテラルのどちらかであるに違いありません、セクション4.1.3で説明されて、セクション4.1.4のEHLO議論で、より詳しく議論するように。
Klensin Standards Track [Page 13] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[13ページ]。
o The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see Section 4.1.1.3) and
MUST be accepted if so used.
o 「郵便局長」という予約されたメールボックス名がドメイン資格なしでRCPTコマンドに使用されるかもしれない、(セクション4.1.1を見てください、.3、)、そのように使用するなら、受け入れなければなりません。
2.3.6. Buffer and State Table
2.3.6. バッファとステートテーブル
SMTP sessions are stateful, with both parties carefully maintaining a common view of the current state. In this document, we model this state by a virtual "buffer" and a "state table" on the server that may be used by the client to, for example, "clear the buffer" or "reset the state table", causing the information in the buffer to be discarded and the state to be returned to some previous state.
双方が慎重に現状の共通認識を維持していて、SMTPセッションはstatefulです。 本書では、私たちは例えば、「バッファをきれいにする」か、または「ステートテーブルをリセットすること」にクライアントによって使用されるかもしれないサーバで仮想の「バッファ」と「ステートテーブル」でこの状態をモデル化します、バッファの情報が捨てられることを引き起こして、状態が何らかの先に返されることを引き起こして。
2.3.7. Commands and Replies
2.3.7. コマンドと回答
SMTP commands and, unless altered by a service extension, message data, are transmitted from the sender to the receiver via the transmission channel in "lines".
SMTPコマンドとどんなメッセージデータもサービス拡大で変更されない場合「系列」におけるトランスミッションチャンネルで送付者から受信機まで送られません。
An SMTP reply is an acknowledgment (positive or negative) sent in "lines" from receiver to sender via the transmission channel in response to a command. The general form of a reply is a numeric completion code (indicating failure or success) usually followed by a text string. The codes are for use by programs and the text is usually intended for human users. RFC 3463 [25], specifies further structuring of the reply strings, including the use of supplemental and more specific completion codes (see also RFC 5248 [26]).
SMTP回答はコマンドに対応したトランスミッションチャンネルを通した「系列」で受信機から送付者に送られた承認(肯定しているか否定している)です。 回答の一般的なフォームは通常、テキスト文字列がいうことになった数値完了コード(失敗を示すか、成功)です。 プログラムによってコードは使用のためのものです、そして、通常、テキストは人間のユーザのために意図します。 RFC3463[25]、回答ストリングの一層の構造を指定して、補足の、そして、より特定の完了コードの使用を含んでいて、(また、RFC5248[26])を見てください。
2.3.8. Lines
2.3.8. 線
Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see Section 4).
線がゼロから成ったか、またはすぐにASCII文字"LF"によって続かれた系列ASCII文字"CR"(十六進法値の0D)で、より多くのデータキャラクタが終わりました。(十六進法値の0A)。 この終止配列は<CRLF>として本書では指示されます。 実装を従わせるのは、系列ターミネータとしていかなる他のキャラクタかキャラクタシーケンスも見分けてはいけませんし、また生成してはいけません。 限界はサーバによって行長に課されるかもしれません(セクション4を見てください)。
In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence.
さらに、テキスト(すなわち、どちらかもう片方のない)における、「むき出し」の"CR"か"LF"キャラクタの外観には、ツールとしてメールシステムを使用するメール実装とアプリケーションで問題を起こす長い歴史があります。 SMTPクライアント実装は、彼らが系列ターミネータとして意図する時を除いて、これらのキャラクタを伝えてはいけなくて、次に、上で示されるように単に<CRLF>系列としてそれらを伝えなければなりません。
Klensin Standards Track [Page 14] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[14ページ]。
2.3.9. Message Content and Mail Data
2.3.9. メッセージ内容とメールデータ
The terms "message content" and "mail data" are used interchangeably in this document to describe the material transmitted after the DATA command is accepted and before the end of data indication is transmitted. Message content includes the message header section and the possibly structured message body. The MIME specification (RFC 2045 [21]) provides the standard mechanisms for structured message bodies.
用語「メッセージ内容」と「メールデータ」は、DATAコマンドを受け入れた後とデータ指示の終わりを伝える前に伝える材料について説明するのに互換性を持って本書では使用されます。 メッセージ内容はメッセージヘッダー部分とことによると構造化されたメッセージ本体を含んでいます。 MIME仕様、(RFC2045[21])は構造化されたメッセージ本体に標準のメカニズムを提供します。
2.3.10. Originator, Delivery, Relay, and Gateway Systems
2.3.10. 創始者、配送、リレー、およびゲートウェイシステム
This specification makes a distinction among four types of SMTP systems, based on the role those systems play in transmitting electronic mail. An "originating" system (sometimes called an SMTP originator) introduces mail into the Internet or, more generally, into a transport service environment. A "delivery" SMTP system is one that receives mail from a transport service environment and passes it to a mail user agent or deposits it in a message store that a mail user agent is expected to subsequently access. A "relay" SMTP system (usually referred to just as a "relay") receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery.
この仕様は4つのタイプのSMTPシステムの中で区別をします、それらのシステムが電子メールを送る際に果たす役割に基づいて。 または、「起因する」システム(時々SMTP創始者と呼ばれる)がインターネットにメールを取り入れる、 より一般に、輸送サービス環境に。 「配送」SMTPシステムは次にアクセサリーに予想されて、それが輸送サービス環境からメールを受け取って、メールユーザエージェントにそれを渡すか、メールユーザエージェントがメッセージ店ですが、またはそれを預ける1つです。 「リレー」SMTPシステム(通常、ちょうど「リレー」に言及される)は、SMTPクライアントからメールを受け取って、それを伝えます、トレース情報を加えるのを除いたメッセージデータへの変更なしで、一層のリレーか配送のための別のSMTPサーバーに。
A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Differences in protocols or message semantics between the transport environments on either side of a gateway may require that the gateway system perform transformations to the message that are not permitted to SMTP relay systems. For the purposes of this specification, firewalls that rewrite addresses should be considered as gateways, even if SMTP is used on both sides of them (see RFC 2979 [27]).
「ゲートウェイ」SMTPシステム(通常、ちょうど「ゲートウェイ」に言及される)は、クライアントシステムから1つの輸送環境でメールを受け取って、別の輸送環境でサーバシステムにそれを伝えます。 この仕様の目的のために、アドレスを書き直すファイアウォールはゲートウェイであるとみなされるべきです、SMTPがそれらの両側で使用されても。ゲートウェイのどちらかの側面のプロトコルの違いか輸送環境の間のメッセージ意味論が、ゲートウェイシステムがメッセージへのSMTPリレー方式に受入れられない変換を実行するのを必要とするかもしれません。(RFC2979[27])を見てください。
2.3.11. Mailbox and Address
2.3.11. メールボックスとアドレス
As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited. The term "mailbox" refers to that depository. The two terms are typically used interchangeably unless the distinction between the location in which mail is placed (the mailbox) and a reference to it (the address) is important. An address normally consists of user and domain specifications. The standard mailbox naming convention is defined to be "local-part@domain"; contemporary usage permits a much broader set of applications than simple "user names". Consequently, and due to a long history of problems when intermediate hosts have attempted to
この仕様で使用されるように、「アドレス」はメールが送られるユーザかメールが預けられる位置を特定する文字列です。 「メールボックス」という用語はその貯蔵所について言及します。 メールが置かれる位置(メールボックス)とそれの参照(アドレス)の区別が重要でない場合、2つの用語が通常互換性を持って使用されます。 通常、アドレスはユーザとドメイン仕様から成ります。 一般的なメールボックス命名規則は" local-part@domain "になるように定義されます。 現代の用法は簡単な「ユーザ名」よりはるかに広いアプリケーションを可能にします。 その結果と、中間的であり問題の長い歴史のため、ホストは、試みました。
Klensin Standards Track [Page 15] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[15ページ]。
optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
単にそのドメインで指定されたホストによる解釈されて割り当てられた意味論がアドレスの一部であったに違いないならそれらを変更するのによる輸送、地方の部分を最適化してください。
2.4. General Syntax Principles and Transaction Model
2.4. 一般構文原則とトランザクションモデル
SMTP commands and replies have a rigid syntax. All commands begin with a command verb. All replies begin with a three digit numeric code. In some commands and replies, arguments are required following the verb or reply code. Some commands do not accept arguments (after the verb), and some reply codes are followed, sometimes optionally, by free form text. In both cases, where text appears, it is separated from the verb or reply code by a space character. Complete definitions of commands and replies appear in Section 4.
SMTPコマンドと回答には、堅い構文があります。 すべてのコマンドがコマンド動詞で始まります。 すべての回答が3ケタ数字コードで始まります。 いくつかのコマンドと回答では、動詞か回答コードに従って、議論が必要です。 いくつかのコマンドは主張(動詞の後の)を受け入れません、そして、いくつかの回答コードが任意に時々従われています、自由形式テキストで。 どちらの場合も、テキストが現れるところに、それは間隔文字によって動詞か回答コードと切り離されます。 コマンドと回答の完全な定義はセクション4に現れます。
Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command and extension name keywords) are not case sensitive, with the sole exception in this specification of a mailbox local-part (SMTP Extensions may explicitly specify case-sensitive elements). That is, a command verb, an argument value other than a mailbox local-part, and free form text MAY be encoded in upper case, lower case, or any mixture of upper and lower case with no impact on its meaning. The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP implementations MUST take care to preserve the case of mailbox local-parts. In particular, for some hosts, the user "smith" is different from the user "Smith". However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive.
動詞とパラメータ値(キーワードというRCPTコマンドと拡大名の例えば、「TO:」か「To:」)は大文字と小文字を区別していません、メールボックスの地方の部分のこの仕様による唯一の例外で(SMTP拡張子は明らかに大文字と小文字を区別する要素を指定するかもしれません)。 それはそうです、コマンド動詞、メールボックスの地方の部分以外のパラメータ値、そして、自由形式テキストが意味で大文字と小文字の大文字、小文字、またはどんな混合物の中にも影響なしでコード化されるかもしれません。 大文字と小文字を区別するとしてメールボックスの地方の部分を扱わなければなりません。 したがって、SMTP実装は、メールボックスの地方の部分に関するケースを保存するために注意されなければなりません。 何人かのホストにとって、ユーザ「鍛冶屋」はユーザ「スミス」と特に、異なっています。 しかしながら、メールボックスの地方の部分のケース感度を利用するのは、相互運用性を妨害して、お勧めできないです。 メールボックスドメインは、正常なDNS規則に従って、したがって、大文字と小文字を区別していません。
A few SMTP servers, in violation of this specification (and RFC 821) require that command verbs be encoded by clients in upper case. Implementations MAY wish to employ this encoding to accommodate those servers.
いくつかのSMTPサーバー、これを違反して仕様(そして、RFC821)はコマンド動詞がコード化されるのを必要とします。大文字の中のクライアントで。 実装は、それらのサーバを収容するのにこのコード化を使いたがっているかもしれません。
The argument clause consists of a variable-length character string ending with the end of the line, i.e., with the character sequence <CRLF>. The receiver will take no action until this sequence is received.
議論節は行の終わりで可変長の文字列結末から成ります、すなわち、キャラクタシーケンス<CRLF>で。 この系列が受け取られているまで、受信機は行動を全く取らないでしょう。
The syntax for each command is shown with the discussion of that command. Common elements and parameters are shown in Section 4.1.2.
各コマンドのための構文はそのコマンドの議論で示されます。 一般的な要素とパラメタはセクション4.1.2で見せられます。
Commands and replies are composed of characters from the ASCII character set [6]. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted, right justified, in an octet with the high-order bit cleared to zero. More specifically, the unextended SMTP service provides 7-bit
コマンドと回答はASCII文字の組[6]からキャラクタで構成されます。 輸送サービスが8ビットのバイト(八重奏)トランスミッションチャンネルを提供するとき、それぞれの7ビットのキャラクタは伝えられます、まさしく正当です、高位のビットがゼロまできれいにされている八重奏で。 より明確に、unextended SMTPサービスは7ビットで提供されます。
Klensin Standards Track [Page 16] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[16ページ]。
transport only. An originating SMTP client that has not successfully negotiated an appropriate extension with a particular server (see the next paragraph) MUST NOT transmit messages with information in the high-order bit of octets. If such messages are transmitted in violation of this rule, receiving SMTP servers MAY clear the high- order bit or reject the message as invalid. In general, a relay SMTP SHOULD assume that the message content it has received is valid and, assuming that the envelope permits doing so, relay it without inspecting that content. Of course, if the content is mislabeled and the data path cannot accept the actual content, this may result in the ultimate delivery of a severely garbled message to the recipient. Delivery SMTP systems MAY reject such messages, or return them as undeliverable, rather than deliver them. In the absence of a server- offered extension explicitly permitting it, a sending SMTP system is not permitted to send envelope commands in any character set other than US-ASCII. Receiving systems SHOULD reject such commands, normally using "500 syntax error - invalid character" replies.
輸送専用。 情報が八重奏の高位のビットにある状態で、首尾よく特定のサーバ(次のパラグラフを見る)と適切な拡大を交渉していない起因しているSMTPクライアントはメッセージを送ってはいけません。 そのようなメッセージがこの規則を違反して送られるなら、SMTPサーバーを受け取るのは、高いオーダービットをきれいにするか、またはメッセージが無効であると拒絶するかもしれません。 その内容を点検しないで、一般に、リレーSMTP SHOULDはそれが受け取ったメッセージ内容が有効であると仮定して、封筒が、そうするのを可能にすると仮定して、それをリレーします。 もちろん、内容が間違ったレッテルを貼られて、データ経路が実際の内容を受け入れることができないなら、これは受取人への厳しく誤り伝えられたメッセージの究極の配送をもたらすかもしれません。 配送SMTPシステムは、それらを提供するよりむしろそのようなメッセージを拒絶するか、または「非-提出物」としてそれらを返すかもしれません。 明らかにそれを可能にするサーバの提供された拡大がないとき、送付SMTPシステムが米国-ASCII以外のどんな文字集合でも封筒コマンドを送ることが許可されていません。 受電方式SHOULDはそのようなコマンド、通常使用している「500構文エラー--無効のキャラクタ」回答を拒絶します。
8-bit message content transmission MAY be requested of the server by a client using extended SMTP facilities, notably the "8BITMIME" extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP servers. However, it MUST NOT be construed as authorization to transmit unrestricted 8-bit material, nor does 8BITMIME authorize transmission of any envelope material in other than ASCII. 8BITMIME MUST NOT be requested by senders for material with the high bit on that is not in MIME format with an appropriate content-transfer encoding; servers MAY reject such messages.
8ビットのメッセージ内容送信はサーバについて拡張SMTP施設を使用しているクライアントによって要求されているかもしれません、著しく"8BITMIME"拡大、RFC1652[22]。 8BITMIME SHOULD、SMTPサーバーによってサポートされてください。 しかしながら、無制限な8ビットの材料を伝えるためにそれを承認に理解してはいけません、そして、8BITMIMEはASCII以外の中のどんな封筒の材料のトランスミッションも認可しません。 8BITMIMEは高いビットがオンの適切な満足している転送がコード化されているMIME形式にはない材料のために送付者によって要求されていてはいけません。 サーバはそのようなメッセージを拒絶するかもしれません。
The metalinguistic notation used in this document corresponds to the "Augmented BNF" used in other Internet mail system documents. The reader who is not familiar with that syntax should consult the ABNF specification in RFC 5234 [7]. Metalanguage terms used in running text are surrounded by pointed brackets (e.g., <CRLF>) for clarity. The reader is cautioned that the grammar expressed in the metalanguage is not comprehensive. There are many instances in which provisions in the text constrain or otherwise modify the syntax or semantics implied by the grammar.
本書では使用されるmetalinguistic記法は他のインターネット・メールシステムドキュメントで使用される「増大しているBNF」に対応しています。 その構文に詳しくない読者はRFC5234[7]でABNF仕様に相談するべきです。 明快のための先鋭な括弧(例えば、<CRLF>)によって広告のための活字原稿で使用されるメタ言語用語は囲まれます。 読者はメタ言語で表された文法が包括的でないと警告されます。 テキストの条項が文法によって含意された構文か意味論を抑制するか、またはそうでなければ変更する多くのインスタンスがあります。
3. The SMTP Procedures: An Overview
3. SMTP手順: 概要
This section contains descriptions of the procedures used in SMTP: session initiation, mail transaction, forwarding mail, verifying mailbox names and expanding mailing lists, and opening and closing exchanges. Comments on relaying, a note on mail domains, and a discussion of changing roles are included at the end of this section. Several complete scenarios are presented in Appendix D.
このセクションはSMTPで用いられた手順の記述を含みます: 交換をメールを転送して、メールボックス名について確かめて、メーリングリストを広げて、開いて、終えて、セッション開始はトランザクションを郵送してください。 リレーのコメント、メール・ドメインに関する注、および役割を変える議論はこのセクションの端に含まれています。 いくつかの完全なシナリオがAppendix Dに提示されます。
Klensin Standards Track [Page 17] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[17ページ]。
3.1. Session Initiation
3.1. セッション開始
An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.
クライアントがサーバに接続を開くと、SMTPセッションは開始されます、そして、サーバは初めのメッセージで反応します。
SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns. While some systems also identify their contact point for mail problems, this is not a substitute for maintaining the required "postmaster" address (see Section 4).
SMTPサーバー実装は220コードの後に接続挨拶回答における、それらのソフトウェアとバージョン情報の識別を含むかもしれません、どんな問題の、より効率的な分離と修理も可能にする習慣。実装は、安全上の配慮を引き起こすところでソフトウェアとバージョン発表を損傷するためにSMTPサーバーに備えるかもしれません。 また、いくつかのシステムがメール問題のためのそれらの接点を特定しますが、これは必要な「郵便局長」アドレスを維持する代用品(セクション4を見る)ではありません。
The SMTP protocol allows a server to formally reject a mail session while still allowing the initial connection as follows: a 554 response MAY be given in the initial connection opening message instead of the 220. A server taking this approach MUST still wait for the client to send a QUIT (see Section 4.1.1.10) before closing the connection and SHOULD respond to any intervening commands with "503 bad sequence of commands". Since an attempt to make an SMTP connection to such a system is probably in error, a server returning a 554 response on connection opening SHOULD provide enough information in the reply text to facilitate debugging of the sending system.
SMTPプロトコルで、サーバはまだ以下の初期の接続を許している間、正式にメールセッションを拒絶できます: 220の代わりに初期の接続初めのメッセージで554応答を与えるかもしれません。 このアプローチで取るサーバは、クライアントがQUITを送るのをまだ待たなければなりません。(接続とSHOULDを終える前の.10が)「コマンドの503の悪い系列」でどんな介入しているコマンドにも反応させるセクション4.1.1を見てください。 以来、SMTP接続をそのようなシステムにする試みはたぶん誤り(デバッグするのを容易にするほど初めのSHOULDが回答テキストの情報を提供する送付システムの接続のときに554応答を返すサーバ)中です。
3.2. Client Initiation
3.2. クライアント開始
Once the server has sent the greeting (welcoming) message and the client has received it, the client normally sends the EHLO command to the server, indicating the client's identity. In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports. Older SMTP systems that are unable to support service extensions, and contemporary clients that do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT return the extended EHLO- style response to a HELO command. For a particular connection attempt, if the server returns a "command not recognized" response to EHLO, the client SHOULD be able to fall back and send HELO.
いったんサーバが挨拶(歓迎する)メッセージを送って、クライアントがそれを受けると、通常、クライアントはEHLOコマンドをサーバに送ります、クライアントのアイデンティティを示して。 セッションを開くことに加えて、EHLOの使用は、クライアントがサービス拡大とサーバがそれがサポートする拡大のリストを提供するという要求を処理できるのを示します。 サービスが拡大であるとサポートすることができないより古いSMTPシステム、および開始されるメールセッションにおけるサービス拡大を必要としない現代のクライアントはEHLOの代わりにHELOを使用するかもしれません。 サーバはHELOコマンドへの拡張EHLOスタイル応答を返してはいけません。 特定の接続試みのために、サーバがEHLOへの「認識されなかったコマンド」応答を返すなら、クライアントSHOULDは後ろへ下がることができて、HELOを送ります。
In the EHLO command, the host sending the command identifies itself; the command may be interpreted as saying "Hello, I am <domain>" (and, in the case of EHLO, "and I support service extension requests").
EHLOコマンドで、コマンドを送るホストは身元を明らかにします。 「こんにちは、私は<ドメイン>(EHLOの場合では、「そして、私は、サービス拡大が要求であるとサポートする」)である」と言いながら、コマンドが解釈されるかもしれません。
Klensin Standards Track [Page 18] RFC 5321 SMTP October 2008
Klensin規格はSMTP2008年10月にRFC5321を追跡します[18ページ]。
3.3. Mail Transactions
3.3. トランザクションを郵送してください。
一覧
スポンサーリンク
