RFC4550 日本語訳
4550 Internet Email to Support Diverse Service Environments (Lemonade)Profile. S. Maes, A. Melnikov. June 2006. (Format: TXT=48790 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group S. Maes
Request for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
コメントを求めるワーキンググループS.メース要求をネットワークでつないでください: 4550年のオラクルカテゴリ: 標準化過程A.メリニコフIsode株式会社2006年6月
Internet Email to Support Diverse Service Environments
(Lemonade) Profile
環境(レモネード)が輪郭を描くさまざまのサービスをサポートするインターネットメール
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 document describes a profile (a set of required extensions, restrictions, and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission, and to efficiently resynchronize in case of loss of connectivity with the server.
このドキュメントはIMAPとメール服従プロトコルのプロフィール(1セットの必要な拡大、制限、および用法モード)について説明します。 このプロフィールで、クライアント(特にメモリ、帯域幅、処理能力、または他の領域で抑制されるもの)は、メールにアクセスして、提出するのに効率的にIMAPとSubmissionを使用できます。 メールをダウンロードして、アップロードして、服従を最適化して、サーバによる接続性の損失の場合に効率的に再連動する必要はなくて、これは受け取られていているメールを転送する能力を含んでいます。
The Internet Email to Support Diverse Service Environments (Lemonade) profile relies upon extensions to IMAP and Mail Submission protocols; specifically, the URLAUTH and CATENATE IMAP protocol (RFC 3501) extensions and the BURL extension to the SUBMIT protocol (RFC 4409).
Support Diverse Service Environments(レモネード)プロフィールへのインターネットメールはIMAPへの拡大とメールSubmissionプロトコルを当てにします。 明確に、URLAUTHとCATENATE IMAPプロトコル(RFC3501)拡大とSUBMITへのBURL拡張子は(RFC4409)について議定書の中で述べます。
Maes & Melnikov Standards Track [Page 1] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[1ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................3
2. Forward without Download ........................................3
2.1. Motivations ................................................3
2.2. Message Sending Overview ...................................4
2.3. Traditional Strategy .......................................4
2.4. Step-by-Step Description ...................................5
2.4.1. Message Assembly Using IMAP CATENATE Extension ......6
2.4.2. Message Assembly Using SMTP CHUNKING and
BURL Extensions ....................................10
2.5. Normative Statements Related to Forward without Download ..14
2.6. Security Considerations for "pawn-tickets" ................14
2.7. The fcc Problem ...........................................15
2.8. Registration of $Forwarded IMAP Keyword ...................15
3. Message Submission .............................................15
3.1. Pipelining ................................................16
3.2. DSN Support ...............................................16
3.3. Message Size Declaration ..................................16
3.4. Enhanced Status Code Support ..............................16
3.5. TLS .......................................................16
4. Quick Resynchronization ........................................16
5. Additional IMAP Extensions .....................................17
6. Summary of the Required IMAP and SMTP Extensions ...............17
7. Future work ....................................................18
8. Security Considerations ........................................18
8.1. Confidentiality Protection of Submitted Messages ..........19
8.2. TLS .......................................................19
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Acknowledgements ..............................................21
1. 序論…3 1.1. このドキュメントで中古のコンベンション…3 2. ダウンロードなしで進めます。3 2.1. 動機…3 2.2. メッセージ送信概要…4 2.3. 伝統的な戦略…4 2.4. 段階的な記述…5 2.4.1. IMAPカテナート拡張子を使用するメッセージアセンブリ…6 2.4.2. SMTP分魂化と節拡張子を使用するメッセージアセンブリ…10 2.5. 規範的陳述はダウンロードなしでフォワードに関連しました。14 2.6. 「質札」のためのセキュリティ問題…14 2.7. fcc Problem…15 2.8. $の登録はキーワードをIMAPに転送しました…15 3. メッセージ提案…15 3.1. パイプライン処理…16 3.2. DSNサポート…16 3.3. メッセージサイズ宣言…16 3.4. ステータスコードサポートを機能アップします…16 3.5. TLS…16 4. 迅速なResynchronization…16 5. 追加IMAP拡張子…17 6. 必要なIMAPとSMTP拡張子の概要…17 7. 今後の仕事…18 8. セキュリティ問題…18 8.1. 提出されたメッセージの秘密性保護…19 8.2. TLS…19 9. 参照…20 9.1. 標準の参照…20 9.2. 有益な参照…21 10. 承認…21
Maes & Melnikov Standards Track [Page 2] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[2ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
1. Introduction
1. 序論
Lemonade provides enhancements to Internet email to support diverse service environments.
レモネードは、さまざまのサービスが環境であるとサポートするためにインターネットメールに増進を提供します。
This document describes the Lemonade profile, which includes:
このドキュメントはLemonadeプロフィールについて説明します。(それは、以下の通りです)。
- "forward without download", which describes exchanges between
Lemonade clients and servers to allow new email messages to be
submitted incorporating content that resides on locations
external to the client.
- クライアントにとっての、外部の位置にある内容を取り入れながら提出されるべき新しいメールメッセージを許容するためにLemonadeクライアントとサーバの間の交換について説明する「ダウンロードのないフォワード。」
- Quick mailbox resynchronization using [CONDSTORE].
- 迅速なメールボックス再同期使用[CONDSTORE]。
- Several IMAP and SMTP extensions that save bandwidth and/or
number of round-trips required to send/receive data.
- 周遊旅行の帯域幅、そして/または、数を節約するいくつかのIMAPとSMTP拡張子がデータを送るか、または受け取るのが必要です。
The organization of this document is as follows. Section 2 describes "forward without download". Section 3 describes additional SMTP extensions that must be supported by all Lemonade Submission servers. Section 4 describes IMAP quick resynchronization.
このドキュメントの組織は以下の通りです。 セクション2は「ダウンロードのないフォワード」について説明します。 セクション3はすべてのLemonade Submissionサーバでサポートしなければならない追加SMTP拡張子について説明します。 セクション4はIMAPの迅速な再同期について説明します。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
In examples, "M:", "I:", and "S:" indicate lines sent by the client messaging user agent, IMAP e-mail server, and SMTP submit server, respectively.
例で「M:」、「私:」、「S:」 クライアントメッセージングユーザエージェント、IMAP Eメールサーバ、およびSMTPによって送られた系列がそれぞれサーバを提出するのを示してください。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
All examples in this document are optimized for Lemonade use and might not represent examples of proper protocol usage for a general use Submit/IMAP client. In particular, examples assume that Lemonade Submit and IMAP servers support all Lemonade extensions described in this document, so they don't show how to deal with absence of an extension.
Lemonadeが司令官のための適切なプロトコル用法に関する例を使用して、表さないかもしれないので、本書では最適化されたすべての例がSubmit/IMAPクライアントを使用します。 特に、例が、Lemonade SubmitとIMAPサーバが本書では説明されたすべてのLemonade拡張子をサポートすると仮定するので、それらは、どのように拡大の欠如に対処するかを示しません。
2. Forward without Download
2. ダウンロードなしで前進しています。
2.1. Motivations
2.1. 動機
The advent of client/server email using the [RFC3501], [RFC2821], and [SUBMIT] protocols has changed what formerly were local disk operations into repetitive network data transmissions.
[RFC3501]、[RFC2821]、および[SUBMIT]プロトコルを使用するクライアント/サーバメールの到来は、以前何が反復性のネットワークデータ伝送へのローカルディスク操作であるかを変えました。
Maes & Melnikov Standards Track [Page 3] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[3ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
Lemonade "forward without download" makes use of the [BURL] SUBMIT extension to enable access to external sources during the submission of a message. In combination with the IMAP [URLAUTH] extension, inclusion of message parts or even entire messages from the IMAP mail store is possible with a minimal trust relationship between the IMAP and SMTP SUBMIT servers.
「ダウンロードのないフォワード」がメッセージの服従の間、外部電源へのアクセスを可能にするために[BURL]SUBMIT拡張子の使用をするレモネード。 IMAP[URLAUTH]拡張子と組み合わせて、IMAPメール店からのメッセージ部分か全体のメッセージさえの包含はIMAPとSMTP SUBMITサーバとの最小量の信頼関係で可能です。
Lemonade "forward without download" has the advantage of maintaining one submission protocol, and thus avoids the risk of having multiple parallel and possibly divergent mechanisms for submission. The client can use Submit/SMTP [SUBMIT] extensions without these being added to IMAP. Furthermore, by keeping the details of message submission in the SMTP SUBMIT server, Lemonade "forward without download" can work with other message retrieval protocols such as Post Office Protocol (POP), Network News Transfer Protocol (NNTP), or whatever else may be designed in the future.
「ダウンロードのないフォワード」がその結果、1つの服従プロトコルを維持しながら利点を持っているレモネードは服従のために複数の平行でことによると分岐しているメカニズムを持つ危険を避けます。 クライアントは、IMAPに加えられながら、これらなしでSubmit/SMTP[SUBMIT]拡張子を使用できます。 その上、SMTP SUBMITサーバ、Lemonadeに「ダウンロードなしで前進していた」状態でメッセージ提案の詳細を保つことによって、ポストオフィスプロトコル(POP)、ネットワークの電子情報を転送するプロトコル(NNTP)などの他のメッセージ検索プロトコルによる仕事、または他のことなら何でも将来、設計される場合がありますように。
2.2. Message Sending Overview
2.2. メッセージ送信概要
The act of sending an email message can be thought of as involving multiple steps: initiation of a new draft, draft editing, message assembly, and message submission.
以下の複数のステップにかかわるとメールメッセージを送る行為を考えることができます: 新しい草稿、草稿編集、メッセージアセンブリ、およびメッセージ提案の開始。
Initiation of a new draft and draft editing takes place in the Mail User Agent (MUA). Frequently, users choose to save more complex messages on an [RFC3501] server (via the APPEND command with the \Draft flag) for later recall by the MUA and resumption of the editing process.
新しい草稿と草稿編集の開始はメール・ユーザー・エージェント(MUA)で行われます。 頻繁に、ユーザは、編集プロセスのMUAと再開で後のリコールのための[RFC3501]サーバ(Draftが旗を揚げさせる\があるAPPENDコマンドを通した)に関する、より複雑なメッセージを保存するのを選びます。
Message assembly is the process of producing a complete message from the final revision of the draft and external sources. At assembly time, external data is retrieved and inserted in the message.
メッセージアセンブリは草稿と外部電源の最終的な改正から完全なメッセージを出すプロセスです。 アセンブル時では、外部のデータは、メッセージに検索されて、挿入されます。
Message submission is the process of inserting the assembled message into the [RFC2821] infrastructure, typically using the [SUBMIT] protocol.
メッセージ提案は[SUBMIT]プロトコルを通常使用して、[RFC2821]インフラストラクチャに組み立てられたメッセージを挿入するプロセスです。
2.3. Traditional Strategy
2.3. 伝統的な戦略
Traditionally, messages are initiated, edited, and assembled entirely within an MUA, although drafts may be saved to an [RFC3501] server and later retrieved from the server. The completed text is then transmitted to a Message Submission Agent (MSA) for delivery.
メッセージは、完全にMUAの中で伝統的に、開始されて、編集されて、組み立てられます、草稿は、[RFC3501]サーバに保存されて、後でサーバから検索されるかもしれませんが。次に、完成したテキストは配送のためにMessage Submissionエージェント(MSA)に伝えられます。
Maes & Melnikov Standards Track [Page 4] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[4ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
There is often no clear boundary between the editing and assembly process. If a message is forwarded, its content is often retrieved immediately and inserted into the message text. Similarly, when external content is inserted or attached, the content is usually retrieved immediately and made part of the draft.
編集とアセンブリプロセスの間には、どんな透明な境界もしばしばあるというわけではありません。 メッセージを転送するなら、内容をすぐに、しばしば検索して、メッセージ・テキストに挿入します。 外部の内容が挿入されるか、または添付されるとき、同様に、内容は草稿の通常、すぐに、検索されて、人工の部分です。
As a consequence, each save of a draft and subsequent retrieve of the draft transmits that entire (possibly large) content, as does message submission.
結果、草稿でその後のセーブが検索するそれぞれ、草稿はその全体(ことによると大きい)の内容を伝えます、メッセージ提案のように。
In the past, this was not much of a problem, because drafts, external data, and the message submission mechanism were typically located on the same system as the MUA. The most common problem was running out of disk quota.
過去に、これは大した問題ではありませんでした、草稿、外部のデータ、およびメッセージ服従メカニズムがMUAと同じシステムに通常見つけられたので。 最も一般的な問題はディスク・クオータを使い果たしていました。
2.4. Step-by-Step Description
2.4. 段階的な記述
The model distinguishes among a Mail User Agent (MUA), an IMAP4Rev1 Server ([RFC3501]), and a SMTP submit server ([SUBMIT]), as illustrated in Figure 1.
モデルはメール・ユーザー・エージェント(MUA)(IMAP4Rev1 Server([RFC3501]))の中で区別します、そして、SMTPはサーバ([SUBMIT])を提出します、図1で例証されるように。
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server S) |
+--------------+
+--------------------+ +--------------+ | | <、-、-、-、-、-、-、-、-、-、-、--、|、|、| MUA(M)| | IMAPv4Rev1| | | | サーバ| | | ------------>| (サーバI) | +--------------------+ +--------------+ ^ | ^ | | | | | | | | | | | | | | | | | | | | | | | | v| | +--------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| SMTP| | | 提出してください。| |-----------------------------| サーバ| | (サーバS) | +--------------+
Figure 1: Lemonade "forward without download"
図1: レモネードは「ダウンロードなしで進めます」。
Lemonade "forward without download" allows a Messaging User Agent to compose and forward an e-mail combining fragments that are located in an IMAP server, without having to download these fragments to the client.
「ダウンロードのないフォワード」がMessaging UserエージェントにIMAPサーバで位置している断片を結合するメールを構成して、これらの断片をクライアントにダウンロードする必要はなくて転送させるレモネード。
Maes & Melnikov Standards Track [Page 5] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[5ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
There are two ways to perform "forward without download", based on where the message assembly takes place. The first uses an extended APPEND command [CATENATE] to edit a draft message in the message store and cause the message assembly on the IMAP server. The second uses a succession of BURL and BDAT commands to submit and assemble (through concatenation) message data from the client and external data fetched from the provided URL. The two subsequent sections provide step-by-step instructions on how "forward without download" is achieved.
「ダウンロードのない前進であっ」て、ベースで働く2つの方法がメッセージアセンブリが行われるところにあります。 1番目はメッセージ店で草稿メッセージを編集して、IMAPサーバでメッセージアセンブリを引き起こす拡張APPENDコマンド[CATENATE]を使用します。秒はBURLとクライアントからのメッセージデータと提供されたURLからとって来られた外部のデータを提出して、組み立てる(連結で)BDATコマンドの連続を使用します。 2つのその後のセクションが「ダウンロードのないフォワード」がどう達成されるかに関する段階的な指示を提供します。
2.4.1. Message Assembly Using IMAP CATENATE Extension
2.4.1. IMAPカテナート拡張子を使用するメッセージアセンブリ
In the [BURL]/[CATENATE] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [CATENATE] extension to [RFC3501] is then used to create the messages on the IMAP server by transmitting new text and assembling them. The [UIDPLUS] IMAP extension is used by the client in order to learn the Unique Identifier (UID) of the created messages. Finally, a [URLAUTH] format URL is given to a [SUBMIT] server for submission using the [BURL] extension.
Lemonade「ダウンロードのないフォワード」戦略の[BURL]/[CATENATE]異形では、メッセージは、初めは、構成されて、MUAの中で編集されます。 [RFC3501]への[CATENATE]拡大はその時、新しいテキストを伝えて、それらを組み立てることによってIMAPサーバにメッセージを作成するのにおいて使用されています。 [UIDPLUS]IMAP拡張子は、作成されたメッセージのUnique Identifier(UID)を学ぶのにクライアントによって使用されます。 最終的に、[BURL]拡張子を使用することで[URLAUTH]形式URLを服従のための[SUBMIT]サーバに与えます。
The flow involved to support such a use case consists of:
そのような使用がケースであるとサポートするためにかかわる流れは以下から成ります。
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below) and
fetches body structures (See [RFC3501]).
M: Iに--、任意である、クライアントがIMAPサーバに接続して、任意にTLSを始動する、(データの機密性が必要であるなら)認証、メールボックス(以下の例の「受信トレイ」)を開けて、ボディー構造([RFC3501]を見る)をとって来ます。
Example:
例:
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
"trip.txt")
"<960723163407.20117h@washington.example.com>"
"Your trip details" "BASE64" 4554 73) "MIXED"))
I: A0051 OK completed
M: A0051 UIDフェッチ25627(UID BODYSTRUCTURE)I: * 「161FETCH、(UID25627BODYSTRUCTURE(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」)無い無い「7ビット」1152 23)、(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」「名前」"trip.txt") "<960723163407.20117h@washington.example.com 、gt;、」 「あなたの旅行の詳細」、「BASE64"4554 73) 「Mixed」) 私:、」 完成したA0051 OK
M: {to I} The client invokes CATENATE (See [CATENATE] for details
of the semantics and steps) -- this allows the MUA to create
messages on the IMAP server using new data combined with one or
more message parts already present on the IMAP server.
M: Iに、クライアントはCATENATEを呼び出します(意味論とステップの詳細に関して[CATENATE]を見てください)--これで、MUAは、1つ以上のメッセージの部品が既に存在していた状態でIMAPサーバで結合された新しいデータを使用することでIMAPサーバにメッセージを作成できます。
Note that the example for this step doesn't use the LITERAL+
[LITERAL+] extension. Without LITERAL+, the new message is
constructed using 3 round-trips. If LITERAL+ is used, the new
message can be constructed using one round-trip.
このステップのための例がLITERAL+[LITERAL+]拡張子を使用しないことに注意してください。 +、LITERALのない新しいメッセージは、3つの周遊旅行を使用することで構成されます。 +がLITERALであるなら使用されている、1つの周遊旅行を使用することで新しいメッセージを構成できます。
Maes & Melnikov Standards Track [Page 6] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[6ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
M: A0052 APPEND Sent FLAGS (\Seen $MDNSent)
CATENATE (TEXT {475}
I: + Ready for literal data
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
M: URL "/INBOX;UIDVALIDITY=385759045/;
UID=25627/;Section=2.MIME" URL "/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2" TEXT {44}
I: + Ready for literal data
M:
M: --------------030308070208000400050907--
M: )
I: A0052 OK [APPENDUID 387899045 45] CATENATE Completed
M: A0052は送られた旗(\目にふれている$MDNSent)のカテナートを追加します。(テキスト475I: +は文字通りのデータのためにMを準備します: Message ID: <419399E1.6000505@caernarfon.example.org>M: 日付: 木曜日、2004年11月12日の16:57: 05 +0000M: From: ボブ Ar <bar@example.org 、gt;、M: MIMEバージョン: 1.0M: To: foo@example.net M: Subject: 私たちの休日旅行Mに関して: コンテントタイプ: 複合か混ぜられる。 M: 「境界=」------------「030308070208000400050907」M: M: --------------030308070208000400050907M: コンテントタイプ: テキスト/平野。 形式=が流れた、M: M: 私たちの旅行代理店はアップデートされたスケジュールを送りました。 M: M: 乾杯、M: ボブM: --------------030308070208000400050907M: 「URL」/受信トレイ; UIDVALIDITY=385759045/。 「UID=25627/; =2.MIMEを区分してください」というURL、」 /受信トレイ。 UIDVALIDITY=385759045/; UID=25627/; 2インチの=テキスト44Iを区分してください: +は文字通りのデータのためにMを準備します: M: --------------030308070208000400050907--M: ) 私: 完成したA0052OK[APPENDUID387899045 45]カテナート
M: {to I} The client uses GENURLAUTH command to request a URLAUTH
URL (see [URLAUTH]).
M: Iに、クライアントはURLAUTH URLを要求するGENURLAUTHコマンドを使用します([URLAUTH]を見てください)。
I: {to M} The IMAP server returns a URLAUTH URL suitable for later
retrieval with URLFETCH (see [URLAUTH] for details of the
semantics and steps).
私: Mに、IMAPサーバはURLFETCHとの後の検索に適したURLAUTH URLを返します(意味論とステップの詳細に関して[URLAUTH]を見てください)。
M: A0054 GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=2005-10-
28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45;expire=
2005-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: A0054 OK GENURLAUTH completed
M: A0054 GENURLAUTHは「: //bob.ar@example.org/Sent; をimapします」。 「UIDVALIDITY=387899045/; uid=45;は=2005-10- 28T23:59:59Zを吐き出します; urlauth=は+ bob.arを提出する」という内部の私: * GENURLAUTHは「: //bob.ar@example.org/Sent; をimapします」。 UIDVALIDITY=387899045/; uid=45; =2005-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: 「インターナル: 91354a473744909de610943775f92038」I: 完成したA0054 OK GENURLAUTH
M: {to S} The client connects to the mail submission server and
starts a new mail transaction. It uses BURL to let the SMTP
submit server fetch the content of the message from the IMAP
M: Sに、クライアントは、メール服従サーバに接続して、新しいメール取引を始めます。 それ、SMTPにサーバを提出させる用途BURLはIMAPからのメッセージの内容をとって来ます。
Maes & Melnikov Standards Track [Page 7] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[7ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
server. (See [BURL] for details of the semantics and steps.)
This allows the MUA to authorize the SMTP submit server to access
the message composed as a result of the CATENATE step. Note that
the second EHLO command is required after a successful STARTTLS
command. Also note that there might be a third required EHLO
command if the second EHLO response doesn't list any BURL options.
Section 2.4.2 demonstrates this.
サーバ(意味論とステップの詳細に関して[BURL]を見てください。) MUAはこれでSMTPを認可できます。CATENATEステップの結果、構成されたメッセージにアクセスするサーバを提出してください。 うまくいっているSTARTTLSが命令した後に2番目のEHLOコマンドが必要であることに注意してください。 また、2番目のEHLO応答が少しのBURLオプションも記載しないなら3番目の必要なEHLOコマンドがあるかもしれないことに注意してください。 セクション2.4 .2 これを示します。
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-CHUNKING
S: 250-AUTH PLAIN
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: MAIL FROM:<bob.ar@example.org>
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
S: 250 2.1.5 foo@example.net OK.
M: BURL imap://bob.ar@example.org/Sent;UIDVALIDITY=387899045/;
uid=45/;urlauth=submit+bar:internal:
91354a473744909de610943775f92038 LAST
S: 220 owlry.example.org ESMTP M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250パイプライン処理S: 250-BURL imap S: 250分魂化S: 250-AUTH平野S: 250-DSN S: 250サイズの10240000秒間: 250-STARTTLS S: 250ENHANCEDSTATUSCODES M: STARTTLS S: 220 TLSを始動するのにおいて準備ができる…TLS交渉、順次データはコード化されています… M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250パイプライン処理S: 250-BURL imap S: 250分魂化S: 250-AUTH平野S: 250-DSN S: 250サイズの10240000秒間: 250ENHANCEDSTATUSCODES M: AUTHの明瞭なaGFycnkAaGFycnkAYWNjaW8= S: 235 2.7.0 PLAIN認証うまくいきます。 M: FROM:<bob.ar@example.org に郵送してください、gt;、S: 250 2.5.0 OKを記述してください。 M: RCPT TO:<foo@example.net 、gt;、S: 250 2.1.5 foo@example.net OK。 M: BURL imap: //bob.ar@example.org/Sent;UIDVALIDITY =387899045/。 uid=45/; urlauth=は内部で以下を提出するか、または禁じます: 91354a473744909de610943775f92038最終
Maes & Melnikov Standards Track [Page 8] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[8ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
S: {to I} The mail submission server uses URLFETCH to fetch the
message to be sent. (See [URLAUTH] for details of the semantics
and steps. The so-called "pawn-ticket" authorization mechanism
uses a URI that contains its own authorization credentials.)
S: Iに、メール服従サーバは、送られるべきメッセージをとって来るのにURLFETCHを使用します。 (意味論とステップの詳細に関して[URLAUTH]を見てください。 いわゆる「質札」認可メカニズムはそれ自身の認可信任状を含むURIを使用します。)
I: {to S} Provides the message composed as a result of the
CATENATE step.
私: Sに、CATENATEステップの結果、構成されたメッセージは提供されています。
Mail submission server opens IMAP connection to the IMAP server:
メール服従サーバはIMAPサーバにIMAP接続を開きます:
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a000 STARTTLS
I: a000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038"
I: * URLFETCH "imap://bob.ar@example.org/Sent;
UIDVALIDITY=387899045/;uid=45/;urlauth=submit+bob.ar:
internal:91354a473744909de610943775f92038" {15065}
...message body follows...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
私: * [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+CATENATE URLAUTH UIDPLUS CONDSTORE IDLE]imap.example.com IMAPサーバ持ち合わせのSを承認してください: a000 STARTTLS I: 現在のa000 Start TLS交渉…TLS交渉で、うまくいきます--コード化された順次データ…。 S: a001 LOGIN submitserverの秘密の私: a001OK submitserverはSにログインしました: a002 URLFETCHは「: //bob.ar@example.org/Sent; をimapします」。 UIDVALIDITY=387899045/; uid=45/; urlauth=は+ bob.arを提出します: 「インターナル: 91354a473744909de610943775f92038」I: * URLFETCHは「: //bob.ar@example.org/Sent; をimapします」。 UIDVALIDITY=387899045/; uid=45/; urlauth=は+ bob.arを提出します: 「インターナル: 91354a473744909de610943775f92038」15065…メッセージ本体は続きます… S: a002のOK URLFETCHの完成した私: a003 LOGOUT S: * BYE、また後で、S: a003OK Logoutうまくいきます。
Note that if the IMAP server doesn't send CAPABILITY response code
in the greeting, the mail submission server must issue the
CAPABILITY command to learn about supported IMAP extensions as
described in RFC 3501.
IMAPサーバが挨拶における応答コードをCAPABILITYに送らないなら、メール服従サーバがRFC3501で説明されるように支持されたIMAP拡張子に関して学ぶCAPABILITYコマンドを発行しなければならないことに注意してください。
Also, if data confidentiality is not required, the mail submission
server may omit the STARTTLS command before issuing the LOGIN
command.
また、データの機密性は必要でないなら、LOGINコマンドを発行する前に、メール服従サーバがSTARTTLSコマンドを省略するかもしれません。
S: {to M} Submission server assembles the complete message, and if
the assembly succeeds, it returns OK to the MUA:
S: Mに、服従サーバは完全なメッセージを組み立てます、そして、アセンブリが成功するなら、OKをMUAに返します:
S: 250 2.5.0 Ok.
S: 250 2.5.0 OK。
M: {to I} The client marks the message containing the forwarded
attachment on the IMAP server.
M: Iに、クライアントはIMAPサーバに進められた付属を含むメッセージをマークします。
Maes & Melnikov Standards Track [Page 9] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[9ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
M: A0053 UIDは25627+FLAGS.SILENT(進められたドル)Iを格納します: * 215がとって来る、(UID25627MODSEQ(12121231000))I: 完成したA0053 OK STORE
Note: the UID STORE command shown above will only work if the
marked message is in the currently selected mailbox; otherwise, it
requires a SELECT. This command can be omitted. The untagged
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
is described in Section 2.8.
以下に注意してください。 現在選択されたメールボックスの中に著しいメッセージがある場合にだけ、上に示されたUID STOREコマンドは働くでしょう。 さもなければ、それはSELECTを必要とします。 このコマンドを省略できます。 untagged FETCH応答は[CONDSTORE]のためです。 $Forwarded IMAPキーワードはセクション2.8で説明されます。
2.4.2. Message Assembly Using SMTP CHUNKING and BURL Extensions
2.4.2. SMTP分魂化と節拡張子を使用するメッセージアセンブリ
In the [BURL]/[CHUNKING] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [SUBMIT], BURL [BURL] and BDAT [CHUNKING] commands are used to create the messages from multiple parts. New body parts are supplied using BDAT commands, while existing body parts are referenced using [URLAUTH] format URLs in BURL commands.
Lemonade「ダウンロードのないフォワード」戦略の[BURL]/[CHUNKING]異形では、メッセージは、初めは、構成されて、MUAの中で編集されます。 服従[SUBMIT]の間、BURL[BURL]とBDAT[CHUNKING]コマンドは、複数の部品からメッセージを作成するのに使用されます。 BDATコマンドを使用することで新しい身体の部分を供給します、既存の身体の部分はBURLコマンドに[URLAUTH]形式URLを使用することで参照をつけられますが。
The flow involved to support such a use case consists of:
流れがそのような使用にサポートにかかわったので、ケースは以下から成ります。
M: {to I -- Optional} The client connects to the IMAP server,
optionally starts TLS (if data confidentiality is required),
authenticates, opens a mailbox ("INBOX" in the example below), and
fetches body structures (see [RFC3501]).
M: Iに--、任意である、クライアントがIMAPサーバに接続して、任意にTLSを始動する、(データの機密性が必要であるなら)認証、メールボックス(以下の例の「受信トレイ」)を開けて、ボディー構造([RFC3501]を見る)をとって来ます。
Example:
例:
M: A0051 UID FETCH 25627 (UID BODYSTRUCTURE)
I: * 161 FETCH (UID 25627 BODYSTRUCTURE (("TEXT" "PLAIN"
("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)(
"TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME"
"trip.txt")
"<960723163407.20117h@washington.example.com>"
"Your trip details" "BASE64" 4554 73) "MIXED"))
I: A0051 OK completed
M: A0051 UIDフェッチ25627(UID BODYSTRUCTURE)I: * 「161FETCH、(UID25627BODYSTRUCTURE(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」)無い無い「7ビット」1152 23)、(「テキスト」「明瞭である」("CHARSET"「米国-ASCII」「名前」"trip.txt") "<960723163407.20117h@washington.example.com 、gt;、」 「あなたの旅行の詳細」、「BASE64"4554 73) 「Mixed」) 私:、」 完成したA0051 OK
M: {to I} The client uses GENURLAUTH command to request URLAUTH
URLs (see [URLAUTH]) referencing pieces of the message to be
assembled.
M: Iに、クライアントは組み立てられるようメッセージの断片に参照をつけるURLAUTH URL([URLAUTH]を見る)に要求するGENURLAUTHコマンドを使用します。
I: {to M} The IMAP server returns URLAUTH URLs suitable for later
retrieval with URLFETCH (see [URLAUTH] for details of the
semantics and steps).
私: MへのIMAPサーバはURLFETCHとの後の検索に適したURLをURLAUTHに返します(意味論とステップの詳細に関して[URLAUTH]を見てください)。
M: A0054 GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar"
M: A0054 GENURLAUTHは「: //bob.ar@example.org/INBOX; をimapします」。 UIDVALIDITY=385759045/; UID=25627/; セクションは2.MIMEと等しいです。 「=2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します」
Maes & Melnikov Standards Track [Page 10] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[10ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
INTERNAL "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar" INTERNAL
I: * GENURLAUTH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF"
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: A0054 OK GENURLAUTH completed
インターナル「imap: //bob.ar@example.org/INBOX; 」 UIDVALIDITY=385759045/; UID=25627/; セクション= 2。 「=2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出する」という内部の私: * GENURLAUTHは「: //bob.ar@example.org/INBOX; をimapします」。 UIDVALIDITY=385759045/; UID=25627/; セクションは2.MIMEと等しいです。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: 「インターナル: A0DEAD473744909de610943775f9BEEF」は「: //bob.ar@example.org/INBOX; をimapします」。 UIDVALIDITY=385759045/; UID=25627/; セクション= 2。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: インターナル: BEEFA0DEAD473744909de610943775f9" I: 完成したA0054 OK GENURLAUTH
M: {to S} The client connects to the mail submission server and
starts a new mail transaction. It uses BURL to instruct the SMTP
submit server to fetch from the IMAP server pieces of the message
to be sent (see [BURL] for details of the semantics and steps).
Note that the second EHLO command is required after a successful
STARTTLS command. The third EHLO command is required if and only
if the second EHLO response doesn't list any BURL options. See
Section 2.4.1 for an example of submission where the third EHLO
command/response is not present.
M: Sに、クライアントは、メール服従サーバに接続して、新しいメール取引を始めます。 それは、命令するのにBURLを使用します。SMTPは、IMAPからサーバ片の送られるべきメッセージをとって来るためにサーバを提出します(意味論とステップの詳細に関して[BURL]を見てください)。 うまくいっているSTARTTLSが命令した後に2番目のEHLOコマンドが必要であることに注意してください。 そして、3番目のEHLOコマンドが必要である、2番目のEHLO応答が少しのBURLオプションも記載しない場合にだけ。 3番目のEHLOコマンド/応答が存在していない服従の例に関してセクション2.4.1を見てください。
S: 220 owlry.example.org ESMTP
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5
S: 250-DSN
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES
M: STARTTLS
S: 220 Ready to start TLS
...TLS negotiation, subsequent data is encrypted...
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 220 owlry.example.org ESMTP M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250パイプライン処理S: 250節S: 250分魂化S: 250-AUTHダイジェスト-MD5 S: 250-DSN S: 250サイズの10240000秒間: 250-STARTTLS S: 250ENHANCEDSTATUSCODES M: STARTTLS S: 220 TLSを始動するのにおいて準備ができる…TLS交渉、順次データはコード化されています… M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250パイプライン処理S: 250節S: 250分魂化S: 250-AUTHのダイジェスト-MD5一夜漬け-MD5平野外部のS: 250-DSN
Maes & Melnikov Standards Track [Page 11] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[11ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
M: EHLO potter.example.org
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BINARYMIME
S: 250-PIPELINING
S: 250-BURL imap imap://imap.example.org
S: 250-CHUNKING
S: 250-AUTH DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL
S: 250-DSN
S: 250-SIZE 10240000
S: 250 ENHANCEDSTATUSCODES
M: MAIL FROM:<bob.ar@example.org> BODY=BINARY
S: 250 2.5.0 Address Ok.
M: RCPT TO:<foo@example.net>
S: 250 2.1.5 foo@example.net OK.
M: BDAT 475
M: Message-ID: <419399E1.6000505@caernarfon.example.org>
M: Date: Thu, 12 Nov 2004 16:57:05 +0000
M: From: Bob Ar <bar@example.org>
M: MIME-Version: 1.0
M: To: foo@example.net
M: Subject: About our holiday trip
M: Content-Type: multipart/mixed;
M: boundary="------------030308070208000400050907"
M:
M: --------------030308070208000400050907
M: Content-Type: text/plain; format=flowed
M:
M: Our travel agent has sent the updated schedule.
M:
M: Cheers,
M: Bob
M: --------------030308070208000400050907
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF
S: 250 2.5.0 OK
M: BURL imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9
S: 250 2.5.0 OK
S: 250サイズの10240000秒間: 250ENHANCEDSTATUSCODES M: AUTHの明瞭なaGFycnkAaGFycnkAYWNjaW8= S: 235 2.7.0 PLAIN認証うまくいきます。 M: EHLO potter.example.org S: 250-owlry.example.com S: 250-8BITMIME S: 250-BINARYMIME S: 250パイプライン処理S: 250-BURL imap imap://imap.example.org S: 250分魂化S: 250-AUTHのダイジェスト-MD5一夜漬け-MD5平野外部のS: 250-DSN S: 250サイズの10240000秒間: 250ENHANCEDSTATUSCODES M: FROM:<bob.ar@example.org に郵送してください、gt;、ボディー=バイナリーS: 250 2.5.0 OKを記述してください。 M: RCPT TO:<foo@example.net 、gt;、S: 250 2.1.5 foo@example.net OK。 M: BDAT475M: Message ID: <419399E1.6000505@caernarfon.example.org>M: 日付: 木曜日、2004年11月12日の16:57: 05 +0000M: From: ボブ Ar <bar@example.org 、gt;、M: MIMEバージョン: 1.0M: To: foo@example.net M: Subject: 私たちの休日旅行Mに関して: コンテントタイプ: 複合か混ぜられる。 M: 「境界=」------------「030308070208000400050907」M: M: --------------030308070208000400050907M: コンテントタイプ: テキスト/平野。 形式=が流れた、M: M: 私たちの旅行代理店はアップデートされたスケジュールを送りました。 M: M: 乾杯、M: ボブM: --------------030308070208000400050907秒間: 250 2.5.0 Mを承認してください: BURL imap: //bob.ar@example.org/INBOX; UIDVALIDITY=385759045/; UID=25627/; セクションは2.MIMEと等しいです。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: インターナル: A0DEAD473744909de610943775f9BEEF S: 250 2.5.0 Mを承認してください: BURL imap: //bob.ar@example.org/INBOX; UIDVALIDITY=385759045/; UID=25627/; セクション= 2。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: インターナル: BEEFA0DEAD473744909de610943775f9 S: 250 2.5.0 OK
Maes & Melnikov Standards Track [Page 12] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[12ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
M: BDAT 44 LAST
M:
M: --------------030308070208000400050907--
M: BDAT44最終M: M: --------------030308070208000400050907--
S: {to I} The mail submission server uses URLFETCH to fetch the
pieces of the message to be sent (see [URLAUTH] for details of the
semantics and steps). The so-called "pawn-ticket" authorization
mechanism uses a URI that contains its own authorization
credentials.
S: Iに、メール服従サーバは、送られるべきメッセージの断片をとって来るのにURLFETCHを使用します(意味論とステップの詳細に関して[URLAUTH]を見てください)。 いわゆる「質札」認可メカニズムはそれ自身の認可信任状を含むURIを使用します。
I: {to S} Returns the requested body parts.
私: 要求された身体の部分をSに返します。
Mail submission server opens IMAP connection to the IMAP server:
メール服従サーバはIMAPサーバにIMAP接続を開きます:
I: * OK [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+
CATENATE URLAUTH UIDPLUS CONDSTORE IDLE] imap.example.com
IMAP server ready
S: a001 LOGIN submitserver secret
I: a001 OK submitserver logged in
S: a002 URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" "imap://
bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9"
I: * URLFETCH "imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2.MIME;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:A0DEAD473744909de610943775f9BEEF" {84}
...message section follows...
"imap://bob.ar@example.org/INBOX;
UIDVALIDITY=385759045/;UID=25627/;Section=2;
expire=2006-10-28T23:59:59Z;urlauth=submit+bob.ar:
internal:BEEFA0DEAD473744909de610943775f9" {15065}
...message section follows...
S: a002 OK URLFETCH completed
I: a003 LOGOUT
S: * BYE See you later
S: a003 OK Logout successful
私: * [CAPABILITY IMAP4REV1 STARTTLS NAMESPACE LITERAL+CATENATE URLAUTH UIDPLUS CONDSTORE IDLE]imap.example.com IMAPサーバ持ち合わせのSを承認してください: a001 LOGIN submitserverの秘密の私: a001OK submitserverはSにログインしました: a002 URLFETCHは「: //bob.ar@example.org/INBOX; をimapします」。 UIDVALIDITY=385759045/; UID=25627/; セクションは2.MIMEと等しいです。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: 「インターナル: A0DEAD473744909de610943775f9BEEF」「imap:// bob.ar@example.org/INBOX; 」 UIDVALIDITY=385759045/; UID=25627/; セクション= 2。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: インターナル: BEEFA0DEAD473744909de610943775f9" I: * URLFETCHは「: //bob.ar@example.org/INBOX; をimapします」。 UIDVALIDITY=385759045/; UID=25627/; セクションは2.MIMEと等しいです。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: 「インターナル: A0DEAD473744909de610943775f9BEEF」84…メッセージ部は続きます… 「imap: //bob.ar@example.org/INBOX; 」 UIDVALIDITY=385759045/; UID=25627/; セクション= 2。 =2006-10-28T23:59:59Zを吐き出してください; urlauth=は+ bob.arを提出します: インターナル: BEEFA0DEAD473744909de610943775f9"15065…メッセージ部は続きます… S: a002のOK URLFETCHの完成した私: a003 LOGOUT S: * BYE、また後で、S: a003OK Logoutうまくいきます。
Note that if the IMAP server doesn't send CAPABILITY response code
in the greeting, the mail submission server must issue the
CAPABILITY command to learn about supported IMAP extensions as
described in RFC 3501.
IMAPサーバが挨拶における応答コードをCAPABILITYに送らないなら、メール服従サーバがRFC3501で説明されるようにサポートしているIMAP拡張子に関して学ぶCAPABILITYコマンドを発行しなければならないことに注意してください。
Maes & Melnikov Standards Track [Page 13] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[13ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
Also, if data confidentiality is required, the mail submission
server should start TLS before issuing the LOGIN command.
また、データの機密性が必要であるなら、LOGINコマンドを発行する前に、メール服従サーバはTLSを始動するべきです。
S: {to M} Submission server assembles the complete message, and if
the assembly succeeds, it acknowledges acceptance of the message
by sending 250 response to the last BDAT command:
S: Mに、服従サーバは完全なメッセージを組み立てます、そして、アセンブリが成功するなら、最後のBDATコマンドに250応答を送ることによって、メッセージの承認を承諾します:
S: 250 2.5.0 Ok, message accepted.
S: 250 2.5.0 OK、メッセージは受け入れました。
M: {to I} The client marks the message containing the forwarded
attachment on the IMAP server.
M: Iに、クライアントはIMAPサーバに進められた付属を含むメッセージをマークします。
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
M: A0053 UIDは25627+FLAGS.SILENT(進められたドル)Iを保存します: * 215がとって来る、(UID25627MODSEQ(12121231000))I: 完成したA0053 OK STORE
Note: the UID STORE command shown above will only work if the
marked message is in the currently selected mailbox; otherwise, it
requires a SELECT. This command can be omitted. The untagged
FETCH response is due to [CONDSTORE]. The $Forwarded IMAP keyword
is described in Section 2.8.
以下に注意してください。 現在選択されたメールボックスの中に著しいメッセージがある場合にだけ、上に示されたUID STOREコマンドは働くでしょう。 さもなければ、それはSELECTを必要とします。 このコマンドを省略できます。 untagged FETCH応答は[CONDSTORE]のためです。 $Forwarded IMAPキーワードはセクション2.8で説明されます。
2.5. Normative Statements Related to Forward without Download
2.5. ダウンロードなしで前方に関連する規範的陳述
Lemonade-compliant IMAP servers MUST support IMAP4Rev1 [RFC3501], CATENATE [CATENATE], UIDPLUS [UIDPLUS], and URLAUTH [URLAUTH]. This support MUST be declared via CAPABILITY [RFC3501].
レモネード対応することのIMAPサーバはIMAP4Rev1[RFC3501]、CATENATE[CATENATE]、UIDPLUS[UIDPLUS]、およびURLAUTH[URLAUTH]をサポートしなければなりません。 CAPABILITY[RFC3501]を通してこのサポートを宣言しなければなりません。
Lemonade-compliant submit servers MUST support BURL [BURL], 8BITMIME [8BITMIME], BINARYMIME [CHUNKING], and CHUNKING [CHUNKING]. This support MUST be declared via EHLO [RFC2821]. BURL MUST support URLAUTH type URLs [URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword (see [BURL] for more details).
サーバを提出してください。レモネード対応する、BURLが[BURL]と、8BITMIME[8BITMIME]と、BINARYMIME[CHUNKING]と、CHUNKING[CHUNKING]であることをサポートしなければなりません。 EHLO[RFC2821]を通してこのサポートを宣言しなければなりません。 BURL MUSTサポートURLAUTHはURL[URLAUTH]をタイプして、その結果、BURL EHLOキーワードに従って、"imap"オプションの広告を出さなければなりません(その他の詳細に関して[BURL]を見ます)。
Additional normative statements are provided in other sections.
追加規範的陳述を他のセクションに提供します。
2.6. Security Considerations for "pawn-tickets"
2.6. 「質札」のためのセキュリティ問題
The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [URLAUTH]. The advantage of this mechanism is that the SMTP submit [SUBMIT] server cannot access any data on the [RFC3501] server without a "pawn- ticket" created by the client.
いわゆる「質札」承認メカニズムはURIを使用します。(それは、[URLAUTH]を使用することでそれ自身の承認資格証明書を含みます)。 このメカニズムの利点はSMTPが[SUBMIT]サーバを提出するということです。クライアントによって作成された「歩のチケット」なしで[RFC3501]サーバに関する少しのデータにもアクセスできません。
The "pawn-ticket" grants access only to the specific data that the SMTP submit [SUBMIT] server is authorized to access, can be revoked by the client, and can have a time-limited validity.
交付金がSMTPが提出する特定のデータ[SUBMIT]だけにアクセスする「質札」サーバは、アクセスに認可されて、クライアントが取り消すことができて、期日の正当性を持つことができます。
Maes & Melnikov Standards Track [Page 14] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[14ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
2.7. The fcc Problem
2.7. fcc Problem
The "fcc problem" refers to delivering a copy of a message to a "file carbon copy" recipient. By far, the most common case of fcc is a client leaving a copy of outgoing mail in a "Sent Mail" or "Outbox" mailbox.
「fcc問題」は「ファイルカーボンコピー」受取人にメッセージのコピーを提供するのを示します。 fccの最も一般的なケースは断然、「送られたメール」か「送信トレイ」メールボックスの中に送信するメールのコピーを残すクライアントです。
In the traditional strategy, the MUA duplicates the effort spent in transmitting to the MSA by writing the message to the fcc destination in a separate step. This may be a write to a local disk file or an APPEND to a mailbox on an IMAP server. The latter is one of the "repetitive network data transmissions" that represents the "problem" aspect of the "fcc problem".
伝統的な戦略で、MUAは別々のステップにおけるfccの目的地にメッセージを書くことによってMSAに伝わるのに費やされた取り組みをコピーします。 これによるaがIMAPサーバにローカルディスクファイルかメールボックスへのAPPENDに書くということであるかもしれません。後者は「fcc問題」の「問題」局面を表す「反復性のネットワークデータ伝送」の1つです。
The [CATENATE] extension to [RFC3501] can be used to address the fcc problem. The final message is constructed in the mailbox designed for outgoing mail. Note that the [CATENATE] extension can only create a single message and only on the server that stages the outgoing message for submission. Additional copies of the message can be created on the same server using one or more COPY commands.
そのfcc問題を訴えるのに[RFC3501]への[CATENATE]拡張子を使用できます。 最終的なメッセージは送信するメールのために設計されたメールボックスの中に構成されます。 [CATENATE]拡大がただ一つのメッセージを作成できるだけであって、サーバだけでは、それが服従のための送信されるメッセージを上演することに注意してください。 同じサーバで1つ以上のCOPYコマンドを使用することでメッセージの複本を作成できます。
2.8. Registration of $Forwarded IMAP Keyword
2.8. $の登録はキーワードをIMAPに転送しました。
The $Forwarded IMAP keyword is used by several IMAP clients to specify that the message was resent to another email address, embedded within or attached to a new message. A mail client sets this keyword when it successfully forwards the message to another email address. Typical usage of this keyword is to show a different (or additional) icon for a message that has been forwarded. Once set, the flag SHOULD NOT be cleared.
$Forwarded IMAPキーワードは、メッセージが新しいメッセージへの埋め込まれたか添付の別のEメールアドレスに再送されたと指定するのに数人のIMAPクライアントによって使用されます。 それが首尾よく別のEメールアドレスにメッセージを転送するとき、メールクライアントはこのキーワードを設定します。 このキーワードの典型的な用法は転送されたメッセージのために異なって(追加する)のアイコンを見せていることです。 かつてのセット、旗のSHOULD NOT、クリアされてください。
Lemonade-compliant servers MUST be able to store the $Forwarded keyword. They MUST preserve it on the COPY operation. The servers MUST support the SEARCH KEYWORD $Forwarded.
レモネード対応することのサーバは$Forwardedキーワードを保存していなければなりません。 彼らはCOPY操作のときにそれを保存しなければなりません。 サーバは、SEARCH KEYWORD$がForwardedであるとサポートしなければなりません。
3. Message Submission
3. メッセージ提案
Lemonade-compliant mail submission servers are expected to implement the following set of SMTP extensions to make message submission efficient.
レモネード対応することのメール服従サーバがメッセージ提案を効率的にするように以下のセットのSMTP拡張子を実装すると予想されます。
Lemonade clients should take advantage of these features.
レモネードクライアントはこれらの特徴を利用するべきです。
Maes & Melnikov Standards Track [Page 15] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[15ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
3.1. Pipelining
3.1. パイプライン処理
Mobile clients regularly use networks with a relatively high latency. Avoidance of round-trips within a transaction has a great advantage for reduction in both bandwidth and total transaction time. For this reason, Lemonade-compliant mail submission servers MUST support the SMTP Service Extensions for Command Pipelining [RFC2920].
モバイルクライアントは定期的に比較的高い潜在があるネットワークを使用します。 トランザクションの中の周遊旅行の回避は帯域幅と総トランザクション時間の両方に減少のためのかなりの利点を持っています。 この理由で、Lemonade対応することのメール服従サーバはCommand Pipelining[RFC2920]のためにSMTP Service Extensionsをサポートしなければなりません。
Clients SHOULD pipeline SMTP commands when possible.
可能でありクライアントSHOULDパイプラインSMTPコマンド。
3.2. DSN Support
3.2. DSNサポート
Lemonade-compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461].
レモネード対応することのメール服従サーバは、配送状態通知[RFC3461]のためにSMTPサービスが拡大であるとサポートしなければなりません。
3.3. Message Size Declaration
3.3. メッセージサイズ宣言
Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC1870].
レモネード対応することのメール服従サーバはMessage Size Declaration[RFC1870]のためにSMTP Service Extensionをサポートしなければなりません。
Lemonade-compliant mail submission servers MUST "expand" all BURL parts before enforcing a message size limit.
メッセージサイズ限界を実施する前に、レモネード対応することのメール服従サーバはすべてのBURLの部品を「広げなければなりません」。
A Lemonade-compliant client SHOULD use message size declaration. In particular, it MUST NOT send a message to a mail submission server, if the client knows that the message exceeds the maximal message size advertised by the submission server.
Lemonade対応することのクライアントSHOULDはメッセージサイズ宣言を使用します。 特に、メール服従サーバにメッセージを送ってはいけません、クライアントが、メッセージが服従サーバによって広告に掲載された最大限度のメッセージサイズを超えているのを知っているなら。
3.4. Enhanced Status Code Support
3.4. 高められたステータスコードサポート
Lemonade-compliant mail submission servers MUST support SMTP Service Extension for Returning Enhanced Error Codes [RFC2034].
レモネード対応することのメール服従サーバはザ・リターニング/死霊のキラー・スートンEnhanced Error Codes[RFC2034]のためにSMTP Service Extensionをサポートしなければなりません。
3.5. TLS
3.5. TLS
Lemonade-compliant mail submission servers MUST support SMTP Service Extension for Secure SMTP over TLS [SMTP-TLS].
レモネード対応することのメール服従サーバはSecure SMTPのためにTLS[SMTP-TLS]の上でSMTP Service Extensionをサポートしなければなりません。
4. Quick Resynchronization
4. 迅速なResynchronization
Lemonade-compliant IMAP servers MUST support the CONDSTORE [CONDSTORE] extension. It allows a client to quickly resynchronize any mailbox by asking the server to return all flag changes that have occurred since the last known mailbox synchronization mark.
レモネード対応することのIMAPサーバは、CONDSTORE[CONDSTORE]が拡大であるとサポートしなければなりません。 それで、最後に知られているメールボックス同期マーク以来起こっているすべての旗の変化を返すようにサーバに頼むことによって、クライアントはどんなメールボックスもすぐに再連動させることができます。
[IMAP-DISC] shows how to perform quick mailbox resynchronization.
[IMAP-DISC]は、どのように迅速なメールボックス再同期を実行するかを示します。
Maes & Melnikov Standards Track [Page 16] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[16ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
5. Additional IMAP Extensions
5. 追加IMAP拡張子
Lemonade-compliant IMAP servers MUST support the NAMESPACE [NAMESPACE] extension. The extension allows clients to discover shared mailboxes and mailboxes belonging to other users.
レモネード対応することのIMAPサーバは、NAMESPACE[NAMESPACE]が拡大であるとサポートしなければなりません。 拡大で、クライアントは、共有されたメールボックスとメールボックスが他のユーザのものであると発見できます。
Lemonade-compliant IMAP servers MUST support the LITERAL+ [LITERAL+] extension. The extension allows clients to save a round-trip each time a non-synchronizing literal is sent.
レモネード対応することのIMAPサーバは+ [LITERAL+]拡大をLITERALにサポートしなければなりません。 拡大は非連動リテラルを送るたびにaを除いた往復にクライアントを許容します。
Lemonade-compliant IMAP servers MUST support the IDLE [IDLE] extension. The extension allows clients to receive instant notifications about changes in the selected mailbox, without needing to poll for changes.
レモネード対応することのIMAPサーバは、IDLE[IDLE]が拡大であるとサポートしなければなりません。 拡大で、変化に投票する必要はなくて、クライアントは選択されたメールボックスにおける変化に関する即時の通知を受け取ることができます。
Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by RFC 3501.
レモネード対応することのIMAPサーバは必要に応じてTLS[RFC3501]の上でRFC3501でIMAPをサポートしなければなりません。
6. Summary of the Required IMAP and SMTP Extensions
6. 必要なIMAPとSMTP拡張子の概要
-----------------------------------------------------|
| Name of SMTP extension | Comment |
|-------------------------|--------------------------|
| PIPELINING | Section 3.1 |
|-------------------------|--------------------------|
| DSN | Section 3.2 |
|-------------------------|--------------------------|
| SIZE | Section 3.3 |
|-------------------------|--------------------------|
| ENHANCEDSTATUSCODES | Section 3.4 |
|-------------------------|--------------------------|
| STARTTLS | Section 3.5 |
|-------------------------|--------------------------|
| BURL | Forward without download,|
| | Section 2 |
|-------------------------|--------------------------|
| URLAUTH support in BURL | Section 2.5 |
|-------------------------|--------------------------|
| CHUNKING, | Section 2.5 |
| BINARYMIME | Section 2.5 |
|-------------------------|--------------------------|
| 8BITMIME, | Required by BURL |
|-------------------------|--------------------------|
| AUTH | Required by Submission, |
| | See [SMTPAUTH]. |
|-------------------------|--------------------------|
-----------------------------------------------------| | SMTP拡張子の名前| コメント| |-------------------------|--------------------------| | パイプライン処理| セクション3.1| |-------------------------|--------------------------| | DSN| セクション3.2| |-------------------------|--------------------------| | サイズ| セクション3.3| |-------------------------|--------------------------| | ENHANCEDSTATUSCODES| セクション3.4| |-------------------------|--------------------------| | STARTTLS| セクション3.5| |-------------------------|--------------------------| | 節| ダウンロードなしで前進しています。| | | セクション2| |-------------------------|--------------------------| | BURLでのURLAUTHサポート| セクション2.5| |-------------------------|--------------------------| | 分魂化| セクション2.5| | BINARYMIME| セクション2.5| |-------------------------|--------------------------| | 8BITMIME| 節が必要です。| |-------------------------|--------------------------| | AUTH| 服従で、必要です。| | | [SMTPAUTH]を見てください。 | |-------------------------|--------------------------|
Maes & Melnikov Standards Track [Page 17] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[17ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
-----------------------------------------------------|
| Name of IMAP extension | Comment |
| or feature | |
|-------------------------|--------------------------|
| NAMESPACE | Section 5 |
|-------------------------|--------------------------|
| CONDSTORE | Section 4 |
|-------------------------|--------------------------|
| STARTTLS |Required by IMAP (RFC3501)|
|-------------------------|--------------------------|
| URLAUTH, | Forward without download,|
| CATENATE, | Section 2 |
| UIDPLUS | |
|-------------------------|--------------------------|
| LITERAL+ | Section 5 |
|-------------------------|--------------------------|
| IDLE | Section 5 |
|-------------------------|--------------------------|
| $Forwarded IMAP keyword | Section 2.8 |
|-------------------------|--------------------------|
-----------------------------------------------------| | IMAP拡張子の名前| コメント| | または、特徴| | |-------------------------|--------------------------| | 名前空間| セクション5| |-------------------------|--------------------------| | CONDSTORE| セクション4| |-------------------------|--------------------------| | STARTTLS|IMAP(RFC3501)が必要です。| |-------------------------|--------------------------| | URLAUTH| ダウンロードなしで前進しています。| | カテナート| セクション2| | UIDPLUS| | |-------------------------|--------------------------| | リテラル+| セクション5| |-------------------------|--------------------------| | 怠けてください。| セクション5| |-------------------------|--------------------------| | $はIMAPキーワードを転送しました。| セクション2.8| |-------------------------|--------------------------|
7. Future work
7. 今後の活動
The Lemonade Working Group is looking into additional issues related to usage of email by mobile devices, possibly including:
Lemonade作業部会はモバイル機器でメールの用法に関連する追加設定を調べることによると含みです:
- Media conversion (static and possibly streamed)
- Transport optimization for low or costly bandwidth and less
reliable mobile networks (e.g., quick reconnect)
- Server to client notifications, possibly outside of the
traditional IMAP band
- Dealing with firewall and intermediaries
- Compression and other bandwidth optimization
- Filtering
- Other considerations for mobile clients
- モバイルクライアントのためのメディア変換(静的でことによると流された)--低いか高価な帯域幅とそれほど信頼できないモバイルネットワーク(例えば、迅速に、再接続する)のための輸送最適化--クライアント通知へのサーバ、伝統的なIMAPバンドの外部--ファイアウォールと仲介者に対応します--ことによると圧縮、および他の帯域幅最適化--フィルタリング--他の問題
8. Security Considerations
8. セキュリティ問題
Security considerations on Lemonade "forward without download" are discussed throughout Section 2. Additional security considerations can be found in [RFC3501] and other documents describing other SMTP and IMAP extensions comprising the Lemonade profile.
セクション2中でLemonadeの上の問題が「ダウンロードなしで進める」セキュリティについて議論します。 Lemonadeプロフィールを包括しながら、他のSMTPとIMAP拡張子について説明する[RFC3501]と他のドキュメントで追加担保問題を見つけることができます。
Note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [SUBMIT]. The mandatory-to-implement authentication mechanism for IMAP is described in [RFC3501].
SMTP服従のための実装するために義務的な認証機構が[SUBMIT]で説明されることに注意してください。 IMAPに、実装するために義務的な認証機構は[RFC3501]で説明されます。
Maes & Melnikov Standards Track [Page 18] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[18ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
8.1. Confidentiality Protection of Submitted Messages
8.1. 提出されたメッセージの秘密性保護
When clients submit new messages, link protection such as TLS guards against an eavesdropper seeing the contents of the submitted message. It's worth noting, however, that even if TLS is not used, the security risks are no worse if BURL is used to reference the text than if the text is submitted directly. If BURL is not used, an eavesdropper gains access to the full text of the message. If BURL is used, the eavesdropper may or may not be able to gain such access, depending on the form of BURL used. For example, some forms restrict use of the URL to an entity authorized as a submission server or a specific user.
クライアントが新しいメッセージを提出するとき、TLSなどのリンク保護は提出されたメッセージのコンテンツを見る立ち聞きする者に用心します。 しかしながら、BURLがテキストに参照をつけるのに使用され、TLSが使用されていなくても、セキュリティリスクが、より悪くないことに注意する価値がある、直接テキストを提出するなら。 BURLが使用されていないなら、立ち聞きする者はメッセージの全文へのアクセスを得ます。 BURLが使用されているなら、立ち聞きする者はそのようなアクセスを得ることができるかもしれません、使用されるBURLのフォームによって。 例えば、いくつかのフォームがURLの使用を服従サーバか特定のユーザとして認可された実体に制限します。
8.2. TLS
8.2. TLS
When Lemonade clients use the BURL extension to mail submission, which requires sending a URLAUTH token to the mail submission server, such a token should be protected from interception to avoid a replay attack that may disclose the contents of the message to an attacker. TLS-based encryption of the mail submission path will provide protection against this attack.
Lemonadeクライアントがメール服従サーバにURLAUTHトークンを送るのを必要とする服従を郵送するのにBURL拡張子を使用すると、そのようなトークンは、メッセージのコンテンツを攻撃者に明らかにするかもしれない反射攻撃を避けるために妨害から保護されるべきです。 メール服従経路のTLSベースの暗号化はこの攻撃に対する保護を提供するでしょう。
Lemonade clients SHOULD use TLS-protected IMAP and mail submission channels when using BURL-based message submission to protect the URLAUTH token from interception.
妨害からURLAUTHトークンを保護するのにBURLベースのメッセージ提案を使用するとき、レモネードクライアントSHOULDはTLSによって保護されたIMAPとメール服従チャンネルを使用します。
Lemonade-compliant mail submission servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token provided by the Lemonade client.
Lemonadeクライアントによって提供されたURLAUTHトークンを使用することでメッセージ内容をとって来るとき、レモネード対応することのメール提案サーバSHOULDはTLSによって保護されたIMAP接続を使用します。
When a client uses SMTP STARTTLS to send a BURL command that references non-public information, there is a user expectation that the entire message content will be treated confidentially. To meet this expectation, the message submission server should use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.
クライアントがそこでその参照非公開情報をBURLコマンドに送るSMTP STARTTLSを使用すると、全体のメッセージ内容をあるユーザ期待は秘密に扱われますか? この期待に合うように、メッセージ服従サーバはそのURLによって参照をつけられる内容をとって来るとき、同等なデータの機密性を提供しながら、STARTTLSかメカニズムを使用するべきです。
Maes & Melnikov Standards Track [Page 19] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[19ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468,
May 2006.
ニューマン、C.「メッセージ服従節拡張子」という[節](RFC4468)は2006がそうするかもしれません。
[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月。
[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月。
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[カテナート] レズニック、P.、「インターネットメッセージアクセス・プロトコル(IMAP)カテナート拡大」、RFC4469、2006年4月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) -
UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、「インターネットMessage Accessプロトコル(IMAP)--、UIDPLUS拡張子、」、RFC4315、12月2005日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, September 2000.
解放された[RFC2920]、N.、「コマンド連続送信のためのSMTPサービス拡張子」、STD60、RFC2920、2000年9月。
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC
1870, November 1995.
[RFC1870]Klensin、J.、解放されています、N.、およびK.ムーア、「SMTPはメッセージサイズ宣言のための拡大を修理します」、STD10、RFC1870、1995年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[提出します] GellensとR.とJ.Klensin、「メールのためのメッセージ提案」、RFC4409、2006年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]ホフマン、P.、「トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子」、RFC3207、2002年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[RFC3461]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
Maes & Melnikov Standards Track [Page 20] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[20ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--URLAUTH拡張子」、RFC4467、5月2006日
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, October 1996.
解放された[RFC2034]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[名前空間] Gahrns、M.、およびC.ニューマン(「IMAP4名前空間」、RFC2342)は1998がそうするかもしれません。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[SMTPAUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[LITERAL+] マイアーズ、J.、「IMAP4非連動誤字誤植」、RFC2088、1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
メリニコフ、A.、およびS.が掘る[CONDSTORE]、「条件付きの店舗運営か迅速な旗のためのIMAP拡張子はResynchronizationを変えます」、RFC4551、2006年6月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IDLE] Leiba、B.、「IMAP4 IDLEコマンド」、RFC2177、1997年6月。
9.2. Informative References
9.2. 有益な参照
[IMAP-DISC] Melnikov, A., "Synchronization operations for
disconnected IMAP4 clients", Work in Progress, October
2004.
[IMAP-DISC] メリニコフ、A.、「外されたIMAP4クライアントのための同期操作」、Progress、2004年10月のWork。
10. Acknowledgements
10. 承認
This document is a product of Lemonade WG. The editors thank the Lemonade WG members that contributed comments and corrections; in particular: Randy Gellens, Dave Cridland, and Greg Vaudreuil.
このドキュメントはLemonade WGの製品です。 エディタはコメントと修正を寄付したLemonade WGメンバーに感謝します。 特に: ランディGellens、デーヴCridland、およびグレッグ・ボードルイ。
This document borrows some text from "Message Submission" (February 2004) by Mark Crispin, as well as from the trio [BURL], [CATENATE], and [URLAUTH].
このドキュメントはマーク・クリスピンが「メッセージ提案」(2004年2月)から何らかのテキストを借ります、よく三つ組の[BURL]、[CATENATE]、および[URLAUTH]のように。
Maes & Melnikov Standards Track [Page 21] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[21ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
Authors' Addresses
作者のアドレス
Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA
ステファーヌH.メースオラクル株式会社500オラクル公園道路M/S4op634アカスギ岸、カリフォルニア94065米国
Phone: +1-650-607-6296 EMail: stephane.maes@oracle.com
以下に電話をしてください。 +1-650-607-6296 メールしてください: stephane.maes@oracle.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
AlexeyメリニコフIsode株式会社5城のビジネス村の36駅のRoadハンプトン、ミドルセックスTW12 2BXイギリス
EMail: Alexey.melnikov@isode.com
メール: Alexey.melnikov@isode.com
Maes & Melnikov Standards Track [Page 22] RFC 4550 Lemonade Profile June 2006
メースとメリニコフ標準化過程[22ページ]RFC4550レモネードは2006年6月の輪郭を描きます。
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)によって提供されます。
Maes & Melnikov Standards Track [Page 23]
メースとメリニコフ標準化過程[23ページ]
一覧
スポンサーリンク
