idnits 2.17.1 draft-irtf-asrg-bcp-blacklists-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 365 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 155 has weird spacing: '... lots of te...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The email contact address SHOULD not use the blacklist in question, and SHOULD be unfiltered in order to allow affected users to get their requests through. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2004) is 7309 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) == Unused Reference: 'RFC 2026' is defined on line 290, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-dnsext-dns-threats-06 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Yakov Shafranovich (Editor) 3 Expiration: October 2004 SolidMatrix Technologies 4 Network Working Group Matt Sergeant 5 MessageLabs 6 Chris Lewis 7 Nortel Networks 8 April 2004 10 Guidelines for Management of DNS Blacklists for Email 11 draft-irtf-asrg-bcp-blacklists-00.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force (IETF), 18 its areas, and its working groups. Note that other groups may 19 also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use 24 Internet-Drafts as reference material or to cite them other 25 than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The rise of spam and other anti-social behavior on the 40 Internet has led to the creation of shared blacklists and 41 whitelists of of IP addresses or domains. This memo discusses 42 guidelines for management of public DNS blacklists. 44 The document will seek BCP status. Comments and discussion of this 45 document should be addressed to the asrg@ietf.org mailing list. 47 Table of Contents 49 Abstract 50 1. Introduction 51 2. The Guidelines. 52 2.1. "Truth in Advertising". 53 2.2. Same Criteria for Listing and Delisting. 54 2.3. Listing/Delisting Criteria MUST Be Easily Available. 55 2.4. Collateral Damage Only as a Measure of Last Resort. 56 2.5. Listings SHOULD Be Temporary. 57 2.6. MUST Have a Direct Non-Public Way to Request Removal. 58 2.7. Removals MUST Be Prompt. 59 2.8. Removals MUST Be Possible in Absence of List Maintainer. 60 2.9. MUST Have an Audit Trail. 61 2.10. Shutdowns MUST Be Done in a Graceful Fashion. 62 3. Special Rules for Blacklists Listing Insecure Machines. 63 3.1. No Automated Probes. 64 3.2. Reasonable Re-scan Periods. 65 4. Summary of Guidelines. 66 5. Security Considerations 67 6. Informative References 68 7. Author(s) Addresses. 69 8. Acknowledgements. 70 9. Full Copyright Statement. 72 1. Introduction. 74 The Anti Spam Research Group (ASRG) was chartered to address the 75 spam problem. The ASRG charter includes: 77 "codification of best current practices in spam management" 79 This note falls within that category by listing guidelines for 80 management of public blacklists. This document will seek BCP status. 82 NOTE: This document is a product of the Anti-Spam Research Group 83 (ASRG) of the IRTF. As per section 3 of [RFC 2014], IRTF 84 groups do not require consensus to publish documents. 85 Therefore readers should be aware that this document 86 does not necessarily represent the consensus of the 87 entire ASRG. 89 NOTE: This document is intended to evolve, based on comments from 90 the Anti-Spam Research Group (ASRG) mailing list. It is 91 certain that the current draft is incomplete and entirely 92 possible that it is inaccurate. Hence, comments are eagerly 93 sought, preferably in the form of suggested text changes, 94 and preferably on the ASRG mailing list, at . 96 1.1. Terminology. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 99 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in 101 [RFC 2119]. 103 Text marked with [[ and ]] denotes editorial notes. 105 2. The Guidelines. 107 Due to the rising amount of spam and other forms of network abuse on 108 the Internet, many community members and companies have begun to 109 create and maintain blacklists of IP addresses and domains to be 110 used for filtering email. The various blacklists in existence vary 111 greatly in their policy, usage and and level of maintenance. These 112 guidelines try to lay out a set of best practices for running 113 a DNS blacklist in an open manner with hope that they will 114 facilitate better management of existing and new blacklists, and 115 provide better information for prospective users in selecting which 116 blacklists to use. 118 These guidelines only address public blacklists and do not apply to 119 privately run blacklists. 121 2.1. "Truth in Advertising". 123 A blacklist MUST carefully describe listing and delisting criteria 124 in a clear and readable manner easily accessible to the public such 125 as the blacklist's web site. A blacklist MUST stick to its 126 criteria and listings that do not meet the published 127 criteria MUST NOT be entered. 129 In other words, be direct and honest as to what the listing 130 criteria are, and never mix in other entries. Do not add spite 131 listings unless spite listings are the raison-d'etre of the 132 blacklist. There is nothing wrong with a blacklist doing this 133 AS LONG AS this is clearly stated in the criteria. But, if the 134 blacklist is "open relays", it MUST be "open relays *only*". 136 2.2. MUST Have the Same Criteria for Listing and Delisting. 138 Getting out of the list MUST be the reverse of getting in. If all 139 things listed in the criteria for listing are cleared up then 140 there SHALL NOT be any added obstacles to remove a given entry from 141 the blacklist. There SHALL NOT be any extra rules for de-listing 142 other than the ones listed in the listing criteria. 144 In addition to this, it is RECOMMENDED that all listings SHOULD be 145 temporary as described in section 2.5. For temporary listings, it 146 is not necessary to clear up the listing criteria to removed. 148 2.3. Listing/Delisting Criteria MUST Be Easily Available. 150 Listing and delisting criteria for blacklists MUST be 151 easily available and SHOULD be in a place clearly marked 152 in its own section of the web site. 154 Often DNS blacklists publish their listing criteria mixed in with 155 lots of technical information about using the blacklist. This can 156 confuse end users, so a separate page or section on its own SHOULD 157 be dedicated to detailing why a specific entry appears in 158 the blacklist. 160 2.4. Collateral Damage Only as a Measure of Last Resort. 162 Extending a range of blocked addresses to try and persuade the 163 owning ISP to act MUST ONLY be performed after contacting the 164 owning ISP about the current block and requesting action, and 165 waiting a reasonable time for the ISP to fix the problem. Any 166 policy for collateral damage MUST be clearly documented in the 167 listing criteria. 169 However, this measure SHOULD only be used as one of last resort 170 or avoided completely in order to minimize damage to other users. 172 2.5. Listings SHOULD Be Temporary. 174 All listings SHOULD be temporary so that if a blacklist doesn't get 175 around to removing an entry, then the entry will time out at some 176 point in the future. For more aggressive spammers (e.g. those 177 running their own ISP) the temporary period can be as much as 178 six (6) months, but we recommend that longer periods SHOULD NOT be 179 used since it is possible that an IP address or domain can change 180 hands in the future, likely going to a non-spammer. 182 We recommend a default timeout period of 24 hours, but that will 183 vary depending on the nature of the list. For systems that 184 do rescans on a regular basis, this period MAY vary depending on the 185 nature of the scan (see section 3.2). 187 Temporary listings do need to have listing criteria cleared up 188 before being removed as described in section 2.2 above. 190 Note that all listings being temporary does not mean that some 191 listings will not remain after the timeout period. If the reason 192 for listing still exists as confirmed by the owner of the 193 blacklist then the timer for timeouts can be started again. 195 2.6. MUST Have a Direct Non-Public Way to Request Removal. 197 As a minimum: the blacklist MUST have a web page that has 198 a removal request function (separate from listing criteria as per 199 section 2.3), and an email address to handle issues beyond that. 200 Preference SHOULD be given to the web removal mechanism. This 201 SHALL NOT not be a pointer to a public mailing list or a newsgroup. 202 Removal requests need to be processed in a non-public way. 204 The email contact address SHOULD not use the blacklist in question, 205 and SHOULD be unfiltered in order to allow affected 206 users to get their requests through. 208 2.7. Removals MUST Be Prompt. 210 The preferred way of doing this is removal without question. This 211 allows people to ask and get their IP address removed immediately, 212 but does not prevent the blacklist owner re-listing their IP address 213 at a later time (for example: subject to seeing more spam, or 214 re-checking the IP address security). A re-listing MAY result in 215 a longer timeout until the listing expires. Bounded exponential 216 backoff is a good choice for listing timeout. 218 Assuming the above is not possible and no listing reasons remain, 219 removal at anyone's request MUST be prompt. By this we mean 220 preferably within a period of 24 hours up to the maximum of 221 three (3) days. 223 2.8. Removals MUST Be Possible in Absence of List Maintainer. 225 Removals MUST be possible in the absence of the list maintainer. If 226 removals cannot be automated (via robot re-testing) then there 227 MUST be multiple list maintainers so that a removal request can be 228 processed if the list owner is on vacation or otherwise unavailable. 230 2.9. MUST Have an Audit Trail. 232 A blacklist MUST maintain an audit trail for all listings and SHOULD 233 make it publicly available in an easy to find location, preferably 234 on the blacklist's web site. 236 2.10. Shutdowns MUST Be Done in a Graceful Fashion. 238 When a blacklist needs to be shutdown, it MUST do so gracefully 239 and not blacklist the entire Internet. 241 [[COMMENT: More input on this will be needed.]] 243 3. Special Rules for Blacklists Listing Insecure Machines. 245 Some blacklists list IP addresses that are insecure in various ways 246 (e.g. open relays, open proxies). These are some recommendations 247 for these systems that MAY not be relevant to regular blacklists. 249 3.1. No Automated Scanning. 251 Blacklists MUST NOT automatically probe for insecure systems without 252 provocation. The reason for this is that there is little agreement 253 in the community as to whether or not this be allowed. So we err 254 on the side of caution. 256 Therefore, listings MUST be "spam in hand" from a spam trap address, 257 or "email in hand" based on either a non-automated test, or a test 258 triggered by a spam message. 260 3.2. Reasonable Re-scan Periods. 262 If the blacklist uses re-scans to determine whether the listing 263 SHOULD timeout or not, the re-scan period SHOULD be reasonable. 264 Scanning SHOULD occur no more often than once every 24 hours. 266 4. Summary of Guidelines. 268 o "Truth in Advertising". 269 o MUST Have Same Criteria for Listing and Delisting. 270 o Listing/Delisting Criteria MUST Be Easily Available. 271 o Collateral Damage Only as a Measure of Last Resort. 272 o Listings SHOULD Be Temporary. 273 o MUST Have a Direct Non-Public Way to Request Removal. 274 o Removals MUST Be Prompt. 275 o Removals MUST Be Possible in Absence of List Maintainer. 276 o MUST Have an Audit Trail. 277 o Shutdowns MUST Be Done in a Graceful Fashion. 279 Special Rules for Blacklists Listing Insecure Machines: 280 o No Automated Scanning. 281 o Reasonable Re-scan Periods. 283 5. Security Considerations 285 Like all DNS-based mechanisms, DNS blacklists are subject to 286 various threats outlined in [DNS-THREATS]. 288 6. Informative References 290 [RFC 2026] Bradner, S., "The Internet Standards Process 291 -- Revision 3", BCP9, RFC 2026, October 1996. 293 [RFC 2014] Weintrib, A., Postel, J,; "IRTF Research Group 294 Guidelines and Procedures", BCP 8, RFC 2014, October 1996 296 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997 299 [DNS-THREATS] Atkins, D. and Austein, R.; "Threat Analysis of the 300 Domain Name System"; February 2004; 301 draft-ietf-dnsext-dns-threats-06 (work-in-progress) 303 7. Author(s) Addresses. 305 Yakov Shafranovich (Editor) 306 SolidMatrix Technologies, Inc. 307 research@solidmatrix.com 308 www.shaftek.org 310 Chris Lewis 311 Nortel Networks 312 clewis@nortelnetworks.com 314 Matt Sergeant 315 MessageLabs, Inc. 316 msergeant@messagelabs.com 318 8. Acknowledgements. 320 We would like to thank John R. Levine for his insightful comments. 322 Funding for the RFC Editor function is currently provided by the 323 Internet Society. 325 9. Full Copyright Statement. 327 Full Copyright Statement 329 Copyright (C) The Internet Society (2004). All Rights Reserved. 331 This document and translations of it may be copied and furnished to 332 others, and derivative works that comment on or otherwise explain it 333 or assist in its implementation may be prepared, copied, published 334 and distributed, in whole or in part, without restriction of any 335 kind, provided that the above copyright notice and this paragraph are 336 included on all such copies and derivative works. However, this 337 document itself may not be modified in any way, such as by removing 338 the copyright notice or references to the Internet Society or other 339 Internet organizations, except as needed for the purpose of 340 developing Internet standards in which case the procedures for 341 copyrights defined in the Internet Standards process must be 342 followed, or as required to translate it into languages other than 343 English. 345 The limited permissions granted above are perpetual and will not be 346 revoked by the Internet Society or its successors or assigns. 348 This document and the information contained herein is provided on an 349 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 350 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 351 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 352 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 353 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."