Internet Draft Yakov Shafranovich (Editor) Expiration: October 2004 SolidMatrix Technologies Network Working Group Matt Sergeant MessageLabs Chris Lewis Nortel Networks April 2004 Guidelines for Management of DNS Blacklists for Email draft-irtf-asrg-bcp-blacklists-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of of IP addresses or domains. This memo discusses guidelines for management of public DNS blacklists. The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. Table of Contents Abstract 1. Introduction 2. The Guidelines. 2.1. "Truth in Advertising". 2.2. Same Criteria for Listing and Delisting. 2.3. Listing/Delisting Criteria MUST Be Easily Available. 2.4. Collateral Damage Only as a Measure of Last Resort. 2.5. Listings SHOULD Be Temporary. 2.6. MUST Have a Direct Non-Public Way to Request Removal. 2.7. Removals MUST Be Prompt. 2.8. Removals MUST Be Possible in Absence of List Maintainer. 2.9. MUST Have an Audit Trail. 2.10. Shutdowns MUST Be Done in a Graceful Fashion. 3. Special Rules for Blacklists Listing Insecure Machines. 3.1. No Automated Probes. 3.2. Reasonable Re-scan Periods. 4. Summary of Guidelines. 5. Security Considerations 6. Informative References 7. Author(s) Addresses. 8. Acknowledgements. 9. Full Copyright Statement. 1. Introduction. The Anti Spam Research Group (ASRG) was chartered to address the spam problem. The ASRG charter includes: "codification of best current practices in spam management" This note falls within that category by listing guidelines for management of public blacklists. This document will seek BCP status. NOTE: This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF. As per section 3 of [RFC 2014], IRTF groups do not require consensus to publish documents. Therefore readers should be aware that this document does not necessarily represent the consensus of the entire ASRG. NOTE: This document is intended to evolve, based on comments from the Anti-Spam Research Group (ASRG) mailing list. It is certain that the current draft is incomplete and entirely possible that it is inaccurate. Hence, comments are eagerly sought, preferably in the form of suggested text changes, and preferably on the ASRG mailing list, at . 1.1. Terminology. 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 [RFC 2119]. Text marked with [[ and ]] denotes editorial notes. 2. The Guidelines. Due to the rising amount of spam and other forms of network abuse on the Internet, many community members and companies have begun to create and maintain blacklists of IP addresses and domains to be used for filtering email. The various blacklists in existence vary greatly in their policy, usage and and level of maintenance. These guidelines try to lay out a set of best practices for running a DNS blacklist in an open manner with hope that they will facilitate better management of existing and new blacklists, and provide better information for prospective users in selecting which blacklists to use. These guidelines only address public blacklists and do not apply to privately run blacklists. 2.1. "Truth in Advertising". A blacklist MUST carefully describe listing and delisting criteria in a clear and readable manner easily accessible to the public such as the blacklist's web site. A blacklist MUST stick to its criteria and listings that do not meet the published criteria MUST NOT be entered. In other words, be direct and honest as to what the listing criteria are, and never mix in other entries. Do not add spite listings unless spite listings are the raison-d'etre of the blacklist. There is nothing wrong with a blacklist doing this AS LONG AS this is clearly stated in the criteria. But, if the blacklist is "open relays", it MUST be "open relays *only*". 2.2. MUST Have the Same Criteria for Listing and Delisting. Getting out of the list MUST be the reverse of getting in. If all things listed in the criteria for listing are cleared up then there SHALL NOT be any added obstacles to remove a given entry from the blacklist. There SHALL NOT be any extra rules for de-listing other than the ones listed in the listing criteria. In addition to this, it is RECOMMENDED that all listings SHOULD be temporary as described in section 2.5. For temporary listings, it is not necessary to clear up the listing criteria to removed. 2.3. Listing/Delisting Criteria MUST Be Easily Available. Listing and delisting criteria for blacklists MUST be easily available and SHOULD be in a place clearly marked in its own section of the web site. Often DNS blacklists publish their listing criteria mixed in with lots of technical information about using the blacklist. This can confuse end users, so a separate page or section on its own SHOULD be dedicated to detailing why a specific entry appears in the blacklist. 2.4. Collateral Damage Only as a Measure of Last Resort. Extending a range of blocked addresses to try and persuade the owning ISP to act MUST ONLY be performed after contacting the owning ISP about the current block and requesting action, and waiting a reasonable time for the ISP to fix the problem. Any policy for collateral damage MUST be clearly documented in the listing criteria. However, this measure SHOULD only be used as one of last resort or avoided completely in order to minimize damage to other users. 2.5. Listings SHOULD Be Temporary. All listings SHOULD be temporary so that if a blacklist doesn't get around to removing an entry, then the entry will time out at some point in the future. For more aggressive spammers (e.g. those running their own ISP) the temporary period can be as much as six (6) months, but we recommend that longer periods SHOULD NOT be used since it is possible that an IP address or domain can change hands in the future, likely going to a non-spammer. We recommend a default timeout period of 24 hours, but that will vary depending on the nature of the list. For systems that do rescans on a regular basis, this period MAY vary depending on the nature of the scan (see section 3.2). Temporary listings do need to have listing criteria cleared up before being removed as described in section 2.2 above. Note that all listings being temporary does not mean that some listings will not remain after the timeout period. If the reason for listing still exists as confirmed by the owner of the blacklist then the timer for timeouts can be started again. 2.6. MUST Have a Direct Non-Public Way to Request Removal. As a minimum: the blacklist MUST have a web page that has a removal request function (separate from listing criteria as per section 2.3), and an email address to handle issues beyond that. Preference SHOULD be given to the web removal mechanism. This SHALL NOT not be a pointer to a public mailing list or a newsgroup. Removal requests need to be processed in a non-public way. 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. 2.7. Removals MUST Be Prompt. The preferred way of doing this is removal without question. This allows people to ask and get their IP address removed immediately, but does not prevent the blacklist owner re-listing their IP address at a later time (for example: subject to seeing more spam, or re-checking the IP address security). A re-listing MAY result in a longer timeout until the listing expires. Bounded exponential backoff is a good choice for listing timeout. Assuming the above is not possible and no listing reasons remain, removal at anyone's request MUST be prompt. By this we mean preferably within a period of 24 hours up to the maximum of three (3) days. 2.8. Removals MUST Be Possible in Absence of List Maintainer. Removals MUST be possible in the absence of the list maintainer. If removals cannot be automated (via robot re-testing) then there MUST be multiple list maintainers so that a removal request can be processed if the list owner is on vacation or otherwise unavailable. 2.9. MUST Have an Audit Trail. A blacklist MUST maintain an audit trail for all listings and SHOULD make it publicly available in an easy to find location, preferably on the blacklist's web site. 2.10. Shutdowns MUST Be Done in a Graceful Fashion. When a blacklist needs to be shutdown, it MUST do so gracefully and not blacklist the entire Internet. [[COMMENT: More input on this will be needed.]] 3. Special Rules for Blacklists Listing Insecure Machines. Some blacklists list IP addresses that are insecure in various ways (e.g. open relays, open proxies). These are some recommendations for these systems that MAY not be relevant to regular blacklists. 3.1. No Automated Scanning. Blacklists MUST NOT automatically probe for insecure systems without provocation. The reason for this is that there is little agreement in the community as to whether or not this be allowed. So we err on the side of caution. Therefore, listings MUST be "spam in hand" from a spam trap address, or "email in hand" based on either a non-automated test, or a test triggered by a spam message. 3.2. Reasonable Re-scan Periods. If the blacklist uses re-scans to determine whether the listing SHOULD timeout or not, the re-scan period SHOULD be reasonable. Scanning SHOULD occur no more often than once every 24 hours. 4. Summary of Guidelines. o "Truth in Advertising". o MUST Have Same Criteria for Listing and Delisting. o Listing/Delisting Criteria MUST Be Easily Available. o Collateral Damage Only as a Measure of Last Resort. o Listings SHOULD Be Temporary. o MUST Have a Direct Non-Public Way to Request Removal. o Removals MUST Be Prompt. o Removals MUST Be Possible in Absence of List Maintainer. o MUST Have an Audit Trail. o Shutdowns MUST Be Done in a Graceful Fashion. Special Rules for Blacklists Listing Insecure Machines: o No Automated Scanning. o Reasonable Re-scan Periods. 5. Security Considerations Like all DNS-based mechanisms, DNS blacklists are subject to various threats outlined in [DNS-THREATS]. 6. Informative References [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996. [RFC 2014] Weintrib, A., Postel, J,; "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [DNS-THREATS] Atkins, D. and Austein, R.; "Threat Analysis of the Domain Name System"; February 2004; draft-ietf-dnsext-dns-threats-06 (work-in-progress) 7. Author(s) Addresses. Yakov Shafranovich (Editor) SolidMatrix Technologies, Inc. research@solidmatrix.com www.shaftek.org Chris Lewis Nortel Networks clewis@nortelnetworks.com Matt Sergeant MessageLabs, Inc. msergeant@messagelabs.com 8. Acknowledgements. We would like to thank John R. Levine for his insightful comments. Funding for the RFC Editor function is currently provided by the Internet Society. 9. Full Copyright Statement. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."