Network Working Group D.M. Royer 
<draft-royer-lemonade-submit-01>  14 June 2003 
Category: Informational  
Expires: 14 December 2003  

IMAP-PROXY service for mobile clients to do submitting and forwarding

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.

This Internet-Draft will expire on 14 December 2003.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.


This memo describes a method that allows mobile clients to use the IMAP protocol and submit messages to a IMAP-PROXY service that understands [E]SMTP and IMAP.


As many mobile devices are both memory and bandwidth limited there needs to be a way for mobile devices to forward and include existing messages and body parts to others using email without downloading.

This is a memo released as part of the discussions on the 'LEMONADE' working group. The idea is that a IMAP-PROXY service can sit on top of an IMAP and [E]SMTP server in order to allow mobile devices the ability to submit and retrieve e-mail through one port.

The basic idea is that the IMAP aware client sends normal IMAP commands to the IMAP server and gets normal IMAP responses. The IMAP client can not tell that it is passing through a IMAP-PROXY and submit service.

How the messages and body part are included is not described in the memo. The memo concentrates on the IMAP-PROXY service itself at the functional level.

IMAP-PROXY servers that support this extension MUST list the keyword CAN-SUBMIT in their CAPABILITY response. No client action is needed to invoke the CAN-SUBMIT capability in a server.


The IMAP-PROXY service sits on top of both IMAP and and SMTP service.

               +---------+  +---------+
               | STANDARD|  | SUBMIT  |
               | IMAP    |  | IMAP    |
               | CLIENT  |  | CLIENT  |
               +---------+  +---------+
                    \           /
                     \         /
                      .       .
                       .     .
                    |  PROXY   |
                      /      \
                     /        \
                    |          |
                 +------+   +------+
                 | IMAP |   | SMTP |
                 |SERVER|   |SERVER|
                 +------+   +------+

The IMAP-PROXY passes all IMAP commands (except SUBMIT) to the IMAP server and passes all IMAP responses back to both the standard and submit IMAP clients.

The SUBMIT command is intercepted by the IMAP-PROXY server. It reads the contents of the message sent by the submit aware IMAP client, includes or forward any messages as specified in the content of the submit message. And send SUBMIT responses back to the SUBMIT aware client.

3SUBMIT command

Arguments:  message literal

Responses:  no specific responses for this command

Result:     OK - append completed
            NO - append error: can't send message.
            BAD - command unknown or arguments invalid

The SUBMIT command submits the literal argument as a new message to the users specified in the message. This argument MUST be in the format of an [RFC-822] message. 8-bit characters are permitted in the message. A server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit SUBMIT data to 7-bit using a [MIME-IMB] content transfer encoding.

The IMAP-PROXY service may check and alter the SMTP headers to ensure they conform to site requirements. This may include making sure the 'From:' line is valid within the site. Might include replacing the Message-Id, removing any Received-By lines, Date, and so on.

A successful submit simply means that the SMTP server accepted all recipients and the message for submission. Just like with any other SMTP submission recipient errors will bounce back to the users INBOX.

Example:    C: A003 SUBMIT {356}
            C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
            C: From: Fred Foobar <foobar@Blurdybloop.COM>
            C: Subject: afternoon meeting
            C: To: mooch@owatagu.siam.edu,badUser@example.com,
            C: Message-Id: <B27397-0100000@Blurdybloop.COM>
            C: MIME-Version: 1.0
            C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
            C: Hello Joe, do you think we can meet at 3:30 tomorrow?
            S: A003 OK SUBMIT completed

If there is an SMTP error the IMAP-PROXY service returns any message followed by any unacceptable recipients. The message is a comma separated string with the non-recipient errors listed first followed by one or more recipients that are invalid. A NO response indicates that no message was sent to any recipient.

This example two users were rejected. The first message
section is empty (message starts with a comma).

S: A123 NO ,badUser@example.com,unknownUser@example.com

An error message not specific to any user. The non
recipient part of the message must not include a comma
as a comma separates the parts of the error message.
And the comma is not part of the message itself.

S: A445 NO MX server not responding,

4CAPABILITY interception

The IMAP-PROXY intercepts the CAPABILITY response from the IMAP server and adds the CAN-SUBMIT capability to the list.

Author's Address

 Doug Royer
 1795 W. Broadway #266

 Idaho Falls, Idaho 83402
Phone: 208-520-4044
Fax: 866-594-8574
EMail: Doug@Royer.com
URI: http://Royer.com/People/Doug

Full Copyright Statement