Network Working Group S. Maes
Request for Comments: 4550 Oracle
Category: Standards Track A. Melnikov
Isode Ltd.
June 2006
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（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やメール提出プロトコルのプロファイル（必要な拡張機能、制約、および使用モードのセット）を記述します。このプロファイルは、クライアント（メモリ、帯域幅、処理能力、または他の領域に制約されることが特に）が効率的にアクセスしてメールを提出するIMAPおよび提出を使用することができます。これは、提出を最適化するために、かつ効率的にサーバーとの接続が失われた場合に再同期するために、ダウンロードしてメールをアップロードすることなく、受信したメールを転送する機能が含まれています。
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).
多様なサービス環境をサポートするインターネット電子メール（レモネード）プロファイルは、IMAPやメール発信プロトコルの拡張機能に依存しています。具体的には、URLAUTHとCATENATE IMAPプロトコル（RFC 3501）の拡張とSUBMITプロトコル（RFC 4409）にバール拡張。
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
Lemonade provides enhancements to Internet email to support diverse service environments.
レモネードは、多様なサービス環境をサポートするために、インターネット電子メールの機能強化を提供します。
This document describes the Lemonade profile, which includes:
この文書では、レモネードプロファイルを、説明します。
- "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.
- レモネードクライアントとサーバ間の交流が新しい電子メールメッセージがクライアントに外部の場所に存在するコンテンツを組み込んで提出できるように説明し、「前方ダウンロードなし」。
- 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節では、すべてのレモネードの提出・サーバによってサポートされている必要があり、追加のSMTPの拡張機能について説明します。第4節では、IMAP迅速な再同期を説明しています。
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：」、「I：」、および「S：」はIMAP電子メールサーバー、クライアントのメッセージングのユーザエージェントによって送信された線を示し、および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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
このドキュメントのすべての例は、レモネードの使用に最適化され、および/ IMAPクライアントを提出する一般的な使用のために適切なプロトコルの使用例を表していない可能性があります。具体的には、例がレモネードを提出し、IMAPサーバがこの文書に記載されているすべてのレモネード拡張をサポートしているので、彼らは拡張子がない場合に対処する方法を示していないことを前提としています。
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]クライアント/サーバーの電子メールの登場以前は、繰り返し、ネットワークデータの送信にローカルディスク操作が何であったか変更されました。
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サーバを提出の間の最小の信頼関係を有することが可能です。
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.
「ダウンロードせずに前方」レモネード一の提出プロトコルを維持するという利点を有し、従って、提出するための複数の平行及びおそらく発散機構を有する危険性を回避します。クライアントは、これらがIMAPに追加されることなく拡張を[SUBMIT]送信/ SMTPを使用することができます。さらに、サーバーをSUBMIT SMTPでメッセージ送信の詳細を保つことによって、「ダウンロードせずに前進」レモネードは、ポストオフィスプロトコル（POP）、ネットワークニュース転送プロトコル（NNTP）、または任意の他かもしれなどの他のメッセージ検索プロトコルで動作することができます将来的には設計されています。
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によってリコールや編集プロセスの再開のために（\ドラフトフラグとAPPENDコマンドを使って）[RFC3501]サーバ上でより複雑なメッセージを保存することを選択しました。
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.
メッセージの送信は、典型的には、[登録]プロトコルを使用して、[RFC2821]のインフラに組み込まメッセージを挿入するプロセスです。
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.
ドラフトは、[RFC3501]サーバに保存し、後でサーバから取得してもよいが、伝統的に、メッセージは、開始、編集、MUA内に完全に組み立てられています。完成したテキストは、配信のためにメッセージ服従エージェント（MSA）に送信されます。
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と同じシステム上に配置したので、過去において、これは、問題の多くはなかったです。最も一般的な問題は、ディスククォータが不足していました。
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のサーバー（[RFC3501]）を区別する、図1に示すようにSMTPは、（[SUBMIT]）サーバを提出します。
+--------------------+ +--------------+
| | <------------ | |
| MUA (M) | | IMAPv4Rev1 |
| | | Server |
| | ------------> | (Server I) |
+--------------------+ +--------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | v
| | +--------------+
| |----------------------> | SMTP |
| | Submit |
|-----------------------------| Server |
| (Server 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.
レモネードは「前方、ダウンロードせずに、」メッセージングユーザーエージェントが構成し、クライアントにこれらの断片をダウンロードすることなく、IMAPサーバに配置された断片を組み合わせた電子メールを転送することができます。
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つの方法があります。最初は、メッセージストアにドラフトメッセージを編集して、IMAPサーバー上のメッセージのアセンブリを引き起こすように拡張APPENDコマンド[CATENATE]を使用しています。第二は、BURLとBDATの連続は、（連結を通じて）メッセージクライアントからのデータと提供されたURLから取得した外部データを提出してアセンブルするためにコマンドを使用しています。 2次のセクションでは、「前方のダウンロードなし」が達成される方法について順を追って説明しています。
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.
[BURL] / [CATENATE]「ダウンロードせずに前進」レモネードの変形戦略では、メッセージが最初に構成され、MUA内で編集します。 [RFC3501]に[CATENATE]拡張は、新しいテキストを送信し、それらを組み立てることにより、IMAPサーバー上のメッセージを作成するために使用されます。 [UIDPLUS] IMAP拡張子が作成されたメッセージの一意識別子（UID）を学ぶために、クライアントによって使用されます。最後に、[URLAUTH]形式のURLは、[BURL]拡張機能を使用して提出する[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を開始認証、メールボックス（以下の例では、「INBOX」）を開き、身体構造をフェッチ（参照[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: {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 +がなければ、新しいメッセージは3ラウンドトリップを使用して構築されます。 LITERAL +を使用する場合は、新しいメッセージが1往復を使用して構築することができます。
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: {to I} The client uses GENURLAUTH command to request a URLAUTH URL (see [URLAUTH]).
M：クライアントはURLAUTHのURLを要求するGENURLAUTHコマンドを使用して、{I}に（[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).
I：IMAPサーバは（意味論および手順の詳細については、[URLAUTH]参照）のURLfetchと後で検索するのに適したURLAUTHのURLを返し{M}に。
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: {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 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.
Mは：{S}にクライアントがメール送信サーバに接続し、新しいメールトランザクションを開始します。これは、SMTPサーバがIMAPサーバからのメッセージの内容をフェッチ提出できるようにBURLを使用しています。 （意味論および手順の詳細については、[BURL]を参照。）これは、MUAはCATENATE工程の結果として、構成されたメッセージにアクセスするためのSMTPサーバを提出承認することを可能にします。二EHLOコマンドが成功したSTARTTLSコマンドの後に必要とされることに注意してください。また、第二EHLO応答は任意のBURLのオプションが表示されない場合には第三の必須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バールの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 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 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認証に成功。 M：MAIL FROM：<bob.ar@example.org> S：250 2.5.0アドレス[OK]をクリックします。 M：RCPT TO：<foo@example.net> S：250 2.1.5 foo@example.net OK。 M：バール・IMAP：//bob.ar@example.org/Sent; UIDVALIDITY = 387899045 /; UID = 45 /; urlauth = +バーを提出：内部：91354a473744909de610943775f92038 LAST
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.
I：{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
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サーバは挨拶で能力応答コードを送信しない場合は、メール送信サーバは、RFC 3501で説明したように、サポート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}に提出サーバーは、完全なメッセージを組み立て、組み立てが成功した場合、それは、MUAにOKを返します。
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サーバ上の転送添付ファイルを含むメッセージをマーク。
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（UID 25627 MODSEQ（12121231000））をFETCH 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が必要です。このコマンドは、省略することができます。タグ無しFETCH応答は[CONDSTORE]によるものです。 $転送されたIMAPキーワードは、セクション2.8に記載されています。
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.
「前方ダウンロードなし」レモネード戦略の[BURL] / [CHUNKING]変形例では、メッセージが最初に構成され、MUA内で編集します。提出時には[SUBMIT]、BURL [BURL]とBDATコマンドは、複数の部品からのメッセージを作成するために使用されている[CHUNKING]。既存の身体部分がバールコマンドで[URLAUTH]形式のURLを使用して参照しながら、新たな身体の部分は、BDATコマンドを使用して供給されます。
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を開始認証、メールボックス（以下の例では、「INBOX」）を開き、本体構造は（参照フェッチ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: {to I} The client uses GENURLAUTH command to request URLAUTH URLs (see [URLAUTH]) referencing pieces of the message to be assembled.
Mは：{I}をクライアントが組み立てられるメッセージの部分を参照する（[URLAUTH]参照）URLAUTH URLを要求する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).
I：{M}にIMAPサーバはのURLfetchと後の検索のために適したURLAUTH URLを（意味論および手順の詳細については、[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"
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
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を使用します。二EHLOコマンドが成功したSTARTTLSコマンドの後に必要とされることに注意してください。二EHLO応答は任意のBURLのオプションが表示されない場合にのみあれば第三EHLOコマンドが必要です。第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 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 TLS ... TLSネゴシエーションを開始する準備ができて、後続のデータが暗号化されています。 .. M：EHLO potter.example.org S：250-owlry.example.com S：250-8BITMIME S：250 BINARYMIME S：250パイプラインS：250 BURL S：250-CHUNKING S：250-AUTH DIGEST -MD5 CRAM-MD5 PLAIN EXTERNAL S：250-DSN
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
M: BDAT 44 LAST
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
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サーバは挨拶で能力応答コードを送信しない場合は、メール送信サーバは、RFC 3501で説明したように、サポートIMAP拡張について学ぶためにCAPABILITYコマンドを発行しなければならないことに注意してください。
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（UID 25627 MODSEQ（12121231000））をFETCH 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が必要です。このコマンドは、省略することができます。タグ無しFETCH応答は[CONDSTORE]によるものです。 $転送されたIMAPキーワードは、セクション2.8に記載されています。
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]、8BITMIME [8BITMIME]、BINARYMIME [CHUNKING]、およびCHUNKING [CHUNKING] BURLをサポートしなければならない提出します。このサポートは、EHLO [RFC2821]で宣言しなければなりません。 BURLは[URLAUTH] URLAUTHタイプのURLをサポートしなければならないので、（詳細は[BURL]参照）BURL EHLOキーワード以下「IMAP」オプションを宣伝しなければなりません。
Additional normative statements are provided in other sections.
追加の規範文は、他のセクションで提供されています。
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.
いわゆる「質屋・チケット」の認証メカニズムは、[URLAUTH]を使用して、独自の認証資格情報が含まれているURIを使用しています。このメカニズムの利点は、SMTPサーバがクライアントによって作成された「質屋・チケット」なし[RFC3501]サーバー上のデータにアクセスすることはできません[SUBMIT]提出するということです。
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]提出し、期間限定の妥当性を持つことができ、特定のデータにアクセスできます。
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への送信に費やされる労力を複製します。これは、ローカルディスクのファイルへの書き込みまたはIMAPサーバー上のメールボックスへのAPPENDかもしれません。後者は、「FCCの問題」の「問題」の態様を表し、「反復ネットワーク・データ伝送」の一つです。
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.
[RFC3501]に[CATENATE]拡張は、FCCの問題に対処するために使用することができます。最後のメッセージは、送信メール用に設計されたメールボックスに構成されています。 [CATENATE]拡張子のみのみ提出するための送信メッセージをステージサーバー上で単一のメッセージを作成することができることに注意してください。メッセージの追加コピーは、一つ以上のCOPYコマンドを使用して、同じサーバー上に作成することができます。
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.
$転送されたIMAPキーワードは、メッセージは、別のメールアドレスに再送内に埋め込まれたり、新しいメッセージに添付されたことを指定するには、いくつかのIMAPクライアントによって使用されます。それが成功した別のメールアドレスにメッセージを転送するとき、メールクライアントは、このキーワードを設定します。このキーワードの典型的な使用法は、転送されたメッセージに対して異なる（または追加の）アイコンを表示することです。一度設定すると、フラグをクリアしないでください。
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.
レモネード準拠のサーバーは、$転送されたキーワードを保存することができなければなりません。彼らは、COPY操作でそれを保存しなければなりません。サーバは、転送された検索キーワード$をサポートしなければなりません。
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.
レモネードクライアントは、これらの機能を活用する必要があります。
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].
モバイルクライアントは、定期的に、比較的高い待ち時間でネットワークを使用しています。トランザクション内のラウンドトリップの回避は、帯域幅と総トランザクション時間の両方の削減のための大きな利点を持っています。このため、レモネード準拠のメール送信サーバは、コマンドパイプライン[RFC2920]のためのSMTPサービス拡張をサポートしなければなりません。
Clients SHOULD pipeline SMTP commands when possible.
クライアントは、可能な場合はパイプラインSMTPコマンドをする必要があります。
Lemonade-compliant mail submission servers MUST support SMTP service extensions for delivery status notifications [RFC3461].
レモネード・苦情メール送信サーバは、配信状態通知[RFC 3461]のためのSMTPサービス拡張をサポートしなければなりません。
Lemonade-compliant mail submission servers MUST support the SMTP Service Extension for Message Size Declaration [RFC1870].
レモネード準拠のメール送信サーバは、メッセージサイズ宣言[RFC1870]のためのSMTPサービス拡張をサポートしなければなりません。
Lemonade-compliant mail submission servers MUST "expand" all BURL parts before enforcing a message size limit.
レモネード準拠のメール送信サーバは、メッセージサイズの制限を強制する前に、すべてのバール・部品を「拡大」しなければなりません。
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-compliant mail submission servers MUST support SMTP Service Extension for Returning Enhanced Error Codes [RFC2034].
レモネード準拠のメール送信サーバは、強化されたエラーコード[RFC2034]を返すためのSMTPサービス拡張をサポートしなければなりません。
Lemonade-compliant mail submission servers MUST support SMTP Service Extension for Secure SMTP over TLS [SMTP-TLS].
レモネード準拠のメール送信サーバはTLS [SMTP-TLS]を介してセキュアなSMTPのためのSMTPサービス拡張をサポートしなければなりません。
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]は迅速なメールボックスの再同期を実行する方法を示しています。
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]拡張をサポートしなければなりません。拡張機能は、クライアントが他のユーザーに属する共有メールボックスとメールボックスを発見することができます。
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 +]拡張をサポートしなければなりません。拡張機能は、クライアントが非同期リテラルが送信されるたびに往復を保存することができます。
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.
RFC 3501で要求されるようレモネード準拠のIMAPサーバはTLS [RFC3501]の上にIMAPをサポートしなければなりません。
-----------------------------------------------------|
| 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]. |
|-------------------------|--------------------------|
-----------------------------------------------------|
| 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 |
|-------------------------|--------------------------|
The Lemonade Working Group is looking into additional issues related to usage of email by mobile devices, possibly including:
レモネードワーキンググループは、おそらく含めて、モバイルデバイスで電子メールの利用に関連する追加の問題を検討しています：
- 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帯域外クライアントの通知にサーバ、 - 低または高価な帯域幅と信頼性の低いモバイルネットワーク（例えば、迅速な再接続）のための交通の最適化圧縮と他の帯域幅の最適化 - フィルタリング - モバイルクライアントのためのその他の考慮事項
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.追加のセキュリティ上の考慮事項は、[RFC3501]とレモネードプロファイルを含む他のSMTPやIMAP拡張を記述する他のドキュメントで見つけることができ、セクション全体で議論されています。
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]に記載されています。
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の警備員としての保護をリンクします。これは、TLSが使用されていない場合でも、BURLは、テキストを直接提出された場合よりも、テキストを参照するために使用されている場合、セキュリティ上のリスクが全く悪化していないこと、しかし、注目に値します。 BURLが使用されていない場合、盗聴者の利益には、メッセージの全文にアクセスできます。 BURLが使用される場合、盗聴者は、または使用BURLの形態に応じて、そのようなアクセスを得ることができなくてもよいです。例えば、いくつかのフォームが提出サーバーまたは特定のユーザーと権限のある機関へのURLの使用を制限します。
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.
レモネードクライアントがメール送信サーバに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ベースのメッセージ送信を使用するときにレモネードクライアントが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.
レモネードクライアントによって提供さURLAUTHトークンを使用してメッセージの内容を取得する際にレモネード準拠のメール送信サーバは、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を使用すると、メッセージ全体の内容は内密に扱われることをユーザーの期待があります。この期待に応えるために、メッセージ送信サーバがSTARTTLSまたはそのURLで参照されるコンテンツを取得する際に同等のデータの機密性を提供するメカニズムを使用する必要があります。
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]ニューマン、C. "メッセージ提出BURL拡張"、RFC 4468、2006年5月。
[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.クロッカー、 "8ビット・MIMEtransportためのSMTPサービス拡張"、RFC 1652、1994年7月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージを送信するためのSMTPサービス拡張" ヴォードルイユ、G.、[CHUNKING]を。
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[CATENATE]レズニック、P.、 "インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張"、RFC 4469、2006年4月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS延長"、RFC 4315、2005年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[RFC2920]解放され、N.、 "コマンドパイプラインのためのSMTPサービス拡張"、STD 60、RFC 2920、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サービス拡張メッセージのサイズ宣言"、STD 10、RFC 1870、1995年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[SUBMIT] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]ホフマン、P.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[RFC3461]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
"強化されたエラーコードを返すためのSMTPサービス拡張" [RFC2034]フリード、N.、RFC 2034、1996年10月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[NAMESPACE] Gahrns、M.とC.ニューマン、 "IMAP4名前空間"、RFC 2342、1998年5月。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTPAUTH]マイヤーズ、J.、 "認証のためのSMTPサービス拡張子"、RFC 2554、1999年3月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[LITERAL +]マイヤーズ、J.、 "IMAP4非同期リテラル"、RFC 2088、1997年1月。
[CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[CONDSTORE]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IDLE] Leiba、B.、 "IMAP4 IDLEコマンド"、RFC 2177、1997年6月。
[IMAP-DISC] Melnikov, A., "Synchronization operations for disconnected IMAP4 clients", Work in Progress, October 2004.
[IMAP-DISC]メルニコフ、A.、 "切断IMAP4クライアントの同期操作"、進歩、2004年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.
この文書では、レモネードWGの製品です。編集者は、コメントと修正を貢献レモネード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].
この文書では、[URLAUTH]マーク・クリスピンによる「メッセージ送信」（2004年2月）だけでなく、トリオから[BURL]、[CATENATE]からいくつかのテキストを借り、そして。
Authors' Addresses
著者のアドレス
Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA
ステファン・H.マース米国Oracle Corporation 500 OracleのパークウェイM / S 4op634レッドウッドショア、CA 94065 USA
Phone: +1-650-607-6296 EMail: stephane.maes@oracle.com
電話：+ 1-650-607-6296 Eメール：stephane.maes@oracle.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.melnikov@isode.com
メールアドレス：Alexey.melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。