idnits 2.17.1 draft-gellens-notify-mail-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 201. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 207), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 140: '...for this message SHOULD implement prot...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2005) is 7041 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Notify Mail R. Gellens 3 Document: draft-gellens-notify-mail-02.txt QUALCOMM 4 Expires: July 2005 January 2005 6 Simple New Mail Notification 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of RFC 3668. 15 By submitting this Internet-Draft, I accept the provisions of 16 Section 3 of RFC 3667 (BCP 78). 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This memo documents a long-standing technique, supported by a large 40 number of mail servers, which allows users to be notified of new 41 mail. In addition to server support, there are a number of clients 42 which support this, ranging from full email clients to specialized 43 clients whose only purpose is to receive new mail notifications and 44 alert a mail client. 46 In brief, the technique is for the server to send the string 47 "nm_notifyuser" CRLF to the finger port on the IP address (either 48 configured or last used) for the user who has received new mail. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 54 3. Simple Mail Notification . . . . . . . . . . . . . . . . . . 3 55 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 5 59 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 60 9. Informative References . . . . . . . . . . . . . . . . . . . 5 61 10. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 5 62 Intellectual Property Statement . . . . . . . . . . . . . . . 5 63 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 64 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 There is a long-standing technique supported by a large number of 69 mail servers which allows users to be notified of new mail. In 70 addition to server support, there are a number of clients which 71 support this, ranging from full email clients to specialized clients 72 whose only purpose is to receive new mail notifications and alert a 73 mail client. This technique is sometimes known as "notify mail" 74 (after a shareware client of the same name), sometimes called 75 "biff", and sometimes the "finger hack". 77 2. Conventions Used in this Document 79 In examples, "C:" is used to indicate lines sent by the client, and 80 "S:" indicates those sent by the server. Line breaks within a 81 command example are for editorial purposes only. Line breaks in the 82 protocol are indicated by "CRLF". 84 3. Simple Mail Notification 86 The technique is for the server to send the string "nm_notifyuser" 87 immediately followed by CRLF to the finger port on the IP address 88 for the user who has received new mail. The finger port is 79. 89 (Note that only the port for finger is used; the finger protocol 90 itself is not used.) 92 The IP address to use may be configured, or the server may use the 93 IP address that was last used to check mail by the user. Typically 94 this is a per-account configuration option. 96 To be useful, on the client system a process must be listening to 97 the finger port. When it receives the "nm_notifyuser" string, it 98 takes a configured action, typically instructing a mail client to 99 fetch mail. 101 Normally, a TCP connection to the target computer is opened, the 102 "nm_notifyuser" string is sent, and the connection is closed without 103 waiting for any response. 105 In some cases UDP is used instead of TCP, but the default and 106 general practice is TCP. Even though one a single message in one 107 direction is sent (with no reply), TCP is used most often, probably 108 for reliability. 110 There is an assumption that the client listening on an IP address 111 only has responsibility for one email account; if a client can check 112 multiple accounts and receives the "nm_notifyuser" string, it does 113 not know which account received the mail. 115 There is a requirement that a finger daemon is not active on the 116 client. 118 4. Example 120 This example assumes that new mail has arrived at server 121 mail.isp.example.com for account fastness@example.net. The server 122 has determined an IP address to which notification should be sent. 124 C: 125 S: 126 C: 127 S: nm_notifyuserCRLF 128 S: 130 5. Security Considerations 132 There is of course no assurance that the "nm_notifyuser" message is 133 being sent to the correct IP address. Nor does the listening agent 134 on the client system have any assurance that a "nm_notifyuser" 135 string was sent by a mail server which has received new mail for the 136 user. 138 It is trivial for an attacker to send large numbers of 139 "nm_notifyuser" messages to any targeted system. Client systems 140 listening for this message SHOULD implement protections against 141 being flooded with notifications. Many server systems already 142 implement protections against users logging in and checking mail too 143 frequently. 145 Since use of this protocol requires that a port be open with an 146 agent listening on it, if that agent contains vulnerabilities it may 147 create a remotely exploitable attack (for example, buffer overflows 148 permitting an attacker to execute arbitrary code on the client 149 system with the permissions of the agent). As usual with a process 150 listening on a port, the process should execute with the least 151 possible privelege level and access. 153 6. IANA Considerations 155 The notify mail hack (and this document) should be included as an 156 additional usage for port 79. 158 7. Acknowledgments 160 The NotifyMail shareware utility was written by Scott Gruby. 162 8. Normative References 164 None. 166 9. Informative References 168 None. 170 10. Author's Addresses 172 Randall Gellens 173 QUALCOMM Incorporated 174 6455 Lusk Blvd. 175 San Diego, CA 92121-2779 176 USA 177 randy@qualcomm.Com 179 Intellectual Property Statement 181 The IETF takes no position regarding the validity or scope of any 182 Intellectual Property Rights or other rights that might be claimed 183 to pertain to the implementation or use of the technology described 184 in this document or the extent to which any license under such 185 rights might or might not be available; nor does it represent that 186 it has made any independent effort to identify any such rights. 187 Information on the procedures with respect to rights in RFC 188 documents can be found in BCP 78 and BCP 79. 190 Copies of IPR disclosures made to the IETF Secretariat and any 191 assurances of licenses to be made available, or the result of an 192 attempt made to obtain a general license or permission for the use 193 of such proprietary rights by implementers or users of this 194 specification can be obtained from the IETF on-line IPR repository 195 at http://www.ietf.org/ipr. 197 The IETF invites any interested party to bring to its attention any 198 copyrights, patents or patent applications, or other proprietary 199 rights that may cover technology that may be required to implement 200 this standard. Please address the information to the IETF at 201 ietf-ipr@ietf.org. 203 Full Copyright Statement 205 Copyright (C) The Internet Society (2005). This document is subject 206 to the rights, licenses and restrictions contained in BCP 78, and 207 except as set forth therein, the authors retain all their rights. 209 Disclaimer 211 This document and the information contained herein are provided on 212 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 213 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 214 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 215 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 216 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 217 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.