[要約] RFC 4146は、新しいメールの通知を簡単に行うためのプロトコルです。目的は、メールクライアントがサーバーに対して新しいメールの存在を効率的に確認できるようにすることです。
Network Working Group R. Gellens Request for Comments: 4146 QUALCOMM Category: Informational August 2005
Simple New Mail Notification
簡単な新しいメール通知
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright(c)The Internet Society(2005)。
Abstract
概要
This memo documents a long-standing technique, supported by a large number of mail servers, which allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client.
このメモは、多数のメールサーバーでサポートされている長年の手法を文書化しており、ユーザーに新しいメールを通知できるようにします。サーバーサポートに加えて、これをサポートする多くのクライアントがあります。これは、完全な電子メールクライアントから専門的なクライアントに至るまで、新しいメール通知を受け取り、メールクライアントに警告することを目的としています。
In brief, the server sends the string "nm_notifyuser" CRLF to the finger port on the IP address (either configured or last used) of the user who has received new mail.
簡単に言えば、サーバーは、新しいメールを受け取ったユーザーのIPアドレス(構成または最後に使用されている)の指「nm_notifyuser」crlfに "nm_notifyuser" crlfを送信します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 3. Simple Mail Notification . . . . . . . . . . . . . . . . . . 2 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Security Considerations . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 3
There is a long-standing technique supported by a large number of mail servers that allows users to be notified of new mail. In addition to server support, there are a number of clients that support this, ranging from full email clients to specialized clients whose only purpose is to receive new mail notifications and alert a mail client. This technique is sometimes known as "notify mail" (after a shareware client of the same name), "biff", and the "finger hack".
ユーザーに新しいメールを通知できる多数のメールサーバーでサポートされている長年の手法があります。サーバーサポートに加えて、これをサポートする多くのクライアントがあります。これは、完全な電子メールクライアントから専門的なクライアントに至るまで、新しいメール通知を受け取り、メールクライアントに警告することを目的としています。この手法は、「メールの通知」(同じ名前のシェアウェアクライアントの後)、「Biff」、および「Finger Hack」と呼ばれることもあります。
In examples, "C:" indicates lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are for editorial purposes only. Line breaks in the protocol are indicated by "CRLF".
例では、「C:」はクライアントから送信された行を示し、「s:」はサーバーから送信された行を示します。コマンドの例内のラインブレークは、編集目的のみを目的としています。プロトコルのラインブレークは、「CRLF」で示されます。
With this technique, the server sends the string "nm_notifyuser" immediately followed by CRLF to the finger port on the IP address for the user who has received new mail. The finger port is 79. Note that only the port for finger is used; the finger protocol itself is not used.
この手法を使用すると、サーバーは、新しいメールを受け取ったユーザーのIPアドレスのFinger Portに、すぐにCRLFがCRLFを送信します。指ポートは79です。指のポートのみが使用されることに注意してください。フィンガープロトコル自体は使用されません。
The IP address to use may be configured, or the server may use the IP address that was last used to check mail by the user. Typically, this is a per-account configuration option.
使用するIPアドレスを構成するか、サーバーがユーザーによるメールを確認するために最後に使用されたIPアドレスを使用する場合があります。通常、これはアカウントごとの構成オプションです。
On the client system, a process must be listening to the finger port to be useful. When it receives the "nm_notifyuser" string, it takes a configured action, typically instructing a mail client to fetch mail.
クライアントシステムでは、プロセスが有用になるにはフィンガーポートを聴く必要があります。「nm_notifyuser」文字列を受信すると、構成されたアクションが必要になり、通常、メールクライアントにメールを送信するよう指示します。
Normally, a TCP connection to the target computer is opened, the "nm_notifyuser" string is sent, and the connection is closed without waiting for a response.
通常、ターゲットコンピューターへのTCP接続が開かれ、「nm_notifyuser」文字列が送信され、応答を待たずに接続が閉じられます。
In some cases, UDP is used instead of TCP, but the default and general practice is TCP. Even though only a single message in one direction is sent (with no reply), TCP is used most often, probably for reliability.
場合によっては、UDPがTCPの代わりに使用されますが、デフォルトおよび一般的な慣行はTCPです。一方向に単一のメッセージのみが送信されますが(返信なし)、TCPはほとんどの場合、おそらく信頼性のために使用されます。
There is an assumption that the client listening on an IP address only has responsibility for one email account. If a client can check multiple accounts and receives the "nm_notifyuser" string, it does not know which account received the mail.
IPアドレスで聞くクライアントは、1つの電子メールアカウントに対してのみ責任を負うという仮定があります。クライアントが複数のアカウントをチェックして「nm_notifyuser」文字列を受信できる場合、どのアカウントがメールを受信したかわかりません。
There is a requirement that a finger daemon not be active on the client.
指のデーモンがクライアントにアクティブでないという要件があります。
This example assumes that new mail has arrived at the server mail.isp.example.com for account fastness@example.net. The server has determined an IP address to which notification should be sent.
この例では、アカウントFastness@example.netのために、新しいメールがServer Mail.isp.example.comに到着したことを前提としています。サーバーは、通知を送信するIPアドレスを決定しました。
C: <listens on TCP port 79> S: <opens TCP connection to IP address port 79> C: <accepts inbound connection on port 79> S: nm_notifyuserCRLF S: <closes TCP connection>
There is no assurance that the "nm_notifyuser" message is being sent to the correct IP address. Nor does the listening agent on the client system have any assurance that an "nm_notifyuser" string was sent by a mail server that has received new mail for the user.
「nm_notifyuser」メッセージが正しいIPアドレスに送信されているという保証はありません。また、クライアントシステムのリスニングエージェントは、ユーザー向けの新しいメールを受信したメールサーバーから「NM_NotifyUser」文字列が送信されたという保証もありません。
It is trivial for an attacker to send large numbers of "nm_notifyuser" messages to a targeted system. Client systems that are listening for this message SHOULD implement protections against being flooded with notifications. Many server systems already implement protections against users logging in and checking mail too frequently.
攻撃者がターゲットシステムに多数の「NM_NOTIFYUSER」メッセージを送信することは些細なことです。このメッセージを聞いているクライアントシステムは、通知があふれていることに対する保護を実装する必要があります。多くのサーバーシステムは、すでに頻繁にメールをログインしてチェックしているユーザーに対する保護を実装しています。
Because use of this protocol requires that a port be open with an agent listening on it, if that agent contains vulnerabilities, it may create a remotely exploitable attack (for example, buffer overflows that permit an attacker to execute arbitrary code on the client system with the permissions of the agent). As usual, with a process listening on a port, the process should execute with the least possible privilege level and access.
このプロトコルを使用するには、エージェントがリスニングされているエージェントでポートを開く必要があるため、そのエージェントに脆弱性が含まれている場合、リモートで悪用可能な攻撃を作成する可能性があります(たとえば、攻撃者がクライアントシステムで任意のコードを実行できるようにするバッファオーバーフローエージェントの権限)。いつものように、ポートでプロセスをリスニングすると、プロセスは最小限の特権レベルとアクセスで実行する必要があります。
The notify mail hack (and this document) should be included as an additional usage for port 79.
Notify Mail Hack(およびこのドキュメント)は、ポート79の追加の使用として含める必要があります。
The NotifyMail shareware utility was written by Scott Gruby.
NotifyMail Sharewareユーティリティは、Scott Grubyによって作成されました。
Author's Address
著者の連絡先
Randall Gellens QUALCOMM Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 USA EMail: randy@qualcomm.com
Randall Gellens Qualcomm Incorporated 6455 Lusk Blvd.サンディエゴ、CA 92121-2779 USAメール:randy@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright(c)The Internet Society(2005)。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。