Network Working Group R. Shacham
Internet-Draft H. Schulzrinne
Expires: November 11, 2007 Columbia University
May 10, 2007
HTTP Header for Future Correspondence Addresses
draft-shacham-http-corr-uris-00
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-
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 November 11, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
communication.
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
section.
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
[10].
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
USA
Email: shacham@cs.columbia.edu
Henning Schulzrinne
Columbia University
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
USA
Email: hgs@cs.columbia.edu
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
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Shacham & Schulzrinne Expires November 11, 2007 [Page 6]