From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4146.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc4146.txt (limited to 'doc/rfc/rfc4146.txt') diff --git a/doc/rfc/rfc4146.txt b/doc/rfc/rfc4146.txt new file mode 100644 index 0000000..38e93cf --- /dev/null +++ b/doc/rfc/rfc4146.txt @@ -0,0 +1,283 @@ + + + + + + +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). + +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. + +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 + + + + + + + + + + + + +Gellens Informational [Page 1] + +RFC 4146 Simple New Mail Notification August 2005 + + +1. Introduction + + 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". + +2. Conventions Used in This Document + + 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". + +3. Simple Mail Notification + + 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. + + 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. + + 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. + + 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. + + 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. + + 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. + + + +Gellens Informational [Page 2] + +RFC 4146 Simple New Mail Notification August 2005 + + + There is a requirement that a finger daemon not be active on the + client. + +4. Example + + 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. + + C: + S: + C: + S: nm_notifyuserCRLF + S: + +5. Security Considerations + + 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. + + 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. + + 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. + +6. IANA Considerations + + The notify mail hack (and this document) should be included as an + additional usage for port 79. + +7. Acknowledgments + + The NotifyMail shareware utility was written by Scott Gruby. + + + + + + +Gellens Informational [Page 3] + +RFC 4146 Simple New Mail Notification August 2005 + + +Author's Address + + Randall Gellens + QUALCOMM Incorporated + 6455 Lusk Blvd. + San Diego, CA 92121-2779 + USA + EMail: randy@qualcomm.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens Informational [Page 4] + +RFC 4146 Simple New Mail Notification August 2005 + + +Full Copyright Statement + + 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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Gellens Informational [Page 5] + -- cgit v1.2.3