idnits 2.17.1 draft-levine-herkula-oneclick-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 1, 2016) is 2702 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Levine 3 Internet-Draft Taughannock Networks 4 Intended status: Standards Track T. Herkula 5 Expires: June 4, 2017 optivo GmbH 6 December 1, 2016 8 Signalling one-click functionality for list email headers 9 draft-levine-herkula-oneclick-10 11 Abstract 13 This document describes a method for signaling a one-click function 14 for the List-Unsubscribe email header field. The need for this 15 arises out of the actuality that mail software sometimes fetches URLs 16 in mail header fields, and thereby accidentally triggers 17 unsubscriptions in the case of the List-Unsubscribe header field. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 4, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Implementation . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Mail senders . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Mail receivers . . . . . . . . . . . . . . . . . . . . . 5 58 4. Additional Requirements . . . . . . . . . . . . . . . . . . . 5 59 5. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. Simple . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8.2. Complex . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 8.3. Complex with multipart/form-data . . . . . . . . . . . . 8 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 67 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 68 A.1. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 9 69 A.2. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 9 70 A.3. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 9 71 A.4. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 9 72 A.5. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 9 73 A.6. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 10 74 A.7. Changes from -03 to -04 . . . . . . . . . . . . . . . . . 10 75 A.8. Changes from -02 to -03 . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction and Motivation 80 An [RFC2369] List-Unsubscribe email header field can contain HTTPS 81 [RFC7230] URIs. In that header field the HTTPS URI is intended to 82 unsubscribe the recipient of the message from the list. But anti- 83 spam software often fetches all resources in mail header fields 84 automatically, without any action by the user, and there is no 85 mechanical way for a sender to tell whether a request was made 86 automatically by anti-spam software or manually requested by a user. 87 To prevent accidental unsubscriptions, senders return landing pages 88 with a confirmation step to finish the unsubscribe request. A live 89 user would recognize and act on the confirmation step, but an 90 automated system would not. That makes the unsubscription process 91 more complex than a single click. 93 Operators of broadcast marketing lists tend to be primarily concerned 94 about deliverability of their mail: whether the mail is delivered to 95 the recipients and how the messages are presented, e.g., whether in 96 the primary inbox or in a junk folder. Many mail systems allow 97 recipients to report mail as spam or junk, and mail streams from 98 senders whose mail is often reported as junk tend to have poor 99 deliverability. Hence the mailers want to make it as easy as 100 possible for recipients to unsubscribe; if an unsubscription process 101 is too difficult, the recipient's alternative is to report mail from 102 the sender as junk until the mail no longer appears in the 103 recipient's inbox. 105 Operators of recipient mail systems are aware that their users do not 106 make a clear distinction between unsubscription and junk. In some 107 cases they allow trustworthy mailers to request notification when 108 their mail is reported as junk, so they can unsubscribe the 109 recipient, but the process of identifying trustworthy mailers and 110 notifying them does not scale well to large numbers of small mailers. 111 This specification provides a way for recipient systems to notify the 112 mailer automatically, using only information within the mail message, 113 and without prearrangement. Some recipient systems might wish to 114 send an unsubscription notice to mailers whenever a user reports a 115 message as junk, or they might offer the user the option to report 116 and unsubscribe. 118 If a mail recipient is unsubscribing manually and the unsubscription 119 process requires confirmation, the resulting web page is presented to 120 the recipient who can then click the appropriate button. But when 121 the unusubscribe action is combined with a user junk report, there is 122 no direct user interaction with the mailer's web site. Similarly, if 123 a mail system automatically unsubscribes recipient mailboxes that 124 have been closed or abandoned, there can be no interaction with a 125 user who is not present. In those cases, the unsubscription process 126 has to work without manual intervention, and in particular without 127 requiring that software attempt to interpret the contents of a 128 confirmation page. 130 This document addresses this part of the problem, with an HTTPS POST 131 action for mail receivers. Mail senders can distinguish this action 132 from other unsubscribe requests and handle it as a one-click 133 unsubscription without manual intervention by the mail recipient. 135 This document has several goals. 137 o Allow email senders to signal that a [RFC2369] List-Unsubscribe 138 header field has One-Click functionality. 140 o Allow MUA (Mail User Agent) users to unsubscribe from mailing 141 lists in a familiar environment and without leaving the MUA 142 context. A receiving system can process an unsubscription request 143 in the background without further interaction, and know that it 144 can be fully processed by the mail sender's system. 146 2. Definitions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119] when written 151 in all capital letters. 153 3. Implementation 155 3.1. Mail senders 157 A mail sender that wishes to enable one-click unsubscriptions places 158 one List-Unsubscribe header field and one List-Unsubscribe-Post 159 header field in the message. The List-Unsubscribe header field MUST 160 contain one HTTPS URI. It MAY contain other non-HTTP/S URIs such as 161 MAILTO:. The List-Unsubscribe-Post header MUST contain the single 162 key/value pair "List-Unsubscribe=One-Click". As described below, the 163 message MUST have a valid DKIM signature that covers at least the 164 List-Unsubscribe and List-Unsubscribe-Post headers. 166 The URI in the List-Unsubscribe header MUST contain enough 167 information to identify the mail recipient and the list from which 168 the recipient is to be removed, so that the unsubscription process 169 can complete automatically. Since there is no provision for extra 170 POST arguments, any information about the message or recipient is 171 encoded in the URI. In particular, One-click has no way to ask the 172 user what address or from what list the user wishes to unsubscribe. 174 The POST request MUST NOT include cookies, http authorization, or any 175 other context information. The unsubscribe operation is logically 176 unrelated to any previous Web activity and context information could 177 inappropriately link the unsubscribe to previous activity. 179 The URI SHOULD include an opaque identifier or other hard to forge 180 component in addition to or instead of the plain-text names of the 181 list and the subscriber. The server handling the unsubscription 182 SHOULD verify that the opaque or hard to forge component is valid. 183 This will deter attacks in which a malicious party sends spam with 184 List-Unsubscribe links for a victim list, with the intention of 185 causing list unsubscriptions from the victim list as a side effect of 186 users reporting the spam, or where the attacker does POSTs directly 187 to the mail sender's unsubscription server. 189 The mail sender needs to provide the infrastructure to handle POST 190 requests to the specified URI in the List-Unsubscribe header, and to 191 handle the unsubscribe requests that its mail will provoke. 193 The mail sender MUST NOT return an HTTPS redirect, since redirected 194 POST actions have historically not worked reliably, and many browsers 195 have turned redirected http POSTs into GETs. 197 This document does not update [RFC2369] so the usage of List- 198 Unsubscribe URIs other than for one-click remains unchanged. 200 3.2. Mail receivers 202 A mail receiver can do a one-click unsubscription by performing an 203 HTTPS POST to the HTTPS URI in the List-Unsubscribe header. It sends 204 the key/value pair in the List-Unsubscribe-Post header as the request 205 body. 207 The POST content SHOULD be sent as "multipart/form-data" [RFC7578] or 208 MAY be sent as "application/x-www-form-urlencoded". These encodings 209 are the ones used by web browsers when sending forms. The target of 210 the POST action is the same as the one in the GET action for a manual 211 unsubscription, so this is intended to allow the same server code to 212 handle both. 214 The mail receiver MUST NOT perform a POST on the the HTTPS URI 215 without user consent. When and how the user consent is obtained is 216 not part of this specification. 218 4. Additional Requirements 220 The message needs at least one valid authentication identifier. In 221 this version of the specification the only supported identifier type 222 is DKIM [RFC6376]. Hence senders MUST apply at least one valid DKIM 223 signature to the message. 225 The List-Unsubscribe and List-Unsubscribe-Post headers MUST be 226 covered by the signature and included in the "h=" tag of a valid 227 DKIM-Signature header field. 229 If the message does not have the required DKIM signature, the mail 230 receiver SHOULD NOT offer a one-click unsubscribe for that message. 232 5. Header Syntax 234 The following ABNF imports fields, WSP, and CRLF from [RFC5322]. It 235 imports ALPHA and DIGIT from [RFC5234]. 237 fields /= list-unsubscribe-post 239 ldh = ALPHA 0*(ALPHA | DIGIT | "-") 241 list-unsubscribe-post = "List-Unsubscribe-Post:" 0*1WSP postarg CRLF 243 postarg = "List-Unsubscribe=One-Click" 245 6. Security Considerations 247 The List-Unsubscribe header can contain a plaintext or encoded 248 version of the recipient address, but that address is usually also in 249 the To: header. This specification allows anyone with access to a 250 message to unsubscribe the recipient of the message, but that's 251 typically the case with existing List-Unsubscribe, just with more 252 steps. 254 A malicious mailer could send spam with content intended to provoke 255 large numbers of unsubscriptions, with suitably crafted headers to 256 send POST requests to servers that perhaps don't want them. But it's 257 been possible to provoke GET requests in a similar way for a long 258 time (and much easier, due to spam filter auto-fetches) so the 259 chances of significantly increased annoyance seem low. The contents 260 of the List-Unsubscribe-Post header is limited to a single known key/ 261 value pair to prevent an attacker from creating malicious messages 262 where the POST operation could simulate a user filling in an 263 arbitrary form on a victim web site. 265 The unsubscribe operation provides a strong hint to the mailer that 266 the address to which the message was sent was valid, and could in 267 principle be used as a way to test whether an email address is valid. 268 In practice, though, there are simpler ways such as embedding image 269 links into the HTML of a message and seeing whether the recipient 270 fetches the images. 272 Since the mailer's server that receives the POST request cannot in 273 general tell where the request is coming from, the URI SHOULD contain 274 an opaque identifier or other hard to forge component to identify the 275 list and recipient address. That can ensure that the request 276 originated from List-Unsubscribe and List-Unsubscribe-Post headers in 277 a message the mailer sent. Also, the request MUST NOT include 278 cookies or other context information to prevent the server from 279 associating the request with previous web requests. 281 7. IANA Considerations 283 IANA is requested to add a new entry to the Permanent Message Header 284 Field Names registry. 286 Header field name: List-Unsubscribe-Post 288 Applicable protocol: mail 290 Status: standard 292 Author/Change controller: IETF 294 Specification document: this document 296 8. Examples 298 8.1. Simple 300 Header in Email 302 List-Unsubscribe: 303 List-Unsubscribe-Post: List-Unsubscribe=One-Click 305 Resulting POST request 307 POST /unsubscribe/opaquepart HTTP/1.1 308 Host: example.com 309 Content-Type: application/x-www-form-urlencoded 310 Content-Length: 26 312 List-Unsubscribe=One-Click 314 8.2. Complex 316 Header in Email 318 List-Unsubscribe: , 319 320 List-Unsubscribe-Post: List-Unsubscribe=One-Click 321 Resulting POST request 323 POST /unsubscribe.html?opaque=123456789 HTTP/1.1 324 Host: example.com 325 Content-Type: application/x-www-form-urlencoded 326 Content-Length: 26 328 List-Unsubscribe=One-Click 330 8.3. Complex with multipart/form-data 332 Header in Email 334 List-Unsubscribe: , 335 336 List-Unsubscribe-Post: List-Unsubscribe=One-Click 338 Resulting POST request 340 POST /unsubscribe.html/opaque123456789 HTTP/1.1 341 Host: example.com 342 Content-Type: multipart/form-data; boundary=------FormBoundaryjWmhtjORrn 343 Content-Length: 218 345 ------FormBoundaryjWmhtjORrn 346 Content-Disposition: form-data; name="List-Unsubscribe" 348 One-Click 349 ------FormBoundaryjWmhtjORrn-- 351 9. Normative References 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax 359 for Core Mail List Commands and their Transport through 360 Message Header Fields", RFC 2369, DOI 10.17487/RFC2369, 361 July 1998, . 363 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 364 Specifications: ABNF", STD 68, RFC 5234, 365 DOI 10.17487/RFC5234, January 2008, 366 . 368 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 369 DOI 10.17487/RFC5322, October 2008, 370 . 372 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 373 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 374 RFC 6376, DOI 10.17487/RFC6376, September 2011, 375 . 377 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 378 Protocol (HTTP/1.1): Message Syntax and Routing", 379 RFC 7230, DOI 10.17487/RFC7230, June 2014, 380 . 382 [RFC7578] Masinter, L., "Returning Values from Forms: multipart/ 383 form-data", RFC 7578, DOI 10.17487/RFC7578, July 2015, 384 . 386 Appendix A. Change Log 388 Remove this section before publication, please. 390 A.1. Changes from -09 to -10 392 Bad cookies. Explain MUA. 394 A.2. Changes from -08 to -09 396 Editorial clarifications, strip out obsolete mentions of variable 397 POST arguments. 399 A.3. Changes from -07 to -08 401 Editorial changes per Ops directorate and security review. 403 Simplify POST argument to one field. 405 Send no context info. 407 A.4. Changes from -06 to -07 409 Added example with multipart/form-data encoding 411 A.5. Changes from -05 to -06 413 Add opaque parts to the security discussion. Editing changes, 414 entities are now senders and receivers, MUSTage clarified. 416 A.6. Changes from -04 to -05 418 Reorganize first sections and add more background. Add ABNF. Add 419 more security advice. 421 A.7. Changes from -03 to -04 423 Require HTTPS. More motivation. 425 A.8. Changes from -02 to -03 427 Describe motivation in intro. Clarify required DKIM. More paranoid 428 scenarios. 430 Authors' Addresses 432 John Levine 433 Taughannock Networks 434 PO Box 727 435 Trumansburg, NY 14886 437 Phone: +1 831 480 2300 438 Email: standards@taugh.com 439 URI: http://jl.ly 441 Tobias Herkula 442 optivo GmbH 443 Wallstrasse 16 444 Berlin 10179 445 DE 447 Phone: +49 30 768078 129 448 Email: t.herkula@optivo.com 449 URI: https://www.optivo.com