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
<draft-tornkvist-pop3-01.txt>
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