#include "standard_disclaimer.h" This document is placed under CC BY-SA 3.0 by the authors. The IETFNG is not the IETF. If you were somehow confused, we apologize. Go ahead and implement this in your favorite MUA if you want. ------------------------------------------------------------------------ Network Working Group A. Laroia Internet-Draft J. Stumpo Intended status: Informational Johns Hopkins ACM Expires: October 3, 2010 April 1, 2010 Cosmetic Carbon Copy draft-jhuacm-cosmetic-carbon-copy-01 Abstract Electronic mail has a facility for sending extra copies of a message to recipients that are not disclosed to the other recipients (blind carbon copy), but the inverse functionality, that of making it appear that certain recipients received the message but not actually sending it to them, is left out. This document defines a message header to facilitate the latter. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 October 3, 2010. Copyright Notice Copyright (c) 2010 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 Laroia & Stumpo Expires October 3, 2010 [Page 1] Internet-Draft Cosmetic Carbon Copy April 2010 (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 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 BSD License. 1. Introduction 1.1. Rationale One of the most powerful features of electronic mail is the ability to easily send copies of the same message to multiple users. For specifying recipients, there are the To:, Cc:, and Bcc: headers defined by [RFC5322], allowing, respectively, primary, secondary, and undisclosed recipients to be specified in the message. One can consider the relationship of Bcc: to Cc: by viewing it as providing the functionality of Cc: (specifying extra, incidental recipients, who are listed in the message headers) minus the listing in the headers. It is perfectly natural to want to consider the opposite relationship: specifying extra recipients in the message headers without actually sending a copy to them. Therefore, a header must be defined for that set of functionality, which is the purpose of this document. 1.2. Notational Conventions This document occasionally uses the terms "MUST", "SHOULD", "RECOMMENDED", "SHOULD NOT", "MUST NOT", and "MAY" in all capital letters. When these terms appear in this manner, they carry the meanings specified in [RFC2119]. This document also uses the notation specified in [RFC2234] to specify the syntax of the message headers that it defines. A Mail User Agent (MUA) is a software component that allows a user to compose new messages, submit messages to a message delivery infrastructure, and retrieve messages delivered to the user's mailbox. 2. The Ccc: Header Laroia & Stumpo Expires October 3, 2010 [Page 2] Internet-Draft Cosmetic Carbon Copy April 2010 2.1. Purpose To implement the inverse functionality to the Bcc: header (Blind Carbon Copy), this document specifies the Ccc: header (Cosmetic Carbon Copy), which mentions the specified recipients in the message headers but does not actually send copies of the message to them. Like the Bcc: header, the Ccc: header is almost entirely an MUA-level idea - it never is included as-is in the resulting submitted message, as this would defeat the purpose of the header. 2.2. Syntax The Ccc: header contains a list of addresses just as the To:, Cc:, and Bcc: headers do. Formally, the syntax is the following: ccc = "Ccc:" (address-list / [CFWS]) CRLF The definitions of "CFWS" and "address-list" are those of [RFC5322]. The Ccc: header may also be folded and commented as allowed therein. 2.3. Handling When a message is composed in an MUA supporting Cosmetic Carbon Copy and the user places recipients into the Ccc: header, the MUA takes the following actions when the message is sent: o The MUA builds the list of recipients to which it will submit the message for delivery based on the To:, Cc:, and Bcc: headers, as specified by [RFC5322]. o The MUA rewrites the Cc: header so that it contains the union of the list of mailboxes specified in the Cc: and Ccc: headers. If there is no Cc: header, a blank one is assumed. This MUST occur only after the other headers are processed to decide who will receive copies of the message. MUAs SHOULD prompt the user for confirmation if any Ccc:'d recipients are going to receive a copy of the message anyway due to inclusion in another header. Additionally, when rewriting the Cc: header, MUAs MAY subtly obfuscate addresses that came from the Ccc: header so that they are still clearly recognizable to a human but will not work if an attempt is made to send a message to them without reversing the obfuscation. There are trade-offs involved in electing to do so or not do so (see Section 4 for more details), so MUAs SHOULD document whether they do so by default and SHOULD provide an option for choosing whether obfuscation is performed. o The MUA removes the Ccc: header or MAY rewrite it to be blank if it wishes to indicate that at least one Cc:'d recipient was Laroia & Stumpo Expires October 3, 2010 [Page 3] Internet-Draft Cosmetic Carbon Copy April 2010 actually a Ccc:. MUAs MUST NOT exercise the latter option if the Cc:/Ccc: mangling resulted in a Cc: header containing only one recipient, as this leaves little ambiguity as to the fate of the message with regard to that recipient. For similar reasons, MUAs SHOULD prompt the user for confirmation if exercising the latter option, especially if few recipients end up in the rewritten Cc: header. (See Section 4 for a detailed explanation of this information leak.) Either way, in the message that is actually submitted, if a Ccc: header is present, it MUST NOT actually contain recipients. The MUA then submits the rewritten message for delivery to the list of recipients that it built in the first step. 2.4. Example Suppose that Alice wishes to invite her friend Bob to see a movie. Alice finds it acceptable for Bob to invite some of his friends to the movie as well, but would rather not have Charlie there. Alice composes the following message: From: alice@example.com To: bob@example.com Ccc: charlie@example.com Subject: MOOOVIEEE! Hey all my friends, join me for a movie tonight! When Alice sends the message, her MUA submits the message for delivery to Bob but not Charlie, and the submitted message resembles the following: From: alice@example.com To: bob@example.com Cc: charlie@example.com Subject: MOOOVIEEE! Hey all my friends, join me for a movie tonight! (Note carefully that the Ccc: header has been replaced with a Cc: header. If the message as composed by Alice had a genuine Cc: header of its own, the lists of recipients in both the Cc: and Ccc: headers would have been merged as specified above.) Suppose that Bob receives the message and wishes to invite Charlie and Daniel as well. Bob assumes Charlie already received a copy of the message by virtue of being in the Cc: header, so he forwards the Laroia & Stumpo Expires October 3, 2010 [Page 4] Internet-Draft Cosmetic Carbon Copy April 2010 message to Daniel only. Daniel receives something like the following: From: bob@example.com To: daniel@example.com Subject: Fwd: MOOOVIEEE! --- Forwarded message --- From: alice@example.com To: bob@example.com Cc: charlie@example.com Subject: MOOOVIEEE! Hey all my friends, join me for a movie tonight! Therefore, even Daniel believes that Charlie already knows about Alice's and Bob's plans. In the end, when the night comes around, Alice, Bob, and Daniel will meet at the movie theater without Charlie, and Alice will secretly sigh in relief. 3. IANA Considerations The following registration shall be made in IANA's Permanent Message Header Field Registry: Header Field Name: Ccc Protocol: mail Status: standard Reference: (this document) 4. Security Considerations If a real recipient of a message that had a Ccc:'d recipient replies to it using reply-to-all, the Ccc:'d recipient will receive a copy of the reply and therefore realize that he or she has been left out of the loop. This is because Ccc:'d recipients are placed into the Cc: header in the message that is actually submitted. Obfuscation of Ccc:'d addresses mitigates this problem somewhat but leaks information about who really received the message and who did not; in particular, somebody replying-to-all on a message that uses such obfuscation is made well aware of who is being kept out because the copies of the reply that would otherwise go to them will bounce. One must carefully weigh the relative benefits and drawbacks of preserving the inability to distinguish Ccc:'d recipients from genuinely Cc:'d recipients versus having the system work even in the face of reply-to-all before deciding whether obfuscation of Ccc:'d Laroia & Stumpo Expires October 3, 2010 [Page 5] Internet-Draft Cosmetic Carbon Copy April 2010 addresses is appropriate for the situation at hand. A noteworthy point about reply-to-all is that it is often considered to be evil, so if the MUA of the user replying-to-all properly implements [RFC3514] and sets the evil bit on the packets involved, RFC3514- compliant systems will ignore the packets, and all will be well. Note that because CCC is analogous to BCC, which is considered standard practice and therefore not evil despite constituting for all practical purposes a lie by omission, messages that were composed with a Ccc: header MUST NOT cause the MUA to set the evil bit on the packets used to send the message, unless the message itself is evil and would therefore cause the evil bit to be set. The option of sending a blank Ccc: header to indicate that at least one Cc:'d recipient was actually a Ccc: inherently leaks information and MUST NOT be exercised if there is only one Cc:'d recipient in the rewritten message because in this case the information leak is total and would eliminate the aura of mystery produced by including such a header, as it is then perfectly clear that the Cc: was indeed actually a Ccc:, defeating the purpose of the allowing the header to be optionally included. As with address obfuscation, whether this is appropriate for a given message depends on how much information the sender is willing to have the recipents know about which Cc:'d recipients never were actually sent the message. 5. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, April 1 2003. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Laroia & Stumpo Expires October 3, 2010 [Page 6] Internet-Draft Cosmetic Carbon Copy April 2010 Authors' Addresses Asheesh Laroia Johns Hopkins ACM New Engineering Building 319 3400 North Charles Street Baltimore, MD 21218 USA Phone: +1 410 516 4063 Email: paulproteus@acm.jhu.edu John Stumpo Johns Hopkins ACM Email: stump@acm.jhu.edu Laroia & Stumpo Expires October 3, 2010 [Page 7]