Internet DRAFT - draft-jayantheesh-smtp-sentcopy
draft-jayantheesh-smtp-sentcopy
INTERNET-DRAFT Jayantheesh S B
Intended status: Standards Track Samsung
Expires: May 2015 Narendra Singh Bisht
Samsung
November 17, 2014
The SMTP SENTCOPY Extension
draft-jayantheesh-smtp-sentcopy-01
Abstract
This memo defines an extension to the SMTP service whereby a server can
advertise the extent of its ability to copy the emails, which are sent
by an IMAP email client to IMAP Sent folders automatically.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.
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 May, 2015.
Copyright Notice
Copyright (c) 2014 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.
Jayantheesh & Narendra Expires May, 2015 [Page 1]
Internet-Draft SMTP SENTCOPY November 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions and Terminology . . . . . . . . . . . . . . . 2
2. SENTCOPY Service Extension . . . . . . . . . . . . . . . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1 Normative References . . . . . . . . . . . . . . . . . . . . . 4
5.2 Informative References . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
Some of the SMTP servers have the ability to copy the emails which are
sent by the email client to the IMAP Sent mailbox automatically. But
this server capability is not advertised to the email client causes,
unnecessary copy of the same mail to IMAP Sent mailbox as well.
Especially in mobile device environment, copying the email twice
consumes unnecessary resources, like mobile data and battery power.
The SMTP SENTCOPY extension provides an ability to advertise, the SMTP
server capability, to the email client thus avoiding the unnecessary
copy of emails to IMAP Sent mailbox.
1.1 Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server. The five characters [...] means that something
has been elided.
2. SENTCOPY Service Extension
As of now whenever an email client sends an email, it has to send it to
the SMTP server as well as upload it to the Sent mailbox of IMAP server.
Some of the SMTP servers have the ability to copy the email sent by the
user to IMAP Sent mailbox also, thus avoiding unnecessary network
transaction. IMAP client cannot know this SMTP server capability unless
it is published as part of EHLO response.
SMTP server MAY have proprietary way of copying the mails or it MAY
follow any standard mechanism mentioned to copy the mails to IMAP Sent
folder. In both the cases, IMAP client SHOULD be notified to avoid
unnecessary copy of emails.
Jayantheesh & Narendra Expires May, 2015 [Page 2]
Internet-Draft SMTP SENTCOPY November 2014
By this way, mail client SHALL easily identify the capabilities of the
SMTP server and avoid uploading the same emails to IMAP Sent mailbox.
The Command SENTCOPY extension is defined as follows:
(1) The name of the SMTP service extension is Sentcopy;
(2) The EHLO keyword value associated with the extension is
SENTCOPY;
(3) No parameter is used with the SENTCOPY EHLO keyword;
When a client wishes to send email, it first issues the EHLO command to
the SMTP server. If the SMTP server responds with code 250 to the EHLO
command and the response includes the EHLO keyword value SENTCOPY, then
the SMTP server has indicated that it has the ability to perform the
copy of emails to IMAP Sent mailbox. By looking at the keyword, client
can avoid doing the copy operation to IMAP Sent mailbox.
Example of SENTCOPY supported SMTP EHLO response
C: EHLO example.com
S: 250-example.com says hello
S: 250-SIZE 35882577
S: 250-8BITMIME
S: 250-PIPELINING
S: 250-CHUNKING
S: 250-SENTCOPY
S: ...
Especially in the mobile device environment, copying the same email
twice consumes more device resources like device battery power and
mobile data. This SHALL be avoided by publishing the SMTP capability
"SENTCOPY" to the email client. Irrespective of the server side
implementation, email client shall easily identify and ignore the
duplicate copy of emails.
3. Security Consideration
This document does not add any new security considerations to SMTP.
4. IANA Considerations
The IANA is requested to add SENTCOPY to the SMTP Capabilities
Registry.
Jayantheesh & Narendra Expires May, 2015 [Page 3]
Internet-Draft SMTP SENTCOPY November 2014
5. References
5.1 Normative References
The following documents contain definitions or specifications that
are necessary to understand this document properly
[RFC5321] J. Klensin, "Simple Mail Transfer Protocol", AT&T
Laboratories, October 2008
[RFC4468] C. Newman, "Message Submission BURL Extension",
Sun Microsystems, May 2006
5. 2 Informative References
The following documents describe related protocols:
[RFC4467] M. Crispin, "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", University of Washington, May 2006
[RFC3501] Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
University of Washington, March 2003
6. Acknowledgement
TBD
7. Author's Address
Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb@gmail.com
Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht@gmail.com
Jayantheesh & Narendra Expires May, 2015 [Page 4]
