Network Working Group J. Levine
Internet-Draft Taughannock Networks
Intended status: Standards Track T. Herkula
Expires: February 24, 2017 optivo GmbH
August 23, 2016
Signalling one-click functionality for list email headers
draft-levine-herkula-oneclick-04
Abstract
This document describes a method for signaling a one-click function
for the list-unsubscribe email header. The need for this arises out
of the actuality that mail software sometimes fetches URLs in mail
headers, and thereby accidentally triggers unsubscriptions in the
case of the list-unsubscribe header.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 24, 2017.
Copyright Notice
Copyright (c) 2016 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Levine & Herkula Expires February 24, 2017 [Page 1]
Internet-Draft One click unsubscribe August 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. High-Level Goals . . . . . . . . . . . . . . . . . . . . . . 3
4. Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Mail senders . . . . . . . . . . . . . . . . . . . . . . 3
5.2. Mail receivers . . . . . . . . . . . . . . . . . . . . . 4
6. Additional Requirements . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.2. Complex . . . . . . . . . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
A.1. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 7
A.2. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
An [RFC2369] email header can contain HTTPS URIs. In a List-
Unsubscribe Header the HTTPS URI is intended to unsubscribe the
recipient of the email from the list. But anti-spam software often
fetches all resources in mail headers automatically, without any
action by the user. As a result of this unintended malicious
behavior, senders implement landing pages with a confirmation step to
finish the unsubscribe request.
If a mail recipient is unsubscribing manually, the confirmation page
is presented to the recipient who can then click the appropriate
button. But in some cases, there is no direct user interaction with
the target web site, as when the unsubscription is a side effect of a
spam report, or is performed automatically on mail sent to an
abandoned mailbox. In those cases, the unsubscription process has to
work without manual intervention, and in particular without requiring
that software attempt to interpret the contents of a confirmation
page.
This document addresses this part of the problem, with a POST action
for receivers that senders can distinguish from other requests and
handle as a one-click unsubscription without manual intervention by
the mail recipient.
Levine & Herkula Expires February 24, 2017 [Page 2]
Internet-Draft One click unsubscribe August 2016
A List-Unsubscribe header can also contain a mailto: URI with an
address to which an unsubscription request is sent. While these URIs
could be used in a one-click fashion, experience has shown that they
do not work well in high volume environments, because the recipient
mail systems (typically e-mail service providers that are optimized
to send large volumes of mail) cannot keep up with the required
number of mailed removal requests. Hence this document considers
only HTTPS URIs.
2. Definitions
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 [RFC2119] when written
in all capital letters.
"One-click" describes an action that directly triggers a change in a
system's state, intended to be applied only with a user's intent.
3. High-Level Goals
This document has several goals.
o Allow email senders to signal One-Click functionality for specific
HTTPS URIs used in [RFC2369] email headers.
o Allow MUA designers to implement independent user interface
features for a better user experience.
o Allow MUA users to trigger intended actions in a familiar
environment and without leaving the MUA context.
4. Out of Scope
This document does not address problems associated with deliberate
malicious behavior.
5. Implementation
5.1. Mail senders
An entity which is responsible for sending an email that wishes to
add an HTTPS URI for one-click unsubscriptions places both a List-
Unsubscribe and a List-Unsubscribe-Post header in the message. The
List-Unsubscribe-Post header may contain multiple key value pairs
needed by the sending entity. It also MUST contain the key value
pair "List-Unsubscribe=One-Click".
Levine & Herkula Expires February 24, 2017 [Page 3]
Internet-Draft One click unsubscribe August 2016
The combination of the URI in the List-Unsubscribe header and the
POST arguments in the List-Unsubscribe-Post header MUST identify the
mail recipient, so that the unsubscription process knows what address
to handle. In particular, One-click has no way to manually ask the
user what address he or she wishes to unsubscribe.
The sending entity needs to provide the infrastructure to handle POST
requests to the specified URI in the List-Unsubscribe header, and to
handle the reasonably foreseeable volume of unsubscribe requests that
its mail will provoke.
The One-Click action triggered by this URI SHOULD complete promptly
and not burden the requester in an inappropriate way. The sending
entity cannot expect that HTTP redirects are followed by the
requester.
5.2. Mail receivers
A receiving entity which wants to use a List-Unsubscribe HTTP URI
from an email that also contains a List-Unsubscribe-Post header
performs an HTTPS POST to the first HTTPS URI in the List-Unsubscribe
header and send the content of the List-Unsubscribe-Post header as
the request body.
The POST content SHOULD be sent as "multipart/form-data" [RFC7578]
and MAY be sent as "application/x-www-form-urlencoded". These
encodings are the ones used by web browsers when sending forms. The
target of the POST action will typically be the same as or similar to
the one in the manual confirmation page when doing a two-click
unsubscribe, so this is intended to allow the same server code to
handle both.
The receiving entity MUST NOT perform a POST on the the HTTPS URI
without user consent. When and how the user consent is obtained is
not part of this specification.
The Request uses the HTTPS verb POST. The HEAD and GET requests are
not intended to be used to trigger a state change. PUT and DELETE
would offer similar functionality but are often unavailable.
6. Additional Requirements
The email needs at least one valid authentication identifier. In
this version of the specification the only supported identifier type
is DKIM [RFC6376], that provides a domain-level identifier in the
content of the "d=" tag of a validated DKIM-Signature header field.
Levine & Herkula Expires February 24, 2017 [Page 4]
Internet-Draft One click unsubscribe August 2016
The List-Unsubscribe and List-Unsubscribe-Post headers need to be
covered by the signature, and hence must be included in the "h=" tag
of a valid DKIM-Signature header field.
7. IANA Considerations
IANA is requested to add a new entry to the Permanent Message Header
Field Names registry.
Header field name: List-Unsubscribe-Post
Applicable protocol: mail
Status: standard
Author/Change controller: IETF
Specification document: this document
8. Examples
8.1. Simple
Header in Email
List-Unsubscribe: <https://example.com/unsubscribe.html>
List-Unsubscribe-Post: List-Unsubscribe=One-Click&recip=user@example.com
Resulting POST request
POST /unsubscribe.html HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
List-Unsubscribe=One-Click&recip=user@example.com
8.2. Complex
Header in Email
List-Unsubscribe: <mailto:listrequest@example.com?subject=unsubscribe>,
<https://example.com/unsubscribe.html?campaign=123456789>
List-Unsubscribe-Post: List-Unsubscribe=One-Click&recip=user@example.com
Levine & Herkula Expires February 24, 2017 [Page 5]
Internet-Draft One click unsubscribe August 2016
Resulting POST request
POST /unsubscribe.html?campaign=123456789 HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
List-Unsubscribe=One-Click&recip=user@example.com
9. Security Considerations
The List-Unsubscribe-Post header will typically contain the recipient
address, but that address is usually also in the To: header. This
specification allows anyone with access to a message to unsubscribe
the recipient of the message, but that's typically the case with
existing List-Unsubscribe, just with more steps.
A creative mailer could send spam with content intended to provoke
large numbers of unsubscriptions, with suitably crafted headers to
send POST requests with arbitrary contents to servers that perhaps
don't want them. But it's been possible to provoke GET requests in a
similar way for a long time (and much easier, due to spam filter
auto-fetches) so the chances of significantly increased annoyance
seem low.
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport through
Message Header Fields", RFC 2369, DOI 10.17487/RFC2369,
July 1998, <http://www.rfc-editor.org/info/rfc2369>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc6376>.
[RFC7578] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015,
<http://www.rfc-editor.org/info/rfc7578>.
Levine & Herkula Expires February 24, 2017 [Page 6]
Internet-Draft One click unsubscribe August 2016
Remove this section before publication, please.
A.1. Changes from -03 to -04
Require HTTPS. More motivation.
A.2. Changes from -02 to -03
Describe motivation in intro. Clarify required DKIM. More paranoid
scenarios.
Authors' Addresses
John Levine
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://jl.ly
Tobias Herkula
optivo GmbH
Wallstrasse 16
Berlin 10179
DE
Phone: +49 30 768078 129
Email: t.herkula@optivo.com
URI: https://www.optivo.com
Levine & Herkula Expires February 24, 2017 [Page 7]
