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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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].
レモネードプロファイル、または単にレモネードは、多様なサービス環境をサポートするために、インターネット電子メールの機能強化を提供します。レモネードのメールサーバーはレモネード提出Serverおよび既存それぞれ、[SUBMIT]と[IMAP]プロトコルに基づいていますレモネードメッセージストア、両方を提供します。彼らはまた、[SIEVE]に基づいて、配達時間のフィルタリングサービスを提供していレモネードメッセージ配信エージェントを含むことができます。
This document describes the Lemonade Profile that includes:
この文書では、レモネードプロファイルについて説明します。
o General common enhancements to Internet Mail, described in 5 and 4.
5と4で説明したインターネットメールへの一般的な共通の機能強化、O。
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.
第8章で説明したクライアントへの外部の場所、上に存在するコンテンツを取り入れた新しい電子メールメッセージを提出できるようにレモネードクライアントとサーバ間の交流を説明し、「ダウンロードなしで進む」O。
o Quick mailbox resynchronization, described in Section 5.1.
セクション5.1で説明したOクイックメールボックスの再同期、。
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.
セクション3.3で説明したように、一般的なメール管理ユースケースをサポートするためにフィルタリング送達時間をO。
The LEMONADE WG used the architecture shown in [LEMONADE-ARCH] to develop the Lemonade Profile.
レモネードWGはレモネードプロフィールを開発する[レモネード-ARCH]に示すアーキテクチャを用います。
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.
OMAの携帯メールイネーブラ（MEM）のレモネードプロファイルのサポートの実現は、IETFによって定義されたインターネットメールプロトコルを使用して（[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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.
このドキュメントのすべての例は、レモネードの使用に最適化され、および/ 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.
このリストに加えて、任意のレモネードメッセージストアは、初期サーバー挨拶とLOGIN後に/コマンドを認証して（[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 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.
全てレモネード提出サーバは、次に、[ESMTP]の特定のプロファイルである、[SUBMIT]に記載のメール発信プロトコルを実装します。したがって、[SUBMIT]または[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キーワード以下 "IMAP" オプションを（詳細は、[SMTP-BURL]を参照）アドバタイズする必要がありますしなければなりません。
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].
レモネード準拠のメール送信サーバーは、[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.
レモネード対応のクライアントは、メッセージサイズの宣言を使用すべきです。それはこのメッセージが送信サーバーによってアドバタイズ最大メッセージサイズを超えていることを知っている場合、特に、クライアントは、メール送信サーバーにメッセージを送ってはいけません。 MAIL FROMコマンド内のメッセージサイズを含む場合、クライアントは、すべてのバール部の解像度の後に組み立てられたメッセージデータのサイズと少なくとも同じ大きさである値を使用しなければなりません。
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].
レモネード準拠のメール送信サーバーはトランスポート層セキュリティ（TLS）[SMTP-TLS]を介したセキュアなSMTPのためのSMTPサービス拡張をサポートしなければなりません。
Support for the DEFLATE compression method, as described in [TLS-COMP], is RECOMMENDED.
DEFLATE圧縮方法のサポートは、[TLS-COMP]に記載されているように、推奨されています。
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-ENABLE] ENABLE拡張をサポートしなければなりません。これらは、クライアントがすぐに以前に記録された状態以降に発生したすべてのフラグの変更や抹消を返すようにサーバーを尋ねることによって、任意のメールボックスを再同期することができます。また、これは、クライアントが誤っているかどうか、またはネットワークの変更の一環として、ケースにはトランスポート層が切断されて再接続スピードアップすることができます。
When implementing QRESYNC [IMAP-QRESYNC], client and servers need to also comply with errata submitted for this document (see Appendix A).
QRESYNC [IMAP-QRESYNC]を実装する場合、クライアントとサーバは、（付録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サーバーでは、BINARY [IMAP-BINARY]拡張をサポートしなければなりません。これは、クライアントからサーバにMIMEボディ部の復号動作を移動します。復号されたデータは、符号化された表現よりもサイズに等しいかそれ以下であるので、これは効果的に帯域幅を減少させます。
[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サーバーでは、常に任意のフォルダに対してコマンドAPPENDでバイナリエンコードされた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はレモネードプロフィールを開発する[レモネード-NOTIFICATIONS]に示す通知アーキテクチャを使用します。
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で概説施設を使用して生成されます。
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.
レモネードメッセージストアはIDLE [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の状態を維持したまま、携帯電話やネットワークリソースを節約するためにアイドル期間中に無線トラフィックチャネルをシャットダウン休眠を、サポートしています。 （詳細については[レモネード-配備]文書を参照）。
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接続のための電子メールクライアントが無期限にアクティブのままではないことができ、またはそれは（可能かさえ常に）お勧めない環境があります。このような状況では、優れたユーザーエクスペリエンスは「興味深い」のイベントがメールストアで発生した場合、それは接続して再同期することができるように、クライアントに通知されている必要があります。絶対最低でも、これは少なくとも、新しいメールの到着が電子メールクライアントへのウェイクアップのいくつかの並べ替えを生成することが必要です。ベンダーの数はこれに様々なソリューションを実装しています。長年にわたり、行われているものの例（長い前付き合っ携帯電話機）として[FINGER-HACK]に記載された技術では、サポートされています。今日では、電子メール・ベンダーの数は、新しいメールが到着したときに携帯電話上のクライアントにSMSまたは他の単純な非ストリーム・メッセージを送信するための施設が含まれます。オープン・モバイル・アライアンス（OMA）は、URL [OMA-EMN]を含む基本的なメッセージを送信するためのWAP PUSHを使用するメカニズムを発表しました。 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上でも非標準トリガメッセージをOMA EMNに、前述した、またはに至るまで、任意の数の技術を使用して達成することができます。いずれの手法では、クライアントは、新しいメールの存在を学習し、それについての情報、それの一部、またはすべてを取得することを決定した後、これをユーザに提示します。
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-ESEARCH]拡張をサポートしなければなりません。拡張機能は、クライアントが効率的に、最初または最後のメッセージを見つける一致するメッセージの数を見つけ、かなりコンパクトな表現でメッセージをマッチングのリストを取得することができます。
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].
レモネードメッセージストアは、したがってCONTEXT = SEARCH、ESORTを実装し、[IMAP-CONTEXT]で定義されたコンテキスト= SORT拡張、ならびに[IMAPソート]で定義されたSORT拡張しなければなりません。
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.)
レモネードメッセージストアは、<n>は、非英語のサポートを追加し、値1または2を有する（国際）とI18NLEVEL = <N> [IMAP-I18N]拡張をサポートする機能を検索し、ソートしなければなりません。 （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
[IMAP-URLを]メッセージ/身体部分のバイト範囲を参照するための新たな構文要素を導入しました。 PARTIAL =フィールド;これは、使用して行われます。 IMAPサーバーがIMAP URLにPARTIALサポートしている場合で使用
CATENATE and URLAUTH extensions, then it MUST advertise the URL-PARTIAL capability in both the CAPABILITY response and the equivalent response-code.
CATENATEとURLAUTH拡張子が、それは能力応答と同等のレスポンス・コードの両方でURL-PARTIAL機能をアドバタイズする必要があります。
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.
レモネードメッセージストアはLITERAL + [IMAP-LITERAL +]拡張をサポートしなければなりません。拡張機能は、クライアントがその都度非同期リテラルが送信されるラウンドトリップを保存することができます。
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サーバはTLS [IMAP] [IMAP]で必要とされる上でIMAPをサポートしなければなりません。セクション5.3で上記のようにTLS-COMP]で指定されるように、サーバーは、TLSのdeflate圧縮アルゴリズムをサポートしなければなりません。
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.
レモネードメッセージストアは$転送されたキーワードを保存することができなければなりません。彼らは、COPY操作でそれを保存しなければなりません。サーバは、転送された検索キーワード$をサポートしなければなりません。
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.
$ SubmitPending IMAPキーワードを提出する待っているようなメッセージを指定します。このキーワードは、すでに提出されたおよび/または編集されているメッセージが保存されている同じメールボックスに提出されるのを待っているメッセージを格納することができます。それはメッセージが送信される必要があると判断した場合、メールクライアントは、このキーワードを設定します。クライアントは、（それは、メッセージが送信を保留していることを決定したものとは異なるクライアントであるかもしれない）メッセージの送信を開始すると、それはアトミック（「STORE（UNCHANGEDSINCE）」を使用して）$提出キーワードを追加します。提出が成功すると、$のSubmitPendingキーワードはアトミックにクリアされます。二つのキーワードは、積極的に提出することが待っているメッセージから、またはすでに送信されたメッセージと区別するために（両方$提出し、$ SubmitPendingキーワードが設定されたメッセージを）提出されたメッセージを許可します。彼らはまた、それらを提出するクライアントがクラッシュしたり、それらを提出する前に終了した場合に提出することになっていたすべてのメッセージが、見つけることができるようにします。
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.
レモネードのメッセージストアは、$ SubmitPendingと$提出キーワードを保存することができなければなりません。レモネードのメッセージストアは、COPY操作にそれらを保存しなければなりません。サーバーは、$提出検索キーワードの$ 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.
サーバー上の仮想メールボックスの定義を永続化する方法を提供し、[IMAP-FILTERS]を、実装することを検討すべきであるOMA MEM要件[OMA-MEM-REQ]を満たすためにターゲットサーバ実装。彼らはまた、ユーザアカウントに関連付けられたユーザー定義データを格納する方法を提供するメタデータ-SERVER [METADATA]拡張を、実装することを検討すべきです。
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.
レモネードメッセージ配信エージェントは、ユーザが受け入れられ、そしてどこが提出されたメッセージを制御することを可能にする、送達の時点で[SIEVE]フィルタリング言語をサポートしなければなりません。
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]、（ふるい拡張のため、名前を）サポートしなければなりません。
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.
レモネードメッセージ配信エージェントは、Sieveスクリプトは、受信したメッセージについて（例えば、XMPP、SIP、または電子メールなどの）通知を生成することを可能にするふるいEnotify拡張を[SIEVE-NOTIFY]、サポートしなければなりません。
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スクリプト言語の変数のサポートを追加するふるい変数拡張[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スクリプト言語に関係の比較のためのサポートを追加しふるいリレーショナル拡張[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スクリプトはIMAP旗/キーワードを設定することができますふるいImap4Flags拡張[SIEVE-IMAP4FLAGS]を、サポートしなければなりません。例えば、これは面白い、緊急、などなど、特定のメッセージを自動的にマークを付けるために使用することができます
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コンパレータ[UNICODE-CASEMAP]、「コンパレータ-I;ユニコード-CASEMAP」ふるいで声明を「必要」。コンパレータは、Unicode文字の大文字と小文字を区別しないマッチングを可能にします。
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]プロトコルを使用して、Sieveスクリプトの管理を支援する検討すべきです。彼らが行う場合、彼らはまた、このセクションに記載されているすべてのSieve拡張[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]既存のプロトコルを[SUBMIT]に基づいているが、クライアントの実装は、レモネードの提出サーバーが提供する機能とレモネードメッセージストアを最大限に活用することをお勧めしますそれぞれ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.
提出Serverへの接続を開くと、クライアントが明示的に代替ポート[RFC5068]を使用するように設定しない限り、ポート587を使用して行う必要があります。投稿サーバへのTCP接続がポート587を使用して開くことに失敗した場合（提出クライアントが使用する正確な手順を規定していませんでした。[SUBMIT]として、[SUBMIT]この要件はで指定されたものよりもやや強いであることに注意してください） 、クライアントは直ちにポート25を使用した理由に関する情報については25を参照[SUBMIT]はクライアントの現在位置に応じて失敗する可能性があるような、別のポートを使用して再試行することができる、およびSMTPの間に故障コードをもたらすことができますトランザクション。
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.
レモネード対応クライアントは、[流し]で説明text / plainのメディアタイプにフォーマットと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]を使用しておよびプロトコルを[SUBMIT]は、繰り返しネットワークデータの送信になるために以前は何であったかをローカルディスク操作を変更しました。
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.
「ダウンロードせずに前方」レモネード一提出プロトコルを維持するという利点を有し、従って、提出するための複数の平行及びおそらく発散機構を有する危険性を回避します。クライアントは、[SUBMIT]これらはIMAPに追加されることなく、拡張機能を使用することができます。さらに、サーバーをSUBMIT SMTPでメッセージ送信の詳細を保つことによって、「ダウンロードせずに前進」レモネードは、POP、NNTP、または任意の他、将来的に設計することができるなど、他のメッセージ検索プロトコルで動作することができます。
The act of sending an email message can be thought of as involving multiple steps: initiation of a new draft, draft editing, message assembly, and message submission.
新しいドラフトの開始、ドラフト編集、メッセージの組み立て、およびメッセージ送信：電子メールメッセージを送信する行為は、複数のステップを含むものとして考えることができます。
Initiation of a new draft and draft editing takes place in the 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で行われます。多くの場合、ユーザーが後でMUAによってリコールや編集プロセスの再開のために（\ドラフトフラグとAPPENDコマンドを使って）[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.
ドラフトは、[IMAP]サーバに保存し、後でサーバから取得してもよいが、伝統的に、メッセージは、開始、編集、MUA内に完全に組み立てられています。完成したテキストは、配信のためにメッセージ服従エージェント（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.
モデルは、メッセージユーザーエージェント（MUA）、IMAPv4Rev1サーバー（[IMAP]）を区別し、SMTPサーバを提出する（[登録]）、図1に示すように。
+--------------------+ +--------------+
| | <------------ | |
| 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.
このセクションでは、informativelyメッセージアセンブリが行われる場所に基づいて、「ダウンロードせずに前進」を実行するための2つの方法を説明します。最初は、メッセージストアにドラフトメッセージを編集して、IMAPサーバー上のメッセージのアセンブリを引き起こすように拡張APPENDコマンド[IMAP-CATENATE]を使用しています。 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.
第二は、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]から[IMAP-CATENATE]拡張は、新しいテキストを送信し、それらを組み立てることにより、IMAPサーバー上のメッセージを作成するために使用されます。 UIDPLUS [IMAP-UIDPLUS] IMAP拡張子が作成されたメッセージのUIDを学ぶために、クライアントによって使用されます。最後に、[IMAP-URLAUTH]形式のURLを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：{Iに - オプション}クライアントは、IMAPサーバーに接続し、必要に応じて、[（データの機密性が必要な場合）、TLSを開始認証、メールボックス（以下の例では、「INBOX」）を開き、本体構造は（参照フェッチ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: {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：{Iへ}クライアント（意味論および手順の詳細については、[IMAP-CATENATE]を参照）CATENATEを起動 - これはMUAが既に存在する1つ以上のメッセージ部分と組み合わせ、新しいデータを使用して、IMAPサーバ上のメッセージを作成することができ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リテラル+]拡張を使用しないことに留意されたいです。 LITERAL +せずに新しいメッセージが3つの往復を用いて構成されています。 LITERAL +を使用する場合は、新しいメッセージが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：クライアントはURLAUTHのURLを要求するGENURLAUTHコマンドを使用して、{I}の（参照[IMAP-URLAUTH]）。 I：{M}にIMAPサーバ（意味論および手順の詳細については、[IMAP-URLAUTH]を参照）のURLfetchと後で検索するのに適した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
Mは：{S}にクライアントがメール送信サーバに接続し、新しいメールトランザクションを開始します。これは、ことができます - それは（意味論と手順の詳細については、[IMAP-URLAUTH]を参照してくださいSMTPサーバがIMAPサーバからのメッセージの内容をフェッチ提出できるようにBURLを使用しています
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.
MUA）がCATENATEステップの結果として、構成されたメッセージにアクセスするためにサーバを送信SMTPを許可します。二EHLOコマンドが成功したSTARTTLSコマンドの後に必要とされることに注意してください。また、第二EHLO応答は任意のBURLのオプションが表示されない場合には第三の必須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.)
S：{I}をメール送信サーバがメッセージを取得するためのURLfetchを使用して送信されます。 （意味論と手順の詳細については、[IMAP-URLAUTH]を参照してください。いわゆる「質屋・チケット」の認証メカニズムは、独自の認証資格情報が含まれているURIを使用しています。）
I: {to S} Provides the message composed as a result of the CATENATE step).
I：{S}に）CATENATEステップの結果として、構成されたメッセージを提供します。
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.
データの機密性が必要とされていない場合は、メール送信サーバは、LOGINコマンドを発行する前に、STARTTLSコマンドを省略することがあります。
S: {to M} Submission server assembles the complete message; if the assembly succeeds, it returns OK to the MUA:
S：{M}に提出サーバーは、完全なメッセージを組み立てます。アセンブリが成功した場合、それはMUAにOKを返します。
S: 250 2.5.0 Ok.
S：250 2.5.0 [OK]をクリックします。
M: {to I} The client marks the message containing the forwarded attachment on the IMAP server.
M：{I}のクライアントは、IMAPサーバ上の転送添付ファイルを含むメッセージをマーク。
M: 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のSTOREコマンドのみ動作します。それ以外の場合は、SELECTが必要です。それは単にクライアント操作や相互運用性に必須ではない非動作のメタデータを変更すると、このコマンドは、省略することができます。タグ無しFETCH応答は[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内で編集します。提出時に[SUBMIT]、BURL [SMTP-BURL]とBDAT [SMTP-BINARYMIME]コマンドは複数の部品からのメッセージを作成するために使用されています。既存の本体部分がバールコマンドで[IMAP-URLAUTH]形式のURLを使用して参照しながら、新たな身体の部分は、BDATコマンドを使用して供給されます。
The flow involved to support such a use case consists of: M: {to I -- Optional} The client connects to the IMAP server, optionally starts TLS (if data confidentiality is required), authenticates, opens a mailbox ("INBOX" in the example below), and fetches body structures (see [IMAP]).
M：このようなユースケースをサポートするために関与する流れがから成る{Iに - オプション}クライアントは、IMAPサーバーに接続し、必要に応じて（データの機密性が必要な場合）、TLSを開始認証、メールボックス（「INBOX」を開き以下の例）、及び身体構造（[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: {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は：{I}をクライアントが組み立てられるメッセージの部分を参照する（[IMAP-URLAUTH]を参照）要求URLAUTH URLにGENURLAUTHコマンドを使用します。 I：{M}にIMAPサーバはのURLfetchと後の検索のために適したURLAUTH URLを（意味論および手順の詳細については、[IMAP-URLAUTH]を参照）を返します。
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は：{S}にクライアントがメール送信サーバに接続し、新しいメールトランザクションを開始します。これは、SMTPは（意味論および手順の詳細については、[SMTP-BURL]を参照）を送信するメッセージのIMAPサーバ片からフェッチするようにサーバに送信指示する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.
二EHLOコマンドが成功したSTARTTLSコマンドの後に必要とされることに注意してください。二EHLO応答は任意のBURLのオプションが表示されない場合にのみあれば第三EHLOコマンドが必要です。第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：{I}をメール送信サーバはメッセージの断片をフェッチするためのURLfetchを使用して送信されます。 （[SMTP-BURL]セマンティクスと手順の詳細については、を参照してください。「質屋・チケット」は、いわゆる認証メカニズムは、独自の認証資格情報が含まれているURIを使用しています。）。私は：{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
I：B003 OKログアウトに成功
Note that if data confidentiality is not required, the mail Submission Server may omit the STARTTLS command before issuing the LOGIN command.
データの機密性が必要とされていない場合は、メール送信サーバは、LOGINコマンドを発行する前に、STARTTLSコマンドを省略することがあります。
S: {to M} Submission Server assembles the complete message; if the assembly succeeds, it acknowledges acceptance of the message by sending 250 response to the last BDAT command:
S：{M}に提出サーバーは、完全なメッセージを組み立てます。アセンブリが成功した場合、それは最後のBDATコマンドへの250応答を送信することにより、メッセージの受け入れを承認します：
S: 250 2.5.0 Ok, message accepted.
S：250 2.5.0 [OK]を、メッセージが受け入れられました。
M: {to I} The client marks the message containing the forwarded attachment on the IMAP server.
M：{I}のクライアントは、IMAPサーバ上の転送添付ファイルを含むメッセージをマーク。
M: 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のSTOREコマンドのみ動作します。それ以外の場合は、SELECTが必要です。前の例と同様に、このコマンドは重要ではなく、省略することができます。タグ無しFETCH応答は[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サーバがクライアントによって作成された「質屋・チケット」なし[IMAP-URLAUTH]サーバー上のデータにアクセスすることはできません[SUBMIT]提出するということです。
The "pawn-ticket" grants access only to the specific data that the SMTP submit [SUBMIT] server is authorized to access, can be revoked by the client, and can have a time-limited validity.
「質屋・チケット」の助成金は、唯一のSMTPクライアントによって取り消されることができ、サーバーがアクセスを許可されている[SUBMIT]提出し、期間限定の妥当性を持つことができ、特定のデータにアクセスできます。
The "fcc problem" refers to delivering a copy of a message to a 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
伝統的な戦略では、MUAは、別の工程でFCCの宛先にメッセージを書き込むことによって、MSAへの送信に費やされる労力を複製します。これは、ローカルディスクのファイルやへの書き込みも可能
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".
IMAPサーバー上のメールボックスに追加します。後者は、「FCCの問題」の「問題」の態様を表し、「反復ネットワーク・データ伝送」の一つです。
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]のAPPENDコマンドによって送信メール用に設計されたメールボックスにアップロードされます。そうする際に、クライアントは第5.10節で説明したの$ SubmitPendingと$提出IMAPキーワードを使用するべきであることに注意してください。また、[IMAP-CATENATE]によって強化されたときなど、APPENDは、メッセージのみの単一のコピーを作成することができ、これは、提出の送信メッセージをステージサーバー上でのみ使用することに注意してください。同じサーバー上のメッセージの追加コピーは、一つ以上のCOPYコマンドを使用して作成することができます。
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]、[SUBMIT]で見つけることができ、[SIEVE]、および他の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の形態に応じて、そのようなアクセスを得ることができなくてもよいです。例えば、いくつかのフォームが提出Serverまたは特定のユーザーとして権限のある機関への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.
レモネードクライアントがメール送信のためのバール・拡張、メール送信サーバにURLAUTHトークンを送信する必要が拡張子を使用する場合は、そのようなトークンは、攻撃者にメッセージの内容を開示することリプレイ攻撃を避けるために、傍受から保護されなければなりません。 [TLS] GENURLAUTHを発行IMAPセッションやメール送信パスの両方のベースの暗号化は、この攻撃に対する保護を提供します。
Lemonade-compliant mail Submission Servers SHOULD use TLS-protected IMAP connections when fetching message content using the URLAUTH token provided by the Lemonade client.
レモネードクライアントによって提供さURLAUTHトークンを使用してメッセージの内容を取得する際にレモネード準拠のメール送信サーバーは、TLSで保護されたIMAP接続を使用すべきです。
When a client uses SMTP STARTTLS to send a BURL command that references non-public information, there is a user expectation that the entire message content will be treated confidentially. To meet this expectation, the message Submission Server SHOULD use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.
クライアントが非公開情報を参照するBURLコマンドを送信するSMTP STARTTLSを使用すると、メッセージ全体の内容は内密に扱われることをユーザーの期待があります。この期待に応えるために、メッセージ送信サーバはSTARTTLSまたはそのURLで参照されるコンテンツを取得する際に同等のデータの機密性を提供するメカニズムを使用すべきです。
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 Serverの構成
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一般に、OMAのMEMによって考慮配置モデルは、従来のIETF配置モデルではないこと
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.
[RFC5226]で定義されているIMAP4機能は、IETFレビューにより登録されています。この文書では、URL-PARTIAL 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拡張：BINARY、COMPRESS = DEFLATE、CONTEXT = SEARCH、CONTEXT = SORT、CONVERT、ENABLE、ESEARCH、ESORT、I18NLEVEL = 1、NOTIFY、QRESYNC、SORT、URL-PARTIAL SASL-IR;
IMAP keywords: $SubmitPending, $Submitted.
IMAPキーワード：$のSubmitPending、提出$。
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、リレーショナル、VACATION、変数、コンパレータ-I;ユニコード-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のDEFLATE圧縮方法を使用することをお勧めします。他のすべての要件は同じまま。
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.
レモネードメールユーザエージェント上のいくつかの追加要件を持つ新しいセクションは、=、特に彼らはフォーマットをサポートするために必要とされる、追加text / plainのメディアタイプにパラメータを流しました。
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.
具体的には、編集者は、彼らのコメントやレビューのためにエリック・バーガー、グレン・パーソンズ、ランドールGellens、フィリップナバラ、ゾルタンOrdogh、グレッグボードルイ、およびファンXiaohuiに感謝したいと思います。
[FLOWED] Gellens, R., "The Text/Plain Format and DelSp Parameters", RFC 3676, February 2004.
[流さ] Gellens、R.、 "text / plainの形式とDelSpパラメータ"、RFC 3676、2004年2月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、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]レズニック、P.、 "インターネットメッセージアクセスプロトコル（IMAP）CATENATE拡張"、RFC 4469、2006年4月。
[IMAP-COMPRESS] Gulbrandsen, A., "The IMAP COMPRESS Extension", RFC 4978, August 2007.
[IMAP-COMPRESS] Gulbrandsenの、A.、 "IMAP COMPRESS拡張"、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]メルニコフ、A.とS.ホール、 "条件付きSTORE操作やクイックフラグの変更を再同期化のためのIMAP拡張"、RFC 4551、2006年6月。
[IMAP-CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.
[IMAP-CONTEXT] Cridland、D.およびC.王、 "IMAP4のためのコンテキスト"、RFC 5267、2008年7月。
[IMAP-CONVERT] Melnikov, A. and P. Coates, "Internet Message Access Protocol - CONVERT Extension", RFC 5259, July 2008.
[IMAP-CONVERT]メルニコフ、A.、およびP.コーツ、 "インターネットメッセージアクセスプロトコル - 拡張CONVERT"、RFC 5259、2008年7月。
[IMAP-ENABLE] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[IMAP-ENABLE] Gulbrandsenの、A.とA.メルニコフ、 "IMAPエクステンションを有効にする"、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]メルニコフ、A.と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]ニューマン、C.、Gulbrandsenの、A.、およびA.メルニコフ、 "インターネットメッセージアクセスプロトコル国際化"、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リテラル+]マイヤーズ、J.、 "IMAP4非同期リテラル"、RFC 2088、1997年1月。
[IMAP-NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
[IMAP名前空間] Gahrns、M.とC.ニューマン、 "IMAP4名前空間"、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.、キング、C.、およびA.メルニコフ、 "IMAPエクステンションをNOTIFY"、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]メルニコフ、A.、Cridland、D.、およびC.ウィルソン、 "クイックメールボックスの再同期のための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の、RFC 4959、2007年9月 "簡易認証セキュリティー層（SASL）初期クライアント応答用のIMAP拡張"。
[IMAP-SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[IMAP-SORT]クリスピン、M.とK.マーチソン、 "インターネットメッセージアクセスプロトコル - SORTとTHREAD拡張機能"、RFC 5256、2008年6月。
[IMAP-UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[IMAP-UIDPLUS]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - UIDPLUS延長"、RFC 4315、2005年12月。
[IMAP-URL] Melnikov, A. and C. Newman, "IMAP URL Scheme", RFC 5092, November 2007.
[IMAP-URL]メルニコフ、A.とC.ニューマン、 "IMAP URLスキーム"、RFC 5092、2007年11月。
[IMAP-URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[IMAP-URLAUTH]クリスピン、M.、 "インターネットメッセージアクセスプロトコル（IMAP） - URLAUTH拡張"、RFC 4467、2006年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SIEVE] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]ギュンター、P.およびT.ショーウォルター監督、 "ふるい：メールフィルタリング言語"、RFC 5228、2008年1月。
[SIEVE-IMAP4FLAGS] Melnikov, A., "Sieve Email Filtering: Imap4flags Extension", RFC 5232, January 2008.
[SIEVE-IMAP4FLAGS]メルニコフ、A.、 "ふるいメールフィルタリング：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]メルニコフ、A.、Leiba、B.、Segmuller、W.、およびT.マーティン、 "ふるい電子メールフィルタリング：通知のための拡張"、RFC 5435、2009年1月。
[SIEVE-RELATIONAL] Segmuller, W. and B. Leiba, "Sieve Email Filtering: Relational Extension", RFC 5231, January 2008.
[SIEVEリレーショナル] Segmuller、W.及びB. Leiba、 "ふるいのメールフィルタリング：リレーショナル拡張"、RFC 5231、2008年1月。
[SIEVE-VACATION] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[SIEVE-VACATION]ショーウォルター監督、T.およびN.フリード、 "ふるいメールフィルタリング：休暇延長"、RFC 5230、2008年1月。
[SIEVE-VARIABLES] Homme, K., "Sieve Email Filtering: Variables Extension", RFC 5229, January 2008.
[SIEVE-変数]オム、K.、 "ふるいメールフィルタリング：変数の拡張"、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.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "8ビット・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.メルニコフ、 "認証のための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]ヴォードルイユ、G.、RFC 3030、2000年12月 "大規模およびバイナリMIMEメッセージの送信のためのSMTPサービス拡張"。
[SMTP-BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[SMTP-BURL]ニューマン、C.、 "メッセージ提出BURL拡張"、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]ムーア、K.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[SMTP-PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[SMTP-PIPELINING]フリード、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.、フリード、N.、およびK.ムーア、 "SMTPサービス拡張メッセージサイズ宣言の"、STD 10、RFC 1870、1995年11月。
[SMTP-STATUSCODES] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
、RFC 2034、1996年10月 "拡張エラーコードを返すためのSMTPサービス拡張" [SMTP-STATUSCODES]フリード、N.、。
[SMTP-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over the Transport Layer Security", RFC 3207, February 2002.
[SMTP-TLS]ホフマン、P.、RFC 3207、2002年2月 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"。
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[SUBMIT] Gellens、R.とJ. Klensin、 "メールのメッセージの提出"、RFC 4409、2006年4月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[TLS-COMP] Hollenbeck, S., "Transport Layer Security Protocol Compression Methods", RFC 3749, May 2004.
[TLS-COMP]ホレンベック、S.、 "トランスポート層セキュリティプロトコル圧縮方法"、RFC 3749、2004年5月。
[UNICODE-CASEMAP] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
[UNICODE-CASEMAP]クリスピン、M.、 "I;ユニコード-CASEMAP - シンプルなUnicode照合アルゴリズム"、RFC 5051、2007年10月。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[ESMTP] Klensin、J.、 "簡易メール転送プロトコル"、RFC 5321、2008年10月。
[Err1807] RFC Errata, Errata ID 1807, RFC 5162, <http://www.rfc-editor.org>.
【Err1807] RFCエラッタ、エラッタのID 1807、RFC 5162、<http://www.rfc-editor.org>。
[Err1808] RFC Errata, Errata ID 1808, RFC 5162, <http://www.rfc-editor.org>.
【Err1808] RFCエラッタ、エラッタのID 1808、RFC 5162、<http://www.rfc-editor.org>。
[Err1809] RFC Errata, Errata ID 1809, RFC 5162, <http://www.rfc-editor.org>.
【Err1809] RFCエラッタ、エラッタのID 1809、RFC 5162、<http://www.rfc-editor.org>。
[Err1810] RFC Errata, Errata ID 1810, RFC 5162, <http://www.rfc-editor.org>.
【Err1810] RFCエラッタ、エラッタのID 1810、RFC 5162、<http://www.rfc-editor.org>。
[FINGER-HACK] Gellens, R., "Simple New Mail Notification", RFC 4146, August 2005.
[FINGER-HACK] Gellens、R.、 "シンプル新着メールの通知"、RFC 4146、2005年8月。
[IMAP-FILTERS] Melnikov, A. and C. King, "IMAP4 Extension for Named Searches (Filters)", RFC 5466, February 2009.
[IMAP-FILTERS]メルニコフ、A.およびC.王、 "名前付き検索（フィルタ）のためのIMAP4拡張"、RFC 5466、2009年2月。
[IMAP-SYNC-HOWTO] Melnikov, A., "Synchronization Operations for Disconnected IMAP4 Clients", RFC 4549, June 2006.
[IMAP-SYNC-HOWTO]メルニコフ、A.、RFC 4549、2006年6月 "切断IMAP4クライアントの同期操作"。
[LEMONADE-ARCH] Burger, E. and G. Parsons, "LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail", RFC 5442, March 2009.
[LEMONADE-ARCH]バーガー、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-展開] Gellens、R.、 "レモネード準拠のモバイル電子メールの展開の考慮事項"、BCP 143、RFC 5383、2008年10月。
[LEMONADE-NOTIFICATIONS] Gellens, R., Ed., "Lemonade Notifications Architecture", RFC 5551, August 2009.
[LEMONADE-NOTIFICATIONS] Gellens、R.、エド。、 "レモネード通知アーキテクチャ"、RFC 5551、2009年8月。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, September 2008.
[MANAGESIEVE]メルニコフ、A.およびT.マーティン、「リモート管理Sieveスクリプトのための議定書」、進歩、2008年9月の作業。
[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（作業中）、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 /ドキュメント/ RD / OMA-RD-MobileEmail-V1_0_20051018-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.、クロッカー、D.、レズニック、P.、オールマン、E.、およびT.フィンチ、 "電子メール服従操作：アクセスと説明責任要件"、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]クロッカー、D.、 "インターネットメールのアーキテクチャ"、RFC 5598、2009年7月。
Appendix A. Errata
付録A.エラッタ
Errata ID: 1807 [Err1807]
エラッタ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
報告ティモ・シレーヌン日：2009-07-14検証名：アレクセイ・メルニコフ日は確認済み：によって報告された2009年7月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有効にするコマンドは、」クライアントによって発行されると（接続が閉じられるまで）、サーバーは自動的にそれらが通常のSTORE / UIDストアによって引き起こされたかどうか、それ以降のすべてのタグなしのFETCH応答でUIDとMOD-配列の両方のデータを含まなければなりませんUNCHANGEDSINCE修飾子、または外部エージェントと、STORE / UIDストア。このルールは、データ項目をFETCH、またはMODSEQは、データ項目をFETCHすることなく、UIDはFETCH UIDおよび/またはMODSEQが含まれていません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フィールドなし迷惑FETCH応答を利用することは非常に困難です。これは、「[消えたが、返信に]サーバが以前に消去メッセージのための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
3000：* 2000消えた2000 * 3（FLAGS（\見て）MODSEQ（14749））をFETCH 5（FLAGS（\見て）MODSEQ（14749））*をFETCH：A1 NOOP * 0はA1 OK A2 NOOP * 10 EXISTS * 1000が消えEXISTS A2 OK NOOPが完了します
The client couldn't do anything with the information from FETCH replies, because it can't know what messages they refer to.
それは、彼らが何を参照してくださいメッセージを知ることができないため、クライアントは、FETCH回答からの情報で何もできませんでした。
Errata ID: 1808 [Err1808]
エラッタ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
報告ティモ・シレーヌン日：2009-07-14検証名：アレクセイ・メルニコフ日は確認済み：によって報告された2009年7月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応答（[CONDSTORE]で定義される）HIGHESTMODSEQ応答コードを使用して更新ごとのメールボックス変更シーケンスを送信しなければなりません。
Example: C: A202 CLOSE S: A202 OK [HIGHESTMODSEQ 20010715194045319] done
例：C：A202 CLOSE 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応答（[CONDSTORE]で定義された）HIGHESTMODSEQ応答コードを使用して更新、メールボックスごとの修正のシーケンスを送ってはいけません。
Example: C: A202 CLOSE S: A202 OK done
例：C：A202のCLOSE S：A202 OK済
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:
サーバーがクライアントに他のクライアントによって行われたすべての変更を送信しない限り、HIGHESTMODSEQが確実に使用することはできません。でも、それはこれを実装するために、クライアントとサーバーの両方のために困難です。例えば：
C1: 2 STORE 1 +FLAGS.SILENT \Deleted S1: * 1 FETCH (MODSEQ 1) S1: 2 OK
C1：* 1 FETCH（MODSEQ 1）S1：2 OK 1 + FLAGS.SILENT \削除S1 2 STORE
C2: 1 STORE 2 +FLAGS.SILENT \Deleted S1: * 2 FETCH (MODSEQ 2) S2: 1 OK
C2：* 2 FETCH（MODSEQ 2）S2：1 OK 2 + FLAGS.SILENT \削除S1 1 STORE
C1: 3 CLOSE S1: 3 [HIGHESTMODSEQ 3]
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.
クライアントは、おそらく唯一のメッセージ1が消去されたと思ったので、それは第二EXPUNGEを登録しません。そして、それはおそらく、それが唯一の新しい抹消について知るために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を第1のクライアントが登録されているだろう間違ったメッセージから\ Deletedフラグを削除していた場合とさらに悪い例は次のようになります。
Errata ID: 1809 [Err1809]
エラッタ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
報告ティモ・シレーヌン日：2009-07-14検証名：アレクセイ・メルニコフ日は確認済み：によって報告された2009年7月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.
完全同期を完了した後、クライアントは、サーバから受信したデータ項目をFETCH任意の迷惑MODSEQのノートを取る必要があります。クライアントは、コマンドにタグ付けされた応答を受信するたびに、データ項目が、最後のタグ付けされた応答以降に受信されたFETCHすべて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.
注：サーバーがMODSEQがmodseqenceの昇順にデータ項目をFETCH送信するために必要とされていないので、それが受信されるとすぐにMODSEQ FETCHデータ項目の値を持つHIGHESTMODSEQ値のクライアントのコピーを更新するのは安全ではありません。これは、接続損失の場合のいくつかの変更を逃しクライアントにつながることができます。
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.
完全同期を完了した後、クライアントは、サーバから受信したデータ項目とHIGHESTMODSEQレスポンスコードをFETCH任意の迷惑MODSEQのノートを取る必要があります。クライアントは、コマンドにタグ付けされた応答を受信するたびに、新しいHIGHESTMODSEQ値を計算するために、受信した迷惑応答をチェックします。 HIGHESTMODSEQ応答コードを受信した場合、クライアントは、それが高い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：A1ストア1：2（UNCHANGEDSINCE 96）+ FLAGS.SILENT \見S：* FETCH -1（UID 6 MODSEQ（103））S：* FETCH 2（UID 7 MODSEQ（101））S：* OK [ A1 OK [3変形]済：HIGHESTMODSEQ 99] MODSEQ 100との応答がS遅延さ消滅しました
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
C：A3 NOOP S：A3 OK [HIGHESTMODSEQ 104]行わ：* 8つのSを消滅します
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.
注：サーバーがMODSEQがmodseqenceの昇順にデータ項目をFETCH送信するために必要とされていないので、それが受信されるとすぐにMODSEQ FETCHデータ項目の値を持つHIGHESTMODSEQ値のクライアントのコピーを更新するのは安全ではありません。いくつかのコマンドも小さくMOD-配列で応答EXPUNGE（又は消失）を遅延させることができます。これらは、接続損失の場合のいくつかの変更を逃しクライアントにつながることができます。
Notes:
ノート：
Rationale:
理論的根拠：
Otherwise clients could lose changes in case of connectivity loss.
そうしないと、クライアントは、接続損失の場合の変更を失う可能性があります。
Errata ID: 1810 [Err1810]
エラッタ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
報告ティモ・シレーヌン日：2009-07-14検証名：アレクセイ・メルニコフ日は確認済み：によって報告された2009年7月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を実装するサーバは、クライアントが接続の損失が発生した場合には変更を失わないような方法でクライアントにタグ付けされていないイベントを送らなければなりません。特に、これは、サーバが送信する場合EXPUNGE（又は消滅）が低いMOD-配列が遅延されると、サーバはEXPUNGEのMOD-配列よりも低い値とHIGHESTMODSEQ応答コードを送信しなければならない返信しながらMODSEQは、データアイテムを取得することを意味します。セクション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
デイブCridland（エディタ）ISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: dave.cridland@isode.com
メールアドレス：dave.cridland@isode.com
Alexey Melnikov (editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフ（エディタ）ISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Stephane H. Maes (editor) Oracle MS 4op634, 500 Oracle Parkway Redwood Shores, CA 94539 USA
ステファンH.マース（編集者）オラクルMS 4op634、500 Oracleのパークウェイレッドウッドショア、CA 94539 USA
Phone: +1-203-300-7786 EMail: stephane.maes@oracle.com
電話：+ 1-203-300-7786 Eメール：stephane.maes@oracle.com