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.



. 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 <asrg@ietf.org>.


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.

. 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.]]

. 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.

. 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.

. Security Considerations

   Like all DNS-based mechanisms, DNS blacklists are subject to
   various threats outlined in [DNS-THREATS].

. 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)


. 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


. 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.

. 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."