Subject: [Asrg] Round 2 of the DNSBL BCP

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 13:07:03 -0400

I've also added comments from Andrew Kirsch, and a tweak or two more.  I 
think most will be pleased with the changes to 2.2.1 and 2.2.3.

John, I think the first go-round went to the IETF as 
draft-irtf-asrg-bcp-blacklists-04 (file was actually 01).  I fixed the 
document so that this one says 02.  Is this going to be a problem? 
Should I call this 05 before distributing to IETF?

If you make comments on the draft, please trim out the stuff you're not 
commenting on.

It would be nice to have several DNSBLs willing to put their name in the 
acknowledgements.

Anti-Spam Research Group - IRTF                                 C. Lewis
Internet-Draft                                           Nortel Networks
Intended status: BCP                                         M. Sergeant
Expires: September 2, 2008                              MessageLabs, Inc
                                                              March 2008

             Guidelines for Management of DNSBLs for Email
                   draft-irtf-asrg-bcp-blacklists-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on September 2, 2008.

Abstract

   The rise of spam and other anti-social behavior on the Internet has
   led to the creation of shared blacklists and whitelists of IP
   addresses or domains.  This memo discusses guidelines for management
   of public DNSBLs by the operators of such DNSBLs, as well as provide
   useful background for server administrators who use DNSBLs.  It is
   not intended to advise on the utility or effiacy of particular DNSBLs
   or the DNSBL concept in general, nor to assist end users with
   questions about spam.

   The document will seek BCP status.  Comments and discussion of this
   document should be addressed to the [email-masked] mailing list.

Lewis & Sergeant        Expires September 2, 2008               [Page 1]

Internet-Draft                  DNSBL BCP                     March 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  DNS-Based Reputation Systems . . . . . . . . . . . . . . .  3
     1.2.  Guidance for DNSBL Users . . . . . . . . . . . . . . . . .  4
     1.3.  Requirements Language  . . . . . . . . . . . . . . . . . .  5
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Transparency . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  Listing/Delisting Criteria SHOULD Be Easily
               Available  . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  Audit Trail SHOULD be maintained . . . . . . . . . . .  7
     2.2.  Listings and Removals  . . . . . . . . . . . . . . . . . .  7
       2.2.1.  Listings SHOULD Be Temporary . . . . . . . . . . . . .  7
       2.2.2.  A Direct Non-Public Way to Request Removal SHOULD
               Be Available . . . . . . . . . . . . . . . . . . . . .  8
       2.2.3.  Removals SHOULD Be Prompt  . . . . . . . . . . . . . .  8
       2.2.4.  SHOULD Have Similar Criteria for Listing and
               Delisting  . . . . . . . . . . . . . . . . . . . . . .  9
       2.2.5.  Removals SHOULD Be Possible in Absence of the
               DNSBL Operator . . . . . . . . . . . . . . . . . . . .  9
   3.  Operational Issues . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  DNSBL Query Root Domain SHOULD be a Subdomain  . . . . . .  9
     3.2.  DNSBLs SHOULD be Adequately Provisioned  . . . . . . . . . 10
     3.3.  DNSBLs SHOULD Provide Operational Flags  . . . . . . . . . 10
     3.4.  Shutdowns MUST Be Done in a Graceful Fashion . . . . . . . 11
     3.5.  Listing of Special and Reserved IP Addresses MUST be
           disclosed  . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.6.  Use of Collateral Damage MUST Be Disclosed . . . . . . . . 12
     3.7.  Considerations for DNSBLs Listing Insecure Hosts . . . . . 13
       3.7.1.  MUST NOT scan without provocation  . . . . . . . . . . 13
       3.7.2.  Re-scan Periods SHOULD be Reasonable . . . . . . . . . 13
       3.7.3.  Scans MUST NOT be Destructive  . . . . . . . . . . . . 13
     3.8.  Protect Against Misconfiguration/Outages . . . . . . . . . 14
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Lewis & Sergeant        Expires September 2, 2008               [Page 2]

Internet-Draft                  DNSBL BCP                     March 2008

1.  Introduction

1.1.  DNS-Based Reputation Systems

   Due to the rising amount of spam and other forms of network abuse on
   the Internet, many community members and companies began to create
   and maintain DNS-based reputation systems ("DNSBL") of IP addresses
   and domains identified as problem sources of email.  These lists also
   have been known as blocklists, or blacklists.  These lists are
   generally used for filtering email, but are often used for other
   purposes (eg: IRC, web access control, and transaction verification).

   DNSBLs may be either public or private.  A public DNSBL makes its
   data available to any party seeking information about data on the
   list, while a private DNSBL is used solely by an organization for its
   own use and the data is not made available publicly.  There are also
   commercial DNSBLs, available for a fee.  Furthermore, some are free
   yet require a fee for higher numbers of queries or certain classes of
   DNSBL users.

   The first publicly available DNSBL using the Domain Name System (DNS)
   for distributing reputation data about email senders emerged in 1997,
   shortly after spam became a problem for network operators and email
   administrators.  This pioneer DNSBL focused on identifying known spam
   sources situated at static (unchanging) IP addresses.  Due to the
   broad adoption of this DNSBL, it had a major impact on static spam
   sources.  Consequently, abusers found other methods for distributing
   their spam, such as relaying messages through unsecured email servers
   or flawed formmail scripts on web pages.  Additional DNSBLs were
   developed by others in order to address these changing tactics, and
   today more than 700 DNSBLs are in operation.

   These DNSBLs vary widely in integrity, strategy, methodology and
   stability.  While listing criteria can sometimes be quite
   controversial, this document deliberately does not discuss the
   rightness or wrongness of any criteria.  We assert that DNSBL
   operators are free to choose whatever listing criteria they wish, as
   long as they're clear to their users what they are.  It is the
   responsibility of the DNSBL user to ensure that the listing criteria
   and other aspects of a DNSBL meets their needs.

   This document is intended to provide guidance to DNSBL operators so
   that they may be able to identify what features users would be
   interested in seeing as part of a high-quality, well-managed DNSBL,
   e.g., a clear listing and delisting policy to which the DNSBL
   operator adheres strictly.  This document is intended to be normative
   rather than prescriptive: it seeks to characterize the features of a
   well-managed DNSBL rather than setting out rules for how DNSBLs

Lewis & Sergeant        Expires September 2, 2008               [Page 3]

Internet-Draft                  DNSBL BCP                     March 2008

   should be operated.

   This document is not intended as a protocol specification of DNSBL
   queries.  See [DNSBL-EMAIL].

1.2.  Guidance for DNSBL Users

   When choosing to adopt a DNSBL, a DNSBL user SHOULD keep the
   following questions in mind:

   1.   What is the intended use of the list?

   2.   Does the list have a web site?

   3.   Are the list's policies stated on the web site?

   4.   Are the policies stated clearly and understandably?

   5.   Does the web site function properly, e.g., hyperlinks?

   6.   Are web pages for removal requirements accessible and working
        properly?

   7.   How long has the list been in operation?

   8.   What are the demographics and quantity of the list's user base?
        In other words, do other sites like my own use this DNSBL?

   9.   Are comparative evaluations of the list available?

   10.  What do your peers or members of the Internet community say
        about the list?

   The DNSBL user MUST ensure that they understand the intended use of
   the DNSBL.  For example, some IP-based DNSBLs are appropriate for use
   only on the peer IP address of the machine connecting to the DNSBL
   user's mail server, and not other IP addresses appearing in an email
   (such as header Received lines or web links), or IRC connections etc.
   While a DNSBL user may choose to ignore the intent of the DNSBL, they
   should implement any variance in compliance with the DNSBL usage
   instructions.

   It is the responsibility of the system administrators who adopt one
   or more DNSBLs to evaluate, understand, and make a determination of
   which DNSBLs are appropriate for the sites they administer.  If you
   are going to allow a third party to make blocking decisions for you,
   you MUST understand the policies and practices of those third parties
   because responsibility for blocking decisions remain ultimately with

Lewis & Sergeant        Expires September 2, 2008               [Page 4]

Internet-Draft                  DNSBL BCP                     March 2008

   you, the system administrator.

   A DNSBL without DNSBL users does not prevent anyone from receiving
   email or any other Internet service.  A DNSBL with no users has no
   effect.  A DNSBL user prevents service by means of a DNSBL, and the
   user therefore MUST assume responsibility for all consequences.

   DNSBL operators are merely expressing an opinion through the
   publication of a DNSBL, and it is their absolute right to do so free
   of legal encumbrance, even in violation of this BCP.  However, it is
   through abiding by the guidelines set forth in this BCP that the
   operators of a DNSBL may gain the trust of their users.

   These guidelines only address public DNSBLs and do not apply to
   private access DNSBLs.

1.3.  Requirements Language

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

2.  Background

   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 DNSBLs.  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 [RFC2014]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 <[email-masked]>.

Lewis & Sergeant        Expires September 2, 2008               [Page 5]

Internet-Draft                  DNSBL BCP                     March 2008

2.1.  Transparency

   A DNSBL SHOULD carefully describe the criteria which are the cause
   for adding, and the criteria for removing an IP address or domain
   name on the list.  Such listing and delisting criteria SHOULD be
   presented in a clear and readable manner easily accessible to the
   public on the DNSBL's web site.  A DNSBL MUST abide by its stated
   listing and delisting criteria.  Entries that do not meet the
   published criteria MUST NOT be added to the DNSBL.

   In other words, be direct and honest and clear about the listing
   criteria, and make certain that only entries meeting the published
   criteria are added to the list.  For example, some DNSBL operators
   have been known to include "spite listings" in the lists they
   administer -- listings of IP addresses or domain names associated
   with someone who has insulted them, rather than actually violating
   the published criteria for inclusion in the list.  There is nothing
   inherently wrong with this practice so long as it is clearly
   disclosed.  For example, a DNSBL described as listing open relays
   only MUST NOT include IP addresses for any other reason.  This
   transparency principle does not require DNSBL operators to disclose
   the precise algorithms and data involved in a listing, but rather the
   intent behind choosing those algorithms and data.

   Furthermore, the DNSBL documentation SHOULD be clear on the intended
   use of the DNSBL - whether it be intended for peer addresses of
   email, IRC, etc.

   Availability of documentation concerning a DNSBL SHOULD NOT be
   dependent on the continued operation of DNS for DNSBL queries.

   In other words, if the DNSBL documentation is at
   "http://dnsbl.example.com", the documentation for the web site should
   not become unavailable if the DNSBL query name servers are not
   available (or shutdown).  See Section 3.1.

2.1.1.  Listing/Delisting Criteria SHOULD Be Easily Available

   Listing and delisting criteria for DNSBLs SHOULD be easily available
   and SHOULD be located in a place clearly marked in its own section of
   the web site affiliated with the DNSBL.

   DNSBLs often publish their listing criteria along with additional
   technical information about using the DNSBL.  This additional
   technical information can confuse end users, so a separate page,
   section or query function on its own SHOULD be dedicated to detailing
   why a specific entry appears in the DNSBL.

Lewis & Sergeant        Expires September 2, 2008               [Page 6]

Internet-Draft                  DNSBL BCP                     March 2008

2.1.2.  Audit Trail SHOULD be maintained

   A DNSBL SHOULD maintain an audit trail for all listings and it is
   RECOMMENDED that it is made publicly available in an easy to find
   location, preferably on the DNSBL's web site.  Please note that
   making audit trail data public does not entail revealing all
   information in the DNSBL operator's possession relating to the
   listing; e.g., a DNSBL operator MAY make the audit trail data
   selectively accessible in such a way as to not disclose information
   that might assist spammers, such as the contents of an email received
   by a DNSBL's spam trap.

2.2.  Listings and Removals

2.2.1.  Listings SHOULD Be Temporary

   In many cases, listings can exist for long periods of time past the
   conditions leading to the listing's creation, and/or the listed
   entity has changed ownership.

   Generally speaking, listings SHOULD be considered temporary, and
   should expire on their own at some point in the future unless reasons
   for listing still exist.

   Expiration intervals SHOULD be chosen to be reasonable for the type
   of listing.  For example:

   1.  DNSBLs based on geographic region or block assignment MAY have
       very long expiration intervals (or only be removed on request and
       the region/assignment change has been verified).

   2.  Automated DNSBLs with highly effective detection and fast listing
       mechanisms can benefit from very short expiration intervals.
       Many of the things that these DNSBLs look for are of relatively
       short duration, and even if they do expire, a resumption of the
       behaviour will be caught quickly by the DNSBL's detection
       mechanisms and relisted.  Yet, by utilizing a short expiration
       interval, after reassignment/problem correction, the listing will
       automatically expire in short order without manual intervention.

   3.  Manually created DNSBL entries SHOULD be periodically reviewed in
       some manner.

   It is RECOMMENDED that DNSBL operators publish that an expiration
   policy exists, and in general terms what it is.  If the DNSBL
   operator is too explicit in published policy, an abuser may be able
   to "game" it, on the other hand, many DNSBL users wish to have an
   idea of how "current" the DNSBL is.  It is the authors' experience

Lewis & Sergeant        Expires September 2, 2008               [Page 7]

Internet-Draft                  DNSBL BCP                     March 2008

   that some automated DNSBLs have increasingly higher error rates as
   the "last detection date" gets older.

   Note that listings being temporary does not mean that some listings
   will not remain after the initial timeout period.  If the DNSBL
   operator determines that the conditions for listing still exists,
   then the timer for determining timeouts can be renewed.

2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available

   Discussions about whether a DNSBL should remove an entry MAY include
   activity in a public forum.  Methods for processing removal requests
   through private, direct exchanges, such as person-to-person email or
   a combination of web page requests and email responses, SHOULD be
   available.  As a minimum, the DNSBL SHOULD have a web page that has a
   removal request function (separate from the page describing listing
   criteria as per Section 2.1.1).  The DNSBL SHOULD also make available
   an email address to handle issues other than blocking issues.

   The DNSBL operator MUST NOT use the list in question in such a way
   that removal requests would be blocked, and, moreover, SHOULD make
   mailboxes available in order to allow affected users to submit their
   requests.  In some cases it is impractical not to filter email to
   accounts due to the amount of spam those mailboxes receive.  If
   filtering should be necessary in such circumstances, filtering
   methods with virtually non-existent false positive rates SHOULD be
   chosen.

2.2.3.  Removals SHOULD Be Prompt

   The response to removal requests (and list removal if the conditions
   for listing are no longer present) SHOULD be prompt.

   A DNSBL MAY impose restrictions on who (e.g. network operator's
   representative or domain owner) may make valid removal requests,
   however, in many cases this is inadvisable because it requires
   impractical amounts of effort and hence NOT RECOMMENDED in most
   cases.

   Many DNSBLs (especially those with highly effective detection and
   fast listing mechanisms) greatly benefit from a "no questions asked"
   removal policy.

   Although this approach allows people to submit a request and have any
   listed IP address removed immediately, it does not prevent the DNSBL
   operator from re-listing the IP address at a later time.

   Many DNSBLs can effectively use a "no questions asked" removal policy

Lewis & Sergeant        Expires September 2, 2008               [Page 8]

Internet-Draft                  DNSBL BCP                     March 2008

   because by their very nature they will redetect or relist problems
   almost immediately.  They can mitigate more organized attempts to
   "game" the system by elementary checking and rate-limiting
   procedures, increasing lockout periods, rescans etc.  Furthermore, a
   few IP addresses more or less do not make a significant difference in
   the overall effectiveness of a DNSBL.  Moreover, a "no questions
   asked" removal policy provides the huge benefit of a swift reaction
   to incorrect listings.

   As an example, one popular DNSBL uses a "no questions asked" removal
   policy, but does perform rate-limiting and malicious removal
   detection and mitigation.

   Another important consideration supporting a "no questions asked"
   self-removal policy is that it forestalls many conflicts between
   DNSBL operators and organizations whose IP addresses have been
   listed.  Such a policy also can be an effective deterrent to legal
   problems.

2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting

   The criteria for being removed from a DNSBL SHOULD bear a reasonable
   relationship to the factors which were the cause of the addition to
   the DNSBL.  If a listed entity fulfills all published requirements
   for removal from a DNSBL, then the DNSBL operator SHOULD NOT impose
   any additional obstacles to remove a given entry from the DNSBL.
   There SHOULD NOT be any extra rules for de-listing other than the
   ones listed in the published listing criteria.

2.2.5.  Removals SHOULD Be Possible in Absence of the DNSBL Operator

   If removals cannot be automated (e.g., via robot re-testing) then the
   DNSBL SHOULD have multiple administrators so that a removal request
   can be processed if the principal list administrator is on vacation
   or otherwise unavailable.

3.  Operational Issues

3.1.  DNSBL Query Root Domain SHOULD be a Subdomain

   By virtue of using domain names, a DNSBL is a hierarchy with a root
   anchored in the global Internet.  The DNSBL "query root" SHOULD be
   below the registered domain, so that the DNSBL information is not
   conflated with domain housekeeping information (e.g., name server or
   MX records) for the domain.  By using this approach, DNSBL queries
   would take the form of "<query>.dnsbl.example.com" rather than
   "<query>.example.com".  Further, this sub-tree should have its own

Lewis & Sergeant        Expires September 2, 2008               [Page 9]

Internet-Draft                  DNSBL BCP                     March 2008

   name servers.  Thus, the DNSBL query root has its own zone file
   containing the DNSBL information, and the registered domain has its
   own name servers containing the information (MX records etc.) for the
   domain.  This approach facilitates clear delineation of function as
   well as orderly DNSBL shutdown because the DNSBL nameserver records
   can be specified separately from the domain's principal nameservers.

   Many DNSBLs support more than one logical zone (DNSBL entries with
   different meanings) that DNSBL users may wish to treat differently
   (or even ignore).  It is RECOMMENDED that, even if there is a single
   DNSBL zone with entry type distinguished by return code, that
   separate subdomains (of the query root) consist only of the
   corresponding entries.  For example, entry types "A" and "B" might
   return 127.0.0.2 and 127.0.0.3 from the consolidated zone (eg:
   dnsbl.example.com), but there should also be zones
   typeA.dnsbl.example.com and typeB.dnsbl.example.com that contain
   their respective types only.  See also Section 3.3.

3.2.  DNSBLs SHOULD be Adequately Provisioned

   The DNSBL SHOULD have sufficient name server capacity to handle the
   expected loading, and have sufficient redundancy to handle normal
   outages.

   Nameservers SHOULD provide appropriate glue records, possibly in
   different TLDs to protect against single-TLD issues.

   If the DNSBL offers zone transfers (in addition to or instead of
   standard DNSBL query mechanisms), it SHOULD be sufficiently
   provisioned to handle the expected loading.

   Note that some DNSBLs have been subject to distributed denial of
   service attacks.  Provisioning SHOULD take the likelyhood of this
   into account, and have plans for dealing with it.

3.3.  DNSBLs SHOULD Provide Operational Flags

   Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 to
   provide online indication of whether the DNSBL is operational.  In
   other words, the result of a DNS lookup will be in the range of
   127.0.0.1 through 127.0.0.255.  Many DNSBLs arrange to have a query
   of 127.0.0.2 return an A record indicating that the IP is listed, and
   a query of 127.0.0.1 return no A record (NXDOMAIN).  When both of
   these indicators are present, this indicates that the DNSBL is
   functioning normally.  See [DNSBL-EMAIL].

   Other results, such as 127.0.0.3, may have different meanings.  This
   operational flag usage and meaning SHOULD be published on the DNSBL's

Lewis & Sergeant        Expires September 2, 2008              [Page 10]

Internet-Draft                  DNSBL BCP                     March 2008

   web site.

   Some mail systems are unable to differentiate between these various
   results or flags, however, so a public DNSBL MUST NOT include
   opposing or widely different meanings -- such as 127.0.0.23 for
   "sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
   same DNS zone.

3.4.  Shutdowns MUST Be Done in a Graceful Fashion

   A number of DNSBLs have shut down operations in such a way as to list
   the entire Internet, sometimes without warning.  These were usually
   done this way to force DNSBL users (mail administrators) to adjust
   their DNSBL client configurations to omit the now inoperative DNSBL
   and to shed the DNS query load from the registered domain name
   servers.  Popular DNSBLs are in use by 10s of thousands of sites, are
   not well monitored, and often not compliant with DNSBL query
   conventions (e.g.: will treat any A record return as being "listed",
   instead of specific 127/8 A record returns) hence shutdowns can be
   quite destructive to all email flow if not done properly.

   The DNSBL operator MUST issue impending shutdown warnings (on the
   DNSBL web site, appropriate mailing lists, newsgroups, vendor
   newsletters etc), and indicate that the DNSBL is inoperative using
   the signalling given in Section 3.3.

   Only after these warnings have been issued for a significant period
   of time (RECOMMENDED: one or more months), should the DNSBL operator
   finally shutdown the DNSBL.

   The shutdown procedure should have the following properties:

   1.  MUST NOT list the entire Internet

   2.  SHOULD shed the DNSBL query load from the DNSBL name servers,
       permitting the registered domain name to continue being useable.

   3.  SHOULD, perhaps through increased delays, indicate to the Mail
       administrator that the DNSBL is no longer functional.

   4.  Name server or query lookups MUST NOT be aimed at third parties
       unrelated to DNSBL operation.  Such behaviour is similar to
       inflicting a DDOS.

   5.  The base domain name SHOULD be registered indefinately, so as to
       ensure that the domain name doesn't represent a "booby trap" for
       future owners, and/or provide a means by which a new owner could
       list the entire Internet.

Lewis & Sergeant        Expires September 2, 2008              [Page 11]

Internet-Draft                  DNSBL BCP                     March 2008

   One way of satisfying the points 1-4 above is to change the DNS name
   servers for the DNSBL to point at "TEST-NET" addresses (see RFC3330
   [RFC3330]).  The below suggested [BIND] declarations will cause a
   DNSBL query to query name servers in TEST-NET addresses, which will
   result in a significant delay, but not return any A records except in
   very unusual circumstances.

   BIND-equivalent DNS declarations for DNSBL shutdown.

   dnsbl.example.com.  604800  IN  NS  u1.example.com.
   dnsbl.example.com.  604800  IN  NS  u2.example.com.
   dnsbl.example.com.  604800  IN  NS  u3.example.com.

   ... [as many as you like]

   u1.example.com.     604800  IN  A   192.0.2.1
   u2.example.com.     604800  IN  A   192.0.2.2
   u3.example.com.     604800  IN  A   192.0.2.3

   ... [as many as you like]

   Assumes DNSBL is named "dnsbl.example.com".  Replace "example.com"
   and "dnsbl.example.com" as appropriate for the DNSBL

   NOTE:  Of course, the above shutdown procedure cannot be implemented
      if Section 3.1 is not followed.

3.5.  Listing of Special and Reserved IP Addresses MUST be disclosed

   The DNSBL MAY list loopback, RFC 1918 [RFC1918], LINK-LOCAL class
   D/E, and any other permanently reserved or special-use IP addresses.
   Such use MUST be disclosed in the documentation related to the DNSBL.

   A functioning DNSBL MUST NOT list 127.0.0.1

3.6.  Use of Collateral Damage MUST Be Disclosed

   Some DNSBLs have adopted a policy of using "collateral damage" as an
   intentional element of the list's operation.  When collateral damage
   is applied, a DNSBL listing is expanded to include IP addresses under
   the control of a provider even though those IP addresses are not the
   source of abusive email.  The theory is that customers impacted by
   collateral damage will apply pressure to the provider to take action
   against the customer which is the cause of the original listing.

   Collateral damage as a DNSBL policy is highly controversial, and
   discussion of the appropriateness of this policy is beyond the scope
   of this document.  However, if a DNSBL has policies and practices

Lewis & Sergeant        Expires September 2, 2008              [Page 12]

Internet-Draft                  DNSBL BCP                     March 2008

   that include the imposition of collateral damage, such policies MUST
   be disclosed.

3.7.  Considerations for DNSBLs Listing Insecure Hosts

   Some DNSBLs list IP addresses of hosts that are insecure in various
   ways (e.g. open relays, open proxies).  The following recommendations
   for such DNSBLs may not be relevant to other types of DNSBLs.

   This practise (scanning for vulnerabilities) can represent a legal
   risk in some jurisdictions.  The following recommendations for such
   DNSBLs MAY help alleviate this risk.

3.7.1.  MUST NOT scan without provocation

   DNSBLs MUST NOT automatically probe for insecure hosts without
   provocation.  There is little agreement in the community as to
   whether or not such activity should be allowed, so this BCP errs on
   the side of caution.

   Therefore, scanning MUST be be targeted, rather than broad-based,
   where a given scan is motivated by a specific reason to have concern
   about the address being scanned.  Examples of such reasons include
   delivery of an email, delivery to a spam trap address, receipt of a
   user complaint, or periodic testing of an address that is already
   listed.

3.7.2.  Re-scan Periods SHOULD be Reasonable

   If the DNSBL operator re-scans a host in order to determine whether
   the listing SHOULD timeout or not, the re-scan period SHOULD be
   reasonable.  Automated scanning SHOULD NOT occur more often than once
   every 24 hours.

   It is RECOMMENDED that automated re-scanning should cease within a
   reasonable period of the vulnerability no longer existing, and
   targetting conditions are no longer met.

3.7.3.  Scans MUST NOT be Destructive

   In the past, some scanning mechanisms have proven to adversely impact
   the scanned host, sometimes in severe fashion.  Scanning
   methodologies MUST be chosen to NOT negatively impact the scanned
   host.

Lewis & Sergeant        Expires September 2, 2008              [Page 13]

Internet-Draft                  DNSBL BCP                     March 2008

3.8.  Protect Against Misconfiguration/Outages

   It is not altogether uncommon for DNSBL users to configure their
   systems improperly for DNSBL queries.  The consequences of error can
   range from undue (or even damaging) load on the DNSBL servers, to
   accidentally blocking all incoming email.

   DNSBL users MUST test their initial DNSBL configurations to ensure
   that they're working correctly, and SHOULD periodically recheck the
   status of the DNSBLs they use and adjust their configuration as
   necessary.

   Common types of misconfigurations include:

   1.  Using wrong (sub-) zones for querying (e.g. 4.3.2.1.example.com
       or 4.3.2.1.dnsbl.exmple.cm instead of 4.3.2.1.dnsbl.example.com)

   2.  Downloading a local mirror of the data, but failing to set up the
       local nameserver infrastructure appropriately, and thus
       continuing to query public nameservers

   3.  Downloading a local mirror of the data, but misconfiguring the
       local nameserver infrastructure to query a locally invented zone
       name (4.3.2.1.dnsbl.local) at the public nameservers.

   4.  Misconfigured local nameservers to not do meaningful caching,
       thus heavily increasing load on public nameservers

   5.  Using the DNSBL query root domain name as the name server for
       queries.

   6.  Using the DNSBL incorrectly. e.g.  Some DNSBLs are suitable only
       for certain types of filtering.  Improper use may result in
       excessive incorrect filtering.

   While in many cases, it can be difficult detect such situations, to
   protect against such misconfiguration, it is RECOMMENDED that DNSBL
   operators make design decisions to mitigate the impact of such
   mistakes, and make efforts to contact administrative contacts to
   remedy the situation where appropriate.  But the DNSBL operator
   SHOULD also prepare to take appropriate steps to protect the
   operational infrastructure (e.g., have the ability to block abusive
   users from causing further damage).

   Appropriate use of the DNSBL (e.g. email, not IRC, not against
   authenticated local users) SHOULD be documented on the web site.

Lewis & Sergeant        Expires September 2, 2008              [Page 14]

Internet-Draft                  DNSBL BCP                     March 2008

4.  Security Considerations

   Any system manager that uses DNSBLs is entrusting part of his or her
   server management to the parties that run the lists.  A DNSBL manager
   that decided to list 0/0 (which has actually happened) could cause
   every server that uses the DNSBL to reject all mail.  Conversely, if
   a DNSBL manager removes all of the entries (which has also happened),
   systems that depend on the DNSBL will find that their filtering
   doesn't work as they want it to.

   If a registered domain used for a DNSBL is allowed to lapse, or the
   DNSBL user spells the DNSBL domain name incorrectly, the system
   manager's server management is now subject to an entirely different
   party than was intended.  Further, even if there is no malicious
   intent, some DNSBL query clients will interpret any A record being
   returned as being listed.

   Like all DNS-based mechanisms, DNSBLs are subject to various threats
   outlined in RFC 3833 [RFC3833]

5.  References

5.1.  Normative References

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group Guidelines
              and Procedures", BCP 8, RFC 2014, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
              September 2002.

   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
              Name System (DNS)", RFC 3833, August 2004.

5.2.  Informative References

   [BIND]     Internet Systems Corporation, "ISC BIND",
              <http://www.isc.org/index.pl?/sw/bind/index.php>.

   [DNSBL-EMAIL]
              Levine, J., "DNS-based blacklists and Whitelists for

Lewis & Sergeant        Expires September 2, 2008              [Page 15]

Internet-Draft                  DNSBL BCP                     March 2008

              E-Mail", November 2005, <http://www.ietf.org/
              internet-drafts/draft-irtf-asrg-dnsbl-04.txt>.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

Appendix A.  Acknowledgements

   We would like to thank John R. Levine, Alan Murphy and Dave Crocker
   for their insightful comments.

   We would also like to thank Yakov Shafranovich and Nick Nicholas for
   editing previous versions of this document.

Authors' Addresses

   Chris Lewis
   Nortel Networks

   Email: [email-masked]

   Matt Sergeant
   MessageLabs, Inc

   Email: [email-masked]

Lewis & Sergeant        Expires September 2, 2008              [Page 16]

Internet-Draft                  DNSBL BCP                     March 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Lewis & Sergeant        Expires September 2, 2008              [Page 17]

_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 1 Apr 2008 15:14:41 -0400

On 1-Apr-08, at 1:07 PM, Chris Lewis wrote:

>    name on the list.

Here we talk about IP addresses or domain names. I think we should  
stick with "Listing" or "Entry".

And did you add something somewhere about how a Listing/Entry might  
map to >1 "thing" in the list? e.g. a range/ASN/whatever?

> 2.2.1.  Listings SHOULD Be Temporary

Much improved.

> 2.2.3.  Removals SHOULD Be Prompt

Also much improved.

>    127.0.0.1 through 127.0.0.255.

I don't think this "in other words" fits. The first talks about  
operational entries, the second talks of results. And the first talks  
of a /8 and the latter the /24.

>   Many DNSBLs arrange to have a query

Not sure why this is a MUST NOT. If people are dumb enough to use a  
mixed list in a broken way they get what they deserve. What's the  
justification?

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: John Levine <[email-masked]>
Date: 1 Apr 2008 19:15:30 -0000

>Should I call this 05 before distributing to IETF?

The prior drafts never made it into the IETF database, so as far as
they are concerned, the prior draft was -01 and this is -02.

Will read and comment when I have a chance, but I gotta get a book in.

R's,
John

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 15:26:42 -0400

> they are concerned, the prior draft was -01 and this is -02.

I'm concerned that the prior draft had -04 within the document.  If I 
publish this new one with the -02 it should have, it'll look like the 
first one is the latest.

[I should have caught this, but I'm a complete newb with the tools and 
the process.]

No wait, the IETF copy _does_ say -01.  But the copy you returned to me 
with your last mods had -04 inside it.  _They_ must have zapped it 
before publication, or you zapped it after the copy you sent back.

Never mind.  We're good - this will be -02 inside and out.

> Will read and comment when I have a chance, but I gotta get a book in.

Thx.

Question: it seems like a number of DNSBL/ex-DNSBL people may be willing 
to publicly endorse this document if they like the final result.  It'd 
be nice to put that in explicitly in the Acknowledgements in one way or 
another (if they're willing to go that far).  Is that IETF-ishly acceptable?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 15:39:39 -0400

> stick with "Listing" or "Entry".

Fixed.

> map to >1 "thing" in the list? e.g. a range/ASN/whatever?

Should I?  Or is John's document the right place for that?

> of a /8 and the latter the /24.

Yes, confusing.  Redrafting:

Most DNSBLs follow a convention of entries for IPs in
127.0.0.0/8 (127.0.0.0-127.0.0.255) to
provide online indication of whether the DNSBL is operational.

>>    functioning normally.  See [DNSBL-EMAIL].

There is a problem with the above.  The reason for the "MUST NOT list 
127.0.0.1" (elsewhere) is that listing it will cause many mail servers 
to block _themselves_ (eg: MSA/MTA configurations of sendmail).  This is 
something that Vixie said years ago.  Yet, we're telling them to 
explicitly list it here. Which is almost as bad as a 0/0 listing.  Tho, 
a little more obvious ;-)

Does anybody know what the current thinking on 127.0.0.1 listing for 
"DNSBL down" is?  Or should I just yank that?

I can't remember where I saw this recommendation (of listing the .1 for 
"DNSBL down").  It was a strong one, otherwise, it wouldn't be there. 
Maybe I misremembered.

> mixed list in a broken way they get what they deserve. What's the  

"Suicidal administrator" prevention.  JD suggested it.  I like it, but 
I'm not committed to it.  Thoughts?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 1 Apr 2008 16:44:10 -0400

> Should I?  Or is John's document the right place for that?

I think the problem is we still do reference "IP address" in various  
places, and so some clarification of terms is needed.

>>> 127.0.0.0/8 to

Except either make that a /24 or fix the range to be the /8. :-)

Matt.

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 07:46:36 +1100

> a little more obvious ;-)

SORBS has listed 127.0.0.1 in the past, though never used it as a return 
code.  It occurred due to error, but it was an easy one - the relay 
tester was triggered to test localhost by someone first setting up an 
open relay then sending spam, then within hours changing the DNS record 
to return 127.0.0.1 for the host.  Result, a request for a valid 
hostname was put in the system then before it was tested someone changed 
the target IP to localhost.  This was fixed fairly promptly but it was 
not an indicator of a shutdown.  I believe other DNSBls have listed 
127.0.0.1 on occasion.

> "DNSBL down" is?  Or should I just yank that?

Yank it in the current form.  I've said this before I think putting 
something in that will never be in a valid listing (including an error 
listing) is the only answer to that one.  Something in 0/8 would work - 
however this is easily typo'd as 0.0.0.0/0, and would easily be machine 
generated so personally I would suggest 255.255.255.255/32.  Using such 
an address would indicate deliberate listing of the world as well as 
'this is now no longer a DNSbl you may use' (regardless of authors wish 
or whether the DNSbl is acutally shut/shutting).

> I'm not committed to it.  Thoughts?

I disagree, simply:  not in the same zone - but no problem with the same 
DNSBl.

Regards,

Mat

---

From: der Mouse <[email-masked]>
Date: Tue, 1 Apr 2008 16:47:54 -0400 (EDT)

> provide online indication of whether the DNSBL is operational.

This still has the problem that 127.0.0.0/8 is not
127.0.0.0-127.0.0.255.  127.0.0.0/8 is 127.0.0.0-127.255.255.255;
127.0.0.0-127.0.0.255 is 127.0.0.0/24.

> 127.0.0.1" (elsewhere) is [...].  This is something that Vixie said
> years ago.  Yet, we're telling them to explicitly list it here.

The text you quote says to list 127.0.0.2 and to _not_ list 127.0.0.1.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Peter J. Holzer" <[email-masked]>
Date: Tue, 1 Apr 2008 23:06:30 +0200

> 127.0.0.0/8 (127.0.0.0-127.0.0.255) to

Either "127.0.0.0/8 (127.0.0.0-127.255.255.255)"
or "127.0.0.0/24 (127.0.0.0-127.0.0.255)".

> explicitly list it here.

Do you? I read the above as:

    127.0.0.2 is listed AND 127.0.0.1 is not listed means the DNSBL is
    functioning normally.

    Any other combination:

    127.0.0.2 is not listed AND 127.0.0.1 is not listed
    127.0.0.2 is not listed AND 127.0.0.1 is listed
    127.0.0.2 is listed     AND 127.0.0.1 is listed

    means the list is not functioning properly.

So listing 127.0.0.1 is way of telling the world that the list is not
functioning properly, but it isn't the only one: Simply not listing
127.0.0.2 means the same and is IMHO preferable.

I did stumble over "both of these indicators are present" at first
reading. The second indicator which must be present is the absence of
entry. Maybe that could be formulated in some way which doesn't force
the reader through such mental contortions.

> Which is almost as bad as a 0/0 listing.

A 0/0 listing will result in both 127.0.0.1 to be listed. Since
127.0.0.1 should never be listed during normal operation, a client can
detect the 0/0 case by quering only 127.0.0.1.

> "DNSBL down").  It was a strong one, otherwise, it wouldn't be there. 

I don't remember it either but I think it may been intended not as a way
to signal "DNSBL down" but as a way to detect the "lists everything"
situation (and conversely, 127.0.0.2 can be used to test for "lists
nothing").

> I'm not committed to it.  Thoughts?

The A record could be used to encode a range. For example 127.0.1.x
could mean "x % of the observed messages from this source are spam"
(in fact I think I've seen at least one such list). Clearly 127.0.1.0
and 127.0.1.100 have opposing meanings, but I don't see this as bad.

	hp

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | [email-masked]         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "J D Falk" <[email-masked]>
Date: Tue, 1 Apr 2008 18:12:03 -0400

Matthew Sullivan wrote:

>>>>    Some mail systems are unable to differentiate between these
>>>>    various results or flags, however, so a public DNSBL MUST NOT
>>>>    include opposing or widely different meanings -- such as
>>>>    127.0.0.23 for "sends good mail" and 127.0.0.99 for "sends bad
>>>>    mail" -- within the same DNS zone.
>>>> 
> I disagree, simply:  not in the same zone - but no problem with the
> same DNSBl.

It already says "within the same DNS zone" at the end of the paragraph,
but I can see how that might be confusing.  Any suggestions for
re-wording?

> and 127.0.1.100 have opposing meanings, but I don't see this as bad.

That's not the usual binary result, however, and can't be used in the
same way -- so I'd see it as a reasonable exception to the Best Current
Practice.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Andrew D Kirch <[email-masked]>
Date: Tue, 01 Apr 2008 18:20:03 -0400

> mixed list in a broken way they get what they deserve. What's the  
This isn't just broken lists it's broken software.  Not all software 
which uses DNSBL's differentiates by returned response.

Andrew

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 09:39:23 +1100

> which uses DNSBL's differentiates by returned response.

Valid point and a separate section on client configuration/usage or even 
a separate RFC would be a good idea.

/ Mat

(not read the draft through yet)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 18:44:29 -0400

> not an indicator of a shutdown.  I believe other DNSBls have listed 

I think I've figured out how this supposed to be said (pardon the raw 
XML).  I also fixed the bungled /8 expansion.  I should know better, 
because we're one of the few who actually _has_ one...

As for accidental listings - perhaps we should say something about 
"SHOULD implement coding checks in DNSBLs" to avoid listing of bits that 
the DNSBL isn't supposed to?  That would go in the section about 
reserved et. al.

What do you think of this version?

<t>Most DNSBLs follow a convention of entries for IPs in
127.0.0.0/8 (127.0.0.0-127.255.255.255) to
provide online indication of whether the DNSBL is operational.
Many DNSBLs arrange to have a query
of 127.0.0.2 return an A record indicating that the IP is listed.
See <xref target="DNSBL-EMAIL" /></t>

<t>If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN),
the DNSBL should be considered non-functional.</t>

<t>Note: In <xref target="down" /> it is noted that some DNSBLs
have shut down in such a way to list all of the Internet.  Further,
in <xref target="reserved" />, DNSBL operators MUST NOT list
127.0.0.1.  Therefore, a positive listing for 127.0.0.1 SHOULD
also be an indicator that the DNSBL is non-functional.</t>

<t>Other results, such as 127.0.0.3, may have different meanings.
This operational flag usage and meaning SHOULD be published on the
DNSBL's web site, and the DNSBL user SHOULD periodically test the
DNSBL.</t>

> I disagree, simply:  not in the same zone - but no problem with the same 

Would a SHOULD NOT instead be sufficient?  A reword is probably better.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 18:56:56 -0400

> a separate RFC would be a good idea.

I'm contemplating doing a more general BCP on filtering (receiver end), 
or perhaps restricted to DNSBLs if the former gets too controversial 
(like if I start ragging about SAV or C/R ;-)  Main things would be 
"reject, not block", "useful, not necessarily fully revealing" error 
codes, plus various attitudinal adjustments ;-)  I have this 10 point 
thing laying around somewhere that forms the basis for the ideas.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 18:59:35 -0400

>> not an indicator of a shutdown.  I believe other DNSBls have listed 

I put this into the section on reserved addresses (becomes second 
paragraph):

         <t>As additional insurance against listings of space that should
         not be through testing or other unforeseen events, DNSBL 
operators SHOULD
         consider implementing facilities to prevent them.  At least one
         popular automated DNSBL has implemented permanent exclusions for
         such addresses.</t>

I consider this a reliability/integrity improvement.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 10:31:59 +1100

Chris Lewis wrote:
> XML). 

Ugh! ;-)

> the DNSBL should be considered non-functional.</t>

No - there are a few that do not have that address at the moment (they 
probably should), but as another example - autoexpiry of the SORBS Proxy 
DBs wiped out the test entrys until I hardcoded them in the DNSBl export 
script to put the entries in regardless of a matching lookup. Consider 
the following (not the wording, only the intent):

 If 127.0.0.2 is missing the user should look at the status of the DNSbl 
as it MAY be due to zone shutdown.

> also be an indicator that the DNSBL is non-functional.</t>

Well the accidental inclusion of 1.0.0.127.dnsbl.sorbs.net did not 
indicate the DNSbl was non-functional, which is why I suggested using 
either 255.255.255.255/32 (or earlier 0.0.0.1/32) the former is 
theoretically impossible as a valid *usable* host address, the latter 
is, just as 127.0.0.1, is a valid address.

> DNSBL's web site, and the DNSBL user SHOULD periodically test the

Agreed, though that is a client operation rather than a DNSBl operation. 
(The other BCP/RFC/Section?)

> Would a SHOULD NOT instead be sufficient?  A reword is probably better.

I did not read it correctly the first time around - read as 'the same 
DNSbl' - not as 'the same DNS zone'

Regards,

Mat

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Apr 2008 19:42:03 -0400

>    following questions in mind:
[...]
>    3.   Are the list's policies stated on the web site?
[...]
>    6.   Are web pages for removal requirements accessible and working

I'd like to see this changed to include other mechanisms that can be
used to communicate policy or handle removals. For example, a number
of DNSBLs have -announce lists which are used to communicate information
about outages (planned and unplanned), policy changes,
zone additions/removals, and so on.

Another angle: I think a web site may well be the best currently available
option for general information, but for at least some DNSBL users (like me),
subscribing to the -announce list is a much better way to keep apprised
of important news.

>    9.   Are comparative evaluations of the list available?

It's not clear to me -- after having done a number of these -- that they
have as much value as we might hope they have.  Without getting into
a long digression on that, the nut of the problem is that everyone's
mail mix is different, as are everyone's mail policies, so while one
evaluation might characterize a DNSBL as "excessive FPs", another
evaluation might characterize it as "excessive FNs".  I'm not saying
this point should be removed; I'm saying that perhaps a caveat to
the effect that "all such evaluations depends on the mail mix used
as well as local policy" should be added.  And, maybe, "if you can't
perform your own evaluation, then evaluations done by organizations
known to have a similar mail mix to yours and a similar set of policies
to yours may be the most applicable".

>    10.  What do your peers or members of the Internet community say

Perhaps this is over-reaching, but spammers and their employees are
known to hold and express opinions about DNSBLs.  I'm not sure how
to change the wording to express the idea that readers should be
careful to seek out the opinions of people whose goals align with theirs.
(That is, if they wish to receive spam, then get the opinions of
spammers.  If not, then get the opinions of anti-spammers.)

>    are going to allow a third party to make blocking decisions for you,

I suggest changing this to reflect [some] usage of [some] DNSBLs
for scoring, not blocking.  Perhaps:

	"If you are going to use a third party's data 
	in your decision-making process..."

or something like that?  But I very much agree with the gist of this.

>    effect.  A DNSBL user prevents service by means of a DNSBL, and the

Again, I suggest wording that covers the usage of DNSBLs for scoring
(which may not result in prevention of service, but may result in
delayed service, or different service, or full service but with some
different internal disposition).  (I'm going to stop pointing this
out each time it comes up to keep this short.)

>    operators of a DNSBL may gain the trust of their users.

I think this can be removed.  It may or may not be their right to express
that opinion --  I think it is, but I'm not an attorney even in *this*
country.  I think it's overbroad to state a global legal opinion.

I also think it's overbroad to say that this BCP is the only path
to trust.  It's *a* path, but it's too much to claim it's the only one.

>    for adding, and the criteria for removing an IP address or domain

I suggest introducing the term RHSBL to refer to domain names, subdomain
names, and host names.

>    use of the DNSBL - whether it be intended for peer addresses of

Suggest adding: "DNSBL providers SHOULD NOT be held accountable in any
way for the consequences of use of a DNSBL in a non-intended application",
or something along those lines.

> 2.2.1.  Listings SHOULD Be Temporary

I very strongly disagree with this statement in the case of domains.
Once a domain is known to operated by a spammer, there's no reason to
ever de-list it if the list's policy equates to "we list spammer domains". 

I would agree with

	Listings MAY be temporary or permanent

followed by discussion of why some (let's say, temporarily open relays
that are repaired) should be temporarily and why some (again, spammer-owned
domain) may be permanent, if that's the policy of the RHSBL maintainer.

>    entity has changed ownership.

I would change this to:

	entity has putatively changed ownership.

There have been cases where network allocations have "changed ownership"
under dubious circumstances, and I'm aware of several instance where
"domains were sold to new owners" who turned out to be the old owners
using a different business name.

I think it's probably beyond the scope of this BCP to get into that
mess, but I do think it would be good to use wording that acknowledges
its existence and does not rule out a certain amount of skepticism
in the face of claims of "changed ownership".

>    Such a policy also can be an effective deterrent to legal problems.

I'd strike this, as it expresses a legal opinion.  (I happen to
agree with that opinion, but IANAL either.)

>    provisioned to handle the expected loading.

Would it be appropriate to mention rsync in this context?

>    servers.  Popular DNSBLs are in use by 10s of thousands of sites, are

'tens", not "10s" ;-)

>    1.  MUST NOT list the entire Internet

I somewhat disagree.  As we're seeing again with ORDB, this is often
the only way for DNSBL operators to reclaim resources.  I don't like it,
it shouldn't be necessary, it has negative consequences, it's bad,
but sadly, it appears to be the only way to reach people who have
done their best to ignore all the communication methods listed in
the prior section.  I don't think DNSBL operators -- having done
their best to shut down services gracefully -- should be perpetually
saddled with a burden they no longer want.

>        administrator that the DNSBL is no longer functional.

I agree with this in spirit: it should work.  But it doesn't seem to.

>        list the entire Internet.

I agree with this, but suggest that wording be added to indicate that
DNSBL operators SHOULD attempt to notify the community if they lose
control of the domain or domain's DNS due to registrar, ISP, or
hosting issues.

> 3.6.  Use of Collateral Damage MUST Be Disclosed

There's no such thing as collateral damage.  I'm going to write
a separate message about that because it's too long to include here.

> 3.7.1.  MUST NOT scan without provocation

I'd make it "SHOULD NOT".  The legal climate is very unclear and there
is frequent vocal disagreement on both sides of this issue in the
security community.  I think there's also plenty of argument over
what "provocation" is and what an appropriate scope of response is.

The general idea is fine, but I would avoid being overly prescriptive
while the community continues to debates this issue and (presumably)
litigation takes place to settle some of surrounding questions in some
jurisdictions.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Apr 2008 19:49:15 -0400

This is a followup to one particular section:

> a separate message about that because it's too long to include here.

This phrase should be excised from this document.  There's no such
thing as "collateral damage" because there's no such thing as
"damage" in this context.

Consider: if you knock on my door and request entry to my home, and I
decline, have I "damaged" you?  No: I have merely declined to extend a
privilege to you.

If you call me, and I do not answer or return your call, or if you send
me a letter, but I do not open it, have I "damaged" you?  No: again,
I've simply declined to extend a privilege -- in this case, the courtesy
of my time and attention.

If you issue an HTTP request to a server I operate, and you are not given
the page you request, but an error message indicating that you're not
authorized to access that page, have I damaged you?  Once again, no,
you've simply not been extended a privilege.

Such privileges are mine to grant and deny at my option -- for any reason,
or for no reason at all other than my personal whim.  I may grant them
in full or part, and I may deny them in full or part.  (And I can grant
them or deny them based on a DNSBL or RHSBL listing if I so choose.)

The same may be said by any operator of any service (HTTP, FTP, SMTP,
etc.)  anywhere on the Internet.  Only someone with an inflated sense
of entitlement would make the claim that they were somehow "damaged"
merely because they weren't granted a privilege.

Similarly, requests for the privilege of SMTP services may be granted or
denied at the pleasure of those providing those services.  If any given
mail system chooses to deny all traffic from hosts whose last IP octet is
a prime number, or from all domains containing the letter "j", or from any
which connect between 1:17 and 2:43 PM, that site is perfectly free to do
so -- and such a decision does not inflict any kind of "damage" on anyone.

Similarly, if any given DNSBL or RHSBL wishes to publish those policies
and implement them, it's free to do so.

I deliberately chose some absurd policy examples to make the point:
of course I wouldn't recommend these particular ones.  But I chose
those ridiculous policies to emphasize that a site furnishing services
(like SMTP) is the sole and final arbiter of the terms and conditions
under which it will do so, and if that site chooses to implement these
or some considerably less far-fetched policies, whatever those policies
are, they don't cause any "damage".  They merely grant/deny a privilege,
as the case may be.

Since those requesting services are never entitled to those privileges,
they can never claim that they are "damaged" if their request is denied.
They might (variously) be upset, disappointed or even surprised
(especially if someone is using the prime number policy, any sane
person would use the Fibonacci sequence) but they're not damaged.

---Rsk

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 01:51:48 +0200

Chris Lewis wrote:

> I think the first go-round went to the IETF as 
> draft-irtf-asrg-bcp-blacklists-04 (file was actually 01).
> I fixed the document so that this one says 02.  Is this
> going to be a problem? 

02 after 01 is fine.

> Should I call this 05 before distributing to IETF?

05 after 01 could mean trouble.

> If you make comments on the draft, please trim out
> the stuff you're not commenting on.

Please do NOT post complete drafts as mail, just go
to the Internet Draft Submit Web form and click on
"send".  Integers are cheap - at least below 99 :-)

 [non-procedural]
> If you are going to allow a third party to make
> blocking decisions for you,  you MUST understand
> the policies and practices of those third parties
> because responsibility for blocking decisions
> remain ultimately with you, the system administrator.

As reported in another mail:  BLs don't make blocking
decisions.  Users of BLs make blocking decisions based
on input from BLs, and on other factors.  IANAL, but
for legal reasons I think it is important to have it
very clear who recommends (BL) and who blocks (user).

>   represent the consensus of the entire ASRG.

This Note is IMO irrelevant, a BCP needs the consensus
of the IETF determined by the IESG after an IETF Last
Call.  The IRTF is not entitled to publish IETF BCPs,
and AFAIK there are no "IRTF BCPs".

>   mailing list, at <[email-masked]>.

This note is apparently for the time while the draft is
discussed.  Please make this clear, e.g. move temporary
stuff into a "document history" section, with a note
that this is not intended for publicataion in the BCP.

> 4.  Security Considerations

You need also "IANA Considerations", especially BCPs
often create IANA registries.  The IANA Considerations
must be there, even if the content is "nothing to do,
remove this section before publication".

> A DNSBL manager that decided to list 0/0 (which has
> actually happened)

Yes, that's why there should be a test item 127.0.0.1
or similar, that's never listed.

> a DNSBL manager removes all of the entries (which
> has also happened)

Yes, that's why there should be a test itme 127.0.0.2
that is always listed, even if a list with all IPs not
ending with "2" hates it.  Maybe add a reference to the
technical RFC for details about test entries for these
security considerations, it's always good to propose a
way to mitigate identified threats.

> [RFC2014]  Weinrib, A. and J. Postel, "IRTF Research Group
>            Guidelines and Procedures", BCP 8, RFC 2014, 
>            October 1996.

That's no normative reference, move it to informative.

>            internet-drafts/draft-irtf-asrg-dnsbl-04.txt>.

OTOH that is IMO a normative reference IFF it ends up on
standards track, as it should.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 01:55:23 +0200

> I'm not committed to it.  Thoughts?

Keep as is.

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 10:59:05 +1100

> subscribing to the -announce list is a much better way to keep apprised

Mandatory condition of anyone using SORBS Rsync servers is they 
subscribe to at least one of the SORBS mailing lists.  The 
sorbs-announce@ mailing list will feed to all the other public lists.

> domain) may be permanent, if that's the policy of the RHSBL maintainer.

I concur -  I have heard the argument that if the reason behind the 
listing changes then delisting should be removed, but I don't 
necessarily agree.  If a spammer has stopped being spammer, doesn't mean 
their listing should be temporary.

> saddled with a burden they no longer want.

I concur, however it needs to be mentioned/addressed in some way as it 
should be a last resort only.  Also we must not forget what happens if 
the DNSbl domain is left to expire.

> control of the domain or domain's DNS due to registrar, ISP, or

My comments above, but how about if you get *.registrar (or ICANN etc) 
to make a domain perm....?  Wouldn't work because every man and his dog 
would say 'I'm running this DNSbl' to avoid expiry.

/ Mat

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 20:46:12 -0400

> as it MAY be due to zone shutdown.

I do not think it onerous to suggest that existing DNSBLs that don't use 
127.0.0.2 should, and there is enough current practise to suggest it 
should be codified as a BCP.

Secondly, you'll notice I didn't say "considered shut down" or imply 
permanence.  If a DNSBL that publishes a 127.0.0.2 diagnostic _stops_ 
doing it, it is indeed operating out of specification (eg: what else is 
going wrong?) at least temporarily, and probably shouldn't be used 
further until it starts signalling 127.0.0.2 properly again.

By stating it this simply, it encourages automation, so if something 
breaks down, email servers _could_ automatically stop trusting the returns.

> indicate the DNSbl was non-functional,

The wording above repeated - it was out of specification, and the rest 
of it is in doubt.  And in some situations it will cause unintended 
blocking.

It's not too onerous IMO to expect DNSBLs to do such elementary basic 
checking.

> which is why I suggested using 

Nobody is doing that - I don't want to suggest something too new.
> (The other BCP/RFC/Section?)

This isn't the only MUST/SHOULD aimed at the DNSBL user, and I think 
it's important in this context.  Tho, it'd be repeated in a "using 
DNSBLs" BCP (if there ever was one).

> DNSbl' - not as 'the same DNS zone'

Okay, I'll leave it alone for now.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 1 Apr 2008 19:58:18 -0500

>  "damage" in this context.

I dissagree. Some listings knowingly include IP addresses not directly
related to distribution of objectionable mail nor direct support or
response gathering of that mail. That is sometimes done to nudge the
users of those listed, but potentially unrelated IP addresses to
complain to the entity responsible for the core issue, or to nudge
that entity to work toward core issue resolution, to mitigate or
remove impact against the users of those other IP addresses.

It happens currently and it seems appropriate to recognize it.

Regards,
Al Iverson

-- 
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com   --   Chicago, IL, USA
Remove "lists" from my email address to reach me faster and directly.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 03:43:03 +0200

> It happens currently and it seems appropriate to recognize it.

Strong ACK.  

Some idiots, one of them living in mirrors I look at, could 
decide that the zones A, B, E, F of a list are exactly what
they want, to save bandwidth they use the combined zone C.

Oops, that gives them also zone D with the collateral damage,
a private pay to unlist scheme.

 Frank

---

From: Rich Kulawiec <[email-masked]>
Date: Tue, 1 Apr 2008 22:09:43 -0400

On Tue, Apr 01, 2008 at 07:58:18PM -0500, Al Iverson wrote:
> response gathering of that mail.

Yes, they do.

But this is obviously not damage.

I'm not expressing an opinion (here) for or against such listing policies.
I'm just pointing out that it is impossible for any DNSBL listing (or
its use) to cause any damage, because all it does is grant or revoke (or
modify, if used for scoring) an access privilege.  And access to services
provided by third parties is never a right: it's always a privilege.

Anyone who thinks they are "damaged" when they are not granted privileges
is laboring under a badly mistaken concept of what "privilege" means.
They are attempting to assert that they are somehow entitled to services
and are thus in some way "damaged" when their inappropriate expectations
are not met.  But absent a legally valid contract, nobody is obligated
to provide them with any services, of any kind, ever.  The operational
reality that most people ARE generously provided with most services most
of the time by default doesn't alter this.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 22:17:04 -0400

> subscribing to the -announce list is a much better way to keep apprised

Done - added:

          <t>Does the DNSBL have a mailing list for announcing
             changes, outages etc?</t>

> to yours may be the most applicable".

Added to the item:

Note: all such evaluations depend on mail mix used as well
as local policy.  DNSBL users SHOULD consider trial
periods and/or ongoing local monitoring of DNSBL suitability.

> spammers.  If not, then get the opinions of anti-spammers.)

H'm.  Added:

DNSBLs can sometimes be quite controversial and sometimes
considerable misinformation is spread.  Ensure that the opinions are 
knowledgeable, and reflect similar goals to yours.

> or something like that?  But I very much agree with the gist of this.

Adopted (slightly modified).

> out each time it comes up to keep this short.)

Yeah, I need to say something about scoring.  In the intro.

"A DNSBL user voluntarily uses DNSBL data to guide their filtering 
decisions, and the...."

That should fix that.

> country.  I think it's overbroad to state a global legal opinion.

Perhaps it should be toned down, but I think it still needs to be said 
somehow.  You don't have to be a lawyer to express an opinion about the law.

> to trust.  It's *a* path, but it's too much to claim it's the only one.

I don't see it as reading "only".

> I suggest introducing the term RHSBL to refer to domain names, subdomain

The document uses "DNSBL" thruout to handle DNS-query-based lists, and 
explicitly calls out both domains/IPs, and is inclusive of SURBLs too. 
I think adding RHSBL/SURBL/URIBL etc will only make the document way 
more opaque than it needs to be and is unnecessary.

> or something along those lines.

I like it.  Taken verbatim.
> ever de-list it if the list's policy equates to "we list spammer domains".

Notice that the section gives plenty of "outs" on the general notion of 
listings, domains or otherwise, and if your listing policy says "domains 
are listed until the heat death of the universe" it's okay.   So I think 
it's fine as is.

And yes, some spamming domains _do_ reform.

> using a different business name.

Either the ownership changed or it didn't.  It would be silly to get 
into a discourse on how spammers lie.  The DNSBL operators know that and 
can make their own judgments.  Tho, um, er, in this case, "putatively" 
;-) done.

I've also made domain listings a bit more explicit as potentially having 
long expiration:

	    <t>DNSBLs based on geographic region, block assignment or
           domains of demonstrably bad actors MAY have
	    very long expiration intervals ..

[including no expiration - request and manual verification only.]

> agree with that opinion, but IANAL either.)

Youse guys are altogether too afraid of lawyers.  I think 
downplayed/informal legal suggestions are useful.  But let's try this:

Such a policy may be an effective measure to prevent small
issues blowing up into big problems.

> Would it be appropriate to mention rsync in this context?

Does this require me to add too many references?  "Rsync zone transfers 
are becoming a defacto standard for DNSBL zone transfers instead of DNS 
protocol operations due to its efficiency".

[Not added, waiting for comment.  Perhaps too much detail.  Maybe John's 
has it.]

>>    servers.  Popular DNSBLs are in use by 10s of thousands of sites, are

Okay ;-)

> saddled with a burden they no longer want.

Note that a DNSBL should only have to do this once.  So, stern advice to 
NOT do it and how to do it right is useful for existing and future 
DNSBLs.   If a DNSBL does do it, it's rather late to get too concerned
about compliance, ain't it? ;-)

The 0/0 phenomena is the media football, it's one of the things that can 
make responsible DNSBL users stay awake at night.  Something needs to be 
said here.

> I agree with this in spirit: it should work.  But it doesn't seem to.

ORDB didn't try it, nor Monkeys, nor OSIRUS.  (At least ORDB and Monkeys 
warned, OSIRUS didn't).  NJABL dynablock (I think that's the right one - 
decommissioned in favour of PBL) and Vixie's old BL are.  Seems to be 
doing the job.  ORDB has been contacted and maybe they'll give it a shot.

> control of the domain or domain's DNS due to registrar, ISP, or

May be a good idea.  Other comments?
> a separate message about that because it's too long to include here.

I'm not going to go thru that one today, other than to say that whatever 
we call it, including "escalation beyond the entities strictly speaking 
responsible for the original listing and likely includes non-abusing 
third parties", something MUST to be said about making sure that the 
DNSBL user has the best possible understanding of the DNSBL policy.  A 
DNSBL user _has_ to know how aggressive the list is relative to the 
range of "stopping the spam only ... putting the cleats to the provider".

Someone may think that everybody who ever sent them any spam should be 
blocked at the ASN level until the heat death of the universe to rub 
their nose in it, but it is NOT the business of the BCP to mandate such 
policies, instead, the BCP aims towards making it as easy as possible 
for a DNSBL user to make an informed choice amongst a broad spectrum of 
options.

A DNSBL operator can weasel out of calling it "collateral damage" by 
defining the DNSBL policies properly, but it is a very real and very 
important consideration in DNSBL choice.  "collateral damage" just 
happens to be the term the industry has settled on for this characteristic.

> what "provocation" is and what an appropriate scope of response is.

I think the section already weasels enough on that.  Totally unprovoked 
(straight and simple scanning of ranges "just because") is pretty 
universally considered a very bad idea.  But since AOL used to "scan if 
you send me email", and I trust their lawyers, that seems to be where 
the divide (for many, but not all obviously) is.

If we get called on it from something with very strong informed opinions 
and the clout to back it up, we can back off.  But until then I want to 
leave it like that.

> litigation takes place to settle some of surrounding questions in some

In the absence of significant debate, I don't see a problem of putting a 
stake in the sand and seeing who salutes to blenderize some metaphors.

Thanks for your valuable comments!

---

From: der Mouse <[email-masked]>
Date: Tue, 1 Apr 2008 22:53:02 -0400 (EDT)

> [A]bsent a legally valid contract, nobody is obligated to provide
> them with any services, of any kind, ever.  The operational reality
> that most people ARE generously provided with most services most of
> the time by default doesn't alter this.

I'm not so sure.  In common-law jurisdictions, there is a rule which
I've seen summarized as "ancient custom has the force of law", which
has been used to do things like establish public right-of-way across
private land where an effectively-public path has existed for long
enough.  It's not clear to me this would wash as a legal argument in
this context, but it's certainly not clear it wouldn't, either.

Does anyone know of any law, either way, in any jurisdiction, bearing
on that theory?  (I'd hope it would be shot down, but would much prefer
to know, either way.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 14:09:58 +1100

> on that theory?  (I'd hope it would be shot down, but would much prefer

Specifically for right-of-way there is a (bi)law that mandates the 
timeout for right-of-way.

If you let someone cross your land without impeding them, for a specific 
period of time (20 years IIRC), after that period you cannot legally 
stop them.  If they have removed anything you set to impede them (eg a 
fence) they can be taken to court for trespass.

I know of no laws relating to technical/internet/computer issues that 
are similar.

/ Mat

---

From: Seth <[email-masked]>
Date: Tue, 1 Apr 2008 23:30:21 -0400 (EDT)

der Mouse <[email-masked]> wrote:

> Does anyone know of any law, either way, in any jurisdiction,
> bearing on that theory?

Look up "public easement".

Seth

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 05:43:51 +0200

Chris Lewis wrote:
 
>> It may or may not be their right to express that opinion --
>> I think it is, but I'm not an attorney even in *this*
 
> Perhaps it should be toned down, but I think it still 
> needs to be said somehow.  You don't have to be a lawyer
> to express an opinion about the law.

The problem is not the opinion expressed in the list.  The
problem is to write "their absolute right" in a BCP when
you are no lawyer.  Some bad ideas published as list could
be illegal where I live.

> The document uses "DNSBL" thruout to handle DNS-query-based
> lists, and explicitly calls out both domains/IPs, and is
> inclusive of SURBLs too. I think adding RHSBL/SURBL/URIBL
> etc will only make the document way more opaque than it
> needs to be and is unnecessary.

Using 127.0.0.2 as always listed test entry is unfortunately
no common practice in RHSBLs I know.  It's also not obvious
that this should be no technical problem.  SURBL is no pure
RHSBL, it covers also IPs.  RFCI is a pure RHSBL today, it
doesn't list 127.0.0.2.  If you think that's not the "b" in
"best" you have to say that RHSBLs have no technical reason
to use say example.tld instead of 127.0.0.2.  I didn't check
if the draft already does this. 

> downplayed/informal legal suggestions are useful.

If you have checked it with lawyers worldwide go for it.
If not avoid it like hell in an IETF BCP.  

> Such a policy may be an effective measure to prevent
> small issues blowing up into big problems.

Much better.

> The 0/0 phenomena is the media football, it's one of the
> things that can make responsible DNSBL users stay awake
> at night.  Something needs to be said here.

+1  Whatever you say, there's no real exit strategy to ever
get out of obscure tools or Web pages related to querying
long dead lists.  Even if the authors update the tools and
Web pages users of old versions or old links will not stop
doing whatever they are doing, hopefully not blocking mail.

 Frank

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 14:44:07 +1100

Frank Ellermann wrote:
> Some idiots,

Ahh yes now I recognise the name.  This is not the appropriate place.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 01 Apr 2008 23:55:12 -0400

> timeout for right-of-way.

I have a mental block on the term used to describe this particular 
theory from common law.  It's similar to but not quite adverse 
possession (squatter law).  It's not eminent domain (expropriation) or 
easement (contractual right-of-way) either.

> fence) they can be taken to court for trespass.

It has to be continuous unfettered access, and the period is different 
from jurisdiction to jurisdiction.  Here I think it's 10 years.  It's 
been applied (successfully) in "walkers versus the mall" cases.

Every year the Nortel Ottawa Campus is "gated" (security stands at the 
road access and "controls access") for a day to break continuity - we 
have ponds that outsiders visit to watch the geese...  ;-)

This is despite the fact that the land is leased from the NCC 
(governmental organization).  Probably a lease requirement, and probably 
why visitors are normally tolerated.

> I know of no laws relating to technical/internet/computer issues that 

How many providers _haven't_ been filtering in one way or another for 
years?  Continuity is presumably broken, even if the law could be 
twisted to apply outside of land access/ownership rights.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 06:00:23 +0200

> Ahh yes now I recognise the name.

http://purl.net/xyzzy/rxwhois.htm#v17

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 1 Apr 2008 23:00:36 -0500

> http://purl.net/xyzzy/rxwhois.htm#v17

Off topic. Keep the personal hatred of whatever offlist.

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 15:06:01 +1100

> have ponds that outsiders visit to watch the geese...  ;-)

My home town a gate with 'private property do not enter' whether open or 
closed whether persons stopped in any other way or not, is sufficient to 
"impede" them.

/ Mat

---

From: Andrew D Kirch <[email-masked]>
Date: Wed, 02 Apr 2008 00:18:11 -0400

> http://purl.net/xyzzy/rxwhois.htm#v17
do not do this again.

Andrew

---

From: Andrew D Kirch <[email-masked]>
Date: Wed, 02 Apr 2008 00:26:28 -0400

> breaks down, email servers _could_ automatically stop trusting the returns.
Mat,
I've generally agreed with you, but I think this is a pretty low 
barrier, and can fix issues for DNSBL's trying to shut down, especially 
with third party software that use DNSBL's to filter spam.

Andrew

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 16:22:32 +1100

>> should be codified as a BCP.

As others indicated 'RHSBl'?

>> further until it starts signalling 127.0.0.2 properly again.

Yeah I know what you are saying but really do you want to have people 
start coding 'the DNSbl is shutdown if this does 127.0.0.2 does not exist'

>> breaks down, email servers _could_ automatically stop trusting the returns.

The point I'm trying to make is that the presence of a test entry or not 
should not indicate any issue other than simple oversight or possible 
problem.  On the other hand I do agree that we need to come to some 
agreement that will cause a server or other automated process to 
discontinue using a DNSbl when instructed by way of a special return.  
Possible options I can see are:

Choose a specific entry to return for 'shutdown' ... suggestions so far:

127.0.0.2 when it doesn't exist. <- I disagree with this - reasons below
127.0.0.1 when returns positive. <- I disagree with this as 127.0.0.1 is 
undesirable in most DNSbl's but it is not an error.
255.255.255.255 when returns positive (my suggestion).
When *any*  lookup returns an address *not* in 127.0.0.0/8.  (This will 
catch all expired domains etc) <- don't recall the source, but would 
also be very agreeable to me.

> with third party software that use DNSBL's to filter spam.

Each is entitled to their comments, I have no problem in a disagreement, 
I just think there are better ways that would not impact due to simple 
oversight or error.  We are looking for a definitive "see this behavior 
and drop this from the config" command/result if we use something simple 
it will negatively impact a lot of users in the event of a simple 
mistake.  Think on this - those who list the world... if they knew to 
use an address other than in 127.0.0.0/8 I'm sure they would have (even 
in OSIRU's case).  In the event of sitefinder morons and other similar 
DNS hijackers, the return of a valid (as in a routable/non RFC 1918) IP 
would cause the software to stop using the DNSbl/DNSbl results, rather 
than "listing the world".  Relying on the presence of 
2.0.0.127.some.domain to return an IP when valid means when the DNS is 
hijacked by a 'sitefinder' the world+dog is listed.

Does that explain my reasoning and persistence on the issue a bit more?

/ Mat

---

From: Steve Atkins <[email-masked]>
Date: Tue, 1 Apr 2008 22:38:12 -0700

> But this is obviously not damage.

That statement is clearly false.

There are two main things a blacklist listing is intended to do.

One is to block spam from being received.

The other is to cause damage, financial and otherwise, to
the owner of the IP address. That is the stated goal of many
blacklists, for at least some subset of their listings.

> is laboring under a badly mistaken concept of what "privilege" means.

Anyone who thinks that blocking email does not cause damage, or
that a blacklist does not block email is... wrong.

Cheers,
   Steve

---

From: Andrew D Kirch <[email-masked]>
Date: Wed, 02 Apr 2008 01:44:40 -0400

Frank Ellermann wrote:
> If you have a problem state what it is.  Folks don't
> go to the trouble to write and publish crap like... 
> http://tools.ietf.org/html/draft-church-dnsbl-harmful
> ...without a reason.
>
>  Frank
>   

Frank,

You've now pissed off two DNSBL operators in a forum which is designed
to engender cooperation among DNSBL operators.  I don't care about Mat's
listing policies, or your opinions of them.  Quite honestly for the
purposes of this forum, I don't give a damn if he's even following
them.  He is the owner and operator of SORBS, I am the owner and
operator of the AHBL.  Our presence is needed here to make this draft a
success, whereas yours is not.  Al Iverson and I both requested that you
stop this behavior after your first post, and you have not.

You opine that DNSBL's are harmful and cite Mat's specifically, however
you then proceed with ad hominem attacks against a DNSBL operator in a
forum where DNSBL operators have come together to examine, evaluate, and
approve standards to improve the quality of all the blacklists willing
to follow these standards.  Either you simply have an ax to grind with
DNSBL's, and their authors (or Mat specifically), you have an ulterior
motive to explain why your actions and words do not align, you are
incapable of forming a coherent argument, you are a liar, or you are a
fool.  Regardless of your reasons, you have demonstrated that you are
incapable of remaining on-topic, and I'm going to have to ask you to
leave as you have demonstrated that you have nothing further to
contribute in this forum.

Andrew
AHBL.org

If you disagree with my stance here, please contact me privately to
discuss the matter, Frank's actions on this list are not the topic of
the list.  I will summarize back to the list if people request it.

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 16:46:50 +1100

> that a blacklist does not block email is... wrong.

A bl[oa]cklist does not block email.
A listing on a bl[oa]cklist can cause email to be blocked.

A bl[oa]cklist without anyone using it will not cause any mail to be 
blocked.
A bl[oa]cklist without anyone using it is pointless.

The statement that 'a blacklist blocks mail' is... wrong.

/ Mat

---

From: Steve Atkins <[email-masked]>
Date: Tue, 1 Apr 2008 22:54:19 -0700

> The statement that 'a blacklist blocks mail' is... wrong.

Sophistry.

Your intent in listing an IP address in your blacklist is that mail
from that IP address be more likely to be blocked or filtered.

Cheers,
   Steve

---

From: Matthew Sullivan <[email-masked]>
Date: Wed, 02 Apr 2008 17:09:01 +1100

Take "me" and 'SORBS' out of the picture when I answer this...

> from that IP address be more likely to be blocked or filtered.

No, the intent is to do *something* that could be to block and/or 
filter, it could also be to indicate an address that should not be 
filtered (granted it would not be called a blocklist in that case), but...

Your statement was 'that a blacklist does not block email is... wrong' 
and you refer to intent as the supporting factor.  An example of why 
that statement is wrong: the original intent of the OPM was to block IRC 
connections, not to block email.  The OPM's original purpose was to 
block IRC connections and not email. (Two similar but actually different 
statements).  People found the OPM was good for blocking spam as well, 
so they - the users - made the OPM entries block email, not the 
operators of the OPM, and before the users did that, entries did *not* 
block/filter/score email.

I agree with why you are saying that, but it is still wrong.

Regards,

Mat

---

From: Steve Atkins <[email-masked]>
Date: Tue, 1 Apr 2008 23:20:16 -0700

> block/filter/score email.

At which point if an opm admin added an IP address to the list,
mail was blocked. If they removed the IP address, mail stopped being
blocked.

The operator of an email blacklist can cause email to be blocked
by a direct action of theirs. They can also cause email to not
be blocked (by use of their list - it may still be blocked for other
reasons, of course) by another direct action of theirs.

It is true that if a blacklist is not publicly known or has such a
poor reputation that literally nobody is using it to block email,
including the operators themselves, then the operators actions
will not block mail or otherwise cause it to be filtered.

At that point, though, it's not a blacklist, and it's out of scope
for this group.

The power of a blacklist operator is given to them by the users
of the blacklist, and the more users there are, the bigger those
users are and the more directly they use the data (i.e. packet
filtering vs a 0.01 spamassassin score) then the more power the
blacklist operator has.

But that power to block email is wielded by the blacklist operator,
and the use it to block email.

Cheers,
   Steve

---

From: "Martin Hannigan" <[email-masked]>
Date: Wed, 2 Apr 2008 02:22:04 -0400

On Tue, Apr 1, 2008 at 7:49 PM, Rich Kulawiec <[email-masked]> wrote:
>  But I chose

I'm not a lawyer and I try not to play one on the Internet, but this
makes a lot of sense to me. It's much akin to claiming that you've
been 'censored' on a private system. Private systems don't censor,
they assert their rights.

Best,

Martin

---

From: Andrew D Kirch <[email-masked]>
Date: Wed, 02 Apr 2008 02:46:33 -0400

Steve Atkins wrote:
> by a direct action of theirs. 
But only so long as the MTA admin, enduser, or intermediary using the 
DNSBL, continues to use us.  I had an experience with Google's Gmail 
servers roughly a year ago where the GMail servers were being used to 
propagate advertisements for a child porn site.  After several hours 
attempting to contact GMail's postmasters via e-mail, friends who knew 
Google employees from Summer of Code, and calling their corporate 
operator trying to get someone in GMail abuse,  I gave up, and RHSBL 
listed gmail.com, and added the individual IP's that sent this spam to 
the DNSBL.  I had several of our users e-mail us asking us if we were 
out of our minds to list GMail, I replied with samples of the CP spam 
we'd gotten from GMail.  Some of these users stopped using the AHBL 
because of this.

I think this scenario is apropos here for several reasons.  One: none of 
these blocks were intended to cause "collateral damage".  I listed a 
domain where I had almost 2 dozen spam sources for child porn, and the 
domain used to spamvertise the child porn.  I say that this didn't cause 
collateral damage because what was blocked was the source of spam, and 
the source of spam alone.  No reasonable person however will look at 
this and say that ham was blocked because of this.

Also this is a situation which disproves the concept that blacklists 
block e-mail.  Our ability to block e-mail begins and ends on the user 
of our list's server.  We have no ability to dictate what the user does 
with our list, or when the user enables, or disables filtering based on 
our list.  It even stands to reason that there are users out there who 
so detest DNSBL's that they whitelist based on our content.  One must of 
course accept this, and move on.

For those that are curious, one of my volunteers did get ahold of a SoC 
volunteer who got her to an exec at Google, and then to an abuse role at 
Gmail to stop the CP spam.  Approximately 17 hours after I placed the 
initial blocks they were removed.

Andrew
AHBL.org

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 2 Apr 2008 08:56:15 +0200

Andrew D Kirch wrote:

> Our presence is needed here to make this draft a success,
> whereas yours is not.  Al Iverson and I both requested
> that you stop this behavior after your first post, and
> you have not.

You have an odd style to discuss an off list mail, but you
quoted it completely, whatever you read in it is visible. 

> You opine that DNSBL's are harmful

Nonsense.  I gave you a link to a draft stating that, off
list, and "crap" isn't the word I'd use when I support it.

> you then proceed with ad hominem attacks against a DNSBL
> operator

Certainly not today and not here, and FWIW also not in the
last year on any list.  
 
> If you disagree with my stance here, please contact me
> privately to discuss the matter

When you anyway answer on list that's pointless.  Whatever
you are up to, it's not related to discussing one or both
of the proposed drafts.  In case you didn't know this, at
some point in time they need some form of consensus, and
starting flamewars won't help.

 Frank

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Apr 2008 04:53:22 -0400

> on that theory?  (I'd hope it would be shot down, but would much prefer

I recognize this concept - it's been used, for example, to defend public
right of access to trails that cross what's now farmland.

But (a) I don't think any Internet services qualify as "ancient",
even if we stipulate "Internet time". ;-)

And (b) a law or judicial ruling applying this to Internet services --
that is, stating that service providers MUST provide certain HTTP or
SMTP or FTP or other services to anyone/someone who doesn't have a valid
contract -- would be disastrous for the Internet.  I'm not aware of any
such law or ruling, but I have a vague recollection that this came up
in one of the spammer legal actions against AOL.  I'll try to find it
and see if my memories on this point are accurate.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Apr 2008 06:15:03 -0400

> blacklists, for at least some subset of their listings.

I'm aware that's sometimes a stated goal.  But "stated goals" don't
define reality.  (For example, I cite the canonical "We take privacy
seriously" boilerplate which now routinely appears in the press releases
of every entity which has disclosed a major data leak.)  While this
might be a stated goal, it's not an achievable goal, because DNSBL
listings (or use of those to deny privileges) can't possibly inflict
damage on anyone.

( This is not to say, by the way that damage isn't possible in such
situations.  Perhaps it is.  But if that comes to pass, please note that
all such damage is completely self-inflicted by organizations which
have made three serious errors:

First, they have conflated their transient, limited privileges (e.g.,
access to FTP services) with perpetual, unlimited rights.   Or perhaps
with contractual obligations which, absent a contract, don't exist.

Second, they have presumed that HTTP or other service providers will
generously continue to provide those privileges even though they're
not obligated to and may cease doing so (in whole or part) at any time
without notice, or may unilaterally change the terms under which they
offer such services, or may restrict such offerings as they see fit.

And third, they've built deeply-flawed cognitive/operational/business
models around the first two errors.  We've seen this in other contexts
-- for example, search engine listings/rankings.

So if, for example, I build a web site which contains tens of thousands
of pages of useful information, and someone decides to launch a
business based on repackaging that information for sale -- and enters
into contractual agreements with its customers to provide same -- and
then I decide one day to block their access to my site, or to turn it
off entirely, have I "damaged" them?  No.  I have merely exercised my
ownership of my resources.  They may be disappointed, upset, angry,
worried, etc., and so might their customers, and this may translate
into some form of damage (to goodwill or to profits or something else),
but I'm not the cause of it: their own errors -- see above -- are the
cause of it.  Substitute SMTP for HTTP and the same applies. )

---Rsk

---

From: "David Nicol" <[email-masked]>
Date: Wed, 2 Apr 2008 07:56:07 -0500

in response to eventual production of term "public easement" in
discussion of "damage" perhaps a form of "damage" which might
be caused by listings could be found in case law indexed under
"libel?"
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Apr 2008 09:40:55 -0400

> be caused by listings could be found in case law indexed under

That's a good point.  But (and here comes the amateur lawyering)
I believe that a valid defense against libel is truth.  If one states:

	"I received spam from 1.2.3.4 and I am listing 1.2.3.4."
or
	"I received spam from 1.2.3.4 and I am listing 1.0.0.0/8."
or
	"I am listing 1.0.0.0/8 because it's Wednesday and I feel like it."

then provided those statements are true, I don't see where
any libel has been committed.

Let me also note (continuing earlier analogy) that if you knock
on my door to request entry, or send me a letter that you want
me to read, or ask for http://www.example.com/private.html, and
in all cases, I decline your requests, that is not libel.

---Rsk

---

From: Seth <[email-masked]>
Date: Wed, 2 Apr 2008 09:49:36 -0400 (EDT)

> from that IP address be more likely to be blocked or filtered.

There are whitelist DNSBLs.

There can certainly be DNSBLs designed to make some mail more likely
to be accepted, and other mail less likely.  There are certainly
DNSBLs with information that some sites use to accept more, and
others use to reject more (e.g. country-code).

There are DNSBLs that exist to prove a point, and the intent of the
lister is not to have any sort of usage (nofalsenegatives,
nofalsepositives, noprimes).

Seth

---

From: John Levine <[email-masked]>
Date: 2 Apr 2008 14:49:48 -0000

>this context, but it's certainly not clear it wouldn't, either.

That's adverse possession.  I'm pretty sure it's unique to real
estate law.

In any event, it doesn't require anyone to provide any services to
anyone.  It just means that the owner can't exclude the users from
their customary use, e.g., walking along a footpath.  I would be
astonished if owners were required to actively do anything to assist
the users, e.g., maintain a footbridge they happened to use.

R's,
John

---

From: John Levine <[email-masked]>
Date: 2 Apr 2008 15:16:19 -0000

>I believe that a valid defense against libel is truth.

Only in the United States, not in the UK nor in many other countries.
(Google for "Zenger".)

And adverse possession only applies to real estate.

The IETF has its own group of Junior Lawyers, and I am pretty sure
that if we make any legal claims, they'll send the doc back to us on
the reasonable grounds that laws differ all over the place, and none
of us are legal experts even for the places we live.

So I think we MUST take out anythink that's likely to be read as legal
advice.

On the other hand, if this BCP is successful, we can expect people to
wave it around in court cases to try to establish that some blacklist
does or does not act in accordance with industry standards.  So please
concentrate on making it clear, and keeping in mind the C, not too far
from what respectable BLs do now.

R's,
John

---

From: John Levine <[email-masked]>
Date: 2 Apr 2008 15:18:19 -0000

>This Note is IMO irrelevant

It's IRTF boilerplate, so it stays.  If this turns into an IETF BCP,
we'll change the boilerplate to whatever BCPs have this week.

>standards track, as it should.

I expect it to be published as informational.

R's,
John

---

From: David Wilson <[email-masked]>
Date: Wed, 02 Apr 2008 16:37:55 +0100

> Only in the United States, not in the UK nor in many other countries. 

(To be picky, there is no such thing as 'UK' law. Scotland has a
different legal setup to England and Wales.)

Looking up "libel truth" in UK pages for Google pointed me to:

http://www.swarb.co.uk/lawb/defTrueLibel.shtml

which is from a personal injury solicitors, so has some legal standing.

The important point is that a libel in English law has to be both untrue
and defamatory.

Something that "causes him to be shunned or avoided" is one means of
defamation and would seem to be a good description of a DNSBL!

cheers

David Wilson.

---

From: der Mouse <[email-masked]>
Date: Wed, 2 Apr 2008 11:44:50 -0400 (EDT)

> And (b) a law or judicial ruling applying this to Internet services
> [...] would be disastrous for the Internet.

Yes, it would.  As I said, I'd hope it would be shot down, but would
much prefer to know about anything of the sort, either way.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Seth <[email-masked]>
Date: Wed, 2 Apr 2008 11:54:59 -0400 (EDT)

The definition of "damage" is a philosophical question.

If I take an action, and as a result you're worse off than you'd be if
I hadn't taken it, have I damaged you?

Think hard before answering "yes".

The action is to lock my door.  You're a thief who walks down the
street, checking for unlocked doors.  If I hadn't locked my door,
you'd have gone into my house and stolen $1,000.  As a result of my
action, you're $1,000 worse off than you'd be if I hadn't taken that
action.  Have I damaged you?

I say, in order for my action to damage you, I must have violated your
rights by that action.  Telling a public truth about somebody is not a
violation of rights.

Seth

---

From: Tony Finch <[email-masked]>
Date: Wed, 02 Apr 2008 16:58:08 +0100

>Only in the United States, not in the UK nor in many other countries.

Yes, truth *is* an absolute defence against libel in the UK.
See for example http://www.urban75.org/info/libel.html

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAIR ISLE: NORTHWEST 5 OR 6 VEERING SOUTHEAST 4 OR 5. VERY ROUGH BECOMING
MODERATE OR ROUGH. SHOWERS THEN RAIN. GOOD BECOMING MODERATE.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Apr 2008 09:06:58 -0700

> There are whitelist DNSBLs.

No, there aren't.

If it's a whitelist, it's not a blacklist. As for operational use of a
whitelist as a blacklist, see my mention of Habeas below.

> nofalsepositives, noprimes).

And yet, those lists still get significant usage. Up to and including
blocking mail if an IP address is listed on them. That the operator[1]
of those lists is listing an IP address due to some inner aesthetic
rather than any relationship to mail emitted from those IP addresses[2]
does not affect the fact that it is the combination of the listing in  
the
blacklist and that there is at least one mailbox provider using the
blacklist to filter mail that will cause the mail to be blocked.

There are going to be edge cases, certainly. Perhaps there's a DNSBL
that the operator doesn't intend to be used to affect mail delivery, and
isn't aware that is being used to affect mail delivery (such as opm in  
it's
first few days, perhaps)? That operator is not aware that they're  
running
a DNSBL, so they're out of scope for this document (if they're not aware
that they're running a DNSBL then they're not going to be affected by
a BCP for DNSBLs). Perhaps there's something that looks like a DNSBL
on a technical level, but it's not intended to be used as one, has  
millions
of users for it's real purpose and that a couple of people misuse it  
as a
DNSBL isn't going to change the behaviour of the operator (in-addr.arpa
and the Habeas whitelist would be two examples there). Again, though,
if the operator does not believe they're running a DNSBL, they're out of
scope for a DNSBL BCP.

We're talking about common practice, as well as best practice, remember.

Cheers,
   Steve

[1] That I'm the operator for two of the lists you mention means I've
thought about this.

[2] The same is true of some non-abstract lists too.

---

From: SM <[email-masked]>
Date: Wed, 02 Apr 2008 09:10:24 -0700

>So I think we MUST take out anythink that's likely to be read as legal

Yes.

>from what respectable BLs do now.

That's something to consider before being added to the 
acknowledgements.  Having the document as a BCP from the authors' 
perspective instead of a "CP" is better.

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 12:19:58 -0400

> That's adverse possession.  I'm pretty sure it's unique to real

Adverse possession is squatter law.  It means that the squatter assumes 
ownership of the land.  I think the law we're thinking about is a bit 
different - establishing a legal right-of-way.  In the former, the 
previous owner has no obligation to the new one. In the latter, there is 
some stuff about ensuring that the, say, footpath doesn't become 
dangerous.  Eg: they can't construct pitfalls.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 2 Apr 2008 11:28:26 -0500

On Wed, Apr 2, 2008 at 11:06 AM, Steve Atkins

>  whitelist as a blacklist, see my mention of Habeas below.

I have to agree with Steve, here.

A whitelist using a DNSBL-like publishing mechanism isn't a DNSBL.
It's a whitelist. A DNSWL.

Regards,
Al Iverson

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Apr 2008 09:32:42 -0700

> It's a whitelist. A DNSWL.

The interesting case is where a list is being used to publish something
like metrics or datapoints about mail delivery (e.g. ISIPP) and it's not
purely a blacklist or whitelist, just something email-related  
delivered by
DNS. That seems even further out of scope for a BCP on binary  
blacklists,
though.

Cheers,
   Steve

---

From: Bruce Stephens <[email-masked]>
Date: Wed, 02 Apr 2008 17:33:02 +0100

David Wilson <[email-masked]> writes:

[...]

> defamation and would seem to be a good description of a DNSBL!

IIUC (and IANAL) the difference with English law is that the defendant
must show that the statement is true.  So (journalists have argued,
anyway) it reverses the usual innocent-until-proven-guilty ordering of
things.  I imagine this wouldn't particularly affect
DNSBLs---presumably you'd easily be able to keep evidence of whatever
your DNSBL is claiming.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 12:36:41 -0400

> you are no lawyer.  Some bad ideas published as list could

I'll fix the other place where it says legal/law.

> if the draft already does this. 

Is there a testing convention for RHSBLs currently in use?  RHSBLs 
_could_ still use the 127.0.0.2 convention just like DNSBLs do, there's 
really nothing preventing it.  Other than deciding whether the octets 
should be reversed or not.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 12:38:49 -0400

> It's a whitelist. A DNSWL.

You're making me have to put in a glossary.... ;-)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 12:44:17 -0400

> from what respectable BLs do now.

Try this rewrite (gets rid of a legal note)

<t>A DNSBL without DNSBL users does not
block (or otherwise impair) email or any other Internet service.
A DNSBL user voluntarily uses the DNSBL data to guide their decisions,
and the user therefore MUST assume responsibility for the
consequences.</t>

<t>DNSBL operators are expressing an opinion through the
publication of a DNSBL.  However,
it is through abiding by the guidelines set forth in this BCP that
the operators of a DNSBL may gain the trust of their users.</t>
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "David Nicol" <[email-masked]>
Date: Wed, 2 Apr 2008 11:48:13 -0500

>  You're making me have to put in a glossary.... ;-)

I liked that the document seemed to frame listing as an early attempt at
"reputation service"
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Seth <[email-masked]>
Date: Wed, 2 Apr 2008 13:18:32 -0400 (EDT)

> in all cases, I decline your requests, that is not libel.

Or, you knock on my door, and I explain "my astrologer recommended
that I not admit anybody wearing a red shirt" there's still no libel.

Seth

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 2 Apr 2008 12:40:11 -0500

>  that I not admit anybody wearing a red shirt" there's still no libel.

Analogies to unrelated things are a poor substitute for competent legal advice.

Regards,
Al Iverson

---

From: "J D Falk" <[email-masked]>
Date: Wed, 2 Apr 2008 14:01:55 -0400

> The statement that 'a blacklist blocks mail' is... wrong.

And yet, if you ask pretty much any DNSBL user what a DNSBL is for,
they'll say it's for blocking mail.  If you ask anyone whose IP (or
other identifier) has been listed what the DNSBL did, they'll say it
blocked their mail.  We anti-spammers have argued this for a decade and
we can argue it for another decade, but a reasonable person will come to
a very different conclusion than we do.

So, the core question: is this BCP written for the most repetitively
pedantic of anti-spammers (some of whom I see on this list -- hi,
guys!), or is it written for reasonable people?  And, if the former, why
are we bothering?

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 14:04:23 -0400

> I liked that the document seemed to frame listing as an early attempt at

That really was deliberate - largely as an attempt to move away from the 
"blacklist cabal" stuff.  But obviously we missed one or two.  The 
remaining one or two need to be in there.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "J D Falk" <[email-masked]>
Date: Wed, 2 Apr 2008 14:06:49 -0400

Steve Atkins wrote:

> The interesting case is where a list is being used to publish
> something like metrics or datapoints about mail delivery (e.g. ISIPP)
> and it's not purely a blacklist or whitelist, just something
> email-related delivered by DNS. 

Yep, there are a few such things now -- but not enough (and not in wide
enough usage) for a BCP yet.

> That seems even further out of scope
> for a BCP on binary blacklists, though.

+1

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 14:21:47 -0400

> that I not admit anybody wearing a red shirt" there's still no libel.

The latter is not really an analogy for the situation.

More like:

You knock on my door, and I explain "my astrologer recommended that I 
not admit anybody that cross-dresses in their bedroom.  And he says that 
you cross-dress.".

If the astrologer's assertion is untrue, that _can_ be actionable libel, 
but there are several other things you'd have to prove before you'd win 
such a case.  You'd probably have to get past the notion that I don't 
have to give any reason to bar you, hence the truth or falsity of my 
reasoning is irrelevant. Whether that same reasoning would apply to an 
ISP I dunno, because it's not a one-to-one situation.  It'd certainly be 
argued that it does.  Comcast is in e360 v. Comcast.

I think the CDA protections would apply in any event, so it's moot as 
per the ISP.

As for the lister...  This is why we said this:

In other words, be direct and honest and clear about the listing
criteria, and make certain that only entries meeting the published
criteria are added to the list.  For example, some DNSBL operators
have been known to include "spite listings" in the lists they
administer -- listings of IP addresses or domain names associated
with someone who has insulted them, rather than actually violating
the published criteria for inclusion in the list.
There is nothing inherently wrong with this practice so long as it
is clearly disclosed.  For example, a DNSBL described as listing open
relays only MUST NOT include IP addresses for any other reason.

The above may sound like an imposition on the DNSBL operator.  On the 
contrary, by following it, they avoid getting into certain types of 
legal difficulties.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 14:25:54 -0400

>> for a BCP on binary blacklists, though.

If I'm forced into a glossary of DNSBL types (DNSBL, DNSWL, RHSBL, URIBL 
etc), other DNS lookupy things (like routeviews, ISIPP etc) should be 
mentioned in passing, if only to rule them out of scope.

A one page appendix maybe.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Larry M. Smith" <[email-masked]>
Date: Wed, 02 Apr 2008 13:34:27 -0500

> "damage" in this context.

IMHO, The term "collateral damage" has been well established in DNSBL 
vernacular to mean listing of additional non-spamming objects in an 
attempt to promote policy change, or possibly a listing error.

Perhaps it could be defined in the document, but I believe the term more 
or less stands on its own.  See 
http://en.wikipedia.org/wiki/Collateral_damage

---

From: "Larry M. Smith" <[email-masked]>
Date: Wed, 02 Apr 2008 13:42:53 -0500

Chris Lewis wrote:
(snip)
> mentioned in passing, if only to rule them out of scope.

Only in that the document refers to DNSBL as a generic.  It could be a 
DNSBL, DNSWL, RHSBL, URIBL, DNSSL (scoring list returning unsigned 
intergers) ... or whatever;  DNSBL in this document refers to some sort 
of DNS based reputation service.

---

From: Andrew D Kirch <[email-masked]>
Date: Wed, 02 Apr 2008 14:50:08 -0400

> a very different conclusion than we do.
Guns don't kill people, people kill people with guns.  Blacklists don't 
block e-mail users using blacklists block e-mail.

Seriously, get it right or I'l lhave to go all card-carrying-NRA-member 
up in here! :)

(yes I really am one)

Andrew
AHBL.org

---

From: "Larry M. Smith" <[email-masked]>
Date: Wed, 02 Apr 2008 13:56:29 -0500

Chris Lewis wrote:
(snip)
> should be reversed or not.

I believe it may be somewhat common to list example.com in this case... 
  And in keeping with a DNSBL should not list 127.0.0.1, and RHSBL 
should not list "localhost.localdomain"

Example;
$ dig +short example.com.rhsbl.sorbs.net
127.0.0.11
$ dig +short localhost.localdomain.rhsbl.sorbs.net
$

---

From: Rich Kulawiec <[email-masked]>
Date: Wed, 2 Apr 2008 15:36:43 -0400

I agree with most of your responses/changes/fixes/updates; most of the
ones that I don't, I'm going to sit back and think for a while before
revisiting them, because you raise some good points that really deserve
some serious offline thought.  Thanks for the detailed response, it's
most illuminating.  But I'm going to respond to one item in particular.

> range of "stopping the spam only ... putting the cleats to the provider".

I agree with this sentiment, and with most of the way you've expressed it.
(And with the following paragraph that I've elided.)

> happens to be the term the industry has settled on for this characteristic.

Let me see if I can explain why I think this is a fairly big deal.
I'm going to advance three slightly different -- but overlapping --
reasons why, one of which is a repeat.

I'm going to begin by (shockingly) agreeing with you in part. ;-)

People *do* use this terminology.  Heck, I've probably been one of them.
But it's bad terminology, because it doesn't describe the situation
accurately.  One of the many good things this BCP could do is to
clarify that this term's a misnomer.  (Or, failing that, it could at
least not propagate it further and/or lend it some measure of credibility.
I'll get to that below.)

1. I've read all the followups here, and nobody has yet shown how
a DNSBL listing (or use of it) damages anyone or anything.  To be sure,
they've shown how people might damage themselves by relying on faulty
assumptions, but that's hardly the responsibility of a DNSBL operator
or DNSBL user.

	( If you rely on my well for free water every day, you're not
	damaged by my decision that you don't get free water any more.

	This is true even if your bread-making business is no longer
	viable due to lack of my water.

	You may in fact be damaged, but not by me: you did it to yourself
	by virtue of your flawed business model. )

I think the reason this can be difficult to wrap one's head around
is that we pretty much take for granted the idea that all offered 'net
services are available to everyone all the time...so much so, that
eventually we begin to consider them an entitlement, not a privilege.

But as lots of people have pointed out elsewhere, one's "entitlements"
only extend to the border of one's ISP (or business network or campus
network or whatever).  Everything beyond that is furnished either
(a) by contractual agreement (like a paid web site membership) or
(b) at the pleasure of its keepers.  And if it pleases those keepers
in (b) to revoke those privileges, that's not damage: it's just
exercise of the rights of ownership.

2. Above I said that I don't want to see this BCP lend credibility
to what I consider to be a serious misnomer.  Here's another
reason why: I can easily see a BCP with that term being waved around in
court by some spammer's attorney as supporting evidence for the claim that

	...defendant deliberately damaged my client's business because
	defendant knowingly carried out a procedure *documented and
	designed to cause damage*...

Arguments in this direction have already been trotted out; they don't
need to be furnished with additional ammunition, especially if it carries
any kind of imprimatur.

3. There are so many possible motives for all the myriad DNSBL listings
and the myriad ways they're used, that absent explicit statements on
a per-listing and per-usage basis by those responsible for both, it's
impossible to say what anybody's motive is.  So I don't think this BCP
should get into that -- I don't think it's necessary or desirable to try to
get inside the heads of people running DNSBLs or using them.  Especially
since that's bound to be incredibly error-prone: one DNSBL operator's
default procedure might be another one's escalation and both might be
employed by a user -- perhaps contrary to the designs of both operators --
to assign message scores, that is, neither for acceptance nor rejection.

To say that in a broader way: I think this BCP should concern itself
with operational issues, not indirect consequences of usage for third
parties -- and "collateral damage", in addition to being a misnomer,
falls into that category.

---Rsk

---

From: Seth <[email-masked]>
Date: Wed, 2 Apr 2008 18:08:05 -0400 (EDT)

"J D Falk" <[email-masked]> wrote:

> they'll say it's for blocking mail.

If you're a little more explicit, they'll admit it's for advice on
which email to block.

> If you ask anyone whose IP (or other identifier) has been listed
> what the DNSBL did, they'll say it blocked their mail.

Or, it advised others to block their mail.

> guys!), or is it written for reasonable people?

The latter, which is not a reason for using imprecise terminology.

Seth

---

From: Seth <[email-masked]>
Date: Wed, 2 Apr 2008 18:30:08 -0400 (EDT)

>> Rich Kulawiec <[email-masked]> wrote:

What is this, a contest for silly analogies?  I can keep playing.

> not admit anybody that cross-dresses in their bedroom.  And he says that 

Or "My astrologer recommended that I not admit anybody that lives on
the same block as somebody who cross-dresses in their bedroom.  And
somebody on your block cross-dresses."

That's much less likely to be actionable libel, because it doesn't
identify you.

Seth

---

From: der Mouse <[email-masked]>
Date: Wed, 2 Apr 2008 18:44:14 -0400 (EDT)

>> If I'm forced into a glossary of DNSBL types (DNSBL, DNSWL, RHSBL,
>> URIBL etc), [...]
> Only in that the document refers to DNSBL as a generic.  It could be
> a DNSBL, DNSWL, RHSBL, URIBL, DNSSL (scoring list returning unsigned
> intergers) ... or whatever;  DNSBL in this document refers to some
> sort of DNS based reputation service.

Might I suggest DNSL, then, instead of DNSBL?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: der Mouse <[email-masked]>
Date: Wed, 2 Apr 2008 18:45:22 -0400 (EDT)

> Guns don't kill people, people kill people with guns.  Blacklists
> don't block e-mail users using blacklists block e-mail.

Y'know, I think that may be the first time I've seen anyone trot out
that NRA line as an analogy for which I think it's actually a *good*
analogy.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 19:37:30 -0400

> Might I suggest DNSL, then, instead of DNSBL?

That, is one of the thoughts I had.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "J D Falk" <[email-masked]>
Date: Wed, 2 Apr 2008 19:46:51 -0400

> der Mouse wrote:
 [ . . . ]
>  That, is one of the thoughts I had.

This is a Best Current Practices document, and thus we've already been
through arguments about intorducing new practices that aren't currently
in widespread use.  Shouldn't we similarly avoid introducing new /words/
that aren't currently in widespread use?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Matthew Sullivan <[email-masked]>
Date: Thu, 03 Apr 2008 11:16:13 +1100

> that aren't currently in widespread use?

Well ya know I've seen DNSBL = DNS Based List as well as DNS Black List 
and DNS Block List.... and you know what for ages I thought the original 
definition was DNS Based List (just because that is exactly what it is).

/ Mat

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 02 Apr 2008 19:36:32 -0700

> I hadn't taken it, have I damaged you?

I think that's the wrong question.

 If I take an action, and as a result you're worse off than you were
 before I took it, have I damaged you?
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 02 Apr 2008 19:45:23 -0700

On Apr 2,  3:36pm, Rich Kulawiec wrote:
> a DNSBL listing (or use of it) damages anyone or anything.
> 

The distinction is that when the term "collateral damage" is used, we
aren't talking about the baker, we're talking refusing water to the
whole village because the baker was taking more than his share.  It
doesn't matter that none of the villagers were entitled to the water;
it doesn't matter that you chose to refuse them all water based on my
advice; it doesn't even matter who (the baker, you, or me) caused the
damage.  The villagers are still damaged collaterally.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 02 Apr 2008 21:14:49 -0400

> definition was DNS Based List (just because that is exactly what it is).

My other thought was exactly that - explicitly use the "based list" 
definition, note/acknowledge the variations of "B" in common usage, and 
briefly enumerate the other types of "based list" (DNSWL etc), mention 
scoring etc.

That's similar to what I did with the terms "spam", "velveeta", "jello" 
when I wrote the usenet spam FAQ back in 1994.  That document introduced 
new terms that are used til this day (and nobody's used "velveeta" or 
"jello" since then, thank heavens.

---

From: Seth <[email-masked]>
Date: Thu, 3 Apr 2008 00:00:52 -0400 (EDT)

> before I took it, have I damaged you?

Today, you have no idea whether you can reach someone by email next
week.  Tomorrow, your IP is added to a list.  You still have no idea
whether you can reach him next week.  Next week, you attempt to email
him, and fail.  Did adding your IP to the list make you worse off?

A website is having a "pick the funniest joke" contest.  I vote for a
joke that isn't yours.  Have I damaged you?  You're worse off, being
less likely to win, as a result of my action.

A friend was planning to buy food from your grocery store to cook for
dinner.  I invite her to a restaurant.  Have I damaged you?

Seth

---

From: David Cawley <[email-masked]>
Date: Wed, 02 Apr 2008 21:27:32 -0700

>> briefly enumerate the other types of "based list" (DNSWL etc), mention 

Personally, I like the idea of defining DNSBL as DNS Based List as
it simply implies list data served up via DNS and it's generic enough
to encompass the various flavors - RHSBL's, URIBL's etc.

Whereas 'Blocklist' implies an action of blocking and the associated
collateral damage. Really, it's the consumer of the data that decides
on the action whether that be blocking, grey listing, tarpitting or even
bypassing spam filtering based on the data returned by the query.

Just my 2c and I'd like to thank all of you working on the document.

Rgds,

David

-- 
David Cawley
Product Development

MailChannels - Reliable Email Delivery
http://mailchannels.com
778 785 6145 tel
604 677 6320 fax

---

From: "Martin Hannigan" <[email-masked]>
Date: Thu, 3 Apr 2008 00:32:03 -0400

>  Just my 2c and I'd like to thank all of you working on the document.

Not all consumers of the data are clear on the purpose or the
realities of using such lists and the more that this document can
address considerably less experienced users of BL's, the better. JD
was clear when he articulated that if this document is for the
professional pedantic spam fighters, well, there might be better
things to do.

I agree that 'Based List' is the way to go.

-M<

---

From: Bart Schaefer <[email-masked]>
Date: Wed, 02 Apr 2008 22:03:48 -0700

On Apr 3, 12:00am, Seth wrote:
> Subject: Re: [Asrg] Round 2 of the DNSBL BCP - "collateral damage"
>

I didn't say the answer to the question was always "yes." However, in
response to this specific straw man, just because I don't know that I'm
worse off doesn't mean that I'm not.

It also doesn't mean that blame for my being worse off can be attached
to the nameless entity who added my IP to the list. Holding someone
responsible is entirely beside the point. If my own behavior had no
bearing on whether my IP is (or is not) on the list, any consequences
(intended or not) that affect me are "collateral," and if those
consequences are adverse they are "damage."

So if the BCP is going to say anything about adverse consequences that
affect a larger group than the directly-identifiable actors, the words
"collateral damage" have the appropriate meaning.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 01:12:59 -0400

> Just my 2c and I'd like to thank all of you working on the document.

I'd like to thank everybody here to making this a rather more productive 
process than I had feared <grin>.

We seem to be converging reasonably well to something that most people 
can at least tolerate.  Can't ask for much more than that.

There seem to be three specific issues under discussion at this point:

- using the right terminology to make the document inclusive of RHSBL, 
URIBL, DNSWL etc, but not necessarily things like routeviews.  I'm going 
to put a couple of paragraphs at the end of the intro expanding "DNSBL" 
as "DNS-Based List" for the purpose of the document, noting the 
alternate expansions in use, briefly describe DNSB[lack]L, RHSBL, URIBL, 
DNSWL as in-scope (have I missed something?), and other more 
"informational, not good/bad indicator" things like ISIPP and Routeviews 
as generally out of scope, but who MAY consider some of the items in the 
BCP as best practise anyway (eg: test, shutdown).  Also some wording 
about users can use them as an absolute (or one factor) block/whitelist 
or a scoring contribution.

[meta: Is it going to be a problem that the IETF document file name has 
"blacklist" and not "dnsbl"?  Leave it alone or change?  If I were to 
change it, I assume that means that it's effectively a brand-new 
document and the revision number reverts to 01.

- "functional signaling" procedures for domain-based DNSBLs.  I could 
either suggest example.com, suggest 127.0.0.2, or punt ("no common 
mechanism is apparent, make one up and document it so that users can 
automate testing if they wish").  I'm inclined to 127.0.0.2 because 
domain-based lists can do it just as easily as IP-based ones.  Are there 
strenuous reasoned objections to that?

- Material about collateral damage - terminology used, etc. It seems 
clear that most think that something has to be said.  I'm going to 
reread the list comments and take another run at that section.  So, it 
may be worth stopping the current threads on it and wait for my new attempt.

If things go as I plan, I will be putting the new draft up on the IETF 
site in a few days.  It will be "02" there, but in order to disambiguate 
  it from the current 02 discussion from the emailed copy, I'll kick off 
discussions with a subject line saying "02A" which will help me 
distinguish the subsequent discussion.

[Or will the IETF accept me calling it 03?]

---

From: Steve Atkins <[email-masked]>
Date: Wed, 2 Apr 2008 22:20:30 -0700

> strenuous reasoned objections to that?

No preference, as long as something is documented in the BCP. Punting
would be Bad, as this point is (IMO) the best reason for the BCP to  
exist
as an RFC-style document ("MUST").

> may be worth stopping the current threads on it and wait for my new  

I'm not convinced "collateral damage" is a great term, but something
needs to be said about the subject. A distinction between unavoidable
collateral damage ("We list IP addresses that emit a lot of spam, even
if they emit real email too."), accidental collateral damage ("We don't
intend to ever block legitimate email, but we may sometimes  
accidentally")
and intentional collateral damage ("We list IP addresses that emit only
legitimate email, in order to punish the owners of those addresses")
might be needed, despite the complexity that adds.

Cheers,
   Steve

---

From: Andrew D Kirch <[email-masked]>
Date: Thu, 03 Apr 2008 01:48:48 -0400

> that NRA line as an analogy for which I think it's actually a *good*
Why's that?  I'm armed to the teeth, my guns have never shot anything I 
didn't aim at.

Andrew

---

From: Andrew D Kirch <[email-masked]>
Date: Thu, 03 Apr 2008 01:50:20 -0400

> Why's that?  I'm armed to the teeth, my guns have never shot anything I 
Apologies, I intended to send this to der Mouse privately.

Andrew

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Apr 2008 08:40:07 -0400

> to encompass the various flavors - RHSBL's, URIBL's etc.

I concur with this, and suggest that perhaps using it would avoid the
necessity of getting into the alphabet soup of all the other terms.

---Rsk

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Apr 2008 09:00:38 -0400

> damage.  The villagers are still damaged collaterally.

I knew I'd hate myself in the morning for introducing this analogy. ;-)

I don't see that they are damaged in any way.  They were never entitled
to the water in the well.  They might have *assumed* they were, because
its owner chose to generously extend privileges to them for some period
of time, but if so, that assumption is their error.

To look at it another way (oh good grief!): their enjoyment of access
to the well for some period of time, at the pleasure of its owner,
was a positive for them.  With the cut-off, that positive no longer exists.
That does NOT result in a negative: it's merely the cessation of
a positive, returning the balance to zero.

No negative, no damage.

Similarly, if I permit mail from example.com for five years but cut it
off tomorrow, I have not damaged the users at example.com.  I've simply
stopped providing them with a free service (a positive) thus returning
the balance to zero: I provide them nothing.  I have not in any way
damaged them, I've just stopped being generous to them.

As an aside, let me note that the correct mental perspective for the
villagers (above) is not to blame the keeper of the well, who has,
after all, generously shared resources for some period of time.  It's
to blame the baker, who drew water in excess every day, severely
impacting my ability to use my own resource.  But as everyone on this
list probably knows, this is not how it plays out with email: users
often vociferously attack the very people who have been exceedingly
generous to them *at the same time that generosity has been repaid
with systemic, sustained abuse*.   This is one of the reasons I've
grabbed onto this point with the tenacity of a starving Chihuahua
holding onto a pork chop: I don't want to see the "victim" attitude
that so many users mistakenly adopt reinforced by a document that
tells them they've been "damaged", when clearly they haven't.

---Rsk

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 3 Apr 2008 09:47:40 -0500

>  strenuous reasoned objections to that?

Yeah, I think it should be example.com. I think it should be the same
type of lookup that you would normally do. I think if you make the
test lookup an IP, you will confuse novices into doing IP-based checks
by accident.

Somebody should nudge folks from SURBL or URIBL to join us here for
their take, or maybe reach out to them if you know them well.

Best,
Al

---

From: John Levine <[email-masked]>
Date: 3 Apr 2008 15:00:08 -0000

>test lookup an IP, you will confuse novices into doing IP-based checks

Agreed.  Looking at my DNS server logs, the people trying to use my DNSBL
are confused enough already.

R's,
John

---

From: Barry Shein <[email-masked]>
Date: Wed, 2 Apr 2008 18:25:02 -0400

Ok, then why not retronym DNSBL to "DNS Bulletin List"?

Bulletin implies purely informational, timely, possibly volatile, less
than fully authoritative, neutral, announcement, etc.

Also, the word "bulletin" is similar (e.g., bolletino) in at least
Italian, French, Spanish, Portuguese, German, and Russian (basically a
cyrillic transliteration) though I'll leave it to others to verify
that. But it seems to be a latin-based, sometimes loan, word in many
languages with the same meaning; dim of Latin "bulla", as in "papal
bull", an edict, document or voting slip.

-- 
        -Barry Shein

The World              | [email-masked]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Login: Nationwide
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Larry M. Smith" <[email-masked]>
Date: Wed, 02 Apr 2008 21:54:12 -0500

> that aren't currently in widespread use?

Perhaps, or perhaps just rename the document to "DNS based reputation 
systems BCP"...  I don't think it really matters, DNSBL as a generic, 
noting that the document uses it as a generic, is also just fine.

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 03 Apr 2008 08:56:22 -0700

On Apr 3,  9:00am, Rich Kulawiec wrote:
}
} To look at it another way (oh good grief!): their enjoyment of access
} to the well for some period of time, at the pleasure of its owner,
} was a positive for them.  With the cut-off, that positive no longer exists.
} That does NOT result in a negative: it's merely the cessation of
} a positive, returning the balance to zero.
} 
} No negative, no damage.

Sorry, but this is not a zero-sum game, and you can't have it both ways.
The whole Internet is built on cooperative access to resources.  By your
argument, no one was damaged when that Pakistani ISP null-routed half
the planet to block access to YouTube, because no one should have
expected to have access to the Ineternet in the first place.

} As an aside, let me note that the correct mental perspective for the
} villagers (above) is not to blame the keeper of the well, who has,
} after all, generously shared resources for some period of time.  It's
} to blame the baker, who drew water in excess every day, severely
} impacting my ability to use my own resource.

I agree completely with that statement, but who is to blame or who gets
blamed has absolutely nothing to do with the accuracy of the description
of the end result.

And if there's anything being said about blame, the salient point being
made in the BCP is that when it comes to block-listings, neither the
baker nor the keeper of the well gets blamed.  The one who gets blamed
is he who advised the keeper about who to cut off.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 12:02:05 -0400

> are confused enough already.

Does any RHSBL or URIBL currently publish a testing procedure?  If 
nobody is, I'm afraid I might have to punt to a "yet to be determined 
common testing mechanism" by the rules of C in BCP.

SURBL _does_ publish IP entries now.

Note that there is no reason why a RHSBL or URIBL couldn't use 127..., 
other than perhaps confusion as to whether the octets should be reversed 
or not.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Apr 2008 12:06:29 -0400

> expected to have access to the Ineternet in the first place.

That is not an analogous situation.  Had YouTube null-routed *itself*,
thus exercising control over its own resources, then that would be
an analogous situation.

We're not discussing third-party intervention here: we're talking
about people exercising control over their own resources.

(And yes, I concur with your view of how the Internet's been built.
I support it fully.  However, one's decision to cooperate and generously
extend privileges to others isn't required to be irrevocable or universal.)

---Rsk

---

From: Steve Atkins <[email-masked]>
Date: Thu, 3 Apr 2008 09:10:39 -0700

> necessity of getting into the alphabet soup of all the other terms.

Given that the whole point of using "DNSBL" is that it's a known and
recognised acronym, redefining it to mean something entirely different
seems to miss that point?

Cheers,
   Steve

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 03 Apr 2008 09:22:30 -0700

On Apr 3, 12:06pm, Rich Kulawiec wrote:
}
} We're not discussing third-party intervention here: we're talking
} about people exercising control over their own resources.

We're *not* talking about that:  we're talking about a third party
who provides advice about what control to exercise over resources.
That third party has the power to intervene; the only difference is
who gave said power to the third party.  The consequence to at least
one, if not both, of the other two parties, is indistinguishable when
that power is asserted, no matter where the power came from.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 12:36:34 -0400

> seems to miss that point?

It's never been effectively formalized as meaning that.  I must confess 
I've always treated it as the generic "based" myself.

Similarly the term "spam" - spam was originally recognized as meaning 
_only_ the same article posted to many Usenet groups.  It didn't include 
the same article cross-posted to many groups (the term was "Jello" I 
think), nor articles doing both ("velveeta").  We were so food-oriented 
back then ;-)

If I had listened to this argument and I hadn't "broken" the "known and 
recognized" meaning of "spam" in the first section in 
http://www.killfile.org/~tskirvin/faqs/spam.html written by me in 1994, 
we'd be calling email spam "marmite" or something equally repulsive ;-)

I've got the following wording in the document now:

    Due to the rising amount of spam and other forms of network abuse on
    the Internet, many community members and companies began to create,
    maintain and publish DNS-based reputation systems (DNS-Based Lists)
    of IP addresses or domains and make reputation suggestions or
    assertions about email sourced from these IP addresses or domains.

    The first DNS-based Lists were almost exclusively intended to be used
    (by email administrators) as lists of abusive IP addresses to block,
    however the DNS publication method has proven to be so robust,
    popular and simple to use, that it has been extended for use in many
    different ways, far beyond the designers' of DNS or DNS-based
    blocking IP lists imaginings.  For example, today, the same basic
    DNS-based listing technology is commonly used for:

    DNSWL  listings of well-behaving email source IP addresses
       (whitelist).

    RHSBL  listings of well/ill behaving email source domains (often
       applied against the domain part of the originating email address
       or DNS PTR (reverse IP) lookups)

    URIBL  listings of well/ill behaving web link domains or host names
       used in email

    Further, the DNSBL user using the list doesn't have to use a listing
    as a pass/fail binary decision, it can use a listing as one factor in
    email filters that make decisions based on scoring multiple factors
    together.

    The DNS-based list technology has even been extended to purely
    informational purposes.  For example, implementations that return
    results based on what geographic region an IP is putatively allocated
    in, implementations that translate an IP address into a ASN number
    and/or allocation block, implementations that indicate whether the
    queried domain is registered through a given Domain registrar,
    implementations that return aggregate numeric reputation for an IP or
    domain from another system's email system, and so on.  The
    possibilities are virtually endless.

    As well, DNS-based listing technology has also been used in areas
    other than email filtering, such as IRC, web access control, and
    transaction verification.

    As the terminology in this area has never been well formalized, often
    overlaps, and lacks precision, this document has been written to use
    the term "DNSBL" to refer to DNS-based lists generally, not just DNS-
    based block (or black) lists.  This document is not applicable to
    some DNSBLs in some areas, these areas will be mentioned as
    appropriate, but it is the author's belief that most of the practises
    are applicable to almost all DNSBLs.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Thu, 03 Apr 2008 09:35:50 -0700

>common testing mechanism" by the rules of C in BCP.

SURBL and URIBL publish a test point.

http://www.surbl.org/data.html

http://www.uribl.com/about.shtml

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 12:45:57 -0400

> http://www.uribl.com/about.shtml

That's two votes for a 127.0.0.2 (as 2.0.0.127.<queryroot>) testpoint, 
and one for a variety of wierd domain named ones, none of which is 
example.com.  In the latter (SURBL), they say that Justin Mason 
suggested _not_ using "example.com" (eg: example.com.sc.surbl.org)

For my own curiousity, I'll ask why Justin said example.com was bad.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Dotzero <[email-masked]>
Date: Thu, 3 Apr 2008 12:47:29 -0400

I've been following this discussion with interest and consciously
avoiding wading in.

I do have one question. Is the object of the exercise to come up with
a BCP from a technical/operations perspective or is the object of the
exercise to craft a document specifically with legal ramifications in
mind? If it is the later I'm going to have to ask which legal
jurisdiction it is being crafted for? (ok, two questions)
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: SM <[email-masked]>
Date: Thu, 03 Apr 2008 10:05:35 -0700

>For my own curiousity, I'll ask why Justin said example.com was bad.

These lists are used to detect URIs appearing in the message 
body.  example.com is a domain reserved for examples and can appear in ham.

Regards,
-sm

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Apr 2008 13:10:35 -0400

> that power is asserted, no matter where the power came from.

If I delegate authority over my well to Fred and authorize him to act on
my behalf to decide who will be generously granted access to it and who
won't, then I am _still_ exercising my authority over my own property
and resources.  I've just delegated part of that authority, and of course
it's my right to do that as I see fit (and to un-delegate it as well,
if it turns out Fred isn't doing what I think he should be doing).

None of this changes the fact that it's still my property.  None of
this changes the fact any privileges I grant to anyone are a positive
for them, and that any privileges I don't grant aren't a negative.
(Try parsing that! ;-) )

Hypothetical follows, "you" is "generic you":

If you want to argue otherwise, then be prepared for my claim that you
have "damaged" me because you haven't honored my request for root-level
ssh access to every system you own.  After all, you have granted that
access to some people: why not to me?  Why are you damaging me by refusing
to give me the same privileges as others?

The answer of course is that you haven't.  You, as the owner of those
systems, get to decide who gets ssh/root privileges.  I don't get a vote,
I don't get to complain, I don't get anything.  And I'm not damaged.

Mail is no different.  And just because your SMTP policy (unlike your
root ssh policy) may be default-permit instead of default-deny doesn't
change that.  You haven't surrendered any part of your control over
your own resources just because you've been generous with them.  And
anyone who has benefitted from your magnanimity has no claim of "damage"
merely because you've (perhaps) decided to stop being so generous.

---Rsk

---

From: "David Nicol" <[email-masked]>
Date: Thu, 3 Apr 2008 12:26:09 -0500

I belive it be appropriate to include the distributed (rather than
centralized) dns-based robust distribution paradigm of SPF,
as a creature within the taxonomy of DNS-based reputation
systems.

Something like

"Distributed, in addition to centralized, DNS-based information
dispersal architectures have been implemented as well,
such as SPF (reference).  This document deals with operation
of services under a central administration."

-- 
bringing useful insights from Computer Science to the larger world
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 13:30:24 -0400

> jurisdiction it is being crafted for? (ok, two questions)

The intent is an operational (not protocol/technical) perspective, with 
a nod to minimize or at least clarify possible legal difficulties.

As for which jurisdiction: a hypothetical alternate universe where the 
law makes logical sense. If that's not an oxymoron ;-)

On a more serious vein, as it doesn't claim to be legal advise (and no 
longer mentions law/legal at all), and intentionally doesn't get into 
enough detail or specifics to be legal doctrine anyway.  At least it 
helps in having people thinking in the right direction.

You don't need to be a physicist and quote gravitational equations in 
order to advise people that jumping off the empire state building has 
some risk involved.

Similarly, you don't need to be a lawyer to tell a DNSBL operator whose 
documentation says it lists for one specific condition _only_, that 
listing someone for anything else is a bad idea and exposes them to 
increased risk.  I can think of one DNSBL operator who could have 
benefited from that advice, and probably avoided a whole lot of trouble. 
  In a jurisdiction other than mine or yours.

Or that by claiming the notion that a DNSBL user is primarily 
responsible for the consequences of a listing (and is also held harmless 
by the CDA anyway) might make a potential plaintiff decide _not_ to sue.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Bart Schaefer <[email-masked]>
Date: Thu, 03 Apr 2008 11:00:37 -0700

On Apr 3,  1:10pm, Rich Kulawiec wrote:
}
} If I delegate authority over my well to Fred and authorize him to
} act on my behalf to decide who will be generously granted access to
} it and who won't, then I am _still_ exercising my authority over
} my own property and resources. I've just delegated part of that
} authority, and of course it's my right to do that as I see fit (and to
} un-delegate it as well, if it turns out Fred isn't doing what I think
} he should be doing).
}
} None of this changes the fact that it's still my property. None of
} this changes the fact any privileges I grant to anyone are a positive
} for them, and that any privileges I don't grant aren't a negative.

All true, but all irrelevant.

On your last sentence above, we've cycled back to "this is not a
zero-sum game," so there's no point in arguing that further.

On the first paragraph, it doesn't make any difference what authority
is being exercised or even who has the right to exercise it.  It only
matters that Fred is a third party with the power to influence what is
done, and that by asserting that influence he can have an effect that
extends beyond the interaction between the original two parties (i.e.,
beyond baker and well-keeper or beyond spammer and mail-provider).

} If you want to argue otherwise, then be prepared for my claim that
} you have "damaged" me because you haven't honored my request for
} root-level ssh access to every system you own. After all, you have
} granted that access to some people: why not to me?

Obviously, I haven't granted that access to you because I'm following
the advice of a trusted third party.  If I handed over automated control
of access to my systems to that third party and he chose to lock out all
my developers (damn, where's that Dilbert link when you need it), then
we might be approaching a valid analogy.

As to whether I've damaged you, I can't tell.  If you work for the
Chinese government and you get fired from your job because you can't
steal secrets from my system, then yeah, I probably damaged you.  That
you may have deserved to be damaged is also irrelevant.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 14:35:45 -0400

> All true, but all irrelevant.

I suggest you both go lookup up the Agency legal concept. 
http://en.wikipedia.org/wiki/Agency_(law) will do.  See also Vicarious 
Liability under "Principals' liability".

If this applies (and I think it probably does or can be made to) the 
Principal (receiver) configures their mail server to query the agent 
(DNSBL), and the agent has "Actual Authority".

The agent has no liability to the third party (mail sender).  And 
apparently even if the agent acts fraudulently for his own benefit! 
(unless the third party knows of the agent's personal agenda.  Not sure 
why I understand this train of logic).

It may not apply directly, but it contains examples of the legal logic 
that would likely apply anyway.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: [email-masked] (Justin Mason)
Date: Thu, 03 Apr 2008 20:01:30 +0100

> body.  example.com is a domain reserved for examples and can appear in ham.

Exactly.

--j.

---

From: "Bart Schaefer" <[email-masked]>
Date: Thu, 3 Apr 2008 12:08:16 -0700

>  I suggest you both go lookup up the Agency legal concept.

Why?  My point is that it's not relevant.  This BCP isn't a legal
document and it doesn't matter whether any liability attaches.  The
only question is whether the phrase "collateral damage" is an accurate
description of the situation in the context of this BCP, not whether
any involved parties can claim damages in court.

If you want to avoid the word "damage" because you're trying to avoid
any semblance of terms that might have a legal definition, that's an
entirely different subject.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Seth <[email-masked]>
Date: Thu, 3 Apr 2008 15:16:23 -0400 (EDT)

Perhaps something like

  A positive response might be returned for an item because of its
  membership in a group of items, some number of which meet the
  criterion for listing the group (e.g. an IP address listed because a
  lot of spam comes from the /24 containing it).  This is often (but
  inaccurately) referred to as "collateral damage".

Seth

---

From: Seth <[email-masked]>
Date: Thu, 3 Apr 2008 16:23:14 -0400 (EDT)

"Chris Lewis" <[email-masked]> wrote:

> http://en.wikipedia.org/wiki/Agency_(law) will do.  See also
> Vicarious Liability under "Principals' liability".

I don't think that applies: an agent has _actual_ power, granted by
the principal.  So, if I point my domain's MX at google or spamarrest,
they become my agent.  But if I google for someone's reputation prior
to accepting email from him, that doesn't make google my agent: they
have no _actual_ power, only advisory.

For this account, Panix is my agent.  They have the _actual_ power.

Seth

---

From: Matthew Sullivan <[email-masked]>
Date: Fri, 04 Apr 2008 07:42:02 +1100

> expected to have access to the Ineternet in the first place.

They had the perfect right to place the null routes on their border, 
problem was due to technical issues people who didn't want it on their 
border received the update and were denied access to an otherwise wanted 
result, by someone not authorised to do that.

The 'by someone not authorised' is the key.

/ Mat

---

From: Matthew Sullivan <[email-masked]>
Date: Fri, 04 Apr 2008 07:42:57 +1100

> other than perhaps confusion as to whether the octets should be reversed 

SORBS uses example.com, and was told to use example.tld so does that as 
well.

/ Mat

---

From: Matthew Sullivan <[email-masked]>
Date: Fri, 04 Apr 2008 07:46:40 +1100

> that power is asserted, no matter where the power came from.

Not quite - the owner of the resource has the right to deny access, the 
entity viewing has the right not to look/use.  The transit providers 
(unless contracts say otherwise) have the right to deny transit.  A 
unrelated, unauthorised party like the Pakistani ISP does not have the 
right to deny access.  A BL is given the right to deny access by the  BL 
user.

/ Mat

---

From: John Levine <[email-masked]>
Date: 3 Apr 2008 22:55:51 -0000

Please don't.  This mission has crept too far already.

If someone else wants to write a BCP for SPF, that would be
fine, but it's not this document.

R's,
John

---

From: John Levine <[email-masked]>
Date: 3 Apr 2008 22:55:51 -0000

R's,
John

---

From: Rich Kulawiec <[email-masked]>
Date: Thu, 3 Apr 2008 21:25:06 -0400

On Thu, Apr 03, 2008 at 12:26:09PM -0500, David Nicol wrote:
> as a creature within the taxonomy of DNS-based reputation systems.

(a) I think of SPF et.al. as very different animals than DNSBLs,
so -- at least to me -- this would be out-of-scope.

(b) SPF et.al. have already been rendered largely moot, whereas DNSBLs
still have considerably utility.  (I've often argued that they're
the single most effective tool we have.)

---Rsk

---

From: Matthew Sullivan <[email-masked]>
Date: Fri, 04 Apr 2008 12:58:24 +1100

> so -- at least to me -- this would be out-of-scope.

Seems a lot of people forgot what SPF gives/does not give.

It is not a solution to spam, however it is a way to stop sender forging 
by spammers.  In the same vein it also stops phishing where the phisher 
forges the target org for the from email address.  It also stops, in 
combination with ensuring the domain actually exists, viruses that are 
sending by using random domains for the from address.

Beyond that, and the people that setup SPF records that are not 
explicit, it doesn't really stop anything.

/ Mat

---

From: Dotzero <[email-masked]>
Date: Fri, 4 Apr 2008 08:07:50 -0400

> Seems a lot of people forgot what SPF gives/does not give.

True.... see below.

> sending by using random domains for the from address.

SPF does NOT protect the "From" email address (RFC2822). It DOES
protect the "Mail From" address (RFC2821) from specific types of abuse
in some circumstances if the receiving domain is checking SPF.

> explicit, it doesn't really stop anything.

True

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 4 Apr 2008 09:14:29 -0400

> Seems a lot of people forgot what SPF gives/does not give.

I'm well aware of SPF (and DKIM, and SenderID).  Whatever their
theoretical merits, I don't consider them worthy of serious operational
consideration, as spammers/phishers already have the ability to render
them moot whenever it pleases them to do so.  But regardless of that
debate, which is arguably off-topic here, I don't believe they should
be mentioned in a BCP about DNSBLs.

---Rsk

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 04 Apr 2008 09:56:22 -0400

> be mentioned in a BCP about DNSBLs.

Agreed: SPF is out of scope for the document despite it being DNS-based, 
as is, for example, filtering based on the presence or absence of 
PTRs/rDNS.  It's so far out of scope that it's probably not worth the 
bits to declare it out of scope.
_______________________________________________
Asrg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/asrg

---

From: Seth <[email-masked]>
Date: Fri, 4 Apr 2008 15:28:51 -0400 (EDT)

Rich Kulawiec <[email-masked]> wrote:

> theoretical merits, I don't consider them worthy of serious
> operational consideration, as spammers/phishers already have the
> ability to render them moot whenever it pleases them to do so.

For domains I trust (including all banks I do business with), I use
SPF to allow stuff they send me to bypass spam filters.  That enables
those filters to be much stronger for stuff that looks like bank
messages.

How would you suggest a spammer can render that moot?

Seth

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Apr 2008 12:57:56 -0700

On Apr 4, 2008, at 12:28 PM, Seth wrote:

> SPF to allow stuff they send me to bypass spam filters.  That  
> enables those filters to be much stronger for stuff that looks like  
> bank messages.
>

Look-alike, cousin domains, and display names.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Fri, 4 Apr 2008 13:04:46 -0700

> Look-alike, cousin domains, and display names.

Are you not clear on how domain-name based whitelisting works?

If you want to whitelist mail that "comes from" example.com's  
mailservers
there are at least two ways of doing that.

One is to explicitly whitelist mail that comes from the IP addresses of
example.com's mailservers. That works fine, but requires each receiving
ISP to maintain those lists of IP addresses.

The other is to allow the owner of example.com to publish the IP  
addresses
of those mailservers, and for all the receiving ISPs to use that list  
of IP
addresses in order to whitelist email coming from example.com's  
mailservers.
SPF is one way to do that. This will whitelist exactly the same set of  
mail
as the first approach, just with less management overhead and less risk
of fat-fingering data.

So, please explain how "Look-alike, cousin domains, and display names"
will render that moot.

Cheers,
   Steve

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 03 Apr 2008 22:20:47 -0400

>> body.  example.com is a domain reserved for examples and can appear in ham.

I feel so ... dumb ;-)  127.0.0.2 will have similar problems.  The thing 
to choose would preferably be something that's not resolveable, and is 
unlikely to ever be used in a real link.  SURBL has something like 
"this-is-not-likely-to-ever-appear.<queryroot>".  Perhaps the BCP should 
  simply give suggestions on how to invent a test string rather than 
mandating a specific one.  Or punt.

---

From: Seth <[email-masked]>
Date: Fri, 4 Apr 2008 17:11:50 -0400 (EDT)

> So, please explain how "Look-alike, cousin domains, and display names"

The spammer will register a lookalike domain, and set the SPF so it
passes.

What Douglas is apparently missing is the fact that the user
whitelisted the real domain, and passing SPF for an unwhitelisted
domain has no effect.

Seth

---

From: John Levine <[email-masked]>
Date: 4 Apr 2008 21:16:39 -0000

If you guys want to argue about SPF, please at least keep the
thread separate from the BCP discussion so we can ignore it
more easily.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Apr 2008 14:16:36 -0700

On Apr 4, 2008, at 1:04 PM, Steve Atkins wrote:
>>> For domains I trust (including all banks I do business with), I  
>>> use SPF to allow stuff they send me to bypass spam filters.  That  
>>> enables those filters to be much stronger for stuff that looks  
>>> like bank messages.
>>>
> mailservers there are at least two ways of doing that.
>
> One is to explicitly whitelist mail that comes from the IP addresses  
> of example.com's mailservers. That works fine, but requires each  
> receiving ISP to maintain those lists of IP addresses.
>
> addresses of those mailservers, and for all the receiving ISPs to  
> use that list of IP addresses in order to whitelist email coming  
> from example.com's mailservers.
> SPF is one way to do that. This will whitelist exactly the same set  
> of mail as the first approach, just with less management overhead  
> and less risk of fat-fingering data.
>
> So, please explain how "Look-alike, cousin domains, and display  
> names" will render that moot.

SPF does not deal with what a person sees, although filtering rules  
may attempt to extend checking to PRAs or Froms, but of course that is  
not SPF.  Of course, such extensions are not fool proof either. This  
is made more dangerous when many recipients see just the display name.

People and filters are easily fooled.  White-listing may bypass  
filtering rules matching against possible phish.  Whether this works  
depends upon bad-actors cooperating and not defeating this  
protection.  A person can be convinced in subtle ways a message is  
from an entity that it is not.  We do a significant amount of phish  
filtering, however this process _must_ deal with images and other  
details related to what may catch a person's eye.  This goes back to  
the first sentence, people and filters are easily fooled.  Distinctive  
annotations are needed, but such annotations may also be spoofed and  
make the recipient more prone.  One of the greatest risks currently  
leading people astray is spoofed email from one of their buddies  
listed within their social network.  Someone pretends to be someone  
you know, and offers a link to something "interesting".

-Doug

---

From: John Levine <[email-masked]>
Date: 4 Apr 2008 21:16:39 -0000

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Fri, 4 Apr 2008 14:36:56 -0700

> mandating a specific one.  Or punt.

It's the eicar problem.

I think there needs to be a standard test string that can be used for  
liveness
testing. It doesn't need to be a syntactically correct domain, though  
if it
were that would make it easy to use for testing of an entire filtering  
system
as well as life-testing of a blacklist. It does need to be common across
blacklists, though, so that it can be hard-coded in software - so that  
URI
based filters can be given new private or public lists to use, without  
the
software developer needing to be aware of them, and can still do  
liveness
checks, to ensure that dead lists aren't queried.

I'd suggest

   "always-listed.standard-email-filtering-test-domain.com"

The latter leaves the possibility of using things like this ...

   url-in-body.standard-email-filtering-test-domain.com
   from-address.standard-email-filtering-test-domain.com
   helo-string.standard-email-filtering-test-domain.com

... to use as standard test patterns for particular sorts of domain  
based
lists that can be used to test whether an entire filtering system is  
working
correctly. (This would be in addition to list-specific test strings that
allow users to craft domains that will hit SURBL, but not URIBL and
so on, not in place of them).

Cheers,
   Steve

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 4 Apr 2008 17:42:20 -0400

> It's the eicar problem.

Yes. Note that years ago I created GTUBE for this exact problem for  
content filters. Unfortunately to this day I think only SpamAssassin  
(and MessageLabs filters) detects it:

http://en.wikipedia.org/wiki/GTUBE

---

From: Steve Atkins <[email-masked]>
Date: Fri, 4 Apr 2008 14:47:24 -0700

> http://en.wikipedia.org/wiki/GTUBE

Yup, GTUBE is perfect for content filters, but I'd be nervous about  
putting it into a DNS query, as some of the characters are unfriendly  
to naive stub resolvers.

But I've found GTUBE *extremely* useful for sanity checking my  
spamassassin installation, and that's the main reason that I think  
that something that really is a domain, and so which can be used as  
part of a test message to check an entire filtering system in addition  
to being used as a liveness check for lists would be valuable.

Cheers,
   Steve

---

From: John Levine <[email-masked]>
Date: 4 Apr 2008 22:03:47 -0000

According to RFC 2606, the reserved top level domain names are:

                   .test
                .example
                .invalid
              .localhost

      ".test" is recommended for use in testing of current or new DNS
      related code.

      ".example" is recommended for use in documentation or as examples.

      ".invalid" is intended for use in online construction of domain
      names that are sure to be invalid and which it is obvious at a
      glance are invalid.

      The ".localhost" TLD has traditionally been statically defined in
      host DNS implementations as having an A record pointing to the
      loop back IP address and is reserved for such use.  Any other use
      would conflict with widely deployed code which assumes this use.

It also reserves example.{com|net|org}

My inclination would be to decree that DNSBL.TEST is the test name for
domain name BLs.  No matter what string we use, there will always be
the possibility of a false alarm if it's used by scanners that recognize
it without the http:// punctuation.  There's no way around that, so I
wouldn't worry about it.

R's,
John

---

From: John Levine <[email-masked]>
Date: 4 Apr 2008 22:03:47 -0000

.test
                .example
                .invalid
              .localhost

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 04 Apr 2008 14:37:09 -0700

>mandating a specific one.  Or punt.

We are looking at two different cases here, the DNSBL which lists the 
connecting IP address/network, etc. and the URBL which lists URIs 
used in the message body.  Instead of having a one-rule-suits-all, 
you can have test.bl.example.com, where bl.example.com is the 
hostname part, for URBLs.

BTW, 127.0.0.2 is only a problem if the application performing the 
query doesn't whitelist IP addresses (RFC 1918, etc.).  I see that 
more as an implementation problem.

If the BCP suggests how to invent a test string, we end up with 
different strings.  It's easier to code for one or two cases.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Apr 2008 15:57:01 -0700

On Apr 4, 2008, at 3:03 PM, John Levine wrote:
>
> My inclination would be to decree that DNSBL.TEST is the test name  
> for domain name BLs.

It might be good to include characters to make this less likely to  
appear within something assumed to be a url.

Perhaps _DNS._BL.TEST could use underscores to make this less likely  
to appear in the wild.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 4 Apr 2008 19:58:32 -0400

> putting it into a DNS query, as some of the characters are unfriendly

Yeah sorry I wasn't clear - I wasn't recommend it for use as a DNSBL  
test.

I like John's suggestion of dnsbl.test.

Matt.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Apr 2008 02:09:28 +0200

Chris Lewis wrote:

> I feel so ... dumb ;-)  127.0.0.2 will have similar problems.

Why should it ?  It works for SURBL and many other lists.

> The thing to choose would preferably be something that's not
> resolveable, and is unlikely to ever be used in a real link.

127.0.0.2 is unlikely enough.  "invalid" would be misleading,
"test" is in theory fine, unless you need "test" for unrelated
tests.  Another advantage of 127.0.0.2, no I18N considerations.

The "example.tld" for RFCI is one thing, if it turns out to be
bad it can be fixed.  For a worldwide "cannot happen" string
you'd have to talk with ICANN, depending on your mood also
with wannabe-roots, ideally update RFC 2606, it's a rathole.

 Frank

---

From: [email-masked] (Justin Mason)
Date: Sat, 05 Apr 2008 09:47:48 +0100

> I like John's suggestion of dnsbl.test.

+1, me too fwiw.

(although content filters would have to be modified to recognise URLs in
the .test TLD, if it's suitable for use for that purpose -- SpamAssassin
doesn't, at least...)

--j.

---

From: SM <[email-masked]>
Date: Sat, 05 Apr 2008 01:47:27 -0700

>it without the http:// punctuation.  There's no way around that, so I

I suggested test instead of dnsbl.test as it's less likely to be 
parsed as a URL.  It's better to avoid the underscore as well as it 
can always be registered as a service name in future. Nowadays, a 
scanner doesn't only identify parts with a http:// as it's common to 
see links such as www.example.com or www.example which rely on MUA 
and browser behavior to get to the site with a click.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 5 Apr 2008 13:49:49 -0000

>parsed as a URL.

Not a bad idea.

---

From: John Levine <[email-masked]>
Date: 5 Apr 2008 13:49:49 -0000

Not a bad idea.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Apr 2008 16:25:11 +0200

> Not a bad idea.

Dunno, the author of I-D.asrg-dnsbl rejected "test" proposals
so far.  You could also argue that when 127.0.0.2 is under the
control of the opposition the DNBL user has more interesting
problems than DNSBL test entries.

 Frank

---

From: George Schlossnagle <[email-masked]>
Date: Fri, 4 Apr 2008 18:16:28 -0400

> http://en.wikipedia.org/wiki/GTUBE

Some of the AS vendors match it (Cloudmark for sure, I think some of  
the others as well).

George

---

From: Matt Sergeant <[email-masked]>
Date: Sat, 5 Apr 2008 12:49:08 -0400

> the .test TLD, if it's suitable for use for that purpose --  

No, that's the point - if you modify SA's URL scanner then there's a  
chance it will find dnsbl.test somewhere and treat such a mail as spam.

The only modification you might want to make to SpamAssassin is to  
check for dnsbl.test.whatever.uri.dnsbl upon startup, to ensure the  
list is operational.

Matt.

---

From: Matthew Sullivan <[email-masked]>
Date: Sun, 06 Apr 2008 17:08:05 +1000

Rich Kulawiec wrote:
> them moot whenever it pleases them to do so.

Since adding relatively restrictive SORBS SPF records the 'bounce 
attack' (ie outscatter attacks) on SORBS have become very manageable and 
almost non existent.
>   But regardless of that

True.

/ Mat

---

From: Matthew Sullivan <[email-masked]>
Date: Sun, 06 Apr 2008 17:13:21 +1000

> more as an implementation problem.

ie sendmail. (sendmail also has a problem with listing 127.0.0.1 which 
is the only server reported that suffers)

> different strings.  It's easier to code for one or two cases.

example.(com|net|org) should not be a valid domain because it is a 
reserved domain so it is valid to use for a test.

/ Mat

---

From: John Levine <[email-masked]>
Date: 6 Apr 2008 18:05:04 -0000

>reserved domain so it is valid to use for a test.

The problem is that those names occur in a certain amount of legit mail,
and a SURBL like check looking for domain name strings might well match
them.

That's why I like test, it's not likely to accidentally get picked out
of a message and interpreted as a domain name.

R's,
John

---

From: John Levine <[email-masked]>
Date: 6 Apr 2008 18:05:04 -0000

R's,
John

---

From: John Payne <[email-masked]>
Date: Tue, 8 Apr 2008 11:52:14 -0400

> block/filter/score email.

I don't know if any of the other people originally involved in OPM  
are around, but I was there from the beginning and it was always my  
intent to use in my MTA configurations.

True, we didn't originally take spamtrap submissions, because we were  
primarily focused on IRC as a detection mechanism, but the spamtrap  
reporting didn't take long to come into use (apparently I committed  
the spamtrap script on June 20th 2002... with the dnsbl-building part  
being checked in on April 6th of that same year - although it looks  
like the dnsbl builder was in place on March 24th according to the  
way back machine).

How time flies :)