[要約] RFC 5550は、Lemonadeプロファイルと呼ばれるもので、異なるサービス環境をサポートするためのインターネットメールに関するものです。このRFCの目的は、モバイルデバイスや低帯域幅のネットワークなど、多様な環境でのメールサービスの改善を提案することです。
Network Working Group D. Cridland, Ed.
Request for Comments: 5550 A. Melnikov, Ed.
Obsoletes: 4550 Isode Limited
Updates: 4469, 4467 S. Maes, Ed.
Category: Standards Track Oracle
August 2009
The Internet Email to Support Diverse Service Environments (Lemonade) Profile
多様なサービス環境（レモネード）プロファイルをサポートするインターネットメール
Abstract
概要
This document describes a profile (a set of required extensions, restrictions, and usage modes), dubbed Lemonade, of the IMAP, mail submission, and Sieve 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 Lemonade Profile relies upon several extensions to IMAP, Sieve, and Mail Submission protocols. The document also defines a new IMAP extension and registers several new IMAP keywords.
レモネードプロファイルは、IMAP、ふるい、およびメールの提出プロトコルへのいくつかの拡張機能に依存しています。ドキュメントはまた、新しいIMAP拡張機能を定義し、いくつかの新しいIMAPキーワードを登録します。
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Summary of the Required Support .................................4
3.1. Lemonade Submission Servers ................................4
3.2. Lemonade Message Stores ....................................5
3.3. Lemonade Message Delivery Agents ...........................7
4. Lemonade Submission Servers .....................................7
4.1. Forward without Download ...................................7
4.2. Pipelining .................................................8
4.3. DSN Support ................................................8
4.4. Message Size Declaration ...................................8
4.5. Enhanced Status Code Support ...............................8
4.6. Encryption and Compression .................................8
5. Lemonade Message Stores .........................................9
5.1. Quick Resynchronization ....................................9
5.2. Message Part Handling ......................................9
5.3. Compression ...............................................10
5.4. Notifications .............................................10
5.5. Searching and View Filters ................................12
5.6. Mailbox Handling ..........................................12
5.7. Forward without Download ..................................12
5.8. Additional IMAP Extensions ................................13
5.9. Registration of $Forwarded IMAP Keyword ...................13
5.10. Registration of $SubmitPending and $Submitted
IMAP Keywords ............................................13
5.11. Related IMAP Extensions ..................................14
6. Lemonade Message Delivery Agents ...............................14
7. Lemonade Message User Agents ...................................15
8. Forward without Download .......................................16
8.1. Motivations ...............................................16
8.2. Message Sending Overview ..................................16
8.3. Traditional Strategy ......................................17
8.4. A New Strategy ............................................18
8.5. Security Considerations for Pawn-Tickets ..................27
8.6. Copies of Sent Messages: The fcc Problem ..................27
9. Deployment Considerations ......................................28
10. Security Considerations .......................................28
10.1. Confidentiality Protection of Submitted Messages .........28
10.2. TLS ......................................................29
10.3. Additional Extensions and Deployment Models ..............29
11. IANA Considerations ...........................................30
12. Changes since RFC 4550 ........................................30
13. Acknowledgements ..............................................31
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................35
Appendix A. Errata ..............................................37
The Lemonade Profile, or simply Lemonade, provides enhancements to Internet email to support diverse service environments. Lemonade mail servers provide both a Lemonade Submission Server and a Lemonade Message Store, which are based on the existing [SUBMIT] and [IMAP] protocols, respectively. They MAY also include a Lemonade Message Delivery Agent, which provides delivery-time filtering services based on [SIEVE].
レモネードプロファイル、または単にレモネードは、多様なサービス環境をサポートするためにインターネットメールの強化を提供します。レモネードメールサーバーは、既存の[送信]および[IMAP]プロトコルに基づいたレモネード提出サーバーとレモネードメッセージストアの両方を提供します。また、[Sieve]に基づいた配信時間フィルタリングサービスを提供するレモネードメッセージ配信エージェントが含まれる場合があります。
This document describes the Lemonade Profile that includes:
このドキュメントでは、次のことを含むレモネードプロファイルについて説明します。
o General common enhancements to Internet Mail, described in 5 and 4.
o 5および4に記載されているインターネットメールの一般的な一般的な機能強化。
o "Forward without download" that describes exchanges between Lemonade clients and servers to allow submitting new email messages incorporating content that resides on locations external to the client, described in Section 8.
o セクション8で説明されているクライアントの外部の場所にあるコンテンツを組み込んだ新しい電子メールメッセージを送信できるように、レモネードクライアントとサーバー間の交換を説明する「ダウンロードなし」を説明します。
o Quick mailbox resynchronization, described in Section 5.1.
o セクション5.1で説明されているクイックメールボックスの再同期。
o Extensions to support more precise, and broader, notifications from the store in support of notifications and view filters, described in 5.4.1 and 5.5.
o 5.4.1および5.5で説明されている通知とビューフィルターをサポートする、より正確で、より広範な通知をサポートするための拡張。
o Delivery-time filtering in support of typical mail management use cases, as described in Section 3.3.
o セクション3.3で説明されているように、典型的なメール管理のユースケースをサポートする配送時間フィルタリング。
The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to develop the Lemonade Profile.
レモネードWGは、[レモネードアーチ]に表示されているアーキテクチャを使用して、レモネードプロファイルを開発しました。
It is intended that the Lemonade Profile support realizations of the OMA's mobile email enabler (MEM) (see [OMA-MEM-REQ] and [OMA-MEM-ARCH]) using Internet Mail protocols defined by the IETF.
IETFによって定義されたインターネットメールプロトコルを使用して、レモネードプロファイルがOMAのモバイルメールイネーブラー（MEM）（[OMA-MEM-REQ]および[OMA-MEM-ARCH]を参照）の実現をサポートすることを意図しています。
In examples, "M:", "I:", and "S:" indicate lines sent by the client Message User Agent, IMAP email 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 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[キーワード]で説明されていると解釈されます。
Other capitalized words are typically names of extensions or commands -- these are uppercased for clarity only, and are case-insensitive.
他の大文字の単語は通常、拡張機能またはコマンドの名前です - これらは明確になるためにのみ高く評価されており、ケース非感受性です。
This document uses terminology defined in [RFC5598]. See [RFC5598] for further details on Email Architecture.
この文書は、[RFC5598]で定義された用語を使用します。電子メールアーキテクチャの詳細については、[RFC5598]を参照してください。
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 Submit and IMAP servers support all Lemonade extensions described in this document, so they do not demonstrate fallbacks in the absence of an extension.
このドキュメントのすべての例は、レモネードの使用のために最適化されており、一般的な使用Submit/IMAPクライアントの適切なプロトコル使用の例を表していない場合があります。特に、例では、送信およびIMAPサーバーがこのドキュメントに記載されているすべてのレモネード拡張機能をサポートしているため、拡張機能がない場合はフォールバックを実証しないことを前提としています。
Lemonade Submission Servers MUST provide a service as described in [SUBMIT], and MUST support the following. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
レモネードの提出サーバーは、[送信]に記載されているようにサービスを提供する必要があり、以下をサポートする必要があります。レモネードプロファイルは、引用されたセクションで詳述されている場合によっては、さらに要件を課すことに注意してください。
+---------------------+--------------------+--------------+
| SMTP extension | Reference | Requirements |
+---------------------+--------------------+--------------+
| 8BITMIME | [SMTP-8BITMIME] | [SMTP-BURL] |
| AUTH | [SMTP-AUTH] | [SUBMIT] |
| BINARYMIME | [SMTP-BINARYMIME] | Section 4.1 |
| BURL imap | [SMTP-BURL] | Section 8 |
| CHUNKING | [SMTP-BINARYMIME] | Section 4.1 |
| DSN | [SMTP-DSN] | Section 4.3 |
| ENHANCEDSTATUSCODES | [SMTP-STATUSCODES] | Section 4.5 |
| PIPELINING | [SMTP-PIPELINING] | Section 4.2 |
| SIZE | [SMTP-SIZE] | Section 4.4 |
| STARTTLS | [SMTP-TLS] | Section 4.6 |
+---------------------+--------------------+--------------+
Lemonade Message Stores MUST provide a service as described in [IMAP], and MUST support the following. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
[IMAP]で説明されているように、レモネードメッセージストアはサービスを提供する必要があり、以下をサポートする必要があります。レモネードプロファイルは、引用されたセクションで詳述されている場合によっては、さらに要件を課すことに注意してください。
+------------------------+------------------+---------------+
| IMAP extension | Reference | Requirements |
+------------------------+------------------+---------------+
| BINARY | [IMAP-BINARY] | Section 5.2 |
| CATENATE | [IMAP-CATENATE] | Section 5.7 |
| COMPRESS=DEFLATE | [IMAP-COMPRESS] | Section 5.3 |
| CONDSTORE | [IMAP-CONDSTORE] | Section 5.1 |
| CONTEXT=SEARCH | [IMAP-CONTEXT] | Section 5.5 |
| CONTEXT=SORT | [IMAP-CONTEXT] | Section 5.5 |
| CONVERT | [IMAP-CONVERT] | Section 5.2 |
| ENABLE | [IMAP-ENABLE] | Section 5.1 |
| ESEARCH | [IMAP-ESEARCH] | Section 5.5 |
| ESORT | [IMAP-CONTEXT] | Section 5.5 |
| I18NLEVEL=1 | [IMAP-I18N] | Section 5.8 |
| IDLE | [IMAP-IDLE] | Section 5.4.1 |
| LITERAL+ | [IMAP-LITERAL+] | Section 5.8 |
| NAMESPACE | [IMAP-NAMESPACE] | Section 5.6 |
| NOTIFY | [IMAP-NOTIFY] | Section 5.4.1 |
| QRESYNC | [IMAP-QRESYNC] | Section 5.1 |
| SASL-IR | [IMAP-SASL-IR] | Section 5.8 |
| SORT | [IMAP-SORT] | Section 5.5 |
| STARTTLS | [IMAP] | - |
| UIDPLUS | [IMAP-UIDPLUS] | Section 5.7 |
| URLAUTH | [IMAP-URLAUTH] | Section 5.7 |
| URL-PARTIAL | Section 5.7.1 | Section 5.7 |
| $Forwarded keyword | - | Section 5.9 |
| $SubmitPending keyword | - | Section 5.10 |
| $Submitted keyword | - | Section 5.10 |
+------------------------+------------------+---------------+
In addition to this list, any Lemonade Message Stores MUST send the CAPABILITY response code (see Section 7.1 of [IMAP]) in the initial server greeting and after the LOGIN/AUTHENTICATE commands.
このリストに加えて、レモネードメッセージストアは、最初のサーバーグリーティングとログイン/認証コマンドの後に、機能応答コード（[IMAP]のセクション7.1を参照）を送信する必要があります。
Lemonade Message Delivery Agents MUST support Sieve mail filtering language as described in [SIEVE], and MUST support the following Sieve extensions. Note that the Lemonade Profile imposes further requirements for some cases, detailed in the sections cited.
レモネードメッセージ配信エージェントは、[Sieve]に記載されているように、Sieve Mailフィルタリング言語をサポートする必要があり、次のSive拡張機能をサポートする必要があります。レモネードプロファイルは、引用されたセクションで詳述されている場合によっては、さらに要件を課すことに注意してください。
+------------------------------+--------------------+--------------+
| Sieve extension | Reference | Requirements |
+------------------------------+--------------------+--------------+
| ENOTIFY | [SIEVE-NOTIFY] | Section 6 |
| IMAP4FLAGS | [SIEVE-IMAP4FLAGS] | Section 6 |
| RELATIONAL | [SIEVE-RELATIONAL] | Section 6 |
| VACATION | [SIEVE-VACATION] | Section 6 |
| VARIABLES | [SIEVE-VARIABLES] | Section 6 |
| comparator-i;unicode-casemap | [UNICODE-CASEMAP] | Section 6 |
+------------------------------+--------------------+--------------+
Lemonade Message Delivery Agents should also consider supporting a Sieve script management protocol, such as [MANAGESIEVE].
レモネードメッセージ配信エージェントは、[ManageSieve]などのふるいスクリプト管理プロトコルをサポートすることも検討する必要があります。
All Lemonade Submission Servers implement the Mail Submission protocol described in [SUBMIT], which is in turn a specific profile of [ESMTP]. Therefore, any MUA designed to submit email via [SUBMIT] or [ESMTP] will interoperate with Lemonade Submission Servers.
すべてのレモネード提出サーバーは、[submit]で説明されているメール送信プロトコルを実装します。これは、[ESMTP]の特定のプロファイルです。したがって、[送信]または[ESMTP]を介して電子メールを送信するように設計されたMUAは、レモネード提出サーバーと相互操作します。
In addition, Lemonade Submission Servers implement the following set of SMTP and Submission extensions to increase message submission efficiency.
さらに、レモネードの提出サーバーは、メッセージの提出効率を高めるために、次のSMTPおよび提出拡張機能のセットを実装します。
In order to optimize network usage for the typical case where message content is copied to, or sourced from, the IMAP store, Lemonade provides support for a suite of extensions collectively known as "forward without download", discussed in detail in Section 8.
IMAPストアからメッセージコンテンツがコピーされる、または供給されている典型的なケースのネットワーク使用を最適化するために、レモネードは、セクション8で詳細に議論されている「フォワードダウンロードなし」と共同で知られる一連の拡張機能をサポートします。
Lemonade Submission Servers MUST support BURL [SMTP-BURL], 8BITMIME [SMTP-8BITMIME], BINARYMIME [SMTP-BINARYMIME], and CHUNKING [SMTP-BINARYMIME] SMTP extensions.
レモネードの提出サーバーは、Burl [SMTP-BURL]、8Bitmime [SMTP-8Bitmime]、BinaryMime [SMTP-BinaryMime]、およびChunking [SMTP-BinaryMime] SMTP拡張機能をサポートする必要があります。
BURL MUST support URLAUTH type URLs [IMAP-URLAUTH], and thus MUST advertise the "imap" option following the BURL EHLO keyword (see [SMTP-BURL] for more details).
BurlはUrlauthタイプのURL [IMAP-Urlauth]をサポートする必要があります。したがって、詳細については、Burl Ehloキーワード（[SMTP-Burl]を参照）に従って「IMAP」オプションを宣伝する必要があります。
Some clients regularly use networks with a relatively high latency, such as mobile or satellite-based networks. Avoidance of round trips within a transaction has a great advantage for the 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 [SMTP-PIPELINING].
一部のクライアントは、モバイルや衛星ベースのネットワークなど、比較的高い遅延を備えたネットワークを定期的に使用しています。トランザクション内での往復の回避は、帯域幅と総トランザクション時間の両方の短縮に大きな利点があります。このため、レモネードに準拠したメール送信サーバーは、コマンドパイプライン[SMTP-Pipelining]のSMTPサービス拡張機能をサポートする必要があります。
Lemonade-compliant mail Submission Servers MUST support SMTP service extensions for delivery status notifications [SMTP-DSN].
Lemonade-Compliant Mail Submissionサーバーは、配信ステータス通知[SMTP-DSN]のSMTPサービス拡張機能をサポートする必要があります。
There is a distinct advantage in detecting failure cases as early as possible in many cases, such as where the user is charged per octet, or where bandwidth is low. This is especially true of large message sizes.
ユーザーがオクテットごとに請求される場所や帯域幅が低い場所など、多くの場合、故障ケースをできるだけ早く検出することには明確な利点があります。これは特に大きなメッセージサイズに当てはまります。
Lemonade Submission Servers MUST support the SMTP service extension for message size declaration [SMTP-SIZE].
レモネードの提出サーバーは、メッセージサイズの宣言[SMTP-Size]のためにSMTPサービス拡張機能をサポートする必要があります。
Lemonade Submission Servers MUST expand all BURL parts before evaluating if the supplied message size is acceptable.
レモネードの提出サーバーは、付属のメッセージサイズが許容できるかどうかを評価する前に、すべてのBurl部品を拡張する必要があります。
A Lemonade-capable client SHOULD use message size declaration. In particular, the client MUST NOT send a message to a mail Submission Server if it knows that the message exceeds the maximal message size advertised by the Submission Server. When including a message size in the MAIL FROM command, the client MUST use a value that is at least as large as the size of the assembled message data after resolution of all BURL parts.
レモネード対応のクライアントは、メッセージサイズの宣言を使用する必要があります。特に、メッセージが提出サーバーによって宣伝されている最大メッセージサイズを超えていることがわかっている場合、クライアントはメール送信サーバーにメッセージを送信してはなりません。コマンドからメールにメッセージサイズを含める場合、クライアントは、すべてのBurlパーツの解像度後に組み立てられたメッセージデータのサイズと同じくらい大きい値を使用する必要があります。
Lemonade-compliant mail Submission Servers MUST support the SMTP service extension for returning enhanced error codes [SMTP-STATUSCODES]. These allow a client to determine the precise cause of failure.
レモネードに準拠したメール送信サーバーは、拡張エラーコード[SMTP-STATUSCODES]を返すためにSMTPサービス拡張機能をサポートする必要があります。これらにより、クライアントは障害の正確な原因を決定することができます。
Lemonade-compliant mail Submission Servers MUST support the SMTP service extension for secure SMTP over Transport Layer Security (TLS) [SMTP-TLS].
Lemonade-Compliant Mail Submissionサーバーは、輸送層セキュリティ（TLS）[SMTP-TLS]上の安全なSMTPのSMTPサービス拡張機能をサポートする必要があります。
Support for the DEFLATE compression method, as described in [TLS-COMP], is RECOMMENDED.
[TLS-Comp]で説明されているように、DERLATE圧縮法のサポートが推奨されます。
All Lemonade Message Stores implement the Internet Message Access Protocol, as defined in [IMAP]. Therefore, any MUA written to access messages using the facilities described in [IMAP] will interoperate with a Lemonade Message Store.
すべてのレモネードメッセージストアは、[IMAP]で定義されているように、インターネットメッセージアクセスプロトコルを実装しています。したがって、[IMAP]に記載されている施設を使用してメッセージにアクセスするために書かれたMUAは、レモネードメッセージストアと相互運用します。
In addition, Lemonade Message Stores provide a set of extensions to address the limitations of some clients and networks.
さらに、レモネードメッセージストアは、一部のクライアントとネットワークの制限に対処するための一連の拡張機能を提供します。
Resynchronization is a costly part of an IMAP session, and mobile networks are generally more prone to unintended disconnection, which in turn makes this problem more acute. Therefore, Lemonade Message Stores provide a suite of extensions to reduce the synchronization cost.
再同期はIMAPセッションの費用のかかる部分であり、モバイルネットワークは一般に意図しない切断を起こしやすく、この問題はより深刻になります。したがって、レモネードメッセージストアは、同期コストを削減するための一連の拡張機能を提供します。
Lemonade-compliant IMAP servers MUST support the CONDSTORE [IMAP-CONDSTORE], the QRESYNC [IMAP-QRESYNC], and the ENABLE [IMAP-ENABLE] extensions. These allow a client to quickly resynchronize any mailbox by asking the server to return all flag changes and expunges that have occurred since a previously recorded state. This can also speed up client reconnect in case the transport layer is cut, whether accidentally or as part of a change in network.
レモネードに準拠したIMAPサーバーは、Condstore [IMAP-Condstore]、QRESYNC [IMAP-QRESYNC]、および[IMAP-exenable]拡張機能をサポートする必要があります。これらにより、クライアントは、以前に記録された状態以降に発生したすべてのフラグの変更と抹消をサーバーに返すように求めることにより、任意のメールボックスをすばやく再同期させることができます。これにより、誤ってまたはネットワークの変更の一部として、輸送層が削減された場合に備えて、クライアントの再接続をスピードアップすることもできます。
When implementing QRESYNC [IMAP-QRESYNC], client and servers need to also comply with errata submitted for this document (see Appendix A).
QRESYNC [IMAP-QRESYNC]を実装する場合、クライアントとサーバーは、このドキュメントに提出されたERRATAにも準拠する必要があります（付録Aを参照）。
[IMAP-SYNC-HOWTO] details how clients perform efficient mailbox resynchronization.
[IMAP-Sync-Howto]は、クライアントが効率的なメールボックス再同期を実行する方法を詳しく説明しています。
The handling of message parts, especially attachments, represents a set of challenges to limited devices, both in terms of the bandwidth used and the capability of the device.
メッセージパーツ、特に添付ファイルの処理は、使用される帯域幅とデバイスの機能の両方の観点から、限られたデバイスに対する一連の課題を表します。
Lemonade-compliant IMAP servers MUST support the BINARY [IMAP-BINARY] extension. This moves MIME body part decoding operations from the client to the server. The decoded data is equal to or less in size than the encoded representation, so this reduces bandwidth effectively.
レモネードに準拠したIMAPサーバーは、バイナリ[IMAP-Binary]拡張機能をサポートする必要があります。これにより、マイムボディパーツのデコード操作がクライアントからサーバーに移動します。デコードされたデータは、エンコードされた表現よりもサイズ以下に等しいため、これにより帯域幅が効果的に減少します。
[IMAP-BINARY] allows for servers to refuse to accept uploaded messages containing binary data, by not accepting the Binary content-transfer-encoding; however, Lemonade-compliant IMAP servers SHALL always accept binary encoded MIME messages in APPEND commands for any folder.
[IMAP-Binary]は、バイナリコンテンツ輸送エンコードを受け入れないことにより、サーバーがバイナリデータを含むアップロードされたメッセージを受け入れることを拒否できます。ただし、レモネードに準拠したIMAPサーバーは、任意のフォルダーの追加コマンドにバイナリエンコードされたMIMEメッセージを常に受け入れなければなりません。
[IMAP-CONVERT] MUST also be supported by servers, which allows clients to request conversions between media types, and allows for scaling images, etc. This provides the ability to view attachments (and sometimes body parts) without the facility to cope with a wide range of media types, or to efficiently view attachments.
[IMAP Convert]はサーバーによってサポートされる必要があります。これにより、クライアントはメディアタイプ間の変換を要求し、画像をスケーリングすることができます。幅広いメディアタイプ、または添付ファイルを効率的に表示する。
Lemonade Message Stores SHOULD support the Deflate compression algorithm for TLS, as defined in [TLS-COMP], in order to facilitate compression at as low a level as possible.
レモネードメッセージストアは、[TLS-Comp]で定義されているように、TLSのDEFLATE圧縮アルゴリズムをサポートする必要があります。
However, the working group acknowledges that for many endpoints, this is a rarely deployed technology, and as such, Lemonade Message Stores MUST provide [IMAP-COMPRESS] support for fallback application-level stream compression, where TLS is not actively providing compression.
ただし、ワーキンググループは、多くのエンドポイントで、これはめったに展開されていないテクノロジーであることを認めているため、レモネードメッセージストアは、TLSが圧縮を積極的に提供していないフォールバックアプリケーションレベルのストリーム圧縮に対して[IMAP-Compress]サポートを提供する必要があります。
The addition of server-to-client notifications transforms the Lemonade Profile into an event-based synchronization protocol. Whenever an event occurs that interests the MUA, a notification can be generated. The Lemonade WG used the notifications architecture shown in [LEMONADE-NOTIFICATIONS] to develop the Lemonade Profile.
サーバーからクライアントへの通知を追加すると、レモネードプロファイルをイベントベースの同期プロトコルに変換します。MUAに関心のあるイベントが発生するたびに、通知を生成できます。レモネードWGは、[レモネードノティフィクション]に示されている通知アーキテクチャを使用して、レモネードプロファイルを開発しました。
If the MUA is connected to the IMAP server, inband notifications are generated using the facilities outlined in Section 5.4.1.
MUAがIMAPサーバーに接続されている場合、セクション5.4.1で概説されている機能を使用してINBAND通知が生成されます。
When the MUA is not connected, the notification filter generates an outband notification. The notification filter may be considered as acting on a push email repository.
MUAが接続されていない場合、通知フィルターはアウトバンド通知を生成します。通知フィルターは、プッシュメールリポジトリに作用すると見なされる場合があります。
If the MUA is not connected, and outband notification is disabled, the client must perform a quick-sync on reconnect to determine mailbox changes, using the mechanisms outlined in Section 5.1.
MUAが接続されておらず、アウトバンド通知が無効になっている場合、セクション5.1で概説されているメカニズムを使用して、クライアントは再接続時に迅速なシンクを実行する必要があります。
Lemonade Message Stores MUST support the IDLE [IMAP-IDLE] extension. The extension allows clients to receive unsolicited notifications about changes in the selected mailbox, without needing to poll for changes. The responses forming these notifications MUST be sent in a timely manner when such changes happen.
レモネードメッセージストアは、アイドル[IMAP-IDLE]拡張機能をサポートする必要があります。この拡張機能により、クライアントは、変更のために投票する必要なく、選択したメールボックスの変更に関する未承諾の通知を受け取ることができます。これらの通知を形成する応答は、そのような変更が発生したときにタイムリーに送信する必要があります。
Lemonade Message Stores also provide the NOTIFY extension described in [IMAP-NOTIFY], which allows clients to request specific event types to be sent immediately to the client, both for the currently selected folder and others. Such event types include message delivery and mailbox renames.
レモネードメッセージストアは、[IMAP-Notify]に記載されているNotify拡張子も提供します。これにより、クライアントは、現在選択されているフォルダーなどの両方で、クライアントに特定のイベントタイプをすぐにクライアントに送信するように要求できます。このようなイベントタイプには、メッセージ配信とメールボックスの改名が含まれます。
Lemonade and TCP provide for long-lived idle connections between the client and mail store, allowing the server to push notifications within IMAP. Some mobile networks support dormancy, which shuts down the radio traffic channel during idle periods to conserve handset and network resources, while maintaining IP and TCP state. (See the [LEMONADE-DEPLOYMENTS] document for more information.)
レモネードとTCPは、クライアントとメールストアの間の長命のアイドル接続を提供し、サーバーがIMAP内で通知をプッシュできるようにします。一部のモバイルネットワークは、IPとTCPの状態を維持しながら、ハンドセットとネットワークリソースを保存するためにアイドル期間中に無線交通チャネルをシャットダウンする休眠状態をサポートしています。（詳細については、[Lemonade-Deployments]ドキュメントを参照してください。）
However, there are environments where the email client cannot remain active indefinitely, or where it is not advisable (or even always possible) for TCP connections to the server to remain up while idle for extended periods. In these situations, a good user experience requires that when "interesting" events occur in the mail store, the client be informed so that it can connect and resynchronize. At an absolute minimum, this requires that at least the arrival of new mail generate some sort of wake-up to the email client. A number of vendors have implemented various solutions to this. As examples of what has been done, for many years (long pre-dating cellular handsets) the technique described in [FINGER-HACK] has been supported. Today, a number of email vendors include facilities to send SMS or other simple non-stream messages to clients on handsets when new mail arrives. The Open Mobile Alliance (OMA) has published a mechanism that uses WAP PUSH to send a basic message containing a URL [OMA-EMN]. The IETF is investigating ways to standardize enhanced functionality in this area.
ただし、電子メールクライアントが無期限にアクティブな状態を維持できない環境、またはサーバーへのTCP接続が長期間アイドル状態にとどまることをお勧めしない（または常に可能）。これらの状況では、優れたユーザーエクスペリエンスでは、メールストアで「興味深い」イベントが発生した場合、クライアントに接続して再同時代化できるように通知される必要があります。絶対的な最小限では、少なくとも新しいメールの到着が電子メールクライアントに何らかの目を覚ますことが必要です。多くのベンダーがこれに対するさまざまなソリューションを実装しています。何が行われているかの例として、長年（長期にわたる携帯電話の携帯電話）[フィンガーハック]に記載されている手法がサポートされています。今日、多くの電子メールベンダーには、新しいメールが到着したときに携帯電話のクライアントにSMSまたはその他の単純な非ストリームメッセージを送信する施設が含まれています。Open Mobile Alliance（OMA）は、WAP Pushを使用してURL [OMA-med]を含む基本メッセージを送信するメカニズムを公開しています。IETFは、この分野の強化された機能を標準化する方法を調査しています。
A "push email" user experience can be achieved using any number of techniques, ranging from always-on TCP connectivity to the server and the NOTIFY extension described above, to OMA EMN, or even a non-standard trigger message over SMS. In any technique, the client learns of the existence of new mail, and decides to fetch information about it, some part of it, or all of it, and then presents this to the user.
「プッシュメール」ユーザーエクスペリエンスは、常にオンになっているTCP接続からサーバー、上記のNotify拡張機能、またはSMSを介した非標準トリガーメッセージまで、任意の数の手法を使用して達成できます。どんなテクニックでも、クライアントは新しいメールの存在を学び、それに関する情報、その一部、またはそのすべてを取得することを決定し、これをユーザーに提示します。
Lemonade Message Stores MUST support the ESEARCH [IMAP-ESEARCH] extension. The extension allows clients to efficiently find the first or last messages, find a count of matching messages, and obtain a list of matching messages in a considerably more compact representation.
レモネードメッセージストアは、esearch [imap-search]拡張機能をサポートする必要があります。この拡張機能により、クライアントは最初のメッセージまたは最後のメッセージを効率的に見つけ、一致するメッセージのカウントを見つけ、よりコンパクトな表現で一致するメッセージのリストを取得できます。
Lemonade Message Stores also provide a mechanism for clients to avoid handling an entire mailbox, instead accessing a view of the mailbox. This technique, common in many desktop clients as a client-side capability, is useful for constrained clients to minimize the quantity of messages and notification data.
レモネードメッセージストアは、メールボックス全体の処理を避け、メールボックスのビューにアクセスするためのメカニズムも提供します。多くのデスクトップクライアントでクライアント側の機能として一般的なこの手法は、制約されたクライアントがメッセージの量と通知データを最小限に抑えるために役立ちます。
Lemonade Message Stores therefore MUST implement the CONTEXT=SEARCH, ESORT, and CONTEXT=SORT extensions defined in [IMAP-CONTEXT], as well as the SORT extension defined in [IMAP-SORT].
したがって、レモネードメッセージストアは、[IMAP-Sort]で定義されているソート拡張機能と同様に、[IMAP-Context]で定義されているコンテキスト=検索、ESORT、およびコンテキスト=ソート拡張機能を実装する必要があります。
Lemonade Message Stores MUST support the NAMESPACE [IMAP-NAMESPACE] extension. The extension allows clients to discover shared mailboxes and mailboxes belonging to other users, and provide a normalized hierarchy view of the mailboxes available.
レモネードメッセージストアは、名前空間[iMap-namespace]拡張機能をサポートする必要があります。この拡張機能により、クライアントは他のユーザーに属する共有メールボックスとメールボックスを発見し、利用可能なメールボックスの正規化された階層ビューを提供できます。
Lemonade Message Stores MUST support the I18NLEVEL=<n> [IMAP-I18N] extension, with <n> having the value 1 or 2. It adds support for non-English (internationalized) search and sort functions. (Note that I18NLEVEL=2 implies support for I18NLEVEL=1, so a Lemonade-compliant client that makes use of this extension MUST recognize either one.)
レモネードメッセージストアは、i18nlevel = <n> [IMAP-I18N]拡張機能をサポートする必要があります。<n>は値1または2を備えています。（i18nlevel = 2はi18nlevel = 1のサポートを暗示しているため、この拡張機能を使用するレモネードに準拠したクライアントは、いずれかを認識する必要があります。）
In order to optimize network usage for the typical case where message content is copied to, or sourced from, the IMAP store, Lemonade provides support for a suite of extensions collectively known as "forward without download", discussed in detail in Section 8.
IMAPストアからメッセージコンテンツがコピーされる、または供給されている典型的なケースのネットワーク使用を最適化するために、レモネードは、セクション8で詳細に議論されている「フォワードダウンロードなし」と共同で知られる一連の拡張機能をサポートします。
Lemonade Message Stores MUST support CATENATE [IMAP-CATENATE], UIDPLUS [IMAP-UIDPLUS], and URLAUTH [IMAP-URLAUTH]. Lemonade Message Stores MUST also support URL-PARTIAL as described in Section 5.7.1.
レモネードメッセージストアは、Catenate [Imap-catenate]、uidplus [imap-uidplus]、およびurlauth [imap-urlauth]をサポートする必要があります。レモネードメッセージストアは、セクション5.7.1で説明されているように、URL-Partialもサポートする必要があります。
[IMAP-URL] introduced a new syntactic element for referencing a byte range of a message/body part. This is done using the ;PARTIAL= field. If an IMAP server supports PARTIAL in IMAP URL used in CATENATE and URLAUTH extensions, then it MUST advertise the URL-PARTIAL capability in both the CAPABILITY response and the equivalent response-code.
[IMAP-URL]は、メッセージ/ボディパーツのバイト範囲を参照するための新しい構文要素を導入しました。これは、; partial = fieldを使用して行われます。IMAPサーバーがCatenateおよびUrlauth拡張機能で使用されるIMAP URLの部分的なサポートをサポートしている場合、機能応答と同等の応答コードの両方でURL特性機能を宣伝する必要があります。
Lemonade Message Stores MUST support the LITERAL+ [IMAP-LITERAL+] extension. The extension allows clients to save a round trip each time a non-synchronizing literal is sent.
レモネードメッセージストアは、文字通りの[IMAPリテラル]拡張機能をサポートする必要があります。拡張機能により、クライアントは、非同期のリテラルが送信されるたびに往復を節約できます。
Lemonade Message Stores MUST also implement the SASL-IR [IMAP-SASL-IR] extension, which allows clients to save a round trip during authentication, potentially pipelining the entire authentication sequence.
レモネードメッセージストアは、SASL-IR [IMAP-SASL-IR]拡張機能も実装する必要があります。これにより、クライアントは認証中に往復を節約でき、認証シーケンス全体をパイプ化する可能性があります。
Lemonade-compliant IMAP servers MUST support IMAP over TLS [IMAP] as required by [IMAP]. As noted above in Section 5.3, servers SHOULD support the deflate compression algorithm for TLS, as specified in [TLS-COMP].
レモネードに準拠したIMAPサーバーは、[IMAP]で要求されているように、TLS [IMAP]を超えるIMAPをサポートする必要があります。セクション5.3で上記のように、サーバーは[TLS-Comp]で指定されているように、TLSのデフレート圧縮アルゴリズムをサポートする必要があります。
The $Forwarded IMAP keyword is used by several IMAP clients to specify that the marked message was forwarded 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 Message Stores MUST be able to store the $Forwarded keyword. They MUST preserve it on the COPY operation. The servers MUST support the SEARCH KEYWORD $Forwarded.
レモネードメッセージストアは、$転送されたキーワードを保存できる必要があります。コピー操作に保存する必要があります。サーバーは、検索キーワード$を転送する必要があります。
The $SubmitPending IMAP keyword designates the message as awaiting to be submitted. This keyword allows storing messages waiting to be submitted in the same mailbox where messages that were already submitted and/or are being edited are stored. A mail client sets this keyword when it decides that the message needs to be sent out. When a client (it might be a different client from the one that decided that the message is pending submission) starts sending the message, it atomically (using "STORE (UNCHANGEDSINCE)") adds the $Submitted keyword. Once submission is successful, the $SubmitPending keyword is atomically cleared. The two keywords allow messages being actively submitted (messages that have both $Submitted and $SubmitPending keywords set) to be distinguished from messages awaiting to be submitted, or from messages already submitted. They also allow all messages that were supposed to be submitted to be found, if the client submitting them crashes or quits before submitting them.
$ submingpending IMAPキーワードは、メッセージを提出するのを待っていると指定します。このキーワードは、既に提出された、編集されているメッセージが保存されている同じメールボックスで送信されるのを待っているメッセージを保存することができます。メールクライアントは、メッセージを送信する必要があると判断したときにこのキーワードを設定します。クライアントがメッセージの送信が保留されていることを決定したクライアントとは別のクライアントである可能性があります）がメッセージの送信を開始すると、原子的に（「store（unchangedsince）」を使用）$送信キーワードを追加します。提出が成功すると、$ submindpendingキーワードが原子的にクリアされます。2つのキーワードを使用すると、メッセージが積極的に送信されることを可能にします（$ submitedと$ submindedingキーワードの両方のメッセージの両方が設定されているメッセージ）は、提出されるのを待つメッセージ、または既に送信されたメッセージから区別されます。また、クライアントがそれらを提出する前にクラッシュまたは終了する場合、提出することを提出することになっていたすべてのメッセージを許可します。
Lemonade Message Stores MUST be able to store the $SubmitPending and the $Submitted keyword. Lemonade Message Stores MUST preserve them on the COPY operation. The servers MUST support the SEARCH KEYWORD $SubmitPending and SEARCH KEYWORD $Submitted.
レモネードメッセージストアでは、$ submintpendingと$ submitedキーワードを保存できる必要があります。レモネードメッセージストアは、コピー操作でそれらを保存する必要があります。サーバーは、検索キーワード$ submitpendingおよび検索キーワード$をサポートする必要があります。
Section 5.11 is non-normative.
セクション5.11は非規範的です。
Server implementations targeting to fulfill OMA MEM requirements [OMA-MEM-REQ] should consider implementing the [IMAP-FILTERS], which provides a way to persist definition of virtual mailboxes on the server. They should also consider implementing the METADATA-SERVER [METADATA] extension, which provides a way of storing user-defined data associated with a user account.
OMA MEM要件を満たすためのターゲットをターゲットにするサーバーの実装[OMA-MEM-REQ]は、サーバー上の仮想メールボックスの定義を維持する方法を提供する[IMAP-Filters]の実装を検討する必要があります。また、ユーザーアカウントに関連付けられたユーザー定義データを保存する方法を提供するメタデータサーバー[メタデータ]拡張機能を実装することも検討する必要があります。
Lemonade Message Delivery Agents MUST support the [SIEVE] filtering language at the point of delivery, allowing the user to control which messages are accepted, and where they are filed.
レモネードメッセージ配信エージェントは、配信の時点で[ふるい]フィルタリング言語をサポートし、ユーザーがどのメッセージを受け入れ、どこに提出するかを制御できるようにする必要があります。
Lemonade Message Delivery Agents MUST support the Sieve Vacation extension [SIEVE-VACATION], which allows the client to set up an auto-responder, typically to report being on vacation (thus the name of the Sieve extension).
レモネードメッセージ配信エージェントは、Sieve Vacation Extension [Sieve-Vacation]をサポートする必要があります。これにより、クライアントは自動回答者を設定できます。通常、休暇中にあることを報告します（したがって、Sieve Extensionの名前）。
Lemonade Message Delivery Agents MUST support the Sieve Enotify extension [SIEVE-NOTIFY], which allows a Sieve script to generate notifications (such as XMPP, SIP, or email) about received messages.
レモネードメッセージ配信エージェントは、Sive Enotify Extension [Sieve-Notify]をサポートする必要があります。これにより、Sive Scriptは受信したメッセージについて通知（XMPP、SIP、電子メールなど）を生成できます。
Lemonade Message Delivery Agents MUST support the Sieve Variables extension [SIEVE-VARIABLES], which adds support for variables to the Sieve scripting language. This extension is typically used with Sieve Enotify or Vacation to customize responses/notifications.
レモネードメッセージ配信エージェントは、シーブ変数の拡張[Sieve-Variables]をサポートする必要があります。この拡張機能は通常、応答/通知をカスタマイズするために、Sieve Enotifyまたは休暇で使用されます。
Lemonade Message Delivery Agents MUST support the Sieve Relational extension [SIEVE-RELATIONAL], which adds support for relational comparisons to the Sieve scripting language. This extension is typically used together with Sieve Enotify.
レモネードメッセージ配信エージェントは、シーブリレーショナルエクステンション[シーブ関連]をサポートする必要があります。これにより、リレーショナル比較がふるいするスクリプト言語とサポートが追加されます。この拡張機能は通常、Sieve Enotifyと一緒に使用されます。
Lemonade Message Delivery Agents MUST support the Sieve Imap4Flags extension [SIEVE-IMAP4FLAGS], which allows a Sieve script to set IMAP flags/keywords when delivering a message to a mailbox. For example, this can be used to automatically mark certain messages as interesting, urgent, etc.
レモネードメッセージ配信エージェントは、Sieve IMAP4FLAGS Extension [Sieve-Imap4Flags]をサポートする必要があります。これにより、メッセージをメールボックスに配信するときにSiveスクリプトがIMAPフラグ/キーワードを設定できます。たとえば、これは特定のメッセージを興味深い、緊急などとして自動的にマークするために使用できます。
Lemonade Message Delivery Agents MUST support the i;unicode-casemap comparator in Sieve [UNICODE-CASEMAP], which is declared as "comparator-i;unicode-casemap" in the Sieve "require" statement. The comparator allows for case-insensitive matching of Unicode characters.
レモネードメッセージ配信エージェントは、シーブ[Unicode-Casemap]のi; Unicode-Casemapコンパレータをサポートする必要があります。コンパレータにより、ユニコード文字のケース非感受性マッチングが可能になります。
Lemonade Message Delivery Agents should consider supporting Sieve script management using the [MANAGESIEVE] protocol. If they do, they MUST also advertise in [MANAGESIEVE] all Sieve extensions listed in this section.
レモネードメッセージ配信エージェントは、[ManagESIEVE]プロトコルを使用して、ふるいスクリプト管理のサポートを検討する必要があります。もしそうなら、彼らはまた、このセクションにリストされているすべてのふるい拡張機能で[ManageSieve]で宣伝する必要があります。
Although all existing IMAP MUAs are Lemonade compliant in as much as all Lemonade services are based on the existing [IMAP] and [SUBMIT] protocols, client implementors are encouraged to take full advantage of the facilities provided by Lemonade Submission Servers and Lemonade Message Stores, as described in 4 and 5, respectively.
既存のすべてのIMAP MUAは、すべてのレモネードサービスが既存の[IMAP]および[送信]プロトコルに基づいているのと同じくらいレモネードに準拠していますが、クライアントの実装者は、レモネード提出サーバーとレモネードメッセージストアが提供する施設を最大限に活用することをお勧めします。それぞれ4と5で説明されているように。
When opening a connection to the Submission Server, clients MUST do so using port 587 unless explicitly configured to use an alternate port [RFC5068]. (Note that this requirement is somewhat stronger than the one specified in [SUBMIT], as [SUBMIT] didn't prescribe the exact procedure to be used by submission clients.) If the TCP connection to the submission server fails to open using port 587, the client MAY then immediately retry using a different port, such as 25. See [SUBMIT] for information on why using port 25 is likely to fail depending on the current location of the client, and may result in a failure code during the SMTP transaction.
提出サーバーへの接続を開くとき、クライアントは、代替ポート[RFC5068]を使用するように明示的に構成されていない限り、ポート587を使用してそうする必要があります。（[送信]で指定されている要件よりも、[送信]が提出されたクライアントが使用する正確な手順を規定していなかったため、この要件は多少強いことに注意してください。）提出サーバーへのTCP接続がポート587を使用して開くことができない場合、その後、クライアントは25などの別のポートを使用してすぐに再試行することができます。ポート25の使用がクライアントの現在の場所に応じて故障する可能性が高い理由については、[送信]を参照してください。取引。
In addition, some specifications are useful to support interoperable messaging with an enhanced user experience.
さらに、一部の仕様は、強化されたユーザーエクスペリエンスで相互運用可能なメッセージングをサポートするのに役立ちます。
Lemonade-capable clients SHOULD support the Format and DelSp parameters to the text/plain media type described in [FLOWED], and generate this format for messages.
レモネード対応クライアントは、[Flowed]に記載されているテキスト/プレーンメディアタイプの形式とDELSPパラメーターをサポートし、メッセージのこの形式を生成する必要があります。
Lemonade-capable clients SHOULD support, and use, the $Forwarded keyword described in Section 5.9.
レモネード対応クライアントは、セクション5.9で説明されている$転送キーワードをサポートし、使用する必要があります。
The advent of client/server email using the [IMAP] and [SUBMIT] protocols changed what formerly were local disk operations to become repetitive network data transmissions.
[IMAP]と[送信]プロトコルを使用したクライアント/サーバーの電子メールの出現は、以前はローカルディスク操作であったものを変更して、ネットワークデータの送信を繰り返しました。
Lemonade "forward without download" makes use of the [SMTP-BURL] 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.
レモネード「フォワードダウンロード」は、[SMTP-BURL]拡張機能を使用して、メッセージの提出中に外部ソースへのアクセスを可能にします。[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] 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 POP, NNTP, or whatever else may be designed in the future.
レモネード「フォワードダウンロードなし」には、1つの提出プロトコルを維持するという利点があり、したがって、提出のための複数の並列および場合によっては異なるメカニズムを持つリスクを回避します。クライアントは、これらをIMAPに追加せずに拡張機能を使用できます。さらに、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 MUA. Frequently, users choose to save more complex messages on an [IMAP] server (via the APPEND command with the \Draft flag) for later recall by the MUA and resumption of the editing process.
新しいドラフトとドラフト編集の開始は、MUAで行われます。多くの場合、ユーザーは、編集プロセスの後でリコールするために、[IMAP]サーバー（\ドラフトフラグを使用した追加コマンドを介して）でより複雑なメッセージを保存することを選択します。
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 [ESMTP] infrastructure, typically using the [SUBMIT] protocol.
メッセージの送信は、通常、[送信]プロトコルを使用して、組み立てられたメッセージを[ESMTP]インフラストラクチャに挿入するプロセスです。
Traditionally, messages are initiated, edited, and assembled entirely within an MUA, although drafts may be saved to an [IMAP] server and later retrieved from the server. The completed text is then transmitted to a Message Submission Agent (MSA) for delivery.
従来、メッセージはMUA内で完全に開始、編集、および組み立てられていますが、ドラフトは[IMAP]サーバーに保存され、後でサーバーから取得される場合があります。完了したテキストは、配信のためにメッセージ提出エージェント（MSA）に送信されます。
There is often no clear boundary between the editing and assembly processes. 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 retrieval 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 between a Message User Agent (MUA), an IMAPv4Rev1 Server ([IMAP]), and an SMTP submit server ([SUBMIT]), as illustrated in Figure 1.
このモデルは、図1に示すように、メッセージユーザーエージェント（MUA）、IMAPV4REV1サーバー（[IMAP]）、および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 Message User Agent to compose and forward an email combining fragments that are located in an IMAP server, without having to download these fragments to the client.
レモネード「フォワードダウンロード」を使用すると、メッセージユーザーエージェントは、これらのフラグメントをクライアントにダウンロードすることなく、IMAPサーバーにあるフラグメントを組み合わせた電子メールを作成して転送できます。
This section informatively describes two ways to perform "forward without download" based on where the message assembly takes place. The first uses the extended APPEND command [IMAP-CATENATE] to edit a draft message in the message store and cause the message assembly on the IMAP server. This is most often used when a copy of the message is to be retained on the IMAP server, as discussed in Section 8.6.
このセクションでは、メッセージアセンブリがどこで行われるかに基づいて、「ダウンロードなしでフォワード」を実行する2つの方法について説明します。最初のものは、拡張された追加コマンド[IMAP-Catenate]を使用して、メッセージストアでドラフトメッセージを編集し、IMAPサーバーにメッセージアセンブリを引き起こします。これは、セクション8.6で説明したように、メッセージのコピーがIMAPサーバーに保持される場合に最もよく使用されます。
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番目は、一連のBurlとBDATコマンドを使用して、連結、クライアントからのメッセージデータ、および提供されたURLから取得された外部データを送信および組み立てます。2つの後続のセクションでは、「ダウンロードなしでのフォワード」がどのように達成されるかについての段階的な指示を提供します。
In the [SMTP-BURL]/[IMAP-CATENATE] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. The [IMAP-CATENATE] extension to [IMAP] is then used to create the messages on the IMAP server by transmitting new text and assembling them. The UIDPLUS [IMAP-UIDPLUS] IMAP extension is used by the client in order to learn the UID of the created messages. Finally, an [IMAP-URLAUTH] format URL is given to a [SUBMIT] server for submission using the BURL [SMTP-BURL] extension.
[SMTP-BURL]/[IMAP-CATENATE]レモネードの「フォワードフォワードダウンロード」戦略で、メッセージは最初にMUA内で構成および編集されます。[IMAP-Catenate] [IMAP]への拡張は、新しいテキストを送信して組み立てることにより、IMAPサーバー上にメッセージを作成するために使用されます。UIDPLUS [IMAP-UIDPLUS] IMAP拡張は、作成されたメッセージのUIDを学習するためにクライアントが使用します。最後に、[IMAP-Urlauth]形式のURLが[SMTP-BURL]拡張機能を使用して[SMTP-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 [IMAP]).
m：{to i -optional}クライアントはIMAPサーバーに接続し、オプションでTLSを起動し（データの機密性が必要な場合）、認証、メールボックス（以下の例で「受信ボックス」）、ボディ構造を取得します（[参照）IMAP]）。
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 [IMAP-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（[IMAP-Catenate]を参照）を呼び出します。IMAPサーバー上。
Note that the example for this step doesn't use the LITERAL+ [IMAP-LITERAL+] extension. Without LITERAL+ the new message is constructed using three round trips. If LITERAL+ is used, the new message can be constructed using one round trip.
このステップの例では、リテラル[IMAPリテラル]拡張機能は使用されないことに注意してください。リテラルがなければ、3回のラウンド旅行を使用して新しいメッセージが作成されます。リテラルを使用すると、1回の往復を使用して新しいメッセージを作成できます。
M: A0052 APPEND Sent FLAGS (\Draft \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 the GENURLAUTH command to request a URLAUTH URL (see [IMAP-URLAUTH]). I: {to M} The IMAP server returns a URLAUTH URL suitable for later retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the semantics and steps).
m：{to i}クライアントはGenurlauthコマンドを使用してUrlauth URLを要求します（[iMap-urlauth]を参照）。i：{to m} IMAPサーバーは、セマンティクスと手順の詳細については、urlfetch（[imap-urlauth]を参照）を使用した後の検索に適したurlauth URLを返します。
M: A0053 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: A0053 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 [IMAP-URLAUTH] 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 8.4.2 demonstrates this.
m：{to s}クライアントはメール送信サーバーに接続し、新しいメールトランザクションを開始します。Burlを使用して、SMTPをSMTP送信サーバーにIMAPサーバーからのメッセージのコンテンツを取得させます（[IMAP-Urlauth]を参照してください。セマンティクスと手順の詳細 - これにより、MUAはSMTP送信サーバーに構成されたメッセージにアクセスすることを許可できます。Catenateステップの結果として）。StartTLSコマンドが成功した後、2番目のEHLOコマンドが必要であることに注意してください。また、2番目のEhlo応答がBurlオプションをリストしていない場合、3番目の必須Ehloコマンドがある可能性があることに注意してください。セクション8.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=
M: MAIL FROM:<bob.ar@example.org>
M: RCPT TO:<foo@example.net>
S: 235 2.7.0 PLAIN authentication successful.
S: 250 2.5.0 Address Ok.
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 [IMAP-URLAUTH] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI that contains its own authorization credentials.) I: {to S} Provides the message composed as a result of the CATENATE step).
s：{to i}メール送信サーバーはurlfetchを使用してメッセージをフェッチします。（セマンティクスと手順の詳細については、[IMAP-Urlauth]を参照してください。いわゆる「ポーンチケット」認証メカニズムは、独自の認証資格情報を含むURIを使用します。）i：{to s}は、結果として構成されたメッセージを提供します。カテネートステップの）。
The mail Submission Server opens an 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...
I: a002 OK URLFETCH completed
S: a003 LOGOUT
I: * BYE See you later
I: a003 OK Logout successful
Note that if data confidentiality is not required, the mail Submission Server may omit the STARTTLS command before issuing the LOGIN command.
データの機密性が不要な場合、ログインコマンドを発行する前に、Mail Submission ServerがStartTLSコマンドを省略する場合があることに注意してください。
S: {to M} Submission server assembles the complete message; if the assembly succeeds, it returns OK to the MUA:
s：{to 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：{to i}クライアントは、IMAPサーバーに転送された添付ファイルを含むメッセージをマークします。
M: A0054 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: A0054 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, as it simply changes non-operational metadata not essential to client operations or interoperability. The untagged FETCH response is due to [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in Section 5.9.
注：上記のUIDストアコマンドは、マークされたメッセージが現在選択されているメールボックスにある場合にのみ機能します。それ以外の場合は、selectが必要です。このコマンドは、クライアントの操作や相互運用性に不可欠ではない非運用メタデータを単純に変更するため、省略できます。攻撃されていないフェッチの応答は、[IMAP-Condstore]によるものです。$転送されたIMAPキーワードは、セクション5.9で説明されています。
In the [IMAP-URLAUTH]/[SMTP-BURL] variant of the Lemonade "forward without download" strategy, messages are initially composed and edited within an MUA. During submission [SUBMIT], BURL [SMTP-BURL] and BDAT [SMTP-BINARYMIME] 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 [IMAP-URLAUTH] format URLs in BURL commands.
レモネード「フォワードダウンロードなし」戦略の[IMAP-URLAUTH]/[SMTP-BURL]バリアントでは、メッセージは最初にMUA内で構成および編集されます。提出中[送信]中、Burl [SMTP-BURL]およびBDAT [SMTP-BinaryMime]コマンドを使用して、複数の部品からメッセージを作成します。BDATコマンドを使用して新しいボディパーツが提供され、既存のボディパーツはBurlコマンドの[IMAP-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 [IMAP]).
そのようなユースケースをサポートするためのフローは、M：{to i -optional}で構成されています。クライアントはIMAPサーバーに接続し、オプションでTLSを起動します（データの機密性が必要な場合）、認証、メールボックス（「受信ボックス」）以下の例）、およびボディ構造を取得します（[IMAP]を参照）。
Example:
例：
M: B0051 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: B0051 OK completed
M：B0051 UID FETCH 25627（UID BODYSTRUCTURE）I： * 161 FETCH（UID 25627 BODYSTRUCTURE（（ "TEXT" "PLAIN"（ "Charset" "US-ASSII"）NIL NIL "7BIT」1152 23）（" Text "" ""Plain "（" charset "" us-ascii "" name "" trip.txt "）" <960723163407.20117h@washington.example.comB0051 OK完了
M: {to I} The client uses the GENURLAUTH command to request URLAUTH URLs (see [IMAP-URLAUTH]) referencing pieces of the message to be assembled. I: {to M} The IMAP server returns URLAUTH URLs suitable for later retrieval with URLFETCH (see [IMAP-URLAUTH] for details of the semantics and steps).
m：{to i}クライアントは、Genurlauthコマンドを使用して、urlauth URL（[imap-urlauth]を参照）を要求します。i：{to m} IMAPサーバーは、セマンティクスと手順の詳細については、urlfetch（[imap-urlauth]を参照）を使用して後の検索に適したurlauth URLを返します。
M: B0052 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: B0052 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 [SMTP-BURL] for details of the semantics and steps).
m：{to s}クライアントはメール送信サーバーに接続し、新しいメールトランザクションを開始します。Burlを使用して、SMTP送信サーバーに、送信されるメッセージのIMAPサーバーのピースからフェッチするよう指示します（セマンティクスと手順の詳細については[SMTP-BURL]を参照）。
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 8.4.1 for an example of submission where the third EHLO command/response is not present.
StartTLSコマンドが成功した後、2番目のEHLOコマンドが必要であることに注意してください。2番目のEhlo応答がBurlオプションをリストしない場合にのみ、3番目のEhloコマンドが必要です。3番目のEhloコマンド/応答が存在しない提出の例については、セクション8.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 [SMTP-BURL] for details of the semantics and steps. The so-called "pawn-ticket" authorization mechanism uses a URI which contains its own authorization credentials.). I: {to S} Returns the requested body parts.
s：{to i}メール送信サーバーはurlfetchを使用して、送信されるメッセージのピースをフェッチします。（セマンティクスとステップの詳細については、[SMTP-BURL]を参照してください。いわゆる「ポーンチケット」認証メカニズムは、独自の認証資格情報を含むURIを使用します。）i：{to s}要求されたボディ部分を返します。
The mail Submission Server opens an 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: b000 STARTTLS
I: b000 Start TLS negotiation now
...TLS negotiation, if successful - subsequent data
is encrypted...
S: b001 LOGIN submitserver secret
I: b001 OK submitserver logged in
S: b002 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...
I: b002 OK URLFETCH completed
S: b003 LOGOUT
I: * BYE See you later
I: b003 OK Logout successful
Note that if data confidentiality is not required, the mail Submission Server may omit the STARTTLS command before issuing the LOGIN command.
データの機密性が不要な場合、ログインコマンドを発行する前に、Mail Submission ServerがStartTLSコマンドを省略する場合があることに注意してください。
S: {to M} Submission Server assembles the complete message; 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: B0053 UID STORE 25627 +FLAGS.SILENT ($Forwarded)
I: * 215 FETCH (UID 25627 MODSEQ (12121231000))
I: B0053 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. As in the previous example, this command is not critical, and can be omitted. The untagged FETCH response is due to [IMAP-CONDSTORE]. The $Forwarded IMAP keyword is described in Section 5.9.
注：上記のUIDストアコマンドは、マークされたメッセージが現在選択されているメールボックスにある場合にのみ機能します。それ以外の場合は、selectが必要です。前の例のように、このコマンドは重要ではなく、省略できます。攻撃されていないフェッチの応答は、[IMAP-Condstore]によるものです。$転送されたIMAPキーワードは、セクション5.9で説明されています。
The so-called "pawn-ticket" authorization mechanism uses a URI, which contains its own authorization credentials using [IMAP-URLAUTH]. The advantage of this mechanism is that the SMTP submit [SUBMIT] server cannot access any data on the [IMAP-URLAUTH] server without a "pawn-ticket" created by the client.
いわゆる「ポーンチケット」認証メカニズムは、[IMAP-Urlauth]を使用して独自の認証資格情報を含むURIを使用します。このメカニズムの利点は、SMTP Submit [Submit]サーバーが、クライアントが作成した「ポーンチケット」なしで[IMAP-Urlauth]サーバー上のデータにアクセスできないことです。
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 mailbox, or "file carbon copy". 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 BURL [SMTP-BURL] extension can be used to eliminate the additional transmission. The final message is uploaded to the mailbox designed for outgoing mail by the APPEND command of [IMAP]. Note that when doing so, the client ought to use the $SubmitPending and $Submitted IMAP keywords described in Section 5.10. Also note that APPEND, including when enhanced by [IMAP-CATENATE], can only create a single copy of the message and this is only of use on the server that stages the outgoing message for submission. Additional copies of the message on the same server can be created by using one or more COPY commands.
Burl [SMTP-BURL]拡張機能を使用して、追加の伝送を排除できます。最終メッセージは、[IMAP]の追加コマンドによって送信メール用に設計されたメールボックスにアップロードされます。そうする場合、クライアントはセクション5.10で説明されている$ submingpendingおよび$送信IMAPキーワードを使用する必要があることに注意してください。また、[IMAP-Catenate]によって強化された場合を含む追加は、メッセージの単一のコピーのみを作成できることに注意してください。これは、送信の送信メッセージをステージングするサーバーでのみ使用することです。同じサーバー上のメッセージの追加コピーは、1つ以上のコピーコマンドを使用して作成できます。
Deployment considerations are discussed extensively in [LEMONADE-DEPLOYMENTS].
展開の考慮事項は、[レモネード展開]で広く議論されています。
Implementors are advised to examine the security considerations of all the referenced documents. This section merely highlights these, and advises implementors on specific issues relating to the combination of extensions.
実装者は、参照されるすべての文書のセキュリティ上の考慮事項を調べることをお勧めします。このセクションは、これらを強調するだけで、拡張機能の組み合わせに関する特定の問題について実装者にアドバイスします。
Security considerations on Lemonade "forward without download" are discussed throughout Section 8. Additional security considerations can be found in [IMAP], [SUBMIT], [SIEVE], and other documents describing other SMTP, IMAP, and Sieve extension comprising the Lemonade Profile.
レモネードに関するセキュリティの考慮事項「フォワードダウンロード」については、セクション8を通して議論されています。追加のセキュリティ上の考慮事項は、[IMAP]、[送信]、[ふるい]、およびレモネードプロファイルを含む他のSMTP、IMAP、およびシーブ拡張を説明するその他のドキュメントにあります。。
Note that the mandatory-to-implement authentication mechanism for SMTP submission is described in [SMTP-AUTH]. The mandatory-to-implement authentication mechanism for IMAP is described in [IMAP].
SMTP提出の必須の実現認証メカニズムは[SMTP-Auth]で説明されていることに注意してください。IMAPの必須の実現認証メカニズムは、[IMAP]で説明されています。
When clients submit new messages, link protection such as [TLS] guards against an eavesdropper seeing the contents of the submitted message. It is 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 for mail submission, an extension that 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 both the IMAP session that issues GENURLAUTH and the mail submission path will provide protection against this attack.
レモネードのクライアントがメールの提出にBurl拡張機能を使用する場合、urlauthトークンをメール提出サーバーに送信する必要がある拡張機能である場合、そのようなトークンは、メッセージの内容を攻撃者に開示する可能性のあるリプレイ攻撃を避けるために傍受から保護する必要があります。[TLS] GenurlauthとMail Submissionパスを発行する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または同等のデータ機密性を提供するメカニズムを使用する必要があります。
This specification provides no additional security measures beyond those in the referenced Internet Mail and Lemonade documents.
この仕様は、参照されているインターネットメールおよびレモネードドキュメントのセキュリティ対策を超えて追加のセキュリティ対策を提供しません。
We note, however, the security risks associated with:
ただし、関連するセキュリティリスクに注意してください。
o Outband notifications
o アウトバンド通知
o Server configuration by client
o クライアントによるサーバー構成
o Client configuration by server
o サーバーによるクライアント構成
o Presence of proxy servers
o プロキシサーバーの存在
o Presence of servers as intermediaries
o 仲介業者としてのサーバーの存在
o In general, the deployment models considered by OMA MEM that are not conventional IETF deployment models
o 一般に、従来のIETF展開モデルではないOMA MEMが考慮した展開モデル
o Measures to address a perceived need to traverse firewalls and mobile network intermediaries
o ファイアウォールとモバイルネットワークの仲介者を通過する必要性が認識されていることに対処するための措置
Deployments that provide these additional services or operate in these environments need to consult the security considerations for the relevant standards and organizational security practices.
これらの追加サービスを提供するか、これらの環境で動作する展開は、関連する基準と組織のセキュリティ慣行についてセキュリティ上の考慮事項を参照する必要があります。
IMAP4 capabilities are registered by IETF Review, as defined in [RFC5226]. This document defines the URL-PARTIAL IMAP capability (Section 5.7.1). IANA added this extension to the IANA IMAP Capability registry.
IMAP4機能は、[RFC5226]で定義されているように、IETFレビューによって登録されています。このドキュメントでは、URL特殊なIMAP機能を定義します（セクション5.7.1）。IANAは、この拡張機能をIANA IMAP機能レジストリに追加しました。
When compared to RFC 4550, this document adds the following additional requirements on a Lemonade compliant IMAP server:
RFC 4550と比較すると、このドキュメントは、レモネードに準拠したIMAPサーバーに次の追加要件を追加します。
IMAP extensions: BINARY, COMPRESS=DEFLATE, CONTEXT=SEARCH,
CONTEXT=SORT, CONVERT, ENABLE, ESEARCH, ESORT, I18NLEVEL=1,
NOTIFY, QRESYNC, SASL-IR, SORT, URL-PARTIAL;
IMAP keywords: $SubmitPending, $Submitted.
IMAPキーワード：$ submitpending、$ submitted。
Other requirements: Require any Lemonade compliant IMAP server to support the CAPABILITY response code.
その他の要件：機能応答コードをサポートするために、レモネードに準拠したIMAPサーバーが必要です。
When compared to RFC 4550, this document adds the following new requirements on a Lemonade compliant Message Delivery Agents:
RFC 4550と比較すると、このドキュメントは、レモネードに準拠したメッセージ配信エージェントに次の新しい要件を追加します。
Support for the Sieve filtering language, together with the following Sieve extensions:
以下のふるい拡張機能とともに、ふるいフィルタリング言語のサポート：
ENOTIFY, IMAP4FLAGS, RELATIONAL, VACATION, VARIABLES, comparator-i;unicode-casemap.
enotify、imap4flags、リレーショナル、休暇、変数、比較-i; unicode-casemap。
When compared to RFC 4550, this document recommends use of the DEFLATE compression method for TLS. All other requirements remain the same.
RFC 4550と比較すると、このドキュメントでは、TLSのデフレート圧縮法の使用を推奨しています。他のすべての要件は同じままです。
Additionally, the following changes/improvments were done to RFC 4550 (the list might be incomplete):
さらに、RFC 4550に対して次の変更/改善が行われました（リストが不完全である可能性があります）。
A new section with some additional requirements on Lemonade Mail User Agents was added, in particular they are required to support Format=flowed parameter to the text/plain media type.
レモネードメールユーザーエージェントに関するいくつかの追加要件を備えた新しいセクションが追加されました。特に、テキスト/プレーンメディアタイプにFlowedパラメーターをサポートする必要があります。
Usage of the $Forwarded IMAP keyword was clarified.
$転送されたIMAPキーワードの使用が明確になりました。
Forward-without-download examples were corrected and extended.
前方にダウンロードの例が修正され、拡張されました。
Added a new section describing in-band and out-of-band notifications from a Lemonade compliant mailstore.
レモネードに準拠したメールストアからの帯域および帯域外の通知を説明する新しいセクションを追加しました。
The editors acknowledge and appreciate the work and comments of the IETF Lemonade working group and the OMA MEM working group.
編集者は、IETFレモネードワーキンググループとOMA MEMワーキンググループの作業とコメントを認め、感謝しています。
In particular, the editors would like to thank Eric Burger, Glenn Parsons, Randall Gellens, Filip Navara, Zoltan Ordogh, Greg Vaudreuil, and Fan Xiaohui for their comments and reviews.
特に、編集者は、エリック・バーガー、グレン・パーソンズ、ランドール・ゲレンズ、フィリップ・ナバラ、ゾルタン・オルドグ、グレッグ・ヴォードルイユ、ファン・シャオフイのコメントとレビューに感謝します。
[FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[Flowed] Gellens、R。、「The Text/Plain Format and Delspパラメーター」、RFC 3676、2004年2月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP] Crispin、M。、「インターネットメッセージアクセスプロトコル -バージョン4REV1」、RFC 3501、2003年3月。
[IMAP-BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[IMAP-Binary] Nerenberg、L。、「IMAP4バイナリコンテンツ拡張」、RFC 3516、2003年4月。
[IMAP-CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[IMAP-Catenate] Resnick、P。、「インターネットメッセージアクセスプロトコル（IMAP）Catenate Extension」、RFC 4469、2006年4月。
[IMAP-COMPRESS] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, August 2007.
[IMAP-Cocpress] Gulbrandsen、A。、「The IMAP Compress Extension」、RFC 4978、2007年8月。
[IMAP-CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[IMAP-Condstore] Melnikov、A。and S. Hole、「条件付きストアの操作またはクイックフラグ変更再同期のためのIMAP拡張」、RFC 4551、2006年6月。
[IMAP-CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[IMAP-Context] Cridland、D。およびC. King、「IMAP4のコンテキスト」、RFC 5267、2008年7月。
[IMAP-CONVERT] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[IMAP -Convert] Melnikov、A。およびP. Coates、「インターネットメッセージアクセスプロトコル - 拡張機能の変換」、RFC 5259、2008年7月。
[IMAP-ENABLE] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[IMAP-Inable] Gulbrandsen、A。and A. Melnikov、「The IMAP Enable Extension」、RFC 5161、2008年3月。
[IMAP-ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[IMAP-Esearch] Melnikov、A。and D. Cridland、「どのような種類の情報が返されるかを制御するための検索コマンドへのIMAP4拡張」、RFC 4731、2006年11月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP-I18N] Newman、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、2008年6月。
[IMAP-IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IMAP-IDLE] Leiba、B。、「IMAP4 IDLEコマンド」、RFC 2177、1997年6月。
[IMAP-LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
[IMAP-LITRAL] Myers、J。、「IMAP4非同期リテラル」、RFC 2088、1997年1月。
[IMAP-NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[IMAP-NamesPace] Gahrns、M。and C. Newman、「IMAP4 Namespace」、RFC 2342、1998年5月。
[IMAP-NOTIFY] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009.
[Imap-notify] Gulbrandsen、A.、King、C。、およびA. Melnikov、「IMAP Notify Extension」、RFC 5465、2009年2月。
[IMAP-QRESYNC] Melnikov, A., Cridland, D., and C. Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", RFC 5162, March 2008.
[IMAP-QRESYNC] Melnikov、A.、Cridland、D。、およびC. Wilson、「Quick Mailbox再同期のためのIMAP4拡張機能」、RFC 5162、2008年3月。
[IMAP-SASL-IR] Siemborski, R. and A. Gulbrandsen, "IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response", RFC 4959, September 2007.
[IMAP-SASL-IR] Siemborski、R。およびA. Gulbrandsen、「単純な認証とセキュリティレイヤー（SASL）初期クライアント応答のIMAP拡張」、RFC 4959、2007年9月。
[IMAP-SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[IMAP -SORT] Crispin、M。and K. Murchison、「インターネットメッセージアクセスプロトコル - ソートおよびスレッド拡張機能」、RFC 5256、2008年6月。
[IMAP-UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[IMAP -UIDPLUS] CRISPIN、M。、「インターネットメッセージアクセスプロトコル（IMAP）-UIDPLUS拡張」、RFC 4315、2005年12月。
[IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[Imap-url] Melnikov、A。and C. Newman、「IMAP URLスキーム」、RFC 5092、2007年11月。
[IMAP-URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[IMAP -Urlauth] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、RFC 4467、2006年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[Sieve] Guenther、P。and T. Showalter、「Sieve：An Email Filtering Language」、RFC 5228、2008年1月。
[SIEVE-IMAP4FLAGS] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008.
[Sieve-Imap4flags] Melnikov、A。、「Sieve Emailフィルタリング：IMAP4FLAGS拡張機能」、RFC 5232、2008年1月。
[SIEVE-NOTIFY] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, "Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
[Sieve-Notify] Melnikov、A.、Leiba、B.、Segmuller、W。、およびT. Martin、「Sieve Emailフィルタリング：通知の拡張」、RFC 5435、2009年1月。
[SIEVE-RELATIONAL] Segmuller, W. and B. Leiba, "Sieve Email Filtering: Relational Extension", RFC 5231, January 2008.
[Sieve-relational] Segmuller、W。and B. Leiba、「Sieve Emailフィルタリング：リレーショナルエクステンション」、RFC 5231、2008年1月。
[SIEVE-VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[Sieve-Vacation] Showalter、T。and N. Freed、「Sieve Emailフィルタリング：休暇拡張」、RFC 5230、2008年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[Sieve-Variables] Homme、K。、「Sieve Emailフィルタリング：変数拡張」、RFC 5229、2008年1月。
[SMTP-8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[SMTP-8Bitmime] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007.
[SMTP-Auth] Siemborski、R。およびA. Melnikov、「認証のためのSMTPサービス拡張」、RFC 4954、2007年7月。
[SMTP-BINARYMIME] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[SMTP-BinaryMime] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、RFC 3030、2000年12月。
[SMTP-BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[SMTP-BURL] Newman、C。、「Message Submission Burl Extension」、RFC 4468、2006年5月。
[SMTP-DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[SMTP-DSN] MOORE、K。、「配送ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス延長」、RFC 3461、2003年1月。
[SMTP-PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[SMTP-Pipelining] Freed、N。、「コマンドパイプラインのSMTPサービス拡張」、STD 60、RFC 2920、2000年9月。
[SMTP-SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
[SMTP-Size] Klensin、J.、Freed、N。、およびK. Moore、「メッセージサイズ宣言のSMTPサービス拡張」、STD 10、RFC 1870、1995年11月。
[SMTP-STATUSCODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[SMTP-STATUSCODES] FREED、N。、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over the Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[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月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[TLS-COMP] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[TLS-Comp] Hollenbeck、S。、「輸送層セキュリティプロトコル圧縮法」、RFC 3749、2004年5月。
[UNICODE-CASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[Unicode-casemap] Crispin、M。、「i; unicode-casemap-Simple Unicode Collation Algorithm」、RFC 5051、2007年10月。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[ESMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[Err1807] RFC Errata, Errata ID 1807, RFC 5162, <http://www.rfc-editor.org>.
[ERR1807] RFC Errata、Errata ID 1807、RFC 5162、<http://www.rfc-editor.org>。
[Err1808] RFC Errata, Errata ID 1808, RFC 5162, <http://www.rfc-editor.org>.
[ERR1808] RFC ERRATA、ERRATA ID 1808、RFC 5162、<http://www.rfc-editor.org>。
[Err1809] RFC Errata, Errata ID 1809, RFC 5162, <http://www.rfc-editor.org>.
[ERR1809] RFC Errata、Errata ID 1809、RFC 5162、<http://www.rfc-editor.org>。
[Err1810] RFC Errata, Errata ID 1810, RFC 5162, <http://www.rfc-editor.org>.
[ERR1810] RFC Errata、Errata ID 1810、RFC 5162、<http://www.rfc-editor.org>。
[FINGER-HACK] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[フィンガーハック] Gellens、R。、「Simple New Mail通知」、RFC 4146、2005年8月。
[IMAP-FILTERS] Melnikov, A. and C. King, "IMAP4 Extension for Named Searches (Filters)", RFC 5466, February 2009.
[IMAP-Filters] Melnikov、A。およびC. King、「名前付き検索のIMAP4拡張（フィルター）」、RFC 5466、2009年2月。
[IMAP-SYNC-HOWTO] Melnikov, A., "Synchronization Operations for Disconnected IMAP4 Clients", RFC 4549, June 2006.
[IMAP-Sync-Howto] Melnikov、A。、「切断されたIMAP4クライアントの同期操作」、RFC 4549、2006年6月。
[LEMONADE-ARCH] Burger, E. and G. Parsons, "LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail", RFC 5442, March 2009.
[レモネードアーチ]バーガー、E。およびG.パーソンズ、「レモネードアーキテクチャ - インターネットメールを使用したオープンモバイルアライアンス（OMA）モバイルメール（MEM）のサポート」、RFC 5442、2009年3月。
[LEMONADE-DEPLOYMENTS] Gellens, R., "Deployment Considerations for Lemonade-Compliant Mobile Email", BCP 143, RFC 5383, October 2008.
[Lemonade Deployments] Gellens、R。、「レモネードに準拠したモバイルメールの展開に関する考慮事項」、BCP 143、RFC 5383、2008年10月。
[LEMONADE-NOTIFICATIONS] Gellens, R., Ed., "Lemonade Notifications Architecture", RFC 5551, August 2009.
[Lemonade-notifications] Gellens、R.、ed。、「レモネード通知アーキテクチャ」、RFC 5551、2009年8月。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[ManageSieve] Melnikov、A。、およびT. Martin、「Sive Scriptsをリモートで管理するためのプロトコル」、2008年9月、Work in Progress。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[メタデータ] Daboo、C。、「IMAPメタデータ拡張」、RFC 5464、2009年2月。
[OMA-EMN] Open Mobile Alliance, "Open Mobile Alliance Email Notification Version 1.0", OMA http:// www.openmobilealliance.org/Technical/release_program/ emn_v10.aspx, October 2007.
[Oma-emn]オープンモバイルアライアンス、「オープンモバイルアライアンスメール通知バージョン1.0」、OMA http：// www.openmobilealliance.org/technical/release_program/ emn_v10.aspx、2007年10月。
[OMA-MEM-ARCH] Open Mobile Alliance, "Mobile Email Architecture Document", OMA (Work in Progress), http://www.openmobilealliance.org/, October 2005.
[OMA-MEM-ARCH]オープンモバイルアライアンス、「モバイルメールアーキテクチャドキュメント」、OMA（Work in Progress）、http：//www.openmobilealliance.org/、2005年10月。
[OMA-MEM-REQ] Open Mobile Alliance, "Mobile Email Requirements Document", OMA http://www.openmobilealliance.org/ release_program/docs/RD/ OMA-RD-MobileEmail-V1_0_20051018-C.pdf, Oct 2005.
[OMA-MEM-REQ]オープンモバイルアライアンス、「モバイルメール要件ドキュメント」、OMA http://www.openmobilealliance.org/ release_program/docs/rd/oma-rd-mobileemail-v1_0_200551018-c.pdf、2005年10月。
[RFC5068] Hutzler, C., Crocker, D., Resnick, P., Allman, E., and T. Finch, "Email Submission Operations: Access and Accountability Requirements", BCP 134, RFC 5068, November 2007.
[RFC5068] Hutzler、C.、Crocker、D.、Resnick、P.、Allman、E.、およびT. Finch、「電子メール提出操作：アクセスおよび説明責任要件」、BCP 134、RFC 5068、2007年11月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[RFC5598] Crocker、D。、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
Errata ID: 1807 [Err1807]
Errata ID：1807 [err1807]
Status: Verified Type: Technical
ステータス：検証型タイプ：技術
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
報告：Timo Sirainen日付報告：2009-07-14 Verifier Name：Alexey Melnikov Date Verified：2009-07-18
Section 1 says:
セクション1は次のように述べています
It should say:
言うべきです：
Once a "CONDSTORE enabling command" is issued by the client, the server MUST automatically include both UID and mod-sequence data in all subsequent untagged FETCH responses (until the connection is closed), whether they were caused by a regular STORE/UID STORE, a STORE/UID STORE with UNCHANGEDSINCE modifier, or an external agent. Note that this rule doesn't affect untagged FETCH responses caused by a FETCH command that doesn't include UID and/or MODSEQ FETCH data item, or UID FETCH without the MODSEQ FETCH data item.
クライアントが「condstore有効コマンド」が発行されると、サーバーは、通常のストア/UIDストアによって引き起こされたかどうかにかかわらず、その後のすべての未編成フェッチ応答（接続が閉じるまで）にUIDとmodシーケンスの両方を自動的に含める必要があります。、変更されていない修飾子を備えたストア/UIDストア、または外部エージェント。このルールは、UIDおよび/またはMODSEQ Fetch Data Item、またはModSeq Fetch Data ItemなしでUID Fetchを含まないFetchコマンドによって引き起こされた未編集のフェッチ応答に影響しないことに注意してください。
Notes:
ノート：
Rationale:
根拠：
It's very difficult for clients to make use of unsolicited FETCH responses without the UID field. This is made even worse by the text that says "servers SHOULD NOT send UIDs for previously expunged messages [in VANISHED replies]". Since it's not a MUST NOT, a conversation with an RFC compliant server could be for example:
クライアントがUIDフィールドなしで未承諾のフェッチ応答を使用することは非常に困難です。これは、「サーバーが以前に削除されたメッセージにUIDを送信してはならない[消滅した返信]」というテキストによってさらに悪化します。必須ではないので、RFC準拠サーバーとの会話は次のことをする可能性があります。
A1 NOOP * 0 EXISTS A1 OK A2 NOOP * 10 EXISTS * VANISHED 1000:2000 * 3 FETCH (FLAGS (\Seen) MODSEQ (14749)) * 5 FETCH (FLAGS (\Seen) MODSEQ (14749)) * VANISHED 2000:3000 A2 OK NOOP Completed
a1 noop * 0が存在するa1 ok a2 noop * 10が存在します *消去1000：2000 * 3 fetch（flags（\ seed）modseq（14749））A2 OKNOOPが完了しました
The client couldn't do anything with the information from FETCH replies, because it can't know what messages they refer to.
クライアントは、フェッチの返信からの情報を何もできませんでした。
Errata ID: 1808 [Err1808]
Errata ID：1808 [err1808]
Status: Verified Type: Technical
ステータス：検証型タイプ：技術
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
報告：Timo Sirainen日付報告：2009-07-14 Verifier Name：Alexey Melnikov Date Verified：2009-07-18
Section 3.4 says:
セクション3.4と言っています：
If at least one message got expunged, the server MUST send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response.
少なくとも1つのメッセージが削除された場合、サーバーは、タグ付きOK応答でhighestmodseq応答コード（[condstore]で定義）を使用して更新されたmailbox変更シーケンスを送信する必要があります。
Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
例：C：A202クローズS：A202 OK [HighestModseq 20010715194045319]完了
It should say:
言うべきです：
The server MUST NOT send the updated per-mailbox modification sequence using the HIGHESTMODSEQ response code (defined in [CONDSTORE]) in the tagged OK response, as this might cause loss of synchronization on the client.
サーバーは、クライアントの同期が失われる可能性があるため、タグ付きOK応答でhightmodseq応答コード（[condstore]で定義）を使用して更新されたpermailbox変更シーケンスを送信してはなりません。
Example: C: A202 CLOSE S: A202 OK done
例：C：A202クローズs：a202 ok done
Notes:
ノート：
Rationale:
根拠：
The HIGHESTMODSEQ can't be used reliably unless server sends to client all changes done by other clients. Even then it's difficult for both clients and servers to implement this. For example:
Serverが他のクライアントによって行われたすべての変更をクライアントに送信しない限り、HightModseqは確実に使用することはできません。それでも、クライアントとサーバーの両方がこれを実装することは困難です。例えば：
C1: 2 STORE 1 +FLAGS.SILENT \Deleted
S1: * 1 FETCH (MODSEQ 1)
S1: 2 OK
C2: 1 STORE 2 +FLAGS.SILENT \Deleted
S1: * 2 FETCH (MODSEQ 2)
S2: 1 OK
C1: 3 CLOSE S1: 3 [HIGHESTMODSEQ 3] The client probably thought that only message 1 was expunged, so it doesn't register the second expunge. And it probably never will if it uses QRESYNC to find out only about new expunges.
c1：3 close s1：3 [highestmodseq 3]クライアントは、おそらくメッセージ1のみが削除されていると考えていたため、2番目の抹消を登録しません。そして、それがQRESYNCを使用して新しい抹消についてのみを見つけるなら、それはおそらく決してそうではありません。
And even worse example would be if the second client had also removed the \Deleted flag from message 1. Then the first client would have registered wrong message to be expunged.
さらに悪い例は、2番目のクライアントがメッセージ1から\削除されたフラグを削除した場合です。その後、最初のクライアントは間違ったメッセージを登録して削除することです。
Errata ID: 1809 [Err1809]
Errata ID：1809 [err1809]
Status: Verified Type: Technical
ステータス：検証型タイプ：技術
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
報告：Timo Sirainen日付報告：2009-07-14 Verifier Name：Alexey Melnikov Date Verified：2009-07-18
Section 5 says:
セクション5と書かれています：
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items received from the server. Whenever the client receives a tagged response to a command, it calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
完全な同期を完了した後、クライアントは、サーバーから受信した未承諾のmodSeqフェッチデータ項目にも注意する必要があります。クライアントがコマンドに対するタグ付き応答を受信するたびに、最後にタグ付けされた応答以降に受信したすべてのMODSEQフェッチデータ項目の中で最高値を計算します。この値がクライアントのhighestmodseq値のコピーよりも大きい場合、クライアントはこの値を新しいhighestmodseq値として使用する必要があります。
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. This can lead to the client missing some changes in case of connectivity loss.
注：サーバーがModSeqcenceの注文を増やす際にModSeq Fethデータアイテムを送信する必要がないため、受信したらすぐに、ModSeq Fetch Data Item値を使用して、highestmodseq値のクライアントのコピーをModSeq Fetch Data Item値を更新することは安全ではありません。これにより、クライアントが接続性の損失の場合にいくつかの変更を欠いている可能性があります。
It should say:
言うべきです：
After completing a full synchronization, the client MUST also take note of any unsolicited MODSEQ FETCH data items and HIGHESTMODSEQ response codes received from the server. Whenever the client receives a tagged response to a command, it checks the received unsolicited responses to calculate the new HIGHESTMODSEQ value. If the HIGHESTMODSEQ response code is received, the client MUST use it even if it has seen higher mod-sequences. Otherwise, the client calculates the highest value among all MODSEQ FETCH data items received since the last tagged response. If this value is bigger than the client's copy of the HIGHESTMODSEQ value, then the client MUST use this value as its new HIGHESTMODSEQ value.
完全な同期を完了した後、クライアントは、未承諾のMODSEQ Fetchデータ項目とサーバーから受信したHightModSeq応答コードについても注意する必要があります。クライアントがコマンドに対するタグ付き応答を受信するたびに、受信した未承諾の応答をチェックして、新しいhighestModSeq値を計算します。hightmodseq応答コードを受信した場合、より高いmodシーケンスが見られていても、クライアントはそれを使用する必要があります。それ以外の場合、クライアントは、最後にタグ付けされた応答以降に受信したすべてのMODSEQ Fetchデータ項目の中で最高値を計算します。この値がクライアントのhighestmodseq値のコピーよりも大きい場合、クライアントはこの値を新しいhighestmodseq値として使用する必要があります。
Example: C: A1 STORE 1:2 (UNCHANGEDSINCE 96) +FLAGS.SILENT \Seen
S: * 1 FETCH (UID 6 MODSEQ (103))
S: * 2 FETCH (UID 7 MODSEQ (101))
S: * OK [HIGHESTMODSEQ 99] VANISHED reply with
MODSEQ 100 is delayed
S: A1 OK [MODIFIED 3] done
C: A2 STORE 3 +FLAGS.SILENT \Seen
S: * 3 FETCH (UID 8 MODSEQ (104))
S: A2 OK [HIGHESTMODSEQ 99] Still delaying VANISHED
C: A3 NOOP
S: * VANISHED 8
S: A3 OK [HIGHESTMODSEQ 104] done
Note: It is not safe to update the client's copy of the HIGHESTMODSEQ value with a MODSEQ FETCH data item value as soon as it is received because servers are not required to send MODSEQ FETCH data items in increasing modseqence order. Some commands may also delay EXPUNGE (or VANISHED) replies with smaller mod-sequences. These can lead to the client missing some changes in case of connectivity loss.
注：サーバーがModSeqcenceの注文を増やす際にModSeq Fethデータアイテムを送信する必要がないため、受信したらすぐに、ModSeq Fetch Data Item値を使用して、highestmodseq値のクライアントのコピーをModSeq Fetch Data Item値を更新することは安全ではありません。また、一部のコマンドは、modシーケンスが小さい場合に、oabunge（またはvanished）返信を遅らせることもあります。これらは、接続性の損失の場合にクライアントがいくつかの変更を欠いていることにつながる可能性があります。
Notes:
ノート：
Rationale:
根拠：
Otherwise clients could lose changes in case of connectivity loss.
それ以外の場合、クライアントは接続性の損失の場合に変更を失う可能性があります。
Errata ID: 1810 [Err1810]
Errata ID：1810 [err1810]
Status: Verified Type: Technical
ステータス：検証型タイプ：技術
Reported By: Timo Sirainen Date Reported: 2009-07-14 Verifier Name: Alexey Melnikov Date Verified: 2009-07-18
報告：Timo Sirainen日付報告：2009-07-14 Verifier Name：Alexey Melnikov Date Verified：2009-07-18
Section 1 says:
セクション1は次のように述べています
It should say:
言うべきです：
Server implementing QRESYNC MUST send untagged events to client in a way that client doesn't lose any changes in case of connectivity loss. In particular this means that if server sends MODSEQ FETCH data items while EXPUNGE (or VANISHED) replies with lower mod-sequences are being delayed, the server MUST send HIGHESTMODSEQ response code with a lower value than the EXPUNGE's mod-sequence. See example in section 5.
QRESYNCを実装するサーバーは、接続性の損失の場合にクライアントが変更を失わないように、クライアントにタグのないイベントをクライアントに送信する必要があります。特に、これは、サーバーがmodSeqフェッチデータ項目を送信中に送信している場合、より低いmodシーケンスで応答が低下している場合、サーバーはexpungeのmodシーケンスよりも低い値でhightmodseq応答コードを送信する必要があります。セクション5の例を参照してください。
Notes:
ノート：
This is related to the other errata in section 5, which describes what the client's behavior should be. This describes what the server's behavior should be. Would have been nice to put them into the same section, but that probably would require larger changes.
これは、クライアントの動作がどうあるべきかを説明するセクション5の他の誤差に関連しています。これは、サーバーの動作がどうあるべきかを説明しています。それらを同じセクションに入れるのは良かったでしょうが、それはおそらくより大きな変更が必要になるでしょう。
Authors' Addresses
著者のアドレス
Dave Cridland (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Dave Cridland（編集者）Isode Limited 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: dave.cridland@isode.com
Alexey Melnikov (editor) 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
Stephane H. Maes (editor) Oracle MS 4op634, 500 Oracle Parkway Redwood Shores, CA 94539 USA
Stephane H. Maes（編集者）Oracle MS 4OP634、500 Oracle Parkway Redwood Shores、CA 94539 USA
Phone: +1-203-300-7786
EMail: stephane.maes@oracle.com