idnits 2.17.1 draft-tornkvist-pop3-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... server whene...' == Line 18 has weird spacing: '...ment is an I...' == Line 19 has weird spacing: '...cuments of t...' == Line 20 has weird spacing: '...ups may also ...' == Line 24 has weird spacing: '... and may be...' == (4 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (11 January 1998) is 9602 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) ** Obsolete normative reference: RFC 1734 (ref. 'POP-AUTH') (Obsoleted by RFC 5034) ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT 2 Network Working Group T. Tornkvist 3 INTERNET-DRAFT SERC, Melbourne 4 11 January 1998 6 Notification - An extension to the Post Office Protocol version 3 7 9 Abstract 11 This memo describes an optional extension to the Post Office Protocol 12 version 3 (POP3), which introduces a possibility for a POP3 client to 13 be notified by a POP3 server whenever the clients mail-drop is 14 accessed. 16 Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Table of Contents 36 1. Conventions Used in this Document .......................... 1 37 2. Introduction ............................................... 2 38 3. Operation .................................................. 2 39 4. NTFY Sent by the Client .................................... 3 40 5. NTFY Sent by the Server .................................... 4 41 6. Alteration to the UPDATE State ............................. 4 42 7. New capabilities ........................................... 5 43 8. Security Considerations .................................... 5 44 9. References ................................................. 6 45 10. Author's address ........................................... 6 47 1. Conventions Used in this Document 49 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 50 and "MAY" in this document are to be interpreted as described in "Key 51 words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 53 In examples, "C:" and "S:" indicate lines sent by the client and 54 server respectively. 56 2. Introduction 58 The Post Office Protocol version 3, as described in [POP3], is a 59 simple and low-cost method of enabling mail access. The host making 60 use of the POP3 service is referred to here as the "client", and 61 the host providing the service as the "server". When a client 62 wants to retrieve mail from a server, a TCP connection to the 63 server is established. The client then uses various POP3 commands to 64 access the mail-drop. Thus every time a client wants to check for 65 new mail he has to poll the server. For a mail-drop 66 which seldom receives new mails this is obvious not economical. 67 It may also be a security issue since repeated attempts to 68 access the server are more vulnerable to interception. This 69 memo tries to remedy this by introducing the concept of notification, 70 and describes how a client can request that the server shall 71 notify the client when any changes have been made to the clients 72 mail-drop. 74 3. Operation 76 Two new POP3 command named NTFY and +NTFY are added. The NTFY 77 command is used by the client in order to request the server that 78 it should notify the client whenever the clients mail-drop is 79 accessed. The +NTFY command is used by the server to notify a 80 client that the clients mail-drop has been accessed. 82 After the server has sent a +NTFY command, both the client and 83 the server MUST enter the AUTHORIZATION state, as described in 84 [POP3]. 86 As soon as a server tries to establish a TCP connection to be 87 used for notification, it also removes the request for notification. 88 It is up to the client to issue a new NTFY command if he wants 89 to be notified again. 91 The client can only issue the NTFY command in the TRANSACTION state. 93 A request for notification will not be activated until the 94 POP3 session enters the UPDATE state. During the TRANSACTION 95 state it is possible to cancel the request for notification as 96 described in the chapter: "NTFY Sent by the Client". 98 4. NTFY Sent by the Client 100 This command can only be sent when the client is in the TRANSACTION 101 state. 103 NTFY timeout [hostname port-number [timestamp]] 105 Arguments: 106 a timeout value in minutes, specified as an integer, 107 greater or equal to zero, an optional hostname and 108 port-number that specifies where to deliver the 109 notification, an optional timestamp to be used as 110 an APOP challenge 112 Restrictions: 113 may only be given in the TRANSACTION state 115 Discussion: 116 The POP3 server issues a positive response if requests 117 for notification can be serviced. The timeout value 118 specifies for how long time the server shall maintain 119 the request for notification. A timeout value of zero 120 shall remove any existing request for notification at 121 the server. 123 A server shall only store one request per user. Hence, 124 a zero timeout value need not be accompanied by any other 125 argument. As a result of this, a request for notification 126 should not be activated until the POP3 session enters the 127 UPDATE state. 129 A server which implements this command must be able to 130 serve timeout values ranging from 0 - 255. However, by 131 using the capability extension [CAPA], a server may however 132 announce a greater maximim value for the timeout (see also 133 the chapter: "New Capabilities"). A negative timeout value 134 should result in an error response. 136 If APOP authentication is to be used. A challenge timestamp 137 can be include as the last argument. Later, when the server 138 issues the notification, it sends the corrsponding digest 139 message (see also the description of +NTFY command and the 140 chapter: "Security Considerations"). 142 Possible Responses: 143 +OK 144 -ERR 146 Examples: 147 C: NTFY 60 campari.rmit.edu.au 9411 148 S: +OK Request for notification accepted 150 C: NTFY 300 campari.rmit.edu.au 9411 151 S: -ERR Timeout value too big 152 C: NTFY 255 campari.rmit.edu.au 9411 153 S: +OK Request for notification accepted 155 C: NTFY 0 156 S: +OK Request for notification removed 158 5. +NTFY Sent by the Server 160 When a client is to be notified about changes made to his mail-drop, 161 the server establish a TCP connection to the specified host and port 162 number. As soon this is done, the request for notification is erased 163 from the server. This is done regardless if the connection was 164 successful or not. 166 +NTFY name [digest] 168 Arguments: 169 A name, specifying the mail-drop in question, and 170 if APOP authentication is to be used, a digest 171 argument. 173 Restrictions: 174 Only one attempt to contact the client will be made. 176 Discussion: 177 As soon the server has sent this command, both the 178 client and the server are supposed to enter the 179 AUTHORIZATION state. The digest argument shall correspond 180 to the msg-id sent by the client in a preceding NTFY 181 command. 183 Examples: 184 S: +NTFY mrose c4c9334bac560ecc979e58001b3e22fb 186 6. Alteration to the UPDATE State 188 A server which has received a request for notification shall not 189 make it valid until the UPDATE state has been entered. This is 190 needed so that a client can change or clear a request for 191 notification previously done in the same POP3 session. 193 7. New capabilities 195 For those servers which implements capabilities [CAPA]. The 196 following new capability SHOULD be used. 198 CAPA tag: 199 NTFY capability 201 Arguments: 202 The maximum timeout value the server will 203 maintain a request for notification. 205 Added commands: 206 NTFY 207 +NTFY 209 Standard commands affected: 210 none 212 Announced states / possible differences: 213 both / no 215 Commands valid in states: 216 TRANSACTION 218 Specific reference: 219 this document 221 Discussion: 222 The NTFY capability indicates that the server implements 223 the method described in this memo for handling request 224 for notification. The timeout value returned is the maximum 225 time in minutes the server will maintain such a request. 226 A server MUST at least be able to maintain a request for 227 notification for 255 minutes. 229 8. Security Considerations 231 After a client has been notified by a server, the session MUST 232 enter the AUTHORIZATION state. The main reason for this is to 233 not introduce a new method for POP3 authentication. Ways 234 to perform POP3 authentication is described in [POP3], [POP-AUTH] 235 and [SASL]. 237 NB: When APOP is used for authentication, it is important that a 238 client really check that the digest, sent from the server in the 239 +NTFY command, really match the challenge most previously sent by 240 the client. This MUST be done in order to avoid possible masquerade 241 attacks, where an attacker may have obtained the host and port 242 information (e.g by sniffing earlier packets being sent). 244 9. References 246 [CAPA] Gellens, R. and Newman, C. and Lundblade, L. 247 "POP3 Extension Mechanism", RFC 2449, Nov-1998. 249 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, March 1997. 252 [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 253 3", STD 53, RFC 1939, May 1996. 255 [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, 256 December 1994. 258 [SASL] Myers, J., "Simple Authentication and Security Layer 259 (SASL)", RFC 2222, October 1997. 261 10. Author's address 263 Torbjorn Tornkvist 264 SERC (Software Engineering Research Center) 265 110 Victoria St, Carlton 266 Victoria 3053 267 AUSTRALIA 269 Phone: +61 3 9925 4089 270 Fax: +61 3 9925 4094 271 Email: tobbe@serc.rmit.edu.au