Network Working Group                                         R. Shacham
Internet-Draft                                            H. Schulzrinne
Expires: November 11, 2007                           Columbia University
                                                            May 10, 2007

            HTTP Header for Future Correspondence Addresses

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 11, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   A large amount of email is non-personal, automated communication,
   such as newsletters, confirmations and legitimate advertisements.
   These are often tagged as spam by content filters.  This type of
   correspondence is usually initiated by a transaction over the web,
   such as a purchase or signing up for a service.  Therefore, we
   propose a new HTTP header to carry the addresses that may be used by
   the provider to correspond with the user.  These may be email
   addresses, or those used in other protocols, such as SIP.  This will

Shacham & Schulzrinne   Expires November 11, 2007               [Page 1]

Internet-Draft         Correspondence HTTP Header               May 2007

   facilitate the automatic inclusion of these addresses in whitelists
   used for spam prevention.

1.  Overview

   A large amount of email is not personal communication, but rather
   automated.  Examples of this include newsletters, confirmations of
   reservations, and legitimate advertisements that are sent as a result
   of a purchase.  These are often tagged as spam by content filters
   because of their similarity to spam.  Such communication is also sent
   as SMS text messages and recorded phone calls over the existing
   cellular or PSTN infrastructure, and it can be expected that, in the
   future, it will be sent over an IP-based infrastructure, in the form
   of audio, video and text, using the Session Initiation Protocol (SIP)
   [2].  Since such an IP-based infrastructure is far more vulnerable to
   spam as described in [9], the challenge of filtering out legitimate
   communication from spam will be faced there too.

   Sender authentication in email through SPF [4], Sender ID [6] or DKIM
   [5] and with the SIP Identity header [7] makes it possible to accept
   communication based on whitelisting.  However, the addresses of
   legitimate senders must be known beforehand.  This is known as the
   "introduction problem".  A user's whitelist or address book is often
   automatically populated by addresses to which he sends, but they will
   not contain the addresses of automated mailers to whom the user never
   sends.  However, automated communication is usually initiated by a
   transaction over the web, such as a purchase or signing up for a free
   service.  Such a transaction provides an opportunity to transfer the
   addresses that may be used to correspond in the future.

   We propose an HTTP [3] header to carry a list of addresses that may
   be used by a provider of goods or services to correspond with the
   client in matters related to a transaction.  The client (browser) may
   include these addresses in a whitelist for automatic acceptance in
   the future.  The methods used to add to the whitelist and query it
   are outside the scope of this document.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

Shacham & Schulzrinne   Expires November 11, 2007               [Page 2]

Internet-Draft         Correspondence HTTP Header               May 2007

3.  New Header Definition

   We define a new HTTP header called "Correspondence-URIs".  The header
   MUST be included only in a response.  This header may contain any
   number of URIs, representing communication addresses of types such as
   email, SIP or "tel".  The ABNF of this header appears below.  The
   mailbox rule is a reference to RFC 1123 [12], the SIP-URI and SIPS-
   URI rules are a reference to RFC 3261 [2], and the telephone-uri rule
   is a reference to RFC 3966 [8].  This specification may be expanded
   to include other URI schemes.

         Correspondence-URI = mailbox / SIP-URI
                            / SIPS-URI / telephone-uri
         Correspondence-URIs = "Correspondence-URIs" HCOLON
                       [Correspondence-URI *(COMMA Correspondence-URI)]

4.  Security Considerations

   This section discusses requirements and guidelines to ensure that
   this header is not used to force users to accept undesired

4.1.  Sending and Processing of the Header

   While the requirements in this section specify how an HTTP server
   should use the header, they, more importantly, should be followed by
   an HTTP client (browser) so that it ignores the header when sent in
   an invalid way, since servers attempting to abuse the mechanism will
   not follow the requirements anyway.

   This header MUST only be included in responses to POST requests.  It
   is unlikely that a website should need to legitimately correspond
   with a user unless he has completed a transaction with the site,
   which would involve a POST request.  Allowing the header in GET
   responses would leave the user open to constantly receive these
   headers, which would require his approval, as mentioned in the next

   The header MUST only include addresses belonging to the same domain
   as the server.  This limits the ability of organizations to provide
   third-party marketers or spammers access to their customer base.

   A client MAY choose to accept this header only when the "https" [11]
   scheme is used.  This would guard against the insertion of an
   unauthorized address into the header field.

Shacham & Schulzrinne   Expires November 11, 2007               [Page 3]

Internet-Draft         Correspondence HTTP Header               May 2007

4.2.  Client Use of The Header

   This section gives guidelines for how a client (browser) should use
   this header once it has accepted it in a response, ie. the
   requirements of the last section have been fulfilled.  Since this is
   a matter of local policy, it is beyond the scope of this document to
   make any normative claims about this use.

   This document does not specify any mechanism for whitelisting.  It
   should be noted, however, that using the addresses returned in this
   HTTP header in a whitelist is only effective when senders are
   authenticated.  This may be done through the Sender Policy Framework
   (SPF) [4], SenderID [6], or Domain Keys Identified Mail (DKIM) [5].

   The browser should not include the addresses in the user's whitelist
   without user approval.  A good way to get this approval is with a
   dialog box popping up at the time of receipt.  He should be made
   aware of which addresses he is accepting.  If he chooses not to
   include the addresses from a specific site in his whitelist, he
   should be given the option of not being asked the next time.

5.  IANA Considerations

   This document requires registration of a Message Header Field, as per
      Header field: Correspondence-URIs
      Applicable protocol: http
      Status: standard
      Author/Change Controller: IETF
      Specification document: this specification

6.  References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", RFC 2119, March 1997.

   [2]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
         Sparks, R., Handley, A., and E. Schooler, "SIP: Session
         Initiation Protocol", RFC 3261, June 2002.

   [3]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
         HTTP/1.1", RFC 2616, June 1999.

   [4]   Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for
         Authorizing Use of Domains in E-Mail, Version 1", RFC 4408,

Shacham & Schulzrinne   Expires November 11, 2007               [Page 4]

Internet-Draft         Correspondence HTTP Header               May 2007

         April 2006.

   [5]   Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and
         M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures",
         February 2007.

   [6]   Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
         RFC 4406, April 2006.

   [7]   Peterson, J. and C. Jennings, "Enhancements for Authenticated
         Identity Management in the Session Initiation Protocol (SIP)",
         RFC 4474, August 2006.

   [8]   Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
         December 2004.

   [9]   Rosenberg, J. and C. Jennings, "The Session Initiation Protocol
         (SIP) and Spam", February 2007.

   [10]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
         Procedures for Message Header Fields", RFC 3864,
         September 2004.

   [11]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [12]  Braden, R., "Requirements for Internet Hosts -- Application and
         Support", RFC 1123, October 1989.

Authors' Addresses

   Ron  Shacham
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027


   Henning  Schulzrinne
   Columbia University
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027


Shacham & Schulzrinne   Expires November 11, 2007               [Page 5]

Internet-Draft         Correspondence HTTP Header               May 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Shacham & Schulzrinne   Expires November 11, 2007               [Page 6]