INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT Network Working Group T. Tornkvist INTERNET-DRAFT SERC, Melbourne 11 January 1998 Notification - An extension to the Post Office Protocol version 3 Abstract This memo describes an optional extension to the Post Office Protocol version 3 (POP3), which introduces a possibility for a POP3 client to be notified by a POP3 server whenever the clients mail-drop is accessed. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Table of Contents 1. Conventions Used in this Document .......................... 1 2. Introduction ............................................... 2 3. Operation .................................................. 2 4. NTFY Sent by the Client .................................... 3 5. NTFY Sent by the Server .................................... 4 6. Alteration to the UPDATE State ............................. 4 7. New capabilities ........................................... 5 8. Security Considerations .................................... 5 9. References ................................................. 6 10. Author's address ........................................... 6 1. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", Tornkvist [Page 1] INTERNET DRAFT Notification - An extension to POP3 11 December 1998 and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 2. Introduction The Post Office Protocol version 3, as described in [POP3], is a simple and low-cost method of enabling mail access. The host making use of the POP3 service is referred to here as the "client", and the host providing the service as the "server". When a client wants to retrieve mail from a server, a TCP connection to the server is established. The client then uses various POP3 commands to access the mail-drop. Thus every time a client wants to check for new mail he has to poll the server. For a mail-drop which seldom receives new mails this is obvious not economical. It may also be a security issue since repeated attempts to access the server are more vulnerable to interception. This memo tries to remedy this by introducing the concept of notification, and describes how a client can request that the server shall notify the client when any changes have been made to the clients mail-drop. 3. Operation Two new POP3 command named NTFY and +NTFY are added. The NTFY command is used by the client in order to request the server that it should notify the client whenever the clients mail-drop is accessed. The +NTFY command is used by the server to notify a client that the clients mail-drop has been accessed. After the server has sent a +NTFY command, both the client and the server MUST enter the AUTHORIZATION state, as described in [POP3]. As soon as a server tries to establish a TCP connection to be used for notification, it also removes the request for notification. It is up to the client to issue a new NTFY command if he wants to be notified again. The client can only issue the NTFY command in the TRANSACTION state. A request for notification will not be activated until the POP3 session enters the UPDATE state. During the TRANSACTION state it is possible to cancel the request for notification as described in the chapter: "NTFY Sent by the Client". Tornkvist [Page 2] INTERNET DRAFT Notification - An extension to POP3 11 December 1998 4. NTFY Sent by the Client This command can only be sent when the client is in the TRANSACTION state. NTFY timeout [hostname port-number [timestamp]] Arguments: a timeout value in minutes, specified as an integer, greater or equal to zero, an optional hostname and port-number that specifies where to deliver the notification, an optional timestamp to be used as an APOP challenge Restrictions: may only be given in the TRANSACTION state Discussion: The POP3 server issues a positive response if requests for notification can be serviced. The timeout value specifies for how long time the server shall maintain the request for notification. A timeout value of zero shall remove any existing request for notification at the server. A server shall only store one request per user. Hence, a zero timeout value need not be accompanied by any other argument. As a result of this, a request for notification should not be activated until the POP3 session enters the UPDATE state. A server which implements this command must be able to serve timeout values ranging from 0 - 255. However, by using the capability extension [CAPA], a server may however announce a greater maximim value for the timeout (see also the chapter: "New Capabilities"). A negative timeout value should result in an error response. If APOP authentication is to be used. A challenge timestamp can be include as the last argument. Later, when the server issues the notification, it sends the corrsponding digest message (see also the description of +NTFY command and the chapter: "Security Considerations"). Possible Responses: +OK -ERR Tornkvist [Page 3] INTERNET DRAFT Notification - An extension to POP3 11 December 1998 Examples: C: NTFY 60 campari.rmit.edu.au 9411 S: +OK Request for notification accepted C: NTFY 300 campari.rmit.edu.au 9411 S: -ERR Timeout value too big C: NTFY 255 campari.rmit.edu.au 9411 S: +OK Request for notification accepted C: NTFY 0 S: +OK Request for notification removed 5. +NTFY Sent by the Server When a client is to be notified about changes made to his mail-drop, the server establish a TCP connection to the specified host and port number. As soon this is done, the request for notification is erased from the server. This is done regardless if the connection was successful or not. +NTFY name [digest] Arguments: A name, specifying the mail-drop in question, and if APOP authentication is to be used, a digest argument. Restrictions: Only one attempt to contact the client will be made. Discussion: As soon the server has sent this command, both the client and the server are supposed to enter the AUTHORIZATION state. The digest argument shall correspond to the msg-id sent by the client in a preceding NTFY command. Examples: S: +NTFY mrose c4c9334bac560ecc979e58001b3e22fb 6. Alteration to the UPDATE State A server which has received a request for notification shall not make it valid until the UPDATE state has been entered. This is needed so that a client can change or clear a request for notification previously done in the same POP3 session. Tornkvist [Page 4] INTERNET DRAFT Notification - An extension to POP3 11 December 1998 7. New capabilities For those servers which implements capabilities [CAPA]. The following new capability SHOULD be used. CAPA tag: NTFY capability Arguments: The maximum timeout value the server will maintain a request for notification. Added commands: NTFY +NTFY Standard commands affected: none Announced states / possible differences: both / no Commands valid in states: TRANSACTION Specific reference: this document Discussion: The NTFY capability indicates that the server implements the method described in this memo for handling request for notification. The timeout value returned is the maximum time in minutes the server will maintain such a request. A server MUST at least be able to maintain a request for notification for 255 minutes. 8. Security Considerations After a client has been notified by a server, the session MUST enter the AUTHORIZATION state. The main reason for this is to not introduce a new method for POP3 authentication. Ways to perform POP3 authentication is described in [POP3], [POP-AUTH] and [SASL]. NB: When APOP is used for authentication, it is important that a client really check that the digest, sent from the server in the +NTFY command, really match the challenge most previously sent by the client. This MUST be done in order to avoid possible masquerade Tornkvist [Page 5] INTERNET DRAFT Notification - An extension to POP3 11 December 1998 attacks, where an attacker may have obtained the host and port information (e.g by sniffing earlier packets being sent). 9. References [CAPA] Gellens, R. and Newman, C. and Lundblade, L. "POP3 Extension Mechanism", RFC 2449, Nov-1998. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. 10. Author's address Torbjorn Tornkvist SERC (Software Engineering Research Center) 110 Victoria St, Carlton Victoria 3053 AUSTRALIA Phone: +61 3 9925 4089 Fax: +61 3 9925 4094 Email: tobbe@serc.rmit.edu.au Tornkvist [Page 6] INTERNET DRAFT EXPIRES JULY 1999 INTERNET DRAFT