Internet Message Access Protocol (IMAP) - SAVEDATE Extension
draft-ietf-extra-imap-savedate-01
EXTRA S. Bosch
Internet-Draft Dovecot Oy
Intended status: Standards Track May 4, 2018
Expires: November 5, 2018
Internet Message Access Protocol (IMAP) - SAVEDATE Extension
draft-ietf-extra-imap-savedate-01
Abstract
This document adds a new capability called "SAVEDATE" to the Internet
Message Access Protocol (IMAP). It defines a new IMAP message
attribute called 'save date' that, unlike the existing 'internal
date' attribute, always indicates the moment at which the message was
saved in its current mailbox. The SAVEDATE capability extends the
FETCH command with the means to retrieve the save date attribute and
it extends the SEARCH command to allow using that attribute in
searching criteria.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 5, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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
Bosch Expires November 5, 2018 [Page 1]
Internet-Draft IMAP - SAVEDATE Extension May 2018
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Save Date Message Attribute . . . . . . . . . . . . . . . . . 3
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4
4.1. CAPABILITY Identification . . . . . . . . . . . . . . . . 4
4.2. FETCH Command and Response Extensions . . . . . . . . . . 4
4.3. SEARCH Command Extension . . . . . . . . . . . . . . . . 4
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
This document extends Internet Message Access Protocol (IMAP)
[IMAP4rev1] with a new capability called "SAVEDATE". This capability
adds a new IMAP message attribute called 'save date'. The save date
is the date and time at which a message was saved in the mailbox it
currently resides. The save date is similar to the existing internal
date attribute in that it is set at the time of delivery. However,
the internal date attribute can be set to an arbitrary value for
messages delivered to the mailbox using the APPEND command and it is
usually copied from the source message for messages delivered using
the COPY command. In contrast, the save date attribute is always set
to the current date and time at the moment the message is saved in
the mailbox, irrespective of how the message is delivered and from
where it originates.
The save date message attribute is useful for implementing automated
removal of messages from a mailbox after a configured amount of time.
For that application, it is necessary to know when the message was
saved in the mailbox, which cannot be reliably determined using the
the internal date attribute.
For example, a common client usage pattern is to move deleted
messages to a Trash mailbox; these messages are considered "deleted"
at the time they are moved to the Trash mailbox. In an effort to
limit the size of the Trash mailbox, a client may subsequently desire
to permanently remove (expunge) all messages in that Trash mailbox
deleted before a certain time (e.g. a configurable expiration
Show full document text