[要約] RFC 3848は、ESMTPとLMTPの送信タイプの登録に関する規格です。このRFCの目的は、これらの送信タイプを一貫性のある方法で識別し、インターネットメールの送信プロトコルの進化を促進することです。
Network Working Group C. Newman
Request for Comments: 3848 Sun Microsystems
Category: Standards Track July 2004
ESMTP and LMTP Transmission Types Registration
ESMTPおよびLMTP送信タイプの登録
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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This registers seven new mail transmission types (ESMTPA, ESMTPS, ESMTPSA, LMTP, LMTPA, LMTPS, LMTPSA) for use in the "with" clause of a Received header in an Internet message.
これにより、インターネットメッセージ内の受信ヘッダーの「with with」節で使用するために、7つの新しいメール伝送タイプ（ESMTPA、ESMTPS、ESMTPSA、LMTPA、LMTPS、LMTPSA）を登録します。
As directed by SMTP [2], IANA maintains a registry [7] of "WITH protocol types" for use in the "with" clause of the Received header in an Internet message. This registry presently includes SMTP [6], and ESMTP [2]. This specification updates the registry as follows:
SMTP [2]が指示したように、IANAは、インターネットメッセージで受信されたヘッダーの「with」句で使用するための「プロトコルタイプで」のレジストリ[7]を維持しています。このレジストリには現在、SMTP [6]とESMTP [2]が含まれています。この仕様は、次のようにレジストリを更新します。
o The new keyword "ESMTPA" indicates the use of ESMTP when the SMTP AUTH [3] extension is also used and authentication is successfully achieved.
o 新しいキーワード「ESMTPA」は、SMTP AUTH [3]拡張も使用され、認証が正常に達成されたときにESMTPの使用を示します。
o The new keyword "ESMTPS" indicates the use of ESMTP when STARTTLS [1] is also successfully negotiated to provide a strong transport encryption layer.
o 新しいキーワード「ESMTPS」は、StartTLS [1]が強力な輸送暗号化層を提供するために正常にネゴシエートされたときにESMTPの使用を示します。
o The new keyword "ESMTPSA" indicates the use of ESMTP when both STARTTLS and SMTP AUTH are successfully negotiated (the combination of ESMTPS and ESMTPA).
o 新しいキーワード「ESMTPSA」は、StartTLSとSMTP AUTHの両方が正常にネゴシエートされた場合のESMTPの使用を示します（ESMTPとESMTPAの組み合わせ）。
o The new keyword "LMTP" indicates the use of LMTP [4].
o 新しいキーワード「LMTP」は、LMTPの使用を示します[4]。
o The new keyword "LMTPA" indicates the use of LMTP when the SMTP AUTH extension is also used and authentication is successfully achieved.
o 新しいキーワード「LMTPA」は、SMTP AUTH拡張も使用され、認証が正常に達成される場合のLMTPの使用を示します。
o The new keyword "LMTPS" indicates the use of LMTP when STARTTLS is also successfully negotiated to provide a strong transport encryption layer.
o 新しいキーワード「LMTPS」は、StartTLSが強力な輸送暗号化層を提供するために正常にネゴシエートされた場合のLMTPの使用を示します。
o The new keyword "LMTPSA" indicates the use of LMTP when both STARTTLS and SMTP AUTH are successfully negotiated (the combination of LSMTPS and LSMTPA).
o 新しいキーワード「LMTPSA」は、StartTLSとSMTP AUTHの両方が正常にネゴシエートされた場合のLMTPの使用を示します（LSMTPとLSMTPAの組み合わせ）。
o The references for the ESMTP and SMTP entries in the registry should be updated to the latest specification [2] since both RFC 821 and RFC 1869 [5] are obsoleted by RFC 2821.
o RFC 821とRFC 1869 [5]の両方がRFC 2821によって廃止されているため、レジストリ内のESMTPおよびSMTPエントリの参照は最新の仕様[2]に更新する必要があります。
The ESMTPA, ESMTPS and ESMTPSA keywords have been implemented in deployed email server software for several years and no problems have been reported with their use.
ESMTPA、ESMTPS、およびESMTPSAキーワードは、数年間展開された電子メールサーバーソフトウェアに実装されており、使用に関して問題は報告されていません。
Use of these additional keywords provides trace information to indicate when various high-level security framing protocols are used for hop-to-hop transport of email without exposing details of the specifics of the security mechanism. This trace information provides an informal way to track the deployment of these mechanisms on the Internet and can assist after-the-fact diagnosis of email abuse.
これらの追加のキーワードを使用すると、セキュリティメカニズムの詳細の詳細を公開することなく、さまざまな高レベルのセキュリティフレーミングプロトコルが電子メールのホップツーホップトランスポートに使用される場合を示すトレース情報が提供されます。このトレース情報は、インターネット上のこれらのメカニズムの展開を追跡するための非公式の方法を提供し、電子メールの乱用の事後診断を支援できます。
These keywords are not normally protected in transport which means they can be modified by an active attacker. They also do not indicate the specifics of the mechanism used, and therefore do not provide any real-world security assurance. They should not be used for mail filtering or relaying decisions except in very controlled environments. As they are both cryptic and hidden in trace headers used primarily to diagnose email problems, it is not expected they will mislead end users with a false sense of security. Information with a higher degree of reliability can be obtained by correlating the Received headers with the logs of the various Mail Transfer Agents through which the message passed.
これらのキーワードは通常、輸送で保護されていないため、アクティブな攻撃者が変更できます。また、使用されるメカニズムの詳細を示していないため、実際のセキュリティ保証は提供されません。非常に制御された環境を除いて、メールのフィルタリングや意思決定の中継に使用しないでください。それらは不可解であり、主に電子メールの問題を診断するために使用されるトレースヘッダーに隠されているため、エンドユーザーを誤ったセキュリティの感覚で誤解させるとは予想されていません。受信したヘッダーを、メッセージが通過したさまざまなメール転送エージェントのログと相関させることにより、より高い信頼性のある情報を取得できます。
The trace information provided by these keywords and other parts of the Received header provide a significant benefit when doing after-the-fact diagnosis of email abuse or problems. Unfortunately, some people in a misguided attempt to hide information about their internal servers will strip Received headers of useful information and reduce their ability to correct security abuses after they happen. The result of such misguided efforts is usually a reduction of the overall security of the systems.
これらのキーワードや受信されたヘッダーの他の部分によって提供されるトレース情報は、メールの乱用や問題の事後診断を行う際に大きな利点をもたらします。残念ながら、内部サーバーに関する情報を非表示にしようとする見当違いの試みにいる一部の人々は、有用な情報のヘッダーを削除し、セキュリティ虐待が発生した後に修正する能力を低下させます。このような誤った努力の結果は、通常、システムの全体的なセキュリティを減らすことです。
[1] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[1] Hoffman、P。、「輸送層のセキュリティ上の安全なSMTPのSMTPサービス拡張」、RFC 3207、2002年2月。
[2] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[2] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[3] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[3] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
[4] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[4] Myers、J。、「ローカルメール転送プロトコル」、RFC 2033、1996年10月。
[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[5] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、STD 10、RFC 1869、1995年11月。
[6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[6] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[7] <http://www.iana.org/assignments/mail-parameters>
Author's Address
著者の連絡先
Chris Newman Sun Microsystems 1050 Lakes Drive West Covina, CA 91790 US
クリスニューマンサンマイクロシステムズ1050レイクスドライブウェストコヴィナ、カリフォルニア州91790米国
EMail: chris.newman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（c）The Internet Society（2004）。この文書は、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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。