Network Working Group I. Pank INTERNET-DRAFT DHL Worldwide Express March 1999 Expires September 1999 Self-Destruct E-mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract As e-mail use is becoming more prevalent and the applications of its use more diverse it is increasingly becoming a burden to users and system administration staff to maintain message stores and "weed-out" obsolete messages. The problem also manifests itself as a direct cost to organisations trying to maintain storage space for user e- mail messages where a considerable proportion of messages are simply forgotten and lay dormant. RFC 822 defines a message representation protocol specifying details about US-ASCII message headers. As an extension to this protocol this memo proposes the introduction of an additional header to enable e-mail messages to "self-destruct" after a specified period depending on a number of conditions that may have been specified by the originator or can subsequently be (re-)specified by the recipient. This memo also proposes possible client and server implementations with a view of soliciting feedback and further refining of the extensions. Pank Expires September 1999 [Page 1] INTERNET-DRAFT Self-Destruct E-mail March 1999 1. Introduction This memo defines a proposed extension to RFC 822 specifying an additional header to enable e-mail to "self-destruct". On occasion messages are sent to individuals or groups that have a pre-determined shelf-life due to their nature or content. The functionality afforded by this extension would enable housekeeping functions on messaging stores to identify messages with obsolete content by inspecting the self-destruct header to determine if a message has become "stale". The actions taken by the housekeeping function is an implementation issue and some possibilities are specified in section 4 - Server-side Implementation. 1.1 Intended operation To enable a message to self-destruct at least one parameter would be required specifying either an absolute date for destruction or the time period before destruction. Using two parameters would enable the "destruct 'n' days after reading" feature, see section 3 - Examples, for detailed information. 2. Extension Syntax A self-destruct header must be included with the message header for interpretation by the destination mail server. The header syntax, using Augmented Backus-Naur Form (ABNF) as used in RFC 822, is as follows self-destruct-header = "Self-Destruct" ":" destruct-spec destruct-spec = ( [destruct-timer]"," [(destruct-timer / destruct-date)] ) / ( [destruct-timer] / [destruct-date] ) destruct-timer = 1*DIGIT "d" / ; no. of days 1*DIGIT "w" / ; no. of weeks 1*DIGIT "m" / ; no. of months 1*DIGIT "y" / ; no. of years destruct-date = date ; absolute date date = 1*2DIGIT month 4DIGIT ; day month year ; e.g. 19 Mar 1999 Pank Expires September 1999 [Page 2] INTERNET-DRAFT Self-Destruct E-mail March 1999 month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" 3. Examples Self-Destruct information may be encoded in a number of ways; either using a timer or an absolute destruct date. The following examples show how this may be achieved. Self-Destruct: 3d / destruct in 3 days regardless Self-Destruct: 3d, / destruct 3 days after reading Self-Destruct: 7d,14d / destruct 7 days after reading / or 14 days regardless Self-Destruct: Fri Mar 19 1999 / destruct on specified date Self-Destruct: 7d,Fri Mar 19 1999 / destruct 7 days after reading / or on specified date 4. Server-side Implementation This may be implemented in a number of ways; either using a housekeeping robot that inspects messages on a daily basis or by collecting and storing a destruction information log each time a message with a "Self-Destruct" header is received which can then be used to provide an index to messages that may have expired. The latter may be more useful on mail servers that do not have an off- peak period where resource intensive robots cannot be used. Messages that have been marked for destruction can either be archived to alternative bulk storage media or to the users trashcan which in turn would be administered using implementation specific tools. 5. Client-side Implementation Client-side implementation is open to artistic licence. Messages that are due to expire can be displayed using display attributes or flagged if they are due to destruct within a specified period. GUI clients may be developed to display an icon alongside messages that are flagged for destruction together with a "progress" type indicator as a visual display indicating how far the message is into it's shelf-life. It would also be possible for clients to issue a delete command to the server if a message that has expired is encountered thus reducing the load on the server. Using this method the server-side daemon may be required to run on a less frequent basis. Pank Expires September 1999 [Page 3] INTERNET-DRAFT Self-Destruct E-mail March 1999 6. References [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. 7. Author's Address Indy Pank DHL Systems Limited Hounslow House 730 London Road Hounslow TW3 1PD, UK Phone: +44 181 607 4000 Fax: +44 181 607 4200 Email: ipank@lhr-sys.dhl.com Pank Expires September 1999 [Page 4]