Network Working Group C. Newman
Request for Comments: 3848 Sun Microsystems
Category: Standards Track July 2004
ESMTP and LMTP Transmission Types Registration
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）インターネット協会（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.
これは、インターネットメッセージで受信ヘッダの「持つ」句で使用するための7つの新しいメール送信タイプ（ESMTPA、ESMTPS、ESMTPSA、LMTP、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の使用（ESMTPSと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.
新しいキーワードは「LMTPS」O 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の使用（LSMTPSと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.
RFC 821とRFC 1869の両方ので[2]レジストリ内ESMTPとSMTPエントリの参照が最新の仕様に更新されるべきであるO [5] RFC 2821によって廃止されています。
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.
電子メールの乱用や問題の事後診断を行う際にこれらのキーワードとReceivedヘッダの他の部分によって提供さトレース情報は、重要な利点を提供します。残念ながら、彼らの内部サーバーについての情報を非表示にするには、見当違いの試みで、何人かの人々は、有用な情報のReceivedヘッダーを削除し、それらが起こる後にセキュリティ侵害を修正する能力が低下します。そのような見当違いの努力の結果は、通常、システムの全体的なセキュリティの減少です。
[1] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[1]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[2] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[2] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[3] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[3]マイヤーズ、J.、 "認証のためのSMTPサービス拡張"、RFC 2554、1999年3月。
[4] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[4]マイヤーズ、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.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[6]ポステル、J.、 "簡易メール転送プロトコル"、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
クリス・ニューマンSun Microsystemsの1050湖ドライブウェストコヴィナ、CA 91790米国
EMail: chris.newman@sun.com
メールアドレス：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。