Internet-Draft The "Pc" field for SMTP Gururaja Grandhi Hewlett-Packard Company Expires: November 03, 2005 May 03, 2005 The "Pc" field for SMTP draft-grandhi-pc-smtp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft specifies a mechanism by which an SMTP sender can send a copy of mail to multiple recipients, with out exposing other's mail address to recipient and vice versa. 1. Introduction Currently if a sender wants to send a message to multiple addresses without exposing the other's mail address, then the sender uses the "Bcc" field in the Mail header to hide the identities marked in the "Bcc" field. The recipients of the mail marked under "Bcc" list will not either have his mail address in the "To" or "Cc" list. Sometimes there is a high chance that this mail gets ignored by the recipient as he is not addressed directly and it is just a blind carbon copy. This draft specifies a mechanism through which a sender can send a copy of message to multiple recipients with a special field in the Mail header, which would interpreted by the SMTP server as "To" list, however protecting their identities from others in the mail communication (something like members in Bcc field and without affecting the other fields in the mail header). Gururaja Grandhi Expires November 03, 2005 [Page 1] Internet-Draft The "Pc" field for SMTP May 03 2005 2. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 3. Requirement The requirement is to provide the user a new field "Pc", that achieves the similar functionality as that of a "Bcc" field. However, the "Pc" recipients of this message will be treated as primary recipients. 4. Header Updates A new field needs to be added into the SMTP header [RECEIVER FIELDS] called "Pc". The SMTP server would ensure to use a member of the "Pc" list as "To" list while delivering to SMTP receiver, however protecting his/her identity to others and vice versa. The intermediate MTAs which does not support "Pc" field will ignore the "Pc" field, which MAY cause the "Pc" field recipient not receiving the mail. 5. Format of the Field The format specification of this field should be treated as a "Cc" field. This field would be a part of the header and would be carried forward throughout the mail thread. 6. Processing of the "Pc" Field Client: The client must treat the "Pc" field as similar to "Cc" field while sending the mail to SMTP servers. The "Pc" list should be added in the Mail header before sending the mail. Server: The "Pc" field MUST be processed only at the final receiver's SMTP servers. Before storing the received message in the message store, for each of the users in the Pc field, the corresponding mail address MUST be appended to the "To:" list of the message. The remaining mail addresses in the "Pc" list SHOULD be ignored. All the remaining fields like To,Cc,Bcc SHOULD be the same in the mail. The "Pc" field MUST be processed after the alias [ALIAS] has been expanded. If an alias is in the "Pc" list, all the members of the alias [ALIAS] should get the ALIAS name in the "To:" list. Relay/Gateway: The Relay/Gateway SHOULD just forward the "Pc" field as it is to the next Relay/Gateway. 7. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. This syntax reuses the appropriate formal syntax defined in the INTERNET MESSAGE FORMAT Gururaja Grandhi Expires November 03, 2005 [Page 2] Internet-Draft The "Pc" field for SMTP May 03 2005 Pc = "Pc:" address-list CRLF CRLF = Carriage return (CR, ASCII value 13) and Line feed (LF, ASCII value 10) address-list = (address *("," address)) / obs-addr-list address = mailbox / group mailbox = name-addr / addr-spec name-addr = [display-name] angle-addr angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr CFWS = *([FWS] comment) (([FWS] comment) / FWS) FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space obs-FWS obs-FWS = 1*WSP *(CRLF 1*WSP) ctext = NO-WS-CTL / ; Non white space controls %d33-39 / ; The rest of the US-ASCII %d42-91 / ; characters not including "(", %d93-126 ; ")", or "\" ccontent = ctext / quoted-pair / comment comment = "(" *([FWS] ccontent) [FWS] ")" addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] dcontent = dtext / quoted-pair dtext = NO-WS-CTL / ; Non white space controls %d33-90 / ; The rest of the US-ASCII %d94-126 ; characters not including "[", ; "]", or "\" group = display-name ":" [mailbox-list / CFWS] ";" [CFWS] mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list Gururaja Grandhi Expires November 03, 2005 [Page 3] Internet-Draft The "Pc" field for SMTP May 03 2005 address-list = (address *("," address)) / obs-addr-list obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address] (([FWS] comment) / FWS) CFWS = *([FWS] comment) (([FWS] comment) / FWS) FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space obs-FWS WSP = space (SP,ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters obs-FWS = 1*WSP *(CRLF 1*WSP) 8. Reply Mail headers The reply mail header will be similar to the recipient who had received mail through "Bcc" field. 9. Security Consideration The intermediate MTAs which does not support "Pc" field will ignore the "Pc" field, which MAY cause the "Pc" field recipient not receiving the mail. There will not be any impact on Spam filters with this new field addition because, for an recipient, "Pc" field is equivalent to "To" and existing filters should work as it is. 10. Example A wants to send a mail to the people B,C,D with out any of them knowing about the other mail addresses. From: A To: X Pc: B,C,D CC: Y Subject: TEST Recipient X's mail looks like: From: A To: X CC: Y Subject: TEST SMTP server capable of delivering the mail to B will append the mails "To" list with B. Gururaja Grandhi Expires November 03, 2005 [Page 4] Internet-Draft The "Pc" field for SMTP May 03 2005 Recipient B's mail looks like: From: A To: X,B CC: Y Subject: TEST Recipient C's mail looks like: From: A To: X,C CC: Y Subject: TEST Recipient D's mail looks like: From: A To: X,D CC: Y Subject: TEST Recipient Y's mail looks like: From: A To: X CC: Y Subject: TEST Appendices A. References The following documents contain definitions or specifications that are necessary to understand this document properly: [ALIAS] J. Klensin, "Simple Mail Transfer Protocol", RFC: 2821, April 2001. [RECEIVER FIELDS] Crocker, D., "Standard of the Format of ARPA Internet Text Messages", RFC 822, August 1982. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [INTERNET MESSAGE FORMAT] P. Resnick, "Internet Message Format", RFC 2822, April 2001. [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. Gururaja Grandhi Expires November 03, 2005 [Page 5] Internet-Draft The "Pc" field for SMTP May 03 2005 Author's Address Gururaja Grandhi Hewlett-Packard, 29, Cunningham road, Bangalore, India 560052 gururaja.grandhi@hp.com +91-80-2205-2884 11. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Gururaja Grandhi Expires November 03, 2005 [Page 6]