idnits 2.17.1 draft-gellens-notify-mail-00.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.5 on line 186. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 172), 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) 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 : ---------------------------------------------------------------------------- No issues found here. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2004) is 7219 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: 8 errors (**), 0 flaws (~~), 3 warnings (==), 3 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-00.txt QUALCOMM 4 Expires: January 2005 July 2004 6 Simple New Mail Notification 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed 12 and any of which I become aware will be disclosed, in accordance 13 with RFC 3668 (BCP 79). 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 (2004). 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" 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. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 58 7. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 8. Informative References . . . . . . . . . . . . . . . . . . . . 4 60 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 5 61 Intellectual Property Statement . . . . . . . . . . . . . . . . 5 62 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 5 63 Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 There is a long-standing technique supported by a large number of 68 mail servers which allows users to be notified of new mail. In 69 addition to server support, there are a number of clients which 70 support this, ranging from full email clients to specialized clients 71 whose only purpose is to receive new mail notifications and alert a 72 mail client. This technique is sometimes known as "notify mail" 73 (after a shareware client of the same name), sometimes called 74 "biff", and sometimes the "finger hack". 76 2. Conventions Used in this Document 78 In examples, "C:" is used to indicate lines sent by the client, and 79 "S:" indicates those sent by the server. Line breaks within a 80 command example are for editorial purposes only. 82 Examples use the 'example.net' domain. 84 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 85 in this document are to be interpreted as defined in [KEYWORDS]. 87 3. Simple Mail Notification 89 The technique is for the server to send the string "nm_notifyuser" 90 to the finger port on the IP address for the user who has received 91 new mail. 93 The IP address to use may be configured, or the server may use the 94 IP address that was last used to check mail by the user. Typically 95 this is a per-account configuration option. 97 To be useful, on the client system a process must be listening to 98 the finger port. When it received the "nm_notifyuser" string, it 99 takes a configured action, typically instructing a mail client to 100 fetch mail. 102 Normally, the a TCP connection to the target computer is opened, the 103 "nm_notifyuser" string is sent, and the connection is closed without 104 waiting for any response. 106 In some cases UDP is used instead of TCP. 108 4. Security Considerations 110 There is of course no assurance that in general the "nm_notifyuser" 111 message is being sent to the correct IP address. Nor does the 112 listening agent on the client system have any assurance that a 113 "nm_notifyuser" string was sent by a mail server which has received 114 new mail for the user. It would be trivial for an attacker to send 115 large numbers of "nm_notifyuser" messages to any targeted system. 116 Client systems listening for this message SHOULD implement 117 protections against being flooded with notifications. Many server 118 systems already implement protections against users logging in and 119 checking mail too frequently. 121 5. IANA Considerations 123 None at this time. 125 6. Acknowledgments 127 The NotifyMail shareware utility was written by Scott Gruby. 129 7. Normative References 131 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 132 Requirement Levels", March 1997, BCP 14, RFC 2119, 133 135 8. Informative References 137 None. 139 9. Author's Addresses 141 Randall Gellens 142 QUALCOMM Incorporated 143 6455 Lusk Blvd. 144 San Diego, CA 92121-2779 145 USA 146 randy@qualcomm.Com 148 Intellectual Property Statement 150 The IETF takes no position regarding the validity or scope of any 151 intellectual property or other rights that might be claimed to 152 pertain to the implementation or use of the technology described in 153 this document or the extent to which any license under such rights 154 might or might not be available; neither does it represent that it 155 has made any effort to identify any such rights. Information on the 156 IETF's procedures with respect to rights in standards-track and 157 standards-related documentation can be found in BCP-11. Copies of 158 claims of rights made available for publication and any assurances 159 of licenses to be made available, or the result of an attempt made 160 to obtain a general license or permission for the use of such 161 proprietary rights by implementors or users of this specification 162 can be obtained from the IETF Secretariat. 164 The IETF invites any interested party to bring to its attention any 165 copyrights, patents or patent applications, or other proprietary 166 rights which may cover technology that may be required to practice 167 this standard. Please address the information to the IETF Executive 168 Director. 170 Full Copyright Statement 172 Copyright (C) The Internet Society (2004). 174 This document is subject to the rights, licenses and restrictions 175 contained in BCP 78, and except as set forth therein, the authors 176 retain all their rights. 178 Disclaimer 180 This document and the information contained herein are provided on 181 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 182 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 183 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 184 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 185 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 186 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.