-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-levine-herkula-oneclick-00.xml
321 lines (319 loc) · 14.4 KB
/
draft-levine-herkula-oneclick-00.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2369 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2369.xml">
<!ENTITY RFC6376 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6376.xml">
<!ENTITY RFC7578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7578.xml">
]>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc toc="yes" ?>
<?rfc tocindent="yes" ?>
<?rfc tocdepth="2" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<rfc category="std" docName="draft-levine-herkula-oneclick-04" ipr="trust200902">
<front>
<title abbrev="One click unsubscribe">Signalling one-click functionality for list email headers</title>
<author fullname="John Levine" initials="J." surname="Levine">
<organization>Taughannock Networks</organization>
<address>
<postal>
<street>PO Box 727</street>
<city>Trumansburg</city>
<code>14886</code>
<region>NY</region>
</postal>
<phone>+1 831 480 2300</phone>
<email>standards@taugh.com</email>
<uri>http://jl.ly</uri>
</address>
</author>
<author fullname="Tobias Herkula" initials="T." surname="Herkula">
<organization>optivo GmbH</organization>
<address>
<postal>
<street>Wallstrasse 16</street>
<city>Berlin</city>
<code>10179</code>
<country>DE</country>
</postal>
<phone>+49 30 768078 129</phone>
<email>t.herkula@optivo.com</email>
<uri>https://www.optivo.com</uri>
</address>
</author>
<date month="August" year="2016"/>
<area>Operations and Management</area>
<keyword>email</keyword>
<keyword>mailing list</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
An <xref target="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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Definitions">
<t>
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
<xref target="RFC2119"/> when written in all capital letters.
</t>
<t>
"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.
</t>
</section>
<section title="High-Level Goals">
<t>This document has several goals.
<list style="symbols">
<t>
Allow email senders to signal One-Click functionality for specific
HTTPS URIs used in
<xref target="RFC2369"/>
email headers.
</t>
<t>
Allow MUA designers to implement independent user interface features for
a better user experience.
</t>
<t>
Allow MUA users to trigger intended actions in a familiar environment
and without leaving the MUA context.
</t>
</list>
</t>
</section>
<section title="Out of Scope">
<t>
This document does not address problems associated with deliberate
malicious behavior.
</t>
</section>
<section title="Implementation">
<section title="Mail senders">
<t>
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".
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section title="Mail receivers">
<t>
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.
</t>
<t>
The POST content SHOULD be sent as
<xref target="RFC7578">"multipart/form-data"</xref>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
</section>
<section title="Additional Requirements">
<t>
The email needs at least one valid authentication identifier. In this
version of the specification the only supported identifier type is DKIM
<xref target="RFC6376"/>, that provides a domain-level identifier in the content of the
"d=" tag of a validated DKIM-Signature header field.
</t>
<t>
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.
</t>
</section>
<section title="IANA Considerations">
<t>
IANA is requested to add a new entry to the Permanent Message Header
Field Names registry.
</t>
<t>
Header field name: List-Unsubscribe-Post
</t>
<t>
Applicable protocol: mail
</t>
<t>
Status: standard
</t>
<t>
Author/Change controller: IETF
</t>
<t>
Specification document: this document
</t>
</section>
<section title="Examples">
<section title="Simple">
<figure>
<preamble>Header in Email</preamble>
<artwork><![CDATA[
List-Unsubscribe: <https://example.com/unsubscribe.html>
List-Unsubscribe-Post: List-Unsubscribe=One-Click&recip=user@example.com
]]></artwork>
</figure>
<figure>
<preamble>Resulting POST request</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<section title="Complex">
<figure>
<preamble>Header in Email</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<figure>
<preamble>Resulting POST request</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
</section>
<section title="Security Considerations">
<t>
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.
</t>
<t>
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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2369;
&RFC6376;
&RFC7578;
</references>
<section title="Change Log">
<t>
Remove this section before publication, please.
</t>
<section title="Changes from -03 to -04">
<t>
Require HTTPS. More motivation.
</t>
</section>
<section title="Changes from -02 to -03">
<t>
Describe motivation in intro.
Clarify required DKIM.
More paranoid scenarios.
</t>
</section>
</section>
</back>
</rfc>