Internet Message Access Protocol (IMAP) - URLAUTH Extension
RFC 4467

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

Network Working Group                                         M. Crispin
Request for Comments: 4467                      University of Washington
Updates: 3501                                                   May 2006
Category: Standards Track

      Internet Message Access Protocol (IMAP) - URLAUTH Extension

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes the URLAUTH extension to the Internet Message
   Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL)
   (RFC 2192).  This extension provides a means by which an IMAP client
   can use URLs carrying authorization to access limited message data on
   the IMAP server.

   An IMAP server that supports this extension indicates this with a
   capability name of "URLAUTH".

1.  Introduction

   In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20
   requires authorization as userid "fred".  However, [IMAPURL] implies
   that it only supports authentication and confuses the concepts of
   authentication and authorization.

   The URLAUTH extension defines an authorization mechanism for IMAP
   URLs to replace [IMAPURL]'s authentication-only mechanism.  URLAUTH
   conveys authorization in the URL string itself and reuses a portion
   of the syntax of the [IMAPURL] authentication mechanism to convey the
   authorization identity (which also defines the default namespace in
   [IMAP]).

   The URLAUTH extension provides a means by which an authorized user of
   an IMAP server can create URLAUTH-authorized IMAP URLs.  A URLAUTH-
   authorized URL conveys authorization (not authentication) to the data

Crispin                     Standards Track                     [Page 1]
RFC 4467                IMAP - URLAUTH Extension                May 2006

   addressed by that URL.  This URL can be used in another IMAP session
   to access specific content on the IMAP server, without otherwise
   providing authorization to any other data (such as other data in the
   mailbox specified in the URL) owned by the authorizing user.

   Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn
   ticket" that carries no authentication information and can be
   redeemed by whomever presents it.  However, unlike a pawn ticket,
   URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-
   authorized URL.  Using these mechanisms, URLAUTH-authorized URLs can
   be usable by:

      . anonymous (the "pawn ticket" model)
      . authenticated users only
      . a specific authenticated user only
      . message submission acting on behalf of a specific user only

   There is also a mechanism for expiration.

   A URLAUTH-authorized URL can be used in the argument to the BURL
   command in message composition, as described in [BURL], for such
   purposes as allowing a client (with limited memory or other
   resources) to submit a message forward or to resend from an IMAP
   mailbox without requiring the client to fetch that message data.

   The URLAUTH is generated using an authorization mechanism name and an
   authorization token, which is generated using a secret mailbox access
   key.  An IMAP client can request that the server generate and assign
   a new mailbox access key (thus effectively revoking all current URLs
   using URLAUTH with the old mailbox access key) but cannot set the
   mailbox access key to a key of its own choosing.

1.1.  Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as defined in [KEYWORDS].

   The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation
   including the core rules defined in Appendix A of [ABNF].

   In examples, "C:" and "S:" indicate lines sent by the client and
   server, respectively.  If a single "C:" or "S:" label applies to
   multiple lines, then the line breaks between those lines are for
   editorial clarity only and are not part of the actual protocol
   exchange.

Crispin                     Standards Track                     [Page 2]
RFC 4467                IMAP - URLAUTH Extension                May 2006

2.  Concepts

2.1.  URLAUTH

   The URLAUTH is a component, appended at the end of a URL, that
   conveys authorization to access the data addressed by that URL.  It
   contains an authorized access identifier, an authorization mechanism
   name, and an authorization token.  The authorization token is
   generated from the URL, the authorized access identifier, the
   authorization mechanism name, and a mailbox access key.

2.2.  Mailbox Access Key