[要約] RFC 4550は、Lemonadeプロファイルと呼ばれるインターネットメールのサービス環境をサポートするための仕様です。その目的は、異なるサービス環境でのメールの送受信を効率的かつ一貫性のある方法で実現することです。
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).
Copyright（c）The Internet Society（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）拡張機能とBurl拡張機能（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.
Lemonadeは、多様なサービス環境をサポートするために、インターネットメールの強化を提供します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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.
このドキュメントのすべての例は、レモネードの使用のために最適化されており、一般的な使用Submit/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]、および[送信]プロトコルを使用したクライアント/サーバーメールの出現により、以前はローカルディスク操作が繰り返しネットワークデータ送信に変更されました。
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]送信拡張機能を使用して、メッセージの提出中に外部ソースへのアクセスを可能にします。IMAP [urlauth]拡張機能と組み合わせて、IMAPとSMTP送信サーバーの間の最小限の信頼関係で、メッセージパーツまたはIMAPメールストアからのメッセージ全体を含めることが可能です。
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 [送信]拡張機能を使用できます。さらに、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）で行われます。多くの場合、ユーザーは[RFC3501]サーバー（\ドラフトフラグを使用して追加コマンドを介して）でより複雑なメッセージを保存することを選択して、MUAによる後で編集プロセスの再開によるリコールを行います。
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.
従来、メッセージはMUA内で完全に開始、編集、および組み立てられていますが、ドラフトは[RFC3501]サーバーに保存され、後でサーバーから取得される場合があります。完了したテキストは、配信のためにメッセージ提出エージェント（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.
このモデルは、図1に示すように、メールユーザーエージェント（MUA）、IMAP4REV1サーバー（[RFC3501]）、およびSMTP送信サーバー（[送信]）を区別します。
+--------------------+ +--------------+
| | <------------ | |
| 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つの方法があります。最初のものは、拡張された追加コマンド[Catenate]を使用して、メッセージストアでドラフトメッセージを編集し、IMAPサーバーにメッセージアセンブリを引き起こします。2番目は、一連の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]拡張機能を使用して[Burl]拡張機能を使用して[送信]サーバーに与えられます。
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：{to i -optional}クライアントは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 FETCH 25627（UIDボディストラクチャ）Plain "（" charset "" us-ascii "" name "" trip.txt "）" <960723163407.20117h@washington.example.comA0051 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：{to i}クライアントは、セマンティクスと手順の詳細については、Catenate（[Catenate]を参照）を呼び出します。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.
このステップの例は、リテラル[リテラル]拡張機能を使用しないことに注意してください。リテラルがなければ、新しいメッセージは3つのラウンドトリップを使用して構築されます。リテラルを使用すると、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：{to i}クライアントはGenurlauthコマンドを使用してUrlauth URLを要求します（[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：{to m} IMAPサーバーは、セマンティクスと手順の詳細については、urlfetch（[urlauth]を参照）を使用して後の検索に適したurlauth urlを返します。
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：{to s}クライアントはメール送信サーバーに接続し、新しいメールトランザクションを開始します。Burlを使用して、SMTPをSMTP Submit ServerにIMAPサーバーからメッセージのコンテンツを取得させます。（セマンティクスとステップの詳細については、[Burl]を参照してください。）これにより、MUAはSMTP Shint Serverに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: {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：{to i}メール送信サーバーはurlfetchを使用してメッセージをフェッチします。（セマンティクスとステップの詳細については、[urlauth]を参照してください。いわゆる「ポーンチケット」承認メカニズムは、独自の承認資格情報を含むURIを使用しています。）
I: {to S} Provides the message composed as a result of the CATENATE step.
i：{to s}は、カテネートステップの結果として構成されたメッセージを提供します。
Mail submission server opens IMAP connection to the IMAP server:
Mail Submission 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サーバーがグリーティングで機能応答コードを送信しない場合、Mail Submissionサーバーは、RFC 3501で説明されているように、サポートされているIMAP拡張機能について学習するために機能コマンドを発行する必要があることに注意してください。
Also, if data confidentiality is not required, the mail submission server may omit the STARTTLS command before issuing the LOGIN command.
また、データの機密性が不要な場合、メール送信サーバーは、ログインコマンドを発行する前にstartTLSコマンドを省略する場合があります。
S: {to M} Submission server assembles the complete message, and if the assembly succeeds, it returns OK to the MUA:
s：{to m}送信サーバーは完全なメッセージを組み立て、アセンブリが成功した場合、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：{to i}クライアントは、IMAPサーバーに転送された添付ファイルを含むメッセージをマークします。
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
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ストアコマンドは、マークされたメッセージが現在選択されているメールボックスにある場合にのみ機能します。それ以外の場合は、selectが必要です。このコマンドは省略できます。攻撃されていないフェッチの応答は、[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内で構成および編集されます。提出中[送信]中、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：{to i -optional}クライアントは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：A0051 UID FETCH 25627（UIDボディストラクチャ）Plain "（" charset "" us-ascii "" name "" trip.txt "）" <960723163407.20117h@washington.example.comA0051 OK完了
M: {to I} The client uses GENURLAUTH command to request URLAUTH URLs (see [URLAUTH]) referencing pieces of the message to be assembled.
m：{to i}クライアントはGenurlauthコマンドを使用して、urlauth urls（[urlauth]を参照）を要求します。
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：{to m} IMAPサーバーは、セマンティクスと手順の詳細については、urlfetch（[urlauth]を参照）を使用した後の検索に適したurlauth urlを返します。
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：{to s}クライアントはメール送信サーバーに接続し、新しいメールトランザクションを開始します。Burlを使用して、SMTP送信サーバーに、送信するメッセージのIMAPサーバーのピースからフェッチするよう指示します（セマンティクスと手順の詳細については[Burl]を参照）。StartTLSコマンドが成功した後、2番目のEHLOコマンドが必要であることに注意してください。2番目のEhlo応答がBurlオプションをリストしない場合にのみ、3番目のEhloコマンドが必要です。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: 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：{to i}メール送信サーバーは、urlfetchを使用して送信されるメッセージのピースをフェッチします（セマンティクスと手順の詳細については[urlauth]を参照）。いわゆる「ポーンチケット」認証メカニズムは、独自の認証資格情報を含むURIを使用します。
I: {to S} Returns the requested body parts.
i：{to s}要求されたボディ部分を返します。
Mail submission server opens IMAP connection to the IMAP server:
Mail Submission 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サーバーがグリーティングで機能応答コードを送信しない場合、Mail Submissionサーバーは、RFC 3501で説明されているように、サポートされているIMAP拡張機能について学習するために機能コマンドを発行する必要があることに注意してください。
Also, if data confidentiality is required, the mail submission server should start TLS before issuing the LOGIN command.
また、データの機密性が必要な場合は、ログインコマンドを発行する前に、Mail Submission Serverが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：{to 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：{to i}クライアントは、IMAPサーバーに転送された添付ファイルを含むメッセージをマークします。
M: A0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0053 OK STORE completed
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ストアコマンドは、マークされたメッセージが現在選択されているメールボックスにある場合にのみ機能します。それ以外の場合は、selectが必要です。このコマンドは省略できます。攻撃されていないフェッチの応答は、[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]をサポートする必要があります。このサポートは、機能[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はUrlauthタイプのURL [Urlauth]をサポートする必要があります。したがって、Burl Ehloキーワードに従って「IMAP」オプションを宣伝する必要があります（詳細については[Burl]を参照）。
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 Submit [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.
「Pawn-Ticket」は、SMTP送信サーバーがアクセスを許可され、クライアントが取り消すことができ、時間制限の有効性を持つことができる特定のデータにのみアクセスを付与します。
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サーバー上のメールボックスに追加される場合があります。後者は、「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.
[RFC3501]への[Catenate]拡張は、FCCの問題に対処するために使用できます。最終メッセージは、送信メール用に設計されたメールボックスに作成されます。[Catenate]拡張機能は、送信の発信メッセージをステージングするサーバー上でのみ単一のメッセージを作成できることに注意してください。メッセージの追加コピーは、1つ以上のコピーコマンドを使用して同じサーバーに作成できます。
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クライアントが使用して、メッセージが別のメールアドレスにresしていることを指定し、新しいメッセージに埋め込まれているか、添付されています。メールクライアントは、メッセージを別のメールアドレスに正常に転送するときにこのキーワードを設定します。このキーワードの典型的な使用法は、転送されたメッセージの別の（または追加の）アイコンを表示することです。設定したら、フラグをクリアしないでください。
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.
レモネードに準拠したサーバーは、$転送されたキーワードを保存できる必要があります。コピー操作に保存する必要があります。サーバーは、検索キーワード$を転送する必要があります。
Lemonade-compliant mail submission servers are expected to implement the following set of SMTP extensions to make message submission efficient.
Lemonade-Compliant Mail Submissionサーバーは、メッセージの提出を効率的にするために、次の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].
Lemonade-Compliant Mail Submissionサーバーは、配信ステータス通知のSMTPサービス拡張機能[RFC3461]をサポートする必要があります。
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.
レモネードに準拠したメール送信サーバーは、メッセージサイズの制限を強制する前に、すべての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-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].
Lemonade-Compliant Mail Submissionサーバーは、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サーバーは、名前空間[名前空間]拡張機能をサポートする必要があります。この拡張機能により、クライアントは他のユーザーに属する共有メールボックスとメールボックスを発見できます。
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サーバーは、リテラル[リテラル]拡張機能をサポートする必要があります。この拡張機能により、クライアントは、非同期のリテラルが送信されるたびに往復を保存できます。
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サーバーは、アイドル[アイドル]拡張機能をサポートする必要があります。この拡張機能により、クライアントは、変更のために投票する必要なく、選択したメールボックスの変更に関するインスタント通知を受け取ることができます。
Lemonade-compliant IMAP servers MUST support IMAP over TLS [RFC3501] as required by RFC 3501.
レモネードに準拠したIMAPサーバーは、RFC 3501で要求されるように、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全体で説明します。レモネードプロファイルを含む他の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提出の必須の実現認証メカニズムは[送信]に記載されていることに注意してください。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拡張機能を郵送するためにBurl拡張機能を使用する場合、そのようなトークンは、攻撃者にメッセージの内容を開示する可能性のあるリプレイ攻撃を避けるために傍受から保護する必要があります。Mail Submission Pathの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.
Lemonadeクライアントは、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.
クライアントがSMTP startTLSを使用して、非公開情報を参照するBurlコマンドを送信すると、メッセージコンテンツ全体が秘密に扱われるというユーザーの期待があります。この期待を満たすために、メッセージ提出サーバーは、そのURLが参照するコンテンツを取得するときに、starttlsまたは同等のデータ機密性を提供するメカニズムを使用する必要があります。
[BURL] Newman, C. "Message Submission BURL Extension", RFC 4468, May 2006.
[Burl] Newman、C。「Message Submission Burl Extension」、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.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[Chunking] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、RFC 3030、2000年12月。
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[Catenate] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）Catenate Extension」、RFC 4469、2006年4月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[uidplus] Crispin、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[RFC2920] Freed、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.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[送信] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン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] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[Urlauth] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、RFC 4467、2006年5月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[名前空間] Gahrns、M。and C. Newman、「IMAP4 NameSpace」、RFC 2342、1998年5月。
[SMTPAUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTPAUTH] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[リテラル]マイヤーズ、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] Melnikov、A。and S. Hole、「条件付き店舗運用またはクイックフラグ変更再同期のためのIMAP拡張」、RFC 4551、2006年6月。
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[アイドル] 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] Melnikov、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メンバーに感謝します。特に：Randy Gellens、Dave Cridland、およびGreg Vaudreuil。
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月）、およびトリオ[バール]、[catenate]、および[urlauth]からのテキストを借用しています。
Authors' Addresses
著者のアドレス
Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA
Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4OP634 Redwood Shores、CA 94065 USA
Phone: +1-650-607-6296
EMail: stephane.maes@oracle.com
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。