[要約] RFC 4468は、メッセージ送信BURL拡張に関する仕様であり、メール送信者がBURLを使用してメッセージを送信するための方法を提供します。目的は、メール送信者がBURLを使用してメッセージを送信する際の手順と要件を定義することです。
Network Working Group C. Newman
Request for Comments: 4468 Sun Microsystems
Updates: 3463 May 2006
Category: Standards Track
Message Submission BURL Extension
メッセージの提出バール拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
The submission profile of Simple Mail Transfer Protocol (SMTP) provides a standard way for an email client to submit a complete message for delivery. This specification extends the submission profile by adding a new BURL command that can be used to fetch submission data from an Internet Message Access Protocol (IMAP) server. This permits a mail client to inject content from an IMAP server into the SMTP infrastructure without downloading it to the client and uploading it back to the server.
Simple Mail Transfer Protocol（SMTP）の提出プロファイルは、電子メールクライアントが配信のための完全なメッセージを送信する標準的な方法を提供します。この仕様は、インターネットメッセージアクセスプロトコル（IMAP）サーバーから提出データを取得するために使用できる新しいBurlコマンドを追加することにより、送信プロファイルを拡張します。これにより、メールクライアントは、クライアントにダウンロードしてサーバーにアップロードすることなく、IMAPサーバーからSMTPインフラストラクチャにコンテンツを挿入できます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. BURL Submission Extension .......................................3
3.1. SMTP Submission Extension Registration .....................3
3.2. BURL Transaction ...........................................3
3.3. The BURL IMAP Options ......................................4
3.4. Examples ...................................................5
3.5. Formal Syntax ..............................................6
4. 8-Bit and Binary ................................................7
5. Updates to RFC 3463 .............................................7
6. Response Codes ..................................................7
7. IANA Considerations .............................................9
8. Security Considerations .........................................9
9. References .....................................................11
9.1. Normative References ......................................11
9.2. Informative References ....................................12
Appendix A. Acknowledgements .....................................13
This specification defines an extension to the standard Message Submission [RFC4409] protocol to permit data to be fetched from an IMAP server at message submission time. This MAY be used in conjunction with the CHUNKING [RFC3030] mechanism so that chunks of the message can come from an external IMAP server. This provides the ability to forward an email message without first downloading it to the client.
この仕様は、メッセージ送信時間にIMAPサーバーからデータを取得できるようにするために、標準メッセージ送信[RFC4409]プロトコルの拡張機能を定義します。これは、メッセージのチャンクが外部IMAPサーバーから来ることができるように、チャンキング[RFC3030]メカニズムと組み合わせて使用できます。これにより、最初にクライアントにダウンロードすることなく、電子メールメッセージを転送する機能が提供されます。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
このドキュメントの「必須」、「必要はない」、「そうでなければ」、「すべきではない」、「必要はない」は、「要件レベルを示すためにRFCで使用するためのキーワード」で定義されている[RFC2119] [RFC2119]。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC4234] notation including the core rules defined in Appendix B of RFC 4234.
正式な構文では、RFC 4234の付録Bで定義されているコアルールを含む、拡張されたバックスノーフォーム（ABNF）[RFC4234]表記を使用します。
This section defines the BURL submission extension.
このセクションでは、Burl Submission Extensionを定義します。
1. The name of this submission extension is "BURL". This extends the Message Submission protocol on port 587 and MUST NOT be advertised by a regular SMTP [RFC2821] server on port 25 that acts as a relay for incoming mail from other SMTP relays.
1. この提出拡張機能の名前は「Burl」です。これにより、ポート587のメッセージ送信プロトコルが拡張され、ポート25の通常のSMTP [RFC2821]サーバーによって宣伝されてはなりません。
2. The EHLO keyword value associated with the extension is "BURL".
2. 拡張機能に関連付けられているEhloキーワード値は「Burl」です。
3. The BURL EHLO keyword will have zero or more arguments. The only argument defined at this time is the "imap" argument, which MUST be present in order to use IMAP URLs with BURL. Clients MUST ignore other arguments after the BURL EHLO keyword unless they are defined by a subsequent IETF standards track specification. The arguments that appear after the BURL EHLO keyword may change subsequent to the use of SMTP AUTH [RFC2554], so a server that advertises BURL with no arguments prior to authentication indicates that BURL is supported but authentication is required to use it.
3. Burl Ehloキーワードには、ゼロ以上の引数があります。現時点で定義されている唯一の議論は「IMAP」引数です。これは、BurlでIMAP URLを使用するために存在する必要があります。クライアントは、後続のIETF標準トラック仕様によって定義されない限り、Burl Ehloキーワードの後に他の引数を無視する必要があります。Burl Ehloキーワードの後に表示される引数は、SMTP Auth [RFC2554]の使用に続いて変更される可能性があるため、認証の前に引数なしでBurlを宣伝するサーバーは、Burlがサポートされているが、それを使用するために認証が必要であることを示します。
4. This extension adds the BURL SMTP verb. This verb is used as a replacement for the DATA command and is only permitted during a mail transaction after at least one successful RCPT TO.
4. この拡張機能は、Burl SMTP動詞を追加します。この動詞は、データコマンドの代替品として使用され、少なくとも1つの成功したRCPTからメール取引中にのみ許可されます。
A simple BURL transaction will consist of MAIL FROM, one or more RCPT TO headers, and a BURL command with the "LAST" tag. The BURL command will include an IMAP URL pointing to a fully formed message ready for injection into the SMTP infrastructure. If PIPELINING [RFC2920] is advertised, the client MAY send the entire transaction in one round trip. If no valid RCPT TO address is supplied, the BURL command will simply fail, and no resolution of the BURL URL argument will be performed. If at least one valid RCPT TO address is supplied, then the BURL URL argument will be resolved before the server responds to the command.
単純なBurlトランザクションは、メールからのメール、1つ以上のRCPTへのヘッダー、および「最後の」タグ付きのBurlコマンドで構成されます。Burlコマンドには、SMTPインフラストラクチャへのインジェクションの準備ができている完全に形成されたメッセージを指すIMAP URLが含まれます。パイプライン[RFC2920]が宣伝されている場合、クライアントは1回の往復でトランザクション全体を送信することができます。対処する有効なRCPTが提供されない場合、Burlコマンドは単に失敗し、Burl URL引数の解決は実行されません。アドレス指定する有効なRCPTが少なくとも1つある場合、サーバーがコマンドに応答する前に、Burl URL引数が解決されます。
A more sophisticated BURL transaction MAY occur when the server also advertises CHUNKING [RFC3030]. In this case, the BURL and BDAT commands may be interleaved until one of them terminates the transaction with the "LAST" argument. If PIPELINING [RFC2920] is also advertised, then the client may pipeline the entire transaction in one round-trip. However, it MUST wait for the results of the "LAST" BDAT or BURL command prior to initiating a new transaction.
サーバーがチャンク[RFC3030]も宣伝するときに、より洗練されたBurlトランザクションが発生する可能性があります。この場合、BurlおよびBDATコマンドは、そのうちの1つが「最後の」引数でトランザクションを終了するまでインターリーブされる可能性があります。パイプライン[RFC2920]も宣伝されている場合、クライアントは1回の往復でトランザクション全体をパイプラインすることができます。ただし、新しいトランザクションを開始する前に、「最後の」BDATまたはBurlコマンドの結果を待つ必要があります。
The BURL command directs the server to fetch the data object to which the URL refers and include it in the message. If the URL fetch fails, the server will fail the entire transaction.
Burlコマンドは、URLが参照するデータオブジェクトをフェッチし、メッセージに含めるようにサーバーに指示します。URLフェッチが失敗した場合、サーバーはトランザクション全体に失敗します。
When "imap" is present in the space-separated list of arguments following the BURL EHLO keyword, it indicates that the BURL command supports the URLAUTH [RFC4467] extended form of IMAP URLs [RFC2192] and that the submit server is configured with the necessary credentials to resolve "urlauth=submit+" IMAP URLs for the submit server's domain.
「IMAP」がBurl Ehloキーワードに続く引数の空間分離リストに存在する場合、BurlコマンドがUrlauth [RFC4467]のIMAP URL [RFC2192]の拡張形態をサポートし、送信サーバーは必要に応じて構成されていることを示します。「urlauth = shint」を解決するための資格情報は、送信サーバーのドメインのIMAP URLSを使用します。
Subsequent to a successful SMTP AUTH command, the submission server MAY indicate a prearranged trust relationship with a specific IMAP server by including a BURL EHLO keyword argument of the form "imap://imap.example.com". In this case, the submission server will permit a regular IMAP URL referring to messages or parts of messages on imap.example.com that the user who authenticated to the submit server can access. Note that this form does not imply that the submit server supports URLAUTH URLs; the submit server must advertise both "imap" and "imap://imap.example.com" to indicate support for both extended and non-extended URL forms.
SMTP認証コマンドが成功した後、提出サーバーは、「IMAP：//imap.example.com」という形式のBurl Ehloキーワード引数を含めることにより、特定のIMAPサーバーとの事前に配置された信頼関係を示す場合があります。この場合、送信サーバーは、IMAP.example.comのメッセージまたはメッセージの一部を参照する通常のIMAP URLに、送信サーバーに認証されたユーザーがアクセスできることを許可します。このフォームは、送信サーバーがurlauth URLをサポートしていることを意味しないことに注意してください。送信サーバーは、「IMAP」と「IMAP：//imap.example.com」の両方を宣伝して、拡張URLフォームと非拡張URLフォームの両方のサポートを示す必要があります。
When the submit server connects to the IMAP server, it acts as an IMAP client and thus is subject to both the mandatory-to-implement IMAP capabilities in Section 6.1.1 of RFC 3501, and the security considerations in Section 11 of RFC 3501. Specifically, this requires that the submit server implement a configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the IMAP server.
送信サーバーがIMAPサーバーに接続すると、IMAPクライアントとして機能するため、RFC 3501のセクション6.1.1の必須のIMAP機能と、RFC 3501のセクション11のセキュリティ上の考慮事項の両方に対応します。具体的には、STARTTLSを使用してSASL Plain [SASL-PLAIN]が使用してIMAPサーバーに認証する構成を送信する必要があります。
When the submit server resolves a URLAUTH IMAP URL, it uses submit server credentials when authenticating to the IMAP server. The authentication identity and password used for submit credentials MUST be configurable. The string "submit" is suggested as a default value for the authentication identity, with no default for the password. Typically, the authorization identity is empty in this case; thus the IMAP server will derive the authorization identity from the authentication identity. If the IMAP URL uses the "submit+" access identifier prefix, the submit server MUST refuse the BURL command unless the userid in the URL's <access> token matches the submit client's authorization identity.
送信サーバーがUrlauth IMAP URLを解決すると、IMAPサーバーを認証するときにSubmit Server資格情報を使用します。資格情報の送信に使用される認証IDとパスワードは、構成可能でなければなりません。文字列「送信」は、パスワードのデフォルトはありませんが、認証IDのデフォルト値として提案されます。通常、この場合、承認IDは空です。したがって、IMAPサーバーは、認証アイデンティティから承認IDを導き出します。IMAP URLが「送信」アクセス識別子プレフィックスを使用している場合、URLの<Access>トークンのユーザーIDが送信クライアントの承認IDと一致しない限り、送信サーバーはBurlコマンドを拒否する必要があります。
When the submit server resolves a regular IMAP URL, it uses the submit client's authorization identity when authenticating to the IMAP server. If both the submit client and the submit server's embedded IMAP client use SASL PLAIN (or the equivalent), the submit server SHOULD forward the client's credentials if and only if the submit server knows that the IMAP server is in the same administrative domain. If the submit server supports SASL mechanisms other than PLAIN, it MUST implement a configuration in which the submit server's embedded IMAP client uses STARTTLS and SASL PLAIN with the submit server's authentication identity and password (for the respective IMAP server) and the submit client's authorization identity.
送信サーバーが通常のIMAP URLを解決すると、IMAPサーバーを認証するときにクライアントの承認IDを送信します。送信クライアントと送信サーバーの埋め込みIMAPクライアントの両方がSASLプレーン（または同等のもの）を使用する場合、送信サーバーがIMAPサーバーが同じ管理領域にあることを知っている場合にのみ、クライアントの資格情報を送信する必要があります。送信サーバーがPlain以外のSASLメカニズムをサポートしている場合、送信サーバーの埋め込まれたIMAPクライアントがStartTLSとSASL Plainを使用して、Strub Serverの認証IDとパスワードを使用して（それぞれのIMAPサーバーに対して）構成を実装する必要があります。。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。単一の「c：」または「s：」が複数の行に適用される場合、それらの線間のラインが編集の明確さのみを目的としており、実際のプロトコル交換の一部ではありません。
Two successful submissions (without and with pipelining) follow:
2つの成功した提出物（パイプラインなしで）が続きます。
<SSL/TLS encryption layer negotiated>
C: EHLO potter.example.com
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-BURL imap
S: 250-AUTH PLAIN
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
S: 235 2.7.0 PLAIN authentication successful.
C: MAIL FROM:<harry@gryffindor.example.com>
S: 250 2.5.0 Address Ok.
C: RCPT TO:<ron@gryffindor.example.com>
S: 250 2.1.5 ron@gryffindor.example.com OK.
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 250 2.5.0 Ok.
<SSL/TLS encryption layer negotiated>
C: EHLO potter.example.com
S: 250-owlry.example.com
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-BURL imap
S: 250-AUTH PLAIN
S: 250-DSN
S: 250 ENHANCEDSTATUSCODES
C: AUTH PLAIN aGFycnkAaGFycnkAYWNjaW8=
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<ron@gryffindor.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 235 2.7.0 PLAIN authentication successful.
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 ron@gryffindor.example.com OK.
S: 250 2.5.0 Ok.
Note that PIPELINING of the AUTH command is only permitted if the selected mechanism can be completed in one round trip, a client initial response is provided, and no SASL security layer is negotiated. This is possible for PLAIN and EXTERNAL, but not for most other SASL mechanisms.
選択したメカニズムを1回の往復で完了し、クライアントの初期応答が提供され、SASLセキュリティ層が交渉されない場合にのみ、認証コマンドのパイプラインが許可されることに注意してください。これは、プレーンで外部では可能ですが、他のほとんどのSASLメカニズムではそうではありません。
Some examples of failure cases:
障害ケースのいくつかの例：
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<malfoy@slitherin.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:91354a473744909de610943775f92038 LAST
S: 250 2.5.0 Address Ok.
S: 550 5.7.1 Relaying not allowed: malfoy@slitherin.example.com
S: 554 5.5.0 No recipients have been specified.
C: MAIL FROM:<harry@gryffindor.example.com>
C: RCPT TO:<ron@gryffindor.example.com>
C: BURL imap://harry@gryffindor.example.com/outbox
;uidvalidity=1078863300/;uid=25;urlauth=submit+harry
:internal:71354a473744909de610943775f92038 LAST
S: 250 2.5.0 Address Ok.
S: 250 2.1.5 ron@gryffindor.example.com OK.
S: 554 5.7.0 IMAP URL authorization failed
The following syntax specification inherits ABNF [RFC4234] and Uniform Resource Identifiers [RFC3986].
次の構文仕様は、ABNF [RFC4234]および均一なリソース識別子[RFC3986]を継承します。
burl-param = "imap" / ("imap://" authority)
; parameter to BURL EHLO keyword
burl-cmd = "BURL" SP absolute-URI [SP end-marker] CRLF
burl-cmd = "burl" sp absolute-uri [sp end-marker] crlf
end-marker = "LAST"
A submit server that advertises BURL MUST also advertise 8BITMIME [RFC1652] and perform the down conversion described in that specification on the resulting complete message if 8-bit data is received with the BURL command and passed to a 7-bit server. If the URL argument to BURL refers to binary data, then the submit server MAY refuse the command or down convert as described in Binary SMTP [RFC3030].
Burlを宣伝する送信サーバーは、8bitmime [RFC1652]を宣伝し、Burlコマンドで8ビットデータが受信され、7ビットサーバーに渡された場合、結果の完全なメッセージに関するその仕様に記載されているダウンコンバージョンを実行する必要があります。BurlへのURL引数がバイナリデータを指す場合、Binary SMTP [RFC3030]に記載されているように、送信サーバーはコマンドまたはダウンコンバートを拒否する場合があります。
The Submit server MAY refuse to accept a BURL command or combination of BURL and BDAT commands that result in un-encoded 8-bit data in mail or MIME [RFC2045] headers. Alternatively, the server MAY accept such data and down convert to MIME header encoding [RFC2047].
送信サーバーは、郵便またはMIME [RFC2045]ヘッダーでエンコードされていない8ビットデータをもたらすBurlコマンドまたはBurlコマンドとBDATコマンドの組み合わせを受け入れることを拒否する場合があります。あるいは、サーバーはそのようなデータを受け入れ、ダウンコンバージョン[RFC2047]をエンコードすることもできます。
SMTP or Submit servers that advertise ENHANCEDSTATUSCODES [RFC2034] use enhanced status codes defined in RFC 3463 [RFC3463]. The BURL extension introduces new error cases that that RFC did not consider. The following additional enhanced status codes are defined by this specification:
EnhancedStatuscodes [RFC2034]を宣伝するSMTPまたは送信SMTPまたはRFC 3463 [RFC3463]で定義された拡張ステータスコードを使用します。Burl Extensionは、RFCが考慮しなかった新しいエラーケースを導入します。次の追加の強化されたステータスコードは、この仕様で定義されています。
X.6.6 Message content not available
X.6.6 メッセージコンテンツは利用できません
The message content could not be fetched from a remote system. This may be useful as a permanent or persistent temporary notification.
メッセージコンテンツをリモートシステムから取得することはできませんでした。これは、永続的または永続的な一時的な通知として役立つ場合があります。
X.7.8 Trust relationship required
X.7.8 信頼関係が必要です
The submission server requires a configured trust relationship with a third-party server in order to access the message content.
送信サーバーは、メッセージコンテンツにアクセスするために、サードパーティサーバーとの構成された信頼関係を必要とします。
This section includes example response codes to the BURL command. Other text may be used with the same response codes. This list is not exhaustive, and BURL clients MUST tolerate any valid SMTP response code. Most of these examples include the appropriate enhanced status code [RFC3463].
このセクションには、Burlコマンドへの応答コードの例が含まれています。他のテキストは、同じ応答コードで使用できます。このリストは網羅的ではなく、Burlクライアントは有効なSMTP応答コードを許容する必要があります。これらの例のほとんどには、適切な強化ステータスコード[RFC3463]が含まれています。
554 5.5.0 No recipients have been specified
554 5.5.0受信者は指定されていません
This response code occurs when BURL is used (for example, with PIPELINING) and all RCPT TOs failed.
この応答コードは、Burlが使用されている場合（たとえば、パイプラインで）発生し、すべてのRCPT TOSが失敗しました。
503 5.5.0 Valid RCPT TO required before BURL
503 5.5.0 Burlの前に必要な有効なRCPT
This response code is an alternative to the previous one when BURL is used (for example, with PIPELINING) and all RCPT TOs failed.
この応答コードは、Burlが使用されている場合（たとえば、パイプラインで）以前のコードに代わるものであり、すべてのRCPT TOSが失敗しました。
554 5.6.3 Conversion required but not supported
554 5.6.3変換は必要ですが、サポートされていません
This response code occurs when the URL points to binary data and the implementation does not support down conversion to base64. This can also be used if the URL points to message data with 8-bit content in headers and the server does not down convert such content.
この応答コードは、URLがバイナリデータを指し、実装がBase64への変換をサポートしていない場合に発生します。これは、URLがヘッダーに8ビットコンテンツを含むデータにメッセージを指し、サーバーがそのようなコンテンツを変換しない場合にも使用できます。
554 5.3.4 Message too big for system
554 5.3.4システムには大きすぎます
The message (subsequent to URL resolution) is larger than the per-message size limit for this server.
メッセージ（URL解像度に続いて）は、このサーバーのメッセージごとのサイズ制限よりも大きくなります。
554 5.7.8 URL resolution requires trust relationship
554 5.7.8 URL解決には、信頼関係が必要です
The submit server does not have a trust relationship with the IMAP server specified in the URL argument to BURL.
送信サーバーは、URL引数でBurlに指定されたIMAPサーバーとの信頼関係を持っていません。
552 5.2.2 Mailbox full
552 5.2.2メールボックスフル
The recipient is local, the submit server supports direct delivery, and the recipient has exceeded his quota and any grace period for delivery attempts.
受信者はローカルであり、送信サーバーは直接配達をサポートし、受信者は彼のクォータと配達の試みの猶予期間を超えています。
554 5.6.6 IMAP URL resolution failed
554 5.6.6 IMAP URL解像度が失敗しました
The IMAP URLFETCH command returned an error or no data.
IMAP urlfetchコマンドは、エラーまたはデータなしを返しました。
250 2.5.0 Waiting for additional BURL or BDAT commands
250 2.5.0追加のBurlまたはBDATコマンドを待っています
A BURL command without the "LAST" modifier was sent. The URL for this BURL command was successfully resolved, but the content will not necessarily be committed to persistent storage until the rest of the message content is collected. For example, a Unix server may have written the content to a queue file buffer, but may not yet have performed an fsync() operation. If the server loses power, the content can still be lost.
「最後の」モディファイアのないBurlコマンドが送信されました。このBurlコマンドのURLは正常に解決されましたが、メッセージコンテンツの残りの部分が収集されるまで、コンテンツが必ずしも永続的なストレージにコミットされるわけではありません。たとえば、UNIXサーバーはコンテンツをキューファイルバッファーに書き込みましたが、FSYNC（）操作をまだ実行していない場合があります。サーバーが電源を失った場合でも、コンテンツが失われる可能性があります。
451 4.4.1 IMAP server unavailable
451 4.4.1 IMAPサーバーは利用できません
The connection to the IMAP server to resolve the URL failed.
URLを解決するためのIMAPサーバーへの接続が失敗しました。
250 2.5.0 Ok.
250 2.5.0 OK。
The URL was successfully resolved, and the complete message data has been committed to persistent storage.
URLは正常に解決され、完全なメッセージデータが永続的なストレージにコミットされています。
250 2.6.4 MIME header conversion with loss performed
250 2.6.4実行された損失によるMIMEヘッダー変換
The URL pointed to message data that included mail or MIME headers with 8-bit data. This data was converted to MIME header encoding [RFC2047], but the submit server may not have correctly guessed the unlabeled character set.
URLは、8ビットデータを含むメールまたはMIMEヘッダーを含むメッセージデータを指し示しました。このデータは、[RFC2047]をエンコードするMIMEヘッダーに変換されましたが、送信サーバーは、ラベルのない文字セットを正しく推測していない可能性があります。
The "BURL" SMTP extension as described in Section 3 has been registered. This registration has been marked for use by message submission [RFC4409] only in the registry.
セクション3で説明されている「Burl」SMTP拡張機能が登録されています。この登録は、レジストリでのみメッセージ送信[RFC4409]によって使用されるためにマークされています。
Modern SMTP submission servers often include content-based security and denial-of-service defense mechanisms such as virus filtering, size limits, server-generated signatures, spam filtering, etc. Implementations of BURL should fetch the URL content prior to application of such content-based mechanisms in order to preserve their function.
最新のSMTP提出サーバーには、多くの場合、コンテンツベースのセキュリティとウイルスフィルタリング、サイズ制限、サーバー生成署名、スパムフィルタリングなどのサービス拒否防御メカニズムが含まれます。 - 機能を維持するためのベースのメカニズム。
Clients that generate unsolicited bulk email or email with viruses could use this mechanism to compensate for a slow link between the client and submit server. In particular, this mechanism would make it feasible for a programmable cell phone or other device on a slow link to become a significant source of unsolicited bulk email and/or viruses. This makes it more important for submit server vendors implementing BURL to have auditing and/or defenses against such denial-of-service attacks including mandatory authentication, logging that associates unique client identifiers with mail transactions, limits on reuse of the same IMAP URL, rate limits, recipient count limits, and content filters.
ウイルスを使用して未承諾のバルクメールまたは電子メールを生成するクライアントは、このメカニズムを使用して、クライアントと送信サーバーの間の遅いリンクを補うことができます。特に、このメカニズムにより、プログラム可能な携帯電話または他のデバイスが遅いリンク上の他のデバイスが、未承諾のバルクメールやウイルスの重要なソースになるために実行可能になります。これにより、Burlを実装するサーバーベンダーを送信すると、必須認証、郵便取引、同じIMAP URLの再利用の制限を関連付けたログを記録する、監査および/または監視拒否攻撃に対する監査および/または防御がより重要になります。制限、受信者数の制限、およびコンテンツフィルター。
Transfer of the URLAUTH [RFC4467] form of IMAP URLs in the clear can expose the authorization token to network eavesdroppers. Implementations that support such URLs can address this issue by using a strong confidentiality protection mechanism. For example, the SMTP STARTTLS [RFC3207] and the IMAP STARTTLS [RFC3501] extensions, in combination with a configuration setting that requires their use with such IMAP URLs, would address this concern.
クリア内のIMAP URLのurlauth [rfc4467]の転送は、認証トークンをネットワーク盗聴者に露出させる可能性があります。そのようなURLをサポートする実装は、強力な機密保護保護メカニズムを使用してこの問題に対処できます。たとえば、SMTP startTls [RFC3207]およびIMAP startTls [RFC3501]拡張は、そのようなIMAP URLでの使用を必要とする構成設定と組み合わせて、この懸念に対処するでしょう。
Use of a prearranged trust relationship between a submit server and a specific IMAP server introduces security considerations. A compromise of the submit server should not automatically compromise all accounts on the IMAP server, so trust relationships involving super-user proxy credentials are strongly discouraged. A system that requires the submit server to authenticate to the IMAP server with submit credentials and subsequently requires a URLAUTH URL to fetch any content addresses this concern. A trusted third party model for proxy credentials (such as that provided by Kerberos 5 [RFC4120]) would also suffice.
送信サーバーと特定のIMAPサーバーとの間に事前に配置された信頼関係を使用すると、セキュリティ上の考慮事項が導入されます。送信サーバーの妥協点は、IMAPサーバー上のすべてのアカウントを自動的に侵害してはならないため、スーパーユーザーのプロキシ資格情報を含む信頼関係は強く落胆します。送信サーバーが資格情報を送信してIMAPサーバーに認証することを要求し、その後、この懸念事項アドレスを取得するためにUrlauth URLが必要です。代理資格情報の信頼できるサードパーティモデル（Kerberos 5 [RFC4120]によって提供されるものなど）でも十分です。
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 address this expectation, the message submission server SHOULD use STARTTLS or a mechanism providing equivalent data confidentiality when fetching the content referenced by that URL.
クライアントがSMTP startTLSを使用して、非公開情報を参照するBurlコマンドを送信すると、メッセージコンテンツ全体が秘密に扱われるというユーザーの期待があります。この期待に対処するために、メッセージ送信サーバーは、そのURLで参照されるコンテンツを取得するときに、starttlsまたは同等のデータ機密性を提供するメカニズムを使用する必要があります。
A legitimate user of a submit server may try to compromise other accounts on the server by providing an IMAP URLAUTH URL that points to a server under that user's control that is designed to undermine the security of the submit server. For this reason, the IMAP client code that the submit server uses must be robust with respect to arbitrary input sizes (including large IMAP literals) and arbitrary delays from the IMAP server. Requiring a prearranged trust relationship between a submit server and the IMAP server also addresses this concern.
送信サーバーの正当なユーザーは、送信サーバーのセキュリティを損なうように設計されたユーザーの制御の下でサーバーを指すIMAP Urlauth URLを提供することにより、サーバー上の他のアカウントを侵害しようとする場合があります。このため、送信サーバーが使用するIMAPクライアントコードは、任意の入力サイズ（大きなIMAPリテラルを含む）およびIMAPサーバーからの任意の遅延に関して堅牢でなければなりません。送信サーバーとIMAPサーバーの間に事前に配置された信頼関係を要求することも、この懸念に対処します。
An authorized user of the submit server could set up a fraudulent IMAP server and pass a URL for that server to the submit server. The submit server might then contact the fraudulent IMAP server to authenticate with submit credentials and fetch content. There are several ways to mitigate this potential attack. A submit server that only uses submit credentials with a fixed set of trusted IMAP servers will not be vulnerable to exposure of those credentials. A submit server can treat the IMAP server as untrusted and include defenses for buffer overflows, denial-of-service slowdowns, and other potential attacks. Finally, because authentication is required to use BURL, it is possible to keep a secure audit trail and use that to detect and punish the offending party.
送信サーバーの承認されたユーザーは、不正なIMAPサーバーを設定し、そのサーバーのURLを送信サーバーに渡すことができます。送信サーバーは、不正なIMAPサーバーに連絡して、資格情報を送信してコンテンツを取得することで認証する場合があります。この潜在的な攻撃を軽減する方法はいくつかあります。信頼できるIMAPサーバーの固定セットを使用して資格情報を送信するだけの送信サーバーは、それらの資格情報の露出に対して脆弱ではありません。送信サーバーは、IMAPサーバーを信頼されていないものとして扱い、バッファーオーバーフロー、サービス拒否の減速、およびその他の潜在的な攻撃のための防御を含めることができます。最後に、Burlを使用するには認証が必要なため、安全な監査証跡を保持し、それを使用して問題のある当事者を検出して罰することができます。
[RFC1652] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[RFC1652] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「8bit-MimetransportのSMTPサービス拡張」、RFC 1652、1994年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[RFC2192]ニューマン、C。、「IMAP URLスキーム」、RFC 2192、1997年9月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC2554] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[RFC3207] Hoffman、P。、「輸送層セキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 3501、2003年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409] Gellens、R。およびJ. Klensin、「Message Submission for Mail」、RFC 4409、2006年4月。
[RFC4467] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
[RFC4467] CRISPIN、M。、「インターネットメッセージアクセスプロトコル（IMAP） - Urlauth Extension」、RFC 4467、2006年5月。
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034] Freed、N。、「拡張エラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K。、「MIME（多目的インターネットメールエクステンション）パート3：ASCII以外のテキストのメッセージヘッダー拡張機能」、RFC 2047、1996年11月。
[RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, September 2000.
[RFC2920] Freed、N。、「コマンドパイプラインのSMTPサービス拡張」、STD 60、RFC 2920、2000年9月。
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[RFC3030] Vaudreuil、G。、「大型およびバイナリMIMEメッセージの送信用SMTPサービス拡張」、RFC 3030、2000年12月。
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[RFC3463] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network認証サービス（V5）」、RFC 4120、2005年7月。
[SASL-PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in Progress, March 2005.
[SASL-Plain] Zeilenga、K。、「プレーンSASLメカニズム」、2005年3月、進行中の作業。
This document is a product of the lemonade WG. Many thanks are due to all the participants of that working group for their input. Mark Crispin was instrumental in the conception of this mechanism. Thanks to Randall Gellens, Alexey Melnikov, Sam Hartman, Ned Freed, Dave Cridland, Peter Coates, and Mark Crispin for review comments on the document. Thanks to the RFC Editor for correcting the author's grammar mistakes. Thanks to Ted Hardie, Randall Gellens, Mark Crispin, Pete Resnick, and Greg Vaudreuil for extremely interesting debates comparing this proposal and alternatives. Thanks to the lemonade WG chairs Eric Burger and Glenn Parsons for concluding the debate at the correct time and making sure this document got completed.
このドキュメントは、レモネードWGの製品です。そのワーキンググループのすべての参加者の入力に感謝しています。マーククリスピンは、このメカニズムの概念に貢献しました。ランドール・ゲレンズ、アレクセイ・メルニコフ、サム・ハートマン、ネッド・フリード、デイブ・クライドランド、ピーター・コーツ、マーク・クリスピンに感謝します。著者の文法の間違いを修正してくれたRFCエディターに感謝します。Ted Hardie、Randall Gellens、Mark Crispin、Pete Resnick、およびGreg Vaudreuilに、この提案と代替案を比較した非常に興味深い議論に感謝します。レモネードWGチェアのエリックバーガーとグレンパーソンズのおかげで、正しい時間に議論を終えて、この文書が完成したことを確認してくれました。
Author's Address
著者の連絡先
Chris Newman Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 US
クリスニューマンサンマイクロシステムズ3401センターレイク博士、スイート410オンタリオ州カリフォルニア州91761米国
EMail: chris.newman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。