idnits 2.17.00 (12 Aug 2021) /tmp/idnits53787/draft-tzink-ipv6mail-whitelist-02.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 10, 2012) is 3632 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5321' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC5598' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'RFC5782' is defined on line 426, but no explicit reference was found in the text == Unused Reference: 'RFC6376' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC5246' is defined on line 438, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4408 (ref. 'RFC5321') (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Zink 3 Internet-Draft Microsoft 4 Intended status: Informational June 10, 2012 5 Expires: November 15, 2012 7 Recommendations for the use of whitelists for email senders 8 transmitting email over IPv6 9 draft-tzink-ipv6mail-whitelist-02 11 Abstract 13 This document contains a plan for how providers of email services 14 can manage one aspect of the problem of email abuse over IPv6. 15 Spammers can send mail from a very large range of IPv6 addresses, 16 and this will make current antispam blocklisting technology less 17 effective. This is because email receivers will have to maintain 18 excessively large lists of IP blocklists which either consume too 19 many resources, or will become stale and therefore ineffective as 20 spammers quickly discard one IP address and move onto the next one. 22 This document recommends that during the transition of email from 23 IPv4 to IPv6, email receivers implement a whitelisting option where 24 they only allow email from permitted senders over IPv6 and reject 25 or throttle email from everyone else sending email over IPv6. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on November 15, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction and Problem Statement . . . . . . . . . . . . . . 5 75 3. Important Notice of Limitations and Scope . . . . . . . . . . 5 76 4. Transition Model - Whitelists . . . . . . . . . . . . . . . . 6 77 5. Population of the IPv6 Whitelists . . . . . . . . . . . . . . 7 78 6. Removal from the whitelists . . . . . . . . . . . . . . . . . 7 79 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 82 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9 83 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Key Terminology 88 This section defines the key terms used in this document. 90 1.1. Email 92 Email is a method of exchanging digital messages from an author to 93 one or more recipients. 95 1.2. Web mail 97 A service which offers web based access to email services which would 98 otherwise be accessed by dedicated email programs running on the 99 device used to access the email. 101 1.3. Host 103 An end user's host, or computer, as used in the context of this 104 document, is intended to refer to a computing device that connects to 105 the Internet. This encompasses devices used by Internet users such 106 as personal computers, including laptops, desktops, and netbooks, as 107 well as mobile phones, smart phones, home gateway devices, and other 108 end user computing devices which are connected or can connect to the 109 public Internet and/or private IP networks. 111 Increasingly, other household systems and devices contain embedded 112 hosts which are connected to or can connect to the public Internet 113 and/or private IP networks. However, these devices may not be under 114 interactive control of the Internet user, such as may be the case 115 with various smart home and smart grid devices. 117 1.4. SMTP 119 As defined in RFC5321. 121 1.5. Internet Customer 123 An end user who leverages a connection to the Internet via an ISP and 124 is provisioned with a public IP to communicate on the Internet. 126 1.6. Internet facing server 128 A server which is addressed with a public IP address that is able to 129 communicate with other publically addressed servers. A server 130 typically hosts a service that can be utilized by the Internet 131 community. 133 1.7. Internal users 135 Known corporate users of the ISP entity. 137 1.8. Blocklist 139 As defined in section 1 of RFC 5782 and typical usage described in 140 section 6 of that same RFC. 142 1.9. Whitelist 144 As defined in section 1 of RFC 5782 and typical usage described in 145 section 6 of that same RFC. 147 2. Introduction and Problem Statement 149 With the depletion of IPv4 address space and the transition of 150 Internet infrastructure to IPv6, it is necessary to address the way 151 in which email services can be transitioned from a IPv4 to that of 152 IPv6. There are significant issues to be addressed around the 153 matter of abuse in an IPv6 based environment which have been 154 addressed and largely resolved when operating using IPv4 as a 155 transport mechanism. 157 The majority of email service providers currently utilize IPv4 158 blocklists (as defined in section 1 of RFC 5782) to reject mail. 159 This is frequently done upon the initial email connection or 160 sometime during the SMTP transaction (e.g., after the HELO, MAIL 161 FROM or RCPT TO). This is done for multiple reasons: 163 (a) To save on more expensive downstream content filtering. 165 (b) To reduce the amount of spam that must be stored for the user 166 in a spam folder and on the mail server. 168 (c) To improve the quality of spam filtering. 170 IPv4 blocklists are manageable because the size of IPv4 address 171 space is approximately 4 billion IPs. Even if in the worst case 172 every single IP address were listed, this is very large but still 173 manageable for email filters with sufficient hardware. The size of 174 the total IPv6 address space is 340 trillion trillion trillion IP 175 addresses. This is far too large for filters to handle or backend 176 hardware to process or maintain. 178 Even if blocklist maintainers listed only the IP addresses that were 179 spamming, a spammer could send spam from an IP address, let the IP 180 address it used get listed on a blocklist, but discard that IP 181 address and move onto the next IP address. By rotating through IP 182 addresses quickly, a spammer would always be one step ahead of the 183 blocklists, and the lists would lose their effectiveness. This 184 would also result in more spam in users' inboxes, and greatly 185 increased processing load for mail filters. 187 3. Transition Model - Whitelists 189 It is assumed that eventually the Internet will come up with a 190 permanent solution to email over IPv6. In the meantime, a transition 191 model is required. 193 Rather than using IP blocklists to reject mail from known bad IP 194 addresses, email receivers who wish to receive email over IPv6 195 should use whitelists to only accept mail from known good IP 196 addresses and reject all email from IPv6 IP addresses that are not 197 on the list. Whitelist population is described in section 4. 199 This IPv6 whitelist is a "Do not reject all mail from this IP 200 address" list; email from these IP addresses may still go through 201 traditional content filtering. IP addresses on this whitelist are 202 there because they send email over IPv6 intentionally, and are not 203 sending email without the computer owner's consent, as part of a 204 botnet. 206 It is not unusual for email receivers in modern spam filters to use 207 whitelists, or "do not block" lists but still filter the mail by 208 content. For example, many large email receivers do not block the IP 209 address ranges of large webmail providers but still apply content 210 filtering. Other email receivers implement whitelists wherein a 211 small set of IP addresses undergo no spam filtering. 213 A flowchart of the process is below: 215 +--------------+ 216 | Inbound mail | 217 | arrives | 218 +--------------+ 219 | 220 | 221 /----------\ 222 +-- No -- / Is sending \ -- Yes --+ 223 | \ IP IPv6? / | 224 | \----------/ | 225 | | 226 +------------+ /-------------------\ 227 | Continue | / Is sending IP \ 228 | normal | +-- No -- \ on IPv6 allow list? / -- Yes --+ 229 | processing | | \-------------------/ | 230 +------------+ | | 231 | | 232 +---------------+ +------------+ 233 | Reject or | | Continue | 234 | throttle mail | | normal | 235 +---------------+ | processing | 236 +------------+ 238 Using an IPv6 whitelist has the following advantages: 240 (a) It allows email communication between those Internet users who 241 need to do it over IPv6 instead of IPv4. 243 (b) It does not permit widespread abuse of email over IPv6 since 244 senders must make an effort to get onto the whitelist. 246 (c) The lists will not take up much memory or bandwidth since the 247 total amount of legitimate senders over IPv6 is projected to be 248 substantially fewer than the total amount of Internet users or 249 devices. There simply are not that many senders who require 250 sending email over IPv6, less than 20 million which is smaller 251 than many IPv4 blocklists. 253 It is not unusual to put restrictions on IP addresses that are newly 254 sending email. Today (2012) on IPv4, Internet users cannot simply 255 start sending email out a new IP address without encountering 256 problems; most spam filters will view mail from a new IP address as 257 abusive and either block it or throttle mail from it. Therefore, 258 representatives between those users contact each other, informing 259 them to expect to see mail from their dormant IP addresses in the 260 near future, or else they ask for a pre-emptive whitelisting. 262 Thus, using an IPv6 whitelist already has precedent. Just as new 263 senders in IPv4 request pre-emptive whitelisting as a courtesy, in 264 IPv6 they will have to acquire pre-emptive whitelisting as a 265 requirement. 267 Another implementation is that receivers of email over IPv6 do not 268 need to reject non-whitelisted anonymous senders over IPv6. Instead, 269 they can throttle the senders by limiting the amount of mail they can 270 send. As time passes, the IPv6 senders can build up a good reputation 271 and move from the throttle list (where the amount of mail they can 272 send per IP address is limited) to the whitelist (where the amount 273 of mail they can send per IP address is nearly unlimited). 275 Thus, the key characteristic of the whitelist solution is not a 276 default-treat-everyone-as-potentially-good-until-they-show-otherwise, 277 but instead treat-everyone-as-suspicious-until-they-prove-otherwise. 278 The decision to throttle or reject mail from untrusted senders is up 279 to the recipient. 281 Email receivers may continue to filter the message by content filter 282 and either store it in the user's spam quarantine, or reject the 283 message based upon spam content, but they must not block messages 284 from those IP addresses due to an IP filtering ban because the 285 sending IP address is IPv6. 287 IPs addresses in the whitelist can be either single IP addresses or 288 in IP address ranges, it is up to the receiver to decide which format 289 to use. 291 4. Type of whitelists 293 It is not necessary to restrict whitelists to use only IP addresess. 294 Email receivers can whitelist based upon sending domain and combine 295 it with an SPF (see RFC 4408) or DKIM (see RFC 6376) validation, or 296 by using certificates such as those exchanged in TLS (see RFC 5246). 297 Using any of these options makes it easier to implement a whitelist 298 based upon domains because domains change more infrequently than 299 senders' IP addresses do. Secondly, any domain whitelists in IPv4 300 can be easily implemented in IPv6 when combined with either a DKIM 301 or SPF check. 303 However, the advantage of using a whitelist based only upon IP 304 addresses is that receiving mail servers can make a Good/Bad 305 decision as soon as the sending IP address connects to the mail 306 server. The drawback of using SPF is that a mail server must wait 307 to perform the whitelist lookup after the MAIL FROM command in the 308 SMTP conversation and wait for a DNS query to return. 310 Similarly, the drawback using DKIM is that the receiving mail 311 server must wait until it receives the entire message and wait for 312 a DNS query to return from looking up the public key to perform the 313 DKIM validation. This slows down the email transaction and 314 increases load on the email infrastructure. 316 5. Population of the IPv6 whitelists 318 It is outside the scope of this Internet Draft to specify how an 319 email receiver should build their own IPv6 whitelists. The following 320 are possible mechanisms to accomplish this: 322 (a) Administrators may contact each other by email over IPv4, by 323 telephone, by regular mail, by word-of-mouth, or any other form 324 of communication. Both parties may agree to whitelist each 325 other, or one party may whitelist the other without the other 326 doing the same. 328 (b) Administrators may rely on a third party reputation service that 329 provides lists of IP addresses of known good senders of email 330 over IPv6. An administrator may acquire this list and 331 proactively whitelist all IP addresses on this list, or a subset 332 of them. 334 (c) If administrators currently use sending domain whitelists in 335 IPv4 by combining them with an SPF or DKIM check, they can use 336 the same domain whitelists in IPv6. SPF supports IPv6, and DKIM 337 does not require the use of the sending IP address. 339 (d) Administrators may give email senders a way to do get onto their 340 whitelists by creating a web portal. Senders can go to this web 341 portal and enter in their sending IP addresses. The web portal 342 may do additional forms of validation (CAPTCHAs, SMS 343 verification) and if the sender passes the checks, their sending 344 IPs are added to the whitelist. 346 (e) Rather than rejecting mail from senders on IPv6, receivers might 347 allow new senders transmitting over IPv6 but throttle them 348 instead. By keeping track of a sending IP addresses' reputation 349 (ratio of spam to non-spam, passing authentication, etc.) over a 350 period of time, a receiver can upgrade the sender from the 351 Untrusted list to the Whitelist. The amount of mail they can 352 send over IPv6 increases as their reputation increases. 354 This changes the whitelist from a binary decision (Accept/Deny) 355 to a sliding-scale whitelist where a sender's reputation is on a 356 sliding scale. 358 Any of these methods, or a combination of them, can be used for 359 whitelist population. 361 6. Removal from the whitelists 363 If an IP address is added onto the whitelist, its reputation should 364 be tracked to ensure that it is not a spamming IP address. This can 365 be performed by keeping track of complaints, monitoring spam-to-non 366 spam volumes, and so forth. If an IP address is discovered to be 367 malicious, the following are possible methods to deal with this: 369 (a) The IP should be removed from the whitelist. 371 (b) Use the sending IP as part of a weight in the spam filter. 373 (c) Lower the sender's reputation which lowers their throttling 374 limits in the case that the email receiver is throttling IP 375 addresses instead of rejecting mail from them. 377 Any of these methods, or a combination of them, can be used to remove 378 IP addresses from the whitelist in the even that they are spamming. 380 7. Security Considerations 382 This document does not address any security issues inherent in IPv6 383 itself but acknowledges the security considerations of RFC 5782 do 384 apply to this document. IPv6 security considerations will need to 385 be addressed in this document as it develops. 387 8. Privacy Considerations 389 This document describes at a high level activities that ISPs should 390 be sensitive to, where the collection or communication of Personally 391 Identifiable Information (PII) may be possible. In addition, when 392 performing this transition, ISPs should be careful to protect any 393 PII collected whether deliberately or inadvertently. 395 Any sharing of data from the user to the ISP and/or authorized third 396 parties should be done on an opt-in basis. Additionally the ISP and 397 or authorized third parties should clearly state what data will be 398 shared and with whom the data will be shared with. 400 Lastly, there my be legal requirements in particular legal 401 jurisdictions concerning how long any subscriber-related or other 402 data is retained, of which an ISP operating in such a jurisdiction 403 should be aware and with which an ISP should comply. 405 9. IANA Considerations 407 There are no IANA considerations in this document. 409 10. Acknowledgements 411 The authors wish to acknowledge the following individuals and groups 412 for performing a detailed review of this document and/or providing 413 comments and feedback that helped to improve and evolve this 414 document: 416 Leiba, B. 418 11. Normative references 420 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 421 October 2008. 423 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 424 July 2009. 426 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 427 February 2010. 429 12. Informative references 431 [RFC5321] Wong, M. and Schlitt, W. "Sender Policy Framework (SPF) 432 for Authorizing Use of Domains in E-Mail, Version 1", 433 RFC 4408, April 2006. 435 [RFC6376] Allman, E., et al, "DomainKeys Identified Mail (DKIM) 436 Signatures", RFC 6376, July 2009. 438 [RFC5246] Dierks, T., and Rescorla, E., "The Transport Layer 439 Security (TLS) Protocol Version 1.2", RFC 5246, 440 August 2008 442 Appendix A. Document Change Log 444 [RFC Editor: This section is to be removed before publication] 446 -00 version: Initial version 447 -01 version: Formatting changes 448 -02 version: Added more options for how to get onto whitelist, 449 more documentation around throttling vs rejecting 451 Appendix B. Open Issues 453 [RFC Editor: This section is to be removed before publication] 455 No open issues to date 457 Authors' Addresses 459 Terry Zink 460 Microsoft 461 1 Microsoft Way 462 Redmond, WA 98052 463 US 465 Email: tzink@microsoft.com 466 URI: http://www.microsoft.com