Network Working Group | D.M. Royer |
INTERNET DRAFT | INET-Consulting |
<draft-royer-lemonade-submit-01> | 14 June 2003 |
Category: Informational | |
Expires: 14 December 2003 |
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 (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.
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, unknownUser@example.com C: Message-Id: <B27397-0100000@Blurdybloop.COM> C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: 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,
The IMAP-PROXY intercepts the CAPABILITY response from the IMAP server and adds the CAN-SUBMIT capability to the list.
Doug Royer | |
INET-Consulting.com | |
1795 W. Broadway #266 | |
Idaho Falls, Idaho 83402 | |
US | |
Phone: | 208-520-4044 |
Fax: | 866-594-8574 |
EMail: | Doug@Royer.com |
URI: | http://Royer.com/People/Doug |
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC editor function is currently provided by the Internet Society.