[要約] RFC 2449は、POP3プロトコルの拡張機構に関する仕様です。このRFCの目的は、POP3サーバーとクライアント間で新しい機能やコマンドを追加するための一貫した方法を提供することです。
Network Working Group R. Gellens
Request for Comments: 2449 Qualcomm
Updates: 1939 C. Newman
Category: Standards Track Innosoft
L. Lundblade
Qualcomm
November 1998
POP3 Extension Mechanism
POP3拡張メカニズム
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
IESG Note
IESG Note
This extension to the POP3 protocol is to be used by a server to express policy descisions taken by the server administrator. It is not an endorsement of implementations of further POP3 extensions generally. It is the general view that the POP3 protocol should stay simple, and for the simple purpose of downloading email from a mail server. If more complicated operations are needed, the IMAP protocol [RFC 2060] should be used. The first paragraph of section 7 should be read very carefully.
POP3プロトコルへのこの拡張は、サーバー管理者が行うポリシー決定を表すためにサーバーによって使用されます。これは、一般に、POP3拡張機能の実装を推奨するものではありません。 POP3プロトコルは単純なままであり、メールサーバーから電子メールをダウンロードするという単純な目的のためであるというのが一般的な見方です。より複雑な操作が必要な場合は、IMAPプロトコル[RFC 2060]を使用する必要があります。セクション7の最初の段落は注意深く読んでください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 3
3. General Command and Response Grammar . . . . . . . . . . . . 3
4. Parameter and Response Lengths . . . . . . . . . . . . . . 4
5. The CAPA Command . . . . . . . . . . . . . . . . . . . . . . 4
6. Initial Set of Capabilities . . . . . . . . . . . . . . . . 5
6.1. TOP capability . . . . . . . . . . . . . . . . . . . . . 6
6.2. USER capability . . . . . . . . . . . . . . . . . . . . 6
6.3. SASL capability . . . . . . . . . . . . . . . . . . . . 7
6.4. RESP-CODES capability . . . . . . . . . . . . . . . . . 8
6.5. LOGIN-DELAY capability . . . . . . . . . . . . . . . . . 8
6.6. PIPELINING capability . . . . . . . . . . . . . . . . . 9
6.7. EXPIRE capability . . . . . . . . . . . . . . . . . . . 10
6.8. UIDL capability . . . . . . . . . . . . . . . . . . . . 13
6.9. IMPLEMENTATION capability . . . . . . . . . . . . . . . 13
7. Future Extensions to POP3 . . . . . . . . . . . . . . . . . 14
8. Extended POP3 Response Codes . . . . . . . . . . . . . . . . 14
8.1. Initial POP3 response codes . . . . . . . . . . . . . . 15
8.1.1. The LOGIN-DELAY response code . . . . . . . . . . . 15
8.1.2. The IN-USE response code . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 18
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 19
The Post Office Protocol version 3 [POP3] is very widely used. However, while it includes some optional commands (and some useful protocol extensions have been published), it lacks a mechanism for advertising support for these extensions or for behavior variations.
Post Office Protocolバージョン3 [POP3]は非常に広く使用されています。ただし、いくつかのオプションのコマンドが含まれています（およびいくつかの便利なプロトコル拡張機能が公開されています）が、これらの拡張機能や動作のバリエーションのサポートをアドバタイズするメカニズムがありません。
Currently these optional features and extensions can only be detected by probing, if at all. This is at best inefficient, and possibly worse. As a result, some clients have manual configuration options for POP3 server capabilities.
現在、これらのオプションの機能と拡張機能は、たとえあったとしても、プロービングによってのみ検出できます。これはせいぜい非効率的であり、おそらくもっと悪いことです。その結果、一部のクライアントには、POP3サーバー機能の手動構成オプションがあります。
Because one of the most important characteristics of POP3 is its simplicity, it is desirable that extensions be few in number (see section 7). However, some extensions are necessary (such as ones that provide improved security [POP-AUTH]), while others are very desirable in certain situations. In addition, a means for discovering server behavior is needed.
POP3の最も重要な特性の1つはその単純さであるため、拡張機能の数は少ないことが望ましい（セクション7を参照）。ただし、一部の拡張機能は必要です（セキュリティを強化する拡張機能[POP-AUTH]など）。特定の状況では非常に望ましい拡張機能もあります。さらに、サーバーの動作を検出する手段が必要です。
This memo updates RFC 1939 [POP3] to define a mechanism to announce support for optional commands, extensions, and unconditional server behavior. Included is an initial set of currently deployed capabilities which vary between server implementations, and several new capabilities (SASL, RESP-CODES, LOGIN-DELAY, PIPELINING, EXPIRE and IMPLEMENTATION). This document also extends POP3 error messages so that machine parsable codes can be provided to the client. An initial set of response codes is included. In addition, an [ABNF] specification of POP3 commands and responses is defined.
このメモはRFC 1939 [POP3]を更新して、オプションのコマンド、拡張機能、および無条件のサーバー動作のサポートを通知するメカニズムを定義します。サーバーの実装間で異なる、現在デプロイされている機能の初期セットと、いくつかの新機能（SASL、RESP-CODES、LOGIN-DELAY、PIPELINING、EXPIRE、およびIMPLEMENTATION）が含まれています。このドキュメントでは、POP3エラーメッセージも拡張しているため、マシンで解析可能なコードをクライアントに提供できます。応答コードの初期セットが含まれています。さらに、POP3コマンドと応答の[ABNF]仕様が定義されています。
Public comments should be sent to the IETF POP3 Extensions mailing list, <ietf-pop3ext@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-pop3ext-request@imc.org>.
パブリックコメントは、IETF POP3 Extensionsメーリングリスト<ietf-pop3ext@imc.org>に送信する必要があります。購読するには、SUBSCRIBEを含むメッセージを<ietf-pop3ext-request@imc.org>に送信してください。
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントのキーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、「要件レベルを示すためのRFCで使用するキーワード」で説明されているように解釈されます。 「[キーワード]。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーによって送信された行を示します。
The general form of POP3 commands and responses is described using [ABNF]:
POP3コマンドと応答の一般的な形式は、[ABNF]を使用して説明されています。
POP3 commands:
POP3コマンド：
command = keyword *(SP param) CRLF ;255 octets maximum
keyword = 3*4VCHAR
param = 1*VCHAR
POP3 responses:
POP3応答：
response = greeting / single-line / capa-resp / multi-line
capa-resp = single-line *capability "." CRLF
capa-tag = 1*cchar
capability = capa-tag *(SP param) CRLF ;512 octets maximum
cchar = %x21-2D / %x2F-7F
;printable ASCII, excluding "."
dot-stuffed = *CHAR CRLF ;must be dot-stuffed
gchar = %x21-3B / %x3D-7F
;printable ASCII, excluding "<"
greeting = "+OK" [resp-code] *gchar [timestamp] *gchar CRLF
;512 octets maximum
multi-line = single-line *dot-stuffed "." CRLF
rchar = %x21-2E / %x30-5C / %x5E-7F
;printable ASCII, excluding "/" and "]"
resp-code = "[" resp-level *("/" resp-level) "]"
resp-level = 1*rchar
schar = %x21-5A / %x5C-7F
;printable ASCII, excluding "["
single-line = status [SP text] CRLF ;512 octets maximum
status = "+OK" / "-ERR"
text = *schar / resp-code *CHAR
timestamp = "<" *VCHAR ">"
;MUST conform to RFC-822 msg-id
This specification increases the length restrictions on commands and parameters imposed by RFC 1939.
この仕様は、RFC 1939によって課されたコマンドとパラメーターの長さ制限を増やします。
The maximum length of a command is increased from 47 characters (4 character command, single space, 40 character argument, CRLF) to 255 octets, including the terminating CRLF.
コマンドの最大長は、47文字（4文字のコマンド、シングルスペース、40文字の引数、CRLF）から、終端のCRLFを含めて255オクテットに増加しました。
Servers which support the CAPA command MUST support commands up to 255 octets. Servers MUST also support the largest maximum command length specified by any supported capability.
CAPAコマンドをサポートするサーバーは、255オクテットまでのコマンドをサポートする必要があります。サーバーは、サポートされている機能で指定されている最大の最大コマンド長もサポートする必要があります。
The maximum length of the first line of a command response (including the initial greeting) is unchanged at 512 octets (including the terminating CRLF).
コマンド応答の最初の行の最大長（最初のグリーティングを含む）は、512オクテット（終端のCRLFを含む）で変更されていません。
The POP3 CAPA command returns a list of capabilities supported by the POP3 server. It is available in both the AUTHORIZATION and TRANSACTION states.
POP3 CAPAコマンドは、POP3サーバーがサポートする機能のリストを返します。 AUTHORIZATION状態とTRANSACTION状態の両方で使用できます。
A capability description MUST document in which states the capability is announced, and in which states the commands are valid.
機能の説明では、機能がアナウンスされた状態、およびコマンドが有効な状態を文書化する必要があります。
Capabilities available in the AUTHORIZATION state MUST be announced in both states.
AUTHORIZATION状態で利用可能な機能は、両方の状態で通知される必要があります。
If a capability is announced in both states, but the argument might differ after authentication, this possibility MUST be stated in the capability description.
機能が両方の状態で発表されているが、認証後に引数が異なる場合は、この可能性を機能の説明に記載する必要があります。
(These requirements allow a client to issue only one CAPA command if it does not use any TRANSACTION-only capabilities, or any capabilities whose values may differ after authentication.)
（これらの要件により、クライアントは、TRANSACTIONのみの機能、または認証後に値が異なる機能を使用しない場合、CAPAコマンドを1つだけ発行できます。）
If the authentication step negotiates an integrity protection layer, the client SHOULD reissue the CAPA command after authenticating, to check for active down-negotiation attacks.
認証ステップが完全性保護層をネゴシエートする場合、クライアントは、認証後にCAPAコマンドを再発行して、アクティブなダウンネゴシエーション攻撃をチェックする必要があります（SHOULD）。
Each capability may enable additional protocol commands, additional parameters and responses for existing commands, or describe an aspect of server behavior. These details are specified in the description of the capability.
各機能は、追加のプロトコルコマンド、既存のコマンドの追加のパラメーターと応答を有効にするか、サーバーの動作の側面を記述します。これらの詳細は、機能の説明で指定されています。
Section 3 describes the CAPA response using [ABNF]. When a capability response describes an optional command, the <capa-tag> SHOULD be identical to the command keyword. CAPA response tags are case-insensitive.
セクション3では、[ABNF]を使用したCAPA応答について説明します。機能応答がオプションのコマンドを説明する場合、<capa-tag>はコマンドキーワードと同一である必要があります（SHOULD）。 CAPA応答タグは大文字と小文字を区別しません。
CAPA
カバー
Arguments: none
引数：なし
Restrictions: none
制限：なし
Discussion: An -ERR response indicates the capability command is not implemented and the client will have to probe for capabilities as before.
説明：-ERR応答は、機能コマンドが実装されておらず、クライアントは以前と同様に機能をプローブする必要があることを示します。
An +OK response is followed by a list of capabilities, one per line. Each capability name MAY be followed by a single space and a space-separated list of parameters. Each capability line is limited to 512 octets (including the CRLF). The capability list is terminated by a line containing a termination octet (".") and a CRLF pair.
+ OK応答の後に、機能のリストが1行に1つずつ続きます。各機能名の後には、単一のスペースと、スペースで区切られたパラメーターのリストが続く場合があります。各能力線は512オクテット（CRLFを含む）に制限されています。機能リストは、終了オクテット（ "。"）とCRLFペアを含む行で終了します。
Possible Responses: +OK -ERR
可能な応答：+ OK -ERR
Examples:
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5 KERBEROS_V4
S: RESP-CODES
S: LOGIN-DELAY 900
S: PIPELINING
S: EXPIRE 60
S: UIDL
S: IMPLEMENTATION Shlemazle-Plotz-v302
S: .
This section defines an initial set of POP3 capabilities. These include the optional POP3 commands, already published POP3 extensions, and behavior variations between POP3 servers which can impact clients.
このセクションでは、POP3機能の初期セットを定義します。これらには、オプションのPOP3コマンド、既に公開されているPOP3拡張、およびクライアントに影響を与える可能性のあるPOP3サーバー間の動作のバリエーションが含まれます。
Note that there is no APOP capability, even though APOP is an optional command in [POP3]. Clients discover server support of APOP by the presence in the greeting banner of an initial challenge enclosed in angle brackets ("<>"). Therefore, an APOP capability would introduce two ways for a server to announce the same thing.
APOPは[POP3]のオプションコマンドですが、APOP機能がないことに注意してください。クライアントは、山かっこ（ "<>"）で囲まれた最初のチャレンジのグリーティングバナーに存在することにより、APOPのサーバーサポートを検出します。したがって、APOP機能は、サーバーが同じことをアナウンスする2つの方法を導入します。
CAPA tag: TOP
CAPAタグ：TOP
Arguments: none
引数：なし
Added commands: TOP
追加されたコマンド：TOP
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: TRANSACTION
状態で有効なコマンド：TRANSACTION
Specification reference: [POP3]
仕様リファレンス：[POP3]
Discussion: The TOP capability indicates the optional TOP command is available.
説明：TOP機能は、オプションのTOPコマンドが使用可能であることを示します。
CAPA tag: USER
CAPAタグ：USER
Arguments: none
引数：なし
Added commands: USER PASS
追加されたコマンド：USER PASS
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: AUTHENTICATION
状態で有効なコマンド：AUTHENTICATION
Specification reference: [POP3]
仕様リファレンス：[POP3]
Discussion: The USER capability indicates that the USER and PASS commands are supported, although they may not be available to all users.
説明：USER機能は、USERおよびPASSコマンドがサポートされていることを示しますが、すべてのユーザーが使用できるわけではありません。
CAPA tag: SASL
CAPAタグ：SASL
Arguments: Supported SASL mechanisms
引数：サポートされているSASLメカニズム
Added commands: AUTH
追加されたコマンド：AUTH
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: AUTHENTICATION
状態で有効なコマンド：AUTHENTICATION
Specification reference: [POP-AUTH, SASL]
仕様リファレンス：[POP-AUTH、SASL]
Discussion: The POP3 AUTH command [POP-AUTH] permits the use of [SASL] authentication mechanisms with POP3. The SASL capability indicates that the AUTH command is available and that it supports an optional base64 encoded second argument for an initial client response as described in the SASL specification. The argument to the SASL capability is a space separated list of SASL mechanisms which are supported.
説明：POP3 AUTHコマンド[POP-AUTH]は、POP3での[SASL]認証メカニズムの使用を許可します。 SASL機能は、AUTHコマンドが使用可能であり、SASL仕様で説明されているように、初期クライアント応答に対してオプションのbase64エンコードされた2番目の引数をサポートすることを示します。 SASL機能への引数は、サポートされるSASLメカニズムのスペース区切りリストです。
CAPA tag: RESP-CODES
CAPAタグ：RESP-CODES
Arguments: none
引数：なし
Added commands: none
追加されたコマンド：なし
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: n/a
状態で有効なコマンド：n / a
Specification reference: this document
仕様リファレンス：このドキュメント
Discussion: The RESP-CODES capability indicates that any response text issued by this server which begins with an open square bracket ("[") is an extended response code (see section 8).
説明：RESP-CODES機能は、このサーバーによって発行された、開き角括弧（ "["）で始まるすべての応答テキストが拡張応答コードであることを示します（セクション8を参照）。
CAPA tag: LOGIN-DELAY
CAPAタグ：LOGIN-DELAY
Arguments: minimum seconds between logins; optionally followed by USER in AUTHENTICATION state.
引数：ログイン間の最小秒数。オプションで、AUTHENTICATION状態のUSERが後に続きます。
Added commands: none
追加されたコマンド：なし
Standard commands affected: USER PASS APOP AUTH
影響を受ける標準コマンド：USER PASS APOP AUTH
Announced states / possible differences: both / yes
発表済みの状態/考えられる違い：両方/はい
Commands valid in states: n/a
状態で有効なコマンド：n / a
Specification reference: this document
仕様リファレンス：このドキュメント
Discussion: POP3 clients often login frequently to check for new mail. Unfortunately, the process of creating a connection, authenticating the user, and opening the user's maildrop can be very resource intensive on the server. A number of deployed POP3 servers try to reduce server load by requiring a delay between logins. The LOGIN-DELAY capability includes an integer argument which indicates the number of seconds after an "+OK" response to a PASS, APOP, or AUTH command before another authentication will be accepted. Clients which permit the user to configure a mail check interval SHOULD use this capability to determine the minimum permissible interval. Servers which advertise LOGIN-DELAY SHOULD enforce it.
ディスカッション：POP3クライアントは、頻繁にログインして新着メールをチェックします。残念ながら、接続を作成し、ユーザーを認証し、ユーザーのメールドロップを開くプロセスは、サーバーで非常に多くのリソースを消費する可能性があります。配備された多数のPOP3サーバーは、ログイン間の遅延を要求することにより、サーバーの負荷を軽減しようとします。 LOGIN-DELAY機能には、PASS、APOP、またはAUTHコマンドへの「+ OK」応答から別の認証が受け入れられるまでの秒数を示す整数引数が含まれています。ユーザーがメールチェック間隔を構成できるようにするクライアントは、この機能を使用して最小許容間隔を決定する必要があります（SHOULD）。 LOGIN-DELAYをアドバタイズするサーバーは、それを強制する必要があります。
If the minimum login delay period could differ per user (that is, the LOGIN-DELAY argument might change after authentication), the server MUST announce in AUTHENTICATION state the largest value which could be set for any user. This might be the largest value currently in use for any user (so only one value per server), or even the largest value which the server permits to be set for any user. The server SHOULD append the token "USER" to the LOGIN-DELAY parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication. The server SHOULD announce the more accurate value in TRANSACTION state. (The "USER" token allows the client to decide if a second CAPA command is needed or not.)
最小ログイン遅延期間がユーザーごとに異なる可能性がある場合（つまり、LOGIN-DELAY引数が認証後に変更される可能性がある場合）、サーバーは、AUTHENTICATION状態で、任意のユーザーに設定できる最大値を通知する必要があります。これは、現在すべてのユーザーが使用している最大値（サーバーごとに1つの値のみ）、またはサーバーがすべてのユーザーに設定できる最大値である場合もあります。サーバーは、認証後により正確な値が利用可能であることをクライアントに通知するために、AUTHENTICATION状態のLOGIN-DELAYパラメータにトークン「USER」を追加する必要があります（SHOULD）。サーバーは、トランザクション状態のより正確な値を通知する必要があります（SHOULD）。 （「USER」トークンにより、クライアントは2番目のCAPAコマンドが必要かどうかを決定できます。）
Servers enforce LOGIN-DELAY by rejecting an authentication command with or without the LOGIN-DELAY error response. See section 8.1.1 for more information.
サーバーは、LOGIN-DELAYエラー応答の有無にかかわらず、認証コマンドを拒否することにより、LOGIN-DELAYを実施します。詳細については、セクション8.1.1を参照してください。
CAPA tag: PIPELINING
CAPAタグ：パイプライン
Arguments: none
引数：なし
Added commands: none
追加されたコマンド：なし
Standard commands affected: all
影響を受ける標準コマンド：すべて
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: n/a
状態で有効なコマンド：n / a
Specification reference: this document
仕様リファレンス：このドキュメント
Discussion: The PIPELINING capability indicates the server is capable of accepting multiple commands at a time; the client does not have to wait for the response to a command before issuing a subsequent command. If a server supports PIPELINING, it MUST process each command in turn. If a client uses PIPELINING, it MUST keep track of which commands it has outstanding, and match server responses to commands in order. If either the client or server uses blocking writes, it MUST not exceed the window size of the underlying transport layer.
説明：PIPELINING機能は、サーバーが一度に複数のコマンドを受け入れることができることを示します。クライアントは、後続のコマンドを発行する前に、コマンドへの応答を待つ必要はありません。サーバーがPIPELININGをサポートしている場合は、各コマンドを順番に処理する必要があります。クライアントがPIPELININGを使用する場合は、未処理のコマンドを追跡し、サーバーの応答をコマンドに順番に一致させる必要があります。クライアントまたはサーバーのいずれかがブロッキング書き込みを使用する場合は、基礎となるトランスポート層のウィンドウサイズを超えてはなりません（MUST）。
Some POP3 clients have an option to indicate the server supports "Overlapped POP3 commands." This capability removes the need to configure this at the client.
一部のPOP3クライアントには、サーバーが「重複したPOP3コマンド」をサポートしていることを示すオプションがあります。この機能により、クライアントでこれを構成する必要がなくなります。
This is roughly synonymous with the ESMTP PIPELINING extension [PIPELINING], however, since SMTP [SMTP] tends to have short commands and responses, the benefit is in grouping multiple commands and sending them as a unit. While there are cases of this in POP (for example, USER and PASS could be batched, multiple RETR and/or DELE commands could be sent as a group), because POP has short commands and sometimes lengthy responses, there is also an advantage is sending new commands while still receiving the response to an earlier command (for example, sending RETR and/or DELE commands while processing a UIDL reply).
これは、ESMTP PIPELINING拡張[PIPELINING]とほぼ同じですが、SMTP [SMTP]はコマンドと応答が短い傾向があるため、複数のコマンドをグループ化し、それらを1つの単位として送信するという利点があります。 POPにはこのようなケースがありますが（たとえば、USERとPASSをバッチ処理でき、複数のRETRコマンドやDELEコマンドをグループとして送信できます）、POPには短いコマンドと、場合によっては長い応答があるため、利点もあります。以前のコマンドへの応答を受信しながら新しいコマンドを送信する（たとえば、UIDL応答の処理中にRETRコマンドやDELEコマンドを送信する）。
CAPA tag: EXPIRE
CAPAタグ：EXPIRE
Arguments: server-guaranteed minimum retention days, or NEVER; optionally followed by USER in AUTHENTICATION state
引数：サーバーで保証された最小保存日数、または絶対にしない;オプションで、AUTHENTICATION状態のUSERが後に続きます
Added commands: none
追加されたコマンド：なし
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / yes
発表済みの状態/考えられる違い：両方/はい
Commands valid in states: n/a
状態で有効なコマンド：n / a
Specification reference: this document
仕様リファレンス：このドキュメント
Discussion: While POP3 allows clients to leave messages on the server, RFC 1939 [POP3] warns about the problems that may arise from this, and allows servers to delete messages based on site policy.
ディスカッション：POP3はクライアントがサーバーにメッセージを残すことを許可しますが、RFC 1939 [POP3]はこれから発生する可能性がある問題について警告し、サーバーがサイトポリシーに基づいてメッセージを削除することを許可します。
The EXPIRE capability avoids the problems mentioned in RFC 1939, by allowing the server to inform the client as to the policy in effect. The argument to the EXPIRE capability indicates the minimum server retention period, in days, for messages on the server.
EXPIRE機能は、サーバーが有効なポリシーについてクライアントに通知できるようにすることで、RFC 1939で言及されている問題を回避します。 EXPIRE機能の引数は、サーバー上のメッセージの最小サーバー保存期間（日数）を示します。
EXPIRE 0 indicates the client is not permitted to leave mail on the server; when the session enters the UPDATE state the server MAY assume an implicit DELE for each message which was downloaded with RETR.
EXPIRE 0は、クライアントがサーバーにメールを残すことが許可されていないことを示します。セッションがUPDATE状態に入ると、サーバーは、RETRでダウンロードされたメッセージごとに暗黙的なDELEを想定できます（MAY）。
EXPIRE NEVER asserts that the server does not delete messages.
EXPIRE NEVERは、サーバーがメッセージを削除しないことを表明します。
The concept of a "retention period" is intentionally vague. Servers may start counting days to expiration when a message is added to a maildrop, when a client becomes aware of the existence of a message through the LIST or UIDL commands, when a message has been acted upon in some way (for example, TOP or RETR), or at some other event. The EXPIRE capability cannot provide a precise indication as to exactly when any specific message will expire. The capability is intended to make it easier for clients to behave in ways which conform to site policy and user wishes. For example, a client might display a warning for attempts to configure a "leave mail on server" period which is greater than or equal to some percentage of the value announced by the server.
「保持期間」の概念は意図的にあいまいです。サーバーは、メッセージがメールドロップに追加されたとき、クライアントがLISTコマンドまたはUIDLコマンドを通じてメッセージの存在を認識したとき、メッセージが何らかの方法で処理されたとき（たとえば、TOPまたはRETR）、または他のイベントで。 EXPIRE機能は、特定のメッセージがいつ期限切れになるかを正確に示すことができません。この機能は、クライアントがサイトのポリシーとユーザーの希望に準拠した方法で動作しやすくすることを目的としています。たとえば、クライアントは、「サーバー上にメールを残す」期間を構成しようとするときに、サーバーによってアナウンスされた値の一定の割合以上の警告を表示する場合があります。
If a site uses any automatic deletion policy, it SHOULD use the EXPIRE capability to announce this.
サイトが自動削除ポリシーを使用している場合は、EXPIRE機能を使用してこれを通知する必要があります（SHOULD）。
The EXPIRE capability, with a parameter other than 0 or NEVER, is intended to let the client know that the server does permit mail to be left on the server, and to present a value which is the smallest which might be in force.
EXPIRE機能は、0またはNEVER以外のパラメーターを使用して、サーバーがメールをサーバーに残すことをサーバーが許可していることをクライアントに通知し、有効な最小値を提示することを目的としています。
Sites which permit users to retain messages indefinitely SHOULD announce this with the EXPIRE NEVER response.
ユーザーがメッセージを無期限に保持できるサイトは、これをEXPIRE NEVER応答で通知する必要があります。
If the expiration policy differs per user (that is, the EXPIRE argument might change after authentication), the server MUST announce in AUTHENTICATION state the smallest value which could be set for any user. This might be the smallest value currently in use for any user (so only one value per server), or even the smallest value which the server permits to be set for any user. The server SHOULD append the token "USER" to the EXPIRE parameter in AUTHENTICATION state, to inform the client that a more accurate value is available after authentication. The server SHOULD announce the more accurate value in TRANSACTION state. (The "USER" token allows the client to decide if a second CAPA command is needed or not.)
有効期限ポリシーがユーザーごとに異なる場合（つまり、EXPIRE引数が認証後に変更される可能性がある場合）、サーバーは、AUTHENTICATION状態で、任意のユーザーに設定できる最小値を通知する必要があります。これは、現在すべてのユーザーに使用されている最小値（サーバーごとに1つの値のみ）の場合もあれば、サーバーが任意のユーザーに設定できる最小値の場合もあります。サーバーは、認証後により正確な値が利用可能であることをクライアントに通知するために、AUTHENTICATION状態のEXPIREパラメータにトークン「USER」を追加する必要があります（SHOULD）。サーバーは、トランザクション状態のより正確な値を通知する必要があります（SHOULD）。 （「USER」トークンにより、クライアントは2番目のCAPAコマンドが必要かどうかを決定できます。）
A site may have a message expiration policy which treats messages differently depending on which user actions have been performed, or based on other factors. For example, a site might delete unseen messages after 60 days, and completely- or partially-seen messages after 15 days.
サイトには、実行されたユーザーアクションに応じて、または他の要因に基づいてメッセージを異なる方法で処理するメッセージ有効期限ポリシーがあります。たとえば、サイトは60日後に未読メッセージを削除し、15日後に完全または部分的に未読メッセージを削除する場合があります。
The announced EXPIRE value is the smallest retention period which is or might be used by any category or condition of the current site policy, for any user (in AUTHENTICATION state) or the specific user (in TRANSACTION state). That is, EXPIRE informs the client of the minimum number of days messages may remain on the server under any circumstances.
発表されたEXPIRE値は、任意のユーザー（AUTHENTICATION状態）または特定のユーザー（TRANSACTION状態）の現在のサイトポリシーの任意のカテゴリまたは条件で使用されている、または使用される可能性がある最小の保持期間です。つまり、EXPIREは、どのような状況でもメッセージがサーバーに留まることができる最小日数をクライアントに通知します。
Examples: EXPIRE 5 USER EXPIRE 30 EXPIRE NEVER EXPIRE 0
例：EXPIRE 5 USER EXPIRE 30 EXPIRE NEVER EXPIRE 0
The first example indicates the server might delete messages after five days, but the period differs per user, and so a more accurate value can be obtained by issuing a second CAPA command in TRANSACTION state. The second example indicates the server could delete messages after 30 days. In the third example, the server announces it does not delete messages. The fourth example specifies that the site does not permit messages to be left on the server.
最初の例は、サーバーが5日後にメッセージを削除する可能性があることを示していますが、期間はユーザーごとに異なるため、TRANSACTION状態で2番目のCAPAコマンドを発行すると、より正確な値を取得できます。 2番目の例は、サーバーが30日後にメッセージを削除できることを示しています。 3番目の例では、サーバーはメッセージを削除しないことを通知します。 4番目の例は、サイトがメッセージをサーバーに残すことを許可しないことを指定しています。
CAPA tag: UIDL
CAPAタグ：UIDL
Arguments: none
引数：なし
Added commands: UIDL
追加されたコマンド：UIDL
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both / no
発表済みの状態/考えられる違い：両方/いいえ
Commands valid in states: TRANSACTION
状態で有効なコマンド：TRANSACTION
Specification reference: [POP3]
仕様リファレンス：[POP3]
Discussion: The UIDL capability indicates that the optional UIDL command is supported.
説明：UIDL機能は、オプションのUIDLコマンドがサポートされていることを示します。
CAPA tag: IMPLEMENTATION
CAPAタグ：実装
Arguments: string giving server implementation information
引数：サーバーの実装情報を示す文字列
Added commands: none
追加されたコマンド：なし
Standard commands affected: none
影響を受ける標準コマンド：なし
Announced states / possible differences: both (optionally TRANSACTION only) / no
発表済みの状態/考えられる違い：両方（オプションでトランザクションのみ）/なし
Commands valid in states: n/a
状態で有効なコマンド：n / a
Specification reference: this document
仕様リファレンス：このドキュメント
Discussion: It is often useful to identify an implementation of a particular server (for example, when logging). This is commonly done in the welcome banner, but one must guess if a string is an implementation ID or not.
ディスカッション：特定のサーバーの実装を特定すると役立つ場合があります（たとえば、ログを記録するとき）。これは通常ウェルカムバナーで行われますが、文字列が実装IDかどうかを推測する必要があります。
The argument to the IMPLEMENTATION capability consists of one or more tokens which identify the server. (Note that since CAPA response tag arguments are space-separated, it may be convenient for the IMPLEMENTATION capability argument to not contain spaces, so that it is a single token.)
IMPLEMENTATION機能の引数は、サーバーを識別する1つ以上のトークンで構成されます。 （CAPA応答タグ引数はスペースで区切られているため、IMPLEMENTATION機能引数がスペースを含まず、単一のトークンになると便利な場合があります。）
Normally, servers announce IMPLEMENTATION in both states. However, a server MAY chose to do so only in TRANSACTION state.
通常、サーバーは両方の状態で実装を通知します。ただし、サーバーはTRANSACTION状態でのみそうすることを選択できます。
A server MAY include the implementation identification both in the welcome banner and in the IMPLEMENTATION capability.
サーバーは、ウェルカムバナーと実装機能の両方に実装IDを含めることができます。
Clients MUST NOT modify their behavior based on the server implementation. Instead the server and client should agree on a private extension.
クライアントは、サーバーの実装に基づいて動作を変更してはなりません。代わりに、サーバーとクライアントはプライベート拡張に同意する必要があります。
Future extensions to POP3 are in general discouraged, as POP3's usefulness lies in its simplicity. POP3 is intended as a download-and-delete protocol; mail access capabilities are available in IMAP [IMAP4]. Extensions which provide support for additional mailboxes, allow uploading of messages to the server, or which deviate from POP's download-and-delete model are strongly discouraged and unlikely to be permitted on the IETF standards track.
POP3の有用性はその単純さにあるため、POP3への将来の拡張は一般に推奨されません。 POP3は、ダウンロードと削除のプロトコルとして意図されています。メールアクセス機能はIMAP [IMAP4]で利用できます。追加のメールボックスのサポートを提供する拡張機能、サーバーへのメッセージのアップロードを可能にする拡張機能、またはPOPのダウンロードと削除のモデルから逸脱した拡張機能は強く推奨されておらず、IETF標準トラックで許可されることはほとんどありません。
Clients MUST NOT require the presence of any extension for basic functionality, with the exception of the authentication commands (APOP, AUTH [section 6.3] and USER/PASS).
クライアントは、認証コマンド（APOP、AUTH [セクション6.3]、およびUSER / PASS）を除いて、基本機能の拡張の存在を要求してはなりません（MUST NOT）。
Section 9 specifies how additional capabilities are defined.
セクション9では、追加機能の定義方法を指定します。
Unextended POP3 is only capable of indicating success or failure to most commands. Unfortunately, clients often need to know more information about the cause of a failure in order to gracefully recover. This is especially important in response to a failed login (there are widely-deployed clients which attempt to decode the error text of a PASS command result, to try and distinguish between "unable to get maildrop lock" and "bad login").
非拡張POP3は、ほとんどのコマンドで成功または失敗を示すことができるだけです。残念ながら、クライアントは正常に回復するために、障害の原因に関する詳細情報を知る必要があることがよくあります。これはログインの失敗に対応する上で特に重要です（PASSコマンドの結果のエラーテキストをデコードして、「メールドロップロックを取得できません」と「不正なログイン」を区別しようとするクライアントが広く展開されています）。
This specification amends the POP3 standard to permit an optional response code, enclosed in square brackets, at the beginning of the human readable text portion of an "+OK" or "-ERR" response. Clients supporting this extension MAY remove any information enclosed in square brackets prior to displaying human readable text to the user. Immediately following the open square bracket "[" character is a response code which is interpreted in a case-insensitive fashion by the client.
この仕様はPOP3標準を修正して、「+ OK」または「-ERR」応答の人間が読めるテキスト部分の先頭に角括弧で囲まれたオプションの応答コードを許可します。この拡張機能をサポートするクライアントは、人間が読めるテキストをユーザーに表示する前に、角括弧で囲まれた情報を削除する場合があります。角かっこ「[」の直後に続くのは、クライアントが大文字と小文字を区別しない方法で解釈する応答コードです。
The response code is hierarchical, with a "/" separating levels of detail about the error. Clients MUST ignore unknown hierarchical detail about the response code. This is important, as it could be necessary to provide further detail for response codes in the future.
応答コードは階層的で、「/」はエラーの詳細レベルを分離します。クライアントは、応答コードに関する不明な階層の詳細を無視する必要があります。将来的に応答コードの詳細を提供する必要が生じる可能性があるため、これは重要です。
Section 3 describes response codes using [ABNF].
セクション3では、[ABNF]を使用した応答コードについて説明します。
If a server supports extended response codes, it indicates this by including the RESP-CODES capability in the CAPA response.
サーバーが拡張応答コードをサポートする場合、CAPA応答にRESP-CODES機能を含めることでこれを示します。
Examples:
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: -ERR [IN-USE] Do you have another POP session running?
This specification defines two POP3 response codes which can be used to determine the reason for a failed login. Section 9 specifies how additional response codes are defined.
この仕様は、ログイン失敗の理由を判別するために使用できる2つのPOP3応答コードを定義しています。セクション9では、追加の応答コードの定義方法を指定します。
This occurs on an -ERR response to an AUTH, USER (see note), PASS or APOP command and indicates that the user has logged in recently and will not be allowed to login again until the login delay period has expired.
これは、AUTH、USER（注を参照）、PASS、またはAPOPコマンドに対する-ERR応答で発生し、ユーザーが最近ログインし、ログイン遅延期間が経過するまで再度ログインすることができないことを示します。
NOTE: Returning the LOGIN-DELAY response code to the USER command avoids the work of authenticating the user but reveals to the client that the specified user exists. Unless the server is operating in an environment where user names are not secret (for example, many popular email clients advertise the POP server and user name in an outgoing mail header), or where server access is restricted, or the server can verify that the connection is to the same user, it is strongly recommended that the server not issue this response code to the USER command. The server still saves the cost of opening the maildrop, which in some environments is the most expensive step.
注：LOGIN-DELAY応答コードをUSERコマンドに返すと、ユーザーの認証作業は回避されますが、指定されたユーザーが存在することがクライアントに示されます。ユーザー名が秘密でない環境でサーバーが動作している場合（たとえば、多くの一般的な電子メールクライアントが送信メールヘッダーでPOPサーバーとユーザー名をアドバタイズする場合）、またはサーバーアクセスが制限されている場合、またはサーバーが接続は同じユーザーに対するものであり、サーバーがこの応答コードをUSERコマンドに発行しないことを強くお勧めします。サーバーは依然としてメールドロップを開くコストを節約します。これは、一部の環境では最も高価なステップです。
This occurs on an -ERR response to an AUTH, APOP, or PASS command. It indicates the authentication was successful, but the user's maildrop is currently in use (probably by another POP3 client).
これは、AUTH、APOP、またはPASSコマンドに対する-ERR応答で発生します。認証は成功したが、ユーザーのメールドロップが現在使用されていることを示しています（おそらく別のPOP3クライアントによって）。
This document requests that IANA maintain two new registries: POP3 capabilities and POP3 response codes.
このドキュメントは、IANAがPOP3機能とPOP3応答コードの2つの新しいレジストリを維持することを要求します。
New POP3 capabilities MUST be defined in a standards track or IESG approved experimental RFC, and MUST NOT begin with the letter "X".
新しいPOP3機能は、標準トラックまたはIESG承認の実験的RFCで定義する必要があり、文字「X」で始めることはできません。
New POP3 capabilities MUST include the following information: CAPA tag Arguments Added commands Standard commands affected Announced states / possible differences Commands valid in states Specification reference Discussion
新しいPOP3機能には、次の情報を含める必要があります。CAPAタグ引数追加されたコマンド影響を受ける標準コマンドアナウンスされた状態/可能な違い状態で有効なコマンド仕様リファレンスディスカッション
In addition, new limits for POP3 command and response lengths may need to be included.
さらに、POP3コマンドと応答の長さの新しい制限を含める必要がある場合があります。
New POP3 response codes MUST be defined in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. (This is the "Specification Required" policy described in [IANA]).
新しいPOP3応答コードは、独立した実装間の相互運用が可能になるように、RFCまたは他の永続的ですぐに利用できるリファレンスで十分詳細に定義する必要があります。 （これは、[IANA]で説明されている「指定が必要な」ポリシーです）。
New POP3 response code specifications MUST include the following information: the complete response code, for which responses (+OK or -ERR) and commands it is valid, and a definition of its meaning and expected client behavior.
新しいPOP3応答コードの仕様には、次の情報を含める必要があります。応答（+ OKまたは-ERR）と有効なコマンドの完全な応答コード、およびその意味と予期されるクライアントの動作の定義。
A capability list can reveal information about the server's authentication mechanisms which can be used to determine if certain attacks will be successful. However, allowing clients to automatically detect availability of stronger mechanisms and alter their configurations to use them can improve overall security at a site.
機能リストは、特定の攻撃が成功するかどうかを判断するために使用できるサーバーの認証メカニズムに関する情報を明らかにすることができます。ただし、クライアントがより強力なメカニズムの可用性を自動的に検出し、それらを使用するように構成を変更できるようにすると、サイトの全体的なセキュリティを向上させることができます。
Section 8.1 discusses the security issues related to use of the LOGIN-DELAY response code with the USER command.
セクション8.1では、USERコマンドでのLOGIN-DELAY応答コードの使用に関連するセキュリティの問題について説明します。
This document has been revised in part based on comments and discussions which took place on and off the IETF POP3 Extensions mailing list. The help of those who took the time to review this memo and make suggestions is appreciated, especially that of Alexey Melnikov, Harald Alvestrand, and Mike Gahrns.
この文書は、IETF POP3 Extensionsメーリングリストの内外で行われたコメントと議論に基づいて部分的に改訂されました。このメモをレビューして提案するために時間を割いてくれた人々の助け、特にアレクセイ・メルニコフ、ハラルド・アルベストランド、マイク・ガーンズの助力に感謝します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IMAP4] Crispin, M., "Internet Message Access Protocol -- Version 4rev1", RFC 2060, December 1996.
[IMAP4] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
[PIPELINING] Freed、N。、「コマンドパイプライン処理用のSMTPサービス拡張」、RFC 2197、1997年9月。
[POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.
[POP3]マイヤーズ、J。およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]マイヤーズJ。、「POP3 AUTHentication command」、RFC 1734、1994年12月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 USA
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd.サンディエゴ、カリフォルニア州92121-2779米国
Phone: +1 619 651 5115
Fax: +1 619 845 7268
EMail: randy@qualcomm.com
Chris Newman Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA
Chris Newman Innosoft International、Inc. 1050 Lakes Drive West Covina、CA 91790 USA
EMail: chris.newman@innosoft.com
Laurence Lundblade QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, Ca, 92121-2779 USA
Laurence Lundblade QUALCOMM Incorporated 6455 Lusk Blvd.サンディエゴ、カリフォルニア州、92121-2779米国
Phone: +1 619 658 3584
Fax: +1 619 845 7268
EMail: lgl@qualcomm.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。