idnits 2.17.1 draft-levine-mailbomb-header-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6376, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 18, 2017) is 2475 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 229 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). 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 Updates: 6376 (if approved) June 18, 2017 5 Intended status: Informational 6 Expires: December 20, 2017 8 A Message Header to Identify Subscription Form Mail 9 draft-levine-mailbomb-header-00 11 Abstract 13 Many organizations have web forms that provoke an e-mail confirmation 14 to the e-mail address provided in the form. Malicious entities do 15 bulk form submissions with forged addresses, resulting in mail floods 16 to the holders of those addresses. This document defines a message 17 header to identify mail sent in response to web forms, so that 18 recipient mail systems can better recognize and mitigate the mail 19 floods. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 20, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 57 3. The Form-Sub header field . . . . . . . . . . . . . . . . . . 3 58 4. Mail flood enhanced status code . . . . . . . . . . . . . . . 3 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 3 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 61 6.1. Provisional Message Header Registry . . . . . . . . . . . 4 62 6.2. Enhanced Status Codes . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 69 1. Introduction 71 Discussion Venue: For the time being, discussion about this draft 72 is directed to the collaboration@mailman.m3aawg.org [1] mailing 73 list. 75 Many organizations have web forms that provoke an e-mail confirmation 76 to the e-mail address provided in the form. Malicious entities sbmit 77 multiple forms with forged addresses, resulting in mail floods to 78 those addresses. We define a message header that identifies mail 79 sent in response to web forms, so that recipient mail systems can 80 better recognize and mitigate the mail floods. 82 Mail systems that recognize a mail flood may defer or reject the 83 mail. We also define an SMTP enhanced status code that a mail system 84 can use in a message rejection SMTP reponse to alert the sending 85 system that the message was rejected due to being part of a mail 86 flood. 88 2. Conventions 90 The terms Message Submission Agent (MSA) and Message Transfer Agent 91 (MTA) are defined as in [RFC5598]. 93 The ABNF [RFC5234] terms CRLF, FWS, and fields are imported from 94 [RFC5322]. 96 3. The Form-Sub header field 98 A MSA or an initial MTA adds a Form-Sub header field to indicate that 99 the message was sent in response to a web form submission. The 100 header consists of a semicolon-separated list of tag=value pairs. 101 The first tag-value pair is "v=1" to indicate that the header uses 102 the initial version of this specification. Subsequent tag-value 103 pairs are optional, and receivers should ignore pairs with unknown 104 tags. 106 The tags ip4 or ip6 contain the IPv4 or IPv6 address, respectively, 107 from which the web form was submitted. The address may be partially 108 redacted for privacy reasons, by replacing groups of digits with the 109 letter "x", for example, 198.51.x.x or 2001:DB8::x or 110 x::1234:abcd:5678:ef01. If the sender cannot determine the 111 submitting IP address, it can include "ip=none". The goal of 112 including the IP address is to help receiving mail systems recognize 113 when a cluster of messages was provoked by the same submitter. 115 ABNF: 117 fields =/ "Form-Sub:" FWS "v=1" *(FWS ";" FWS fsarg) CRLF 119 fsarg = "ip4=" ip4redacted 120 ip4redacted = IPv4 address with parts optionally replaced by "x" 122 fsarg =/ "ip6=" ip6redacted 123 ip6redacted = IPv6 address with parts optionally replaced by "x" 125 fsarg =/ "ip=none" 127 The Form-Sub header should be included within the set of the headers 128 signed by any DKIM [RFC6376] signature headers. 130 4. Mail flood enhanced status code 132 A mail receiver may choose to defer or reject mail that it recognizes 133 as part of a mail flood. It can include the enhanced status code 134 X.7.TBD to indicate that the rejection is due to the message being 135 part of a mail flood that includes Form-Sub headers. 137 5. Security Considerations 139 IP addresses are sometimes considered to be personally identifable 140 information. This specification allows partially redacted addresses 141 as a compromise to avoid identifying individual persons, while still 142 providing receivers a hint to recognize bulk submissions by the same 143 party. 145 The Form-Sub header discloses information from a sender to a 146 receiver, and the X.7.TBD enhanced status code discloses information 147 from a receiver to a sender that they would not otherwise have. If 148 one party suspects the other is malicious, e.g., a receiver fears 149 that a sender is probing to see what its mail volume limits are, it 150 might not include the header or the status code for the possibly 151 malicious other party. 153 6. IANA Considerations 155 IANA is requested to update registries as follows. 157 6.1. Provisional Message Header Registry 159 The following value is added to the Provisional Message Header 160 Registry 162 +------------------+----------+----------+--------+-----------------+ 163 | Header Field | Template | Protocol | Status | Reference | 164 | name | | | | | 165 +------------------+----------+----------+--------+-----------------+ 166 | Form-Sub | . | mail | . | (this document) | 167 +------------------+----------+----------+--------+-----------------+ 169 Table 1: Provisional Message Header Registry Added Value 171 6.2. Enhanced Status Codes 173 The following value is added to the Enhanced Status Codes Enumerated 174 Status Codes Registry 175 +------+-------+--------+----------+--------+--------+--------------+ 176 | Code | Sampl | Associ | Descript | Refere | Submit | Change | 177 | | e | ated | ion | nce | ter | Controller | 178 | | Text | Basic | | | | | 179 | | | Status | | | | | 180 | | | Code | | | | | 181 +------+-------+--------+----------+--------+--------+--------------+ 182 | X.7. | Mail | The me | . | [this | J. | standards@ta | 183 | TBD | flood | ssage | | docume | Levine | ugh.com | 184 | | detec | appear | | nt] | | | 185 | | ted | s to | | | | | 186 | | | be | | | | | 187 | | | part | | | | | 188 | | | of a | | | | | 189 | | | mail | | | | | 190 | | | flood | | | | | 191 | | | of sim | | | | | 192 | | | ilar a | | | | | 193 | | | busive | | | | | 194 | | | messag | | | | | 195 | | | es. | | | | | 196 +------+-------+--------+----------+--------+--------+--------------+ 198 Table 2: Enunerated Status Codes Registry Added Value 200 7. Acknowledgments 202 Kurt Andersen and the M3AAWG Collaboration Committee provided the 203 good parts. 205 8. References 207 8.1. Normative References 209 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 210 Specifications: ABNF", STD 68, RFC 5234, 211 DOI 10.17487/RFC5234, January 2008, 212 . 214 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 215 DOI 10.17487/RFC5322, October 2008, 216 . 218 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 219 DOI 10.17487/RFC5598, July 2009, 220 . 222 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 223 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 224 RFC 6376, DOI 10.17487/RFC6376, September 2011, 225 . 227 8.2. URIs 229 [1] mailto:collaboration@mailman.m3aawg.org 231 Author's Address 233 John Levine 234 Taughannock Networks 235 PO Box 727 236 Trumansburg, NY 14886 238 Phone: +1 831 480 2300 239 Email: standards@taugh.com