Subject: [Asrg] DNSBL BCP v.2.0

From: "Nick Nicholas" <[email-masked]>
Date: Thu, 8 Feb 2007 13:22:01 -0800

Greetings:

With much help from the authors as well as the ASRG chair and Dave
Crocker, I have finally completed the revisions to the DNSBL BCP.  A
copy is beneath my .sig so that you may make your comments inline if
desired.  I tried to include as many comments as possible from the
discussion of the previous draft, but the authors and the editor deemed
it was necessary to decline to use some of the suggestions.

Flame away!  I'm wearing my Nomex suit.  :-)

Regards,

Nick

--
 
Nick Nicholas
Knowledge Engineer
Habeas Inc.
650-694-3320
[email-masked]

-------------------

Internet Draft                             Yakov Shafranovich (Editor)
Expiration: August 2007                       SolidMatrix Technologies
Network Working Group                           Nick Nicholas (Editor)
                                                                Habeas 
                                                         Matt Sergeant
                                                           MessageLabs
                                                           Chris Lewis
                                                       Nortel Networks
                                                         February 2007

   Guidelines for Management of DNS-Based Reputation Systems for Email
     		 draft-irtf-asrg-bcp-blacklists-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF),
   its areas, and its working groups.  Note that other groups may
   also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use
   Internet-Drafts as reference material or to cite them other
   than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

    Copyright (C) The Internet Society (2007).  All Rights Reserved.

Abstract
 
   The rise of spam and other anti-social behavior on the
   Internet has led to the creation of shared blacklists and
   whitelists of of IP addresses or domains. This memo discusses
   guidelines for management of public DNS blacklists.
   
   The document will seek BCP status. Comments and discussion of this
   document should be addressed to the [email-masked] mailing list.

Table of Contents

   Abstract
   1. Introduction
      1.1  DNS-Based Reputation Systems
      1.2  Guidance for DNSBL Users
      1.3  Terminology
   2. Background.
      2.1.  Transparency
         2.1.2.  Listing/Delisting Criteria SHOULD Be Easily Available.
         2.1.3.  An Audit Trail SHOULD Be Maintained.
      2.2.  Listings and Removals
         2.2.1.  Listings SHOULD Be Temporary.
         2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be
                 Available.
         2.2.3.  Removals SHOULD Be Prompt.
         2.2.4.  Criteria for Listing and Delisting SHOULD Be Similar.
         2.2.5.  Removals SHOULD Be Possible in Absence of List
Maintainer.
   3.  Operational Issues
       3.1. Inactively Maintained Lists SHOULD Cease Operations.  
       3.2. Cessation of List Operations MUST Be Done in a Graceful
Fashion.
       3.3. Content of DNSBL Zone File SHOULD Be Limited.
       3.4. Special and Reserved IP Addresses MAY Be Used.
       3.5. Use of Collateral Damage MUST Be Disclosed.
       3.6. Special Considerations for Blacklists Listing Insecure
Hosts.
        3.6.1.  MUST NOT Scan Without Provocation.
        3.6.2.  Re-scan Periods SHOULD Be Reasonable.
   4. Security Considerations
   5. Informative References
   6. Author(s) Addresses.
   7. Acknowledgements.
   8. Full Copyright Statement.

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 and blacklists.  These
   lists are used for filtering email.  DNSBLs are either public or
   private.  A public DNSBL makes its data available to any party
   seeking information from the list, but a private DNSBL is used 
   solely by an organization for its own use and the data is not made 
   available publicly.

   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 IP addresses.  Due to the broad 
   adoption of this DNSBL, it had a devastating 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.
  
   Existing DNSBLs vary greatly in their policy, usage and and level 
   of maintenance.  These guidelines try to lay out a set of best 
   practices for running a DNSBL in an open manner with the hope that 
   they will facilitate better management of DNSBLs, and provide better 
   information for prospective users in selecting which DNSBLs to use.

   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 are clear to their users what those criteria are.
   The DNSBL user has the responsibility to ensure that the listing 
   criteria and other aspects of a DNSBL meets its needs.

   This document is also intended to provide guidance to DNSBL
   administrators 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 administrator 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 should be operated.

1.2.  Guidance for DNSBL Users

   When choosing to adopt a DNSBL, an administrator 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.  Are web pages for removal requirements accessible and 
       functioning properly?
   6.  How long has the list been in operation?
   7.  What are the demographics and quantity of the list's user base?
   8.  Are comparative evaluations of the list available?
   9.  What do your peers or members of the Internet community say
       about the list.
   
   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 a
   system or network administrator allows a third party to make 
   blocking decisions for its network, then the administrator MUST 
   understand the policies and practices of those third parties 
   because responsibility for blocking decisions remain ultimately 
   with the administrator.  A DNSBL does not prevent anyone from 
   receiving email or any other Internet service.  A DNSBL *user* 
   prevents service delivery using the DNSBL as a tool for doing so.

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

   These guidelines address public DNSBLs only and do not apply to
   privately operated DNSBLs.

1.3. Terminology.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC 2119].
   
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], 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]>.

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 through a mechanism such as 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.
   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 administrators to
   disclose the precise algorithms and data involved in a listing.

   Availability of documentation concerning a DNSBL SHOULD NOT be
   dependent on the continued operation of DNS for the DNSBL zone file.
   In other words, if the DNSBL documentation is located at 
   http://example.com/dnsbl/, the documentation web site SHOULD remain
   available even if the DNSBL zone file is not available. See also 
   Section 3.2

2.1.2. 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 blacklist. This 
   additional technical information can confuse end users, so a 
   separate page or section on its own SHOULD be dedicated to 
   detailing why a specific entry appears in the DNSBL.

2.1.3. An Audit Trail SHOULD Be Maintained.

   A DNSBL SHOULD maintain an audit trail for all listings and SHOULD
   make it 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
   administrator's possession relating to the listing; e.g., a DNSBL
   administrator MAY make the audit trail data selectively accessible
   in such a way that spam trap addresses are not disclosed.

2.2  Listings and Removals

2.2.1.  Listings SHOULD Be Temporary.

   With the exception of DNSBLs that that are based on data that does
   not change, such as those include the IP addresses associated with 
   a specific country or geographic region, all listings SHOULD be 
   temporary so that an entry will time out at some point in the 
   future. For more aggressive spammers (e.g., those operating their 
   own ISP) the temporary period MAY be as much as six (6) months.  
   However, longer periods SHOULD NOT be used since it is possible 
   that an IP address or domain can change hands, possibly being 
   allocated to a non-abusive user.
 
   Note that all listings being temporary does not mean that some
   listings will not remain after the initial timeout period. If the 
   DNSBL administrator determines that the conditions for listing 
   still exists, then the timer for determining timeouts MAY 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.2).  The DNSBL SHOULD also make available an email 
   address in order to handle issues other than blocking issues.
   
   The DNSBL administrator MUST NOT use the list in question in such
   a way that removal requests would be blocked, and, moreover,
   SHOULD make unfiltered mailboxes available in order to allow 
   affected users to submit their requests.  In some cases it is 
   impractical not to filter email to role 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.

   Requests for removal SHOULD be honored without question.
   Although this approach allows people to submit a request and have
   any listed IP address removed immediately, it does not prevent 
   the DNSBL administrator from re-listing the IP address at a 
   later time (for example: subject to seeing more spam, or 
   re-checking the IP address security). A re-listing MAY result in 
   a longer timeout until the listing expires before it is eligible 
   for removal.  Bounded exponential backoff is a good choice for 
   listing timeout.

   Assuming the above is not possible and no listing reasons remain,
   removal at anyone's request SHOULD be prompt.  Removal requests
   SHOULD be acted upon within a period of 24 hours, and SHOULD be
   handled within three (3) days.

   Most DNSBLs can effectively use a "no questions asked" removal 
   policy 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 implementing a "no questions 
   asked" removal policy also performs rate-limiting and malicious 
   removal detection.

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

2.2.4  Criteria for Listing and Delisting SHOULD Be Similar

   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 administrator 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.
   
   In addition, it is RECOMMENDED that all listings SHOULD be temporary 
   as described in section 2.2.1. For temporary listings, it is not 
   necessary to correct the causes of the listing in order to be removed

   from the DNSBL.

2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.

   Removals SHOULD be possible in the absence of the list administrator.

   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. Inactively Maintained Lists SHOULD Cease Operations

   If a DNSBL is no longer actively maintained, it SHOULD cease
   operations in accordance with the principles set forth in section
   3.2.

3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion.

   When a DNSBL ceases operations and is taken out of circulation,
   it MUST do so in a graceful manner so that it does not create 
   excessive DNS queries or list the entire Internet.
   
   The recommended approach is to put the DNSBL in its own second
   level domain, and then point the DNS NS records for that second 
   level domain to 127.255.255.255.  The TTL for that record should be 
   set at the maximum allowed period of one week.

3.3. Content of DNSBL Zone File SHOULD Be Limited.

   The content of a DNSBL zone file SHOULD be limited to DNSBL entries
   and relevant control information such as the TTL for the entry, 
   explanatory TXT records, etc.  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, MX or SPF records).  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 occupy its own zone.  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.

3.4.  Special and Reserved IP Addresses MAY Be Used.

   The DNSBL MAY list loopback, RFC 1918, 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.
   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 particular, most DNSBLs use a positive response for 127.0.0.2 
   for this.  See reference [DNSBL-EMAIL] for additional information.

3.5. 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 bring pressure upon 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
   that include the imposition of collateral damage, such policies
   MUST be disclosed.

3.6.  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 
   regular DNSBLs.

3.6.1. MUST NOT scan without provocation.

   DNSBLs MUST NOT automatically probe for insecure systems without
   provocation. There is little agreement in the community as to whether

   or not such activity should be allowed, so this BCP adopts a more
   conservative policy.
   
   Therefore, scanning MUST be be targeted, rather than broad-based, 
   with a given scan motivated by a specific reason to have concern
   about the IP address being scanned.  Examples of such reasons 
   include delivery of a message to a spam trap address, receipt of 
   a user complaint, or periodic testing of an IP address that is 
   listed already.

3.6.2. Re-scan Periods SHOULD be Reasonable.

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

4. Security Considerations

   Like all DNS-based mechanisms, DNSBLs are subject to various 
   threats outlined in [RFC 3833].
   
5. Informative References

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

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

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997
  
   [RFC 3833] Atkins, D. and Austein, R.; "Threat Analysis of the
   Domain Name System", RFC 3833, August 2004

   [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and 
   Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005

6. Author(s) Addresses.

     Yakov Shafranovich (Editor)
     SolidMatrix Technologies, Inc.
     [email-masked]
     www.shaftek.org

     Nick Nicholas (Editor)
     Habeas, Inc.
     [email-masked]

     Chris Lewis
     Nortel Networks
     [email-masked]

     Matt Sergeant
     MessageLabs, Inc.
     [email-masked]

8. Acknowledgements.

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

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

9. Full Copyright Statement.

   Full Copyright Statement

   Copyright (C) The Internet Society (2007). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Feb 2007 01:27:15 +0100

Nick Nicholas wrote:

> you may make your comments inline if desired

Okay, you get it then in source order, from typo to whatever
else I might see.

>  whitelists of of IP addresses or domains. This memo discusses

s/of of/of/

>    addresses and domains identified as problem sources of email.  These

Some DNSBLs are in fact "DNS based lists" used for other purposes
like Geo location.  If you haven't done it later you could note
that you're not talking about the general "DNSBL" concept.

>    These DNSBLs vary widely in integrity, strategy, methodology and

s/These//  They all vary widely.

>    7.  What are the demographics and quantity of the list's user base?

How are admins supposed to evaluate this ?  Sounds bogus for me.

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

They all say it's bad for various conflicting reasons, none of them
related to any incident in the last five years.

>    If a system or network administrator allows a third party to make
>    with the administrator.

Yes.  And actually a list does NEVER make blocking decisions for a
list user, because nobody is forced to use it.  How about "uses the
proposals of a third party to make blocking decisions".

>    privately operated DNSBLs.

s/do/may/ ?  Some proposals should also make sense for private lists.

>         does not necessarily represent the consensus of the

Is that necessary ?  As a BCP it will have IETF consensus no matter
what the ASRG situation might be.

>    public through a mechanism such as the DNSBL's web site. A DNSBL

s/through a mechanism such as/on /  No nonsense please, if it has no
Web site it's anyway bogus.

>    available even if the DNSBL zone file is not available.

I don't get this, if the list works like 2.0.0.127.example.net, then the
accompanying Web site SHOULD be located at http://example.net  Otherwise
the list is bogus and SHOULD NOT be used.  Of course it's fine if it has
other URLs for its policy.

>    a specific country or geographic region

s/include/listing/ (?)

>    own ISP) the temporary period MAY be as much as six (6) months.

+    own ISP) the temporary period could be considerably longer (e.g.,
+    weeks) as stated in the listing policy.

I don't get the idea of an arbitrary magic number "6 months".  For a
list with say bogon IPs it would be "as long as necessary", unlimited.
You address this later, but IMO no fixed limit also here is clearer.

>    allocated to a non-abusive user.

Add "unless it's the stated list policy to cause collateral damage
for users getting their IPs from spam-supporting organizations."

>    for removal.  Bounded exponential backoff is a good choice for

ACK, and that upper limit could be worse than six months.

>    Removals SHOULD be possible in the absence of the list administrator.

Delete this line.

>    set at the maximum allowed period of one week.

Intersting, many DNS details are still a kind of mystery for me, users
would then try to ask a name server at 127.255.255.255, and because
that's a broadcast address on their own LAN they'd get an error, is
that the idea ?   Was that concept already tested anywhere ?

>    "<query>.dnsbl.example.com" rather than "<query>.example.com".

That's what I meant above, http://dnsbl.example.com for the Web site,
and other URLs for the case when the list is terminated.  Ideally as
redirection (moved permanently) to the more persistent URL.

>    any other permanently reserved or special-use IP addresses.

No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT
abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please
limit it as good as you can).

>    Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8

Indeed, and anything else is just wrong.

>    In particular, most DNSBLs use a positive response for 127.0.0.2

s/most/many/ and s/for/of/  You should also mention that lists SHOULD
support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the
opposite (never listed), without ever returning 127.0.0.1 as a result.

>    for this.  See reference [DNSBL-EMAIL] for additional information.

Maybe that's not more needed if you explain the trivial concepts here.

>    Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005

If you keep RFC 1918 you've to list it as reference.  RFC 2119 should
be noted as normative - I think you've somehow lost the section with
normative references.

Nice draft, I like it, thanks,

 Frank

---

From: Tony Finch <[email-masked]>
Date: Fri, 09 Feb 2007 02:20:59 +0000

"Nick Nicholas" <[email-masked]> wrote:

The draft looks pretty sensible to me.

>   DNSBLs are either public or 
>   seeking information from the list, but a private DNSBL is used=20
>   solely by an organization for its own use and the data is not made=20
>   available publicly.

There are also commercial DNSBLs which are public except that "any party"
must be willing and able to pay.

>   not change, such as those include the IP addresses associated with=20
>   a specific country or geographic region, all listings SHOULD be=20
>   temporary so that an entry will time out at some point in the=20
>   future.

IP addresses can move country or region - consider an international ISP.
I don't think there are any certain unchanging attributes of IP addresses.

>   Requests for removal SHOULD be honored without question.

I think this requirement needs more hedging, since it depends on the
DNSBL listing policy. For example, the requirement is not appropriate
if the listing is based on who the address space has been allocated to,
especially if the reason is that it has been allocated to criminals.
In that case you expect to come into conflict with people who are listed.

>   it MUST do so in a graceful manner so that it does not create=20

What do you mean by "excessive"? Is this a reference to insane DNS
clients that generate more traffic when a DNS server goes away?

>   Like all DNS-based mechanisms, DNSBLs are subject to various=20

The recommendations for DNSBL users should be in this section.  It's worth
emphasizing that spam is a security problem and that DNSBLs are one
of many ways to tackle it. DNSBLs usually relate to the SMTP client,
which can have a limited relationship to the origin of the message if
the client is relaying or forwarding. However RHSBLs exist as well,
which have no guaranteed relationship to the client or the origin of
the message, but can still be useful.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
HUMBER: NORTHWESTERLY 5 OR 6. MODERATE OR ROUGH. WINTRY SHOWERS. GOOD.

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 8 Feb 2007 22:17:28 -0500

> that you're not talking about the general "DNSBL" concept.

I think we entirely cover that under 2.2.1. Please let us know if you  
think we don't.

> How are admins supposed to evaluate this ?  Sounds bogus for me.

Certainly easy to lie about, but a BCP doesn't cover lying. It could  
certainly be stated on the DNSBL's web page, or could be stated on a  
separate page on whichdnsbl.com (yes, I made that up, though it is  
available!).

> related to any incident in the last five years.

:-) Not sure how we could encode that in a BCP.

> proposals of a third party to make blocking decisions".

Not sure which part you think is badly worded here. Please elaborate.

> s/do/may/ ?  Some proposals should also make sense for private lists.

Possibly, but that is not the intention, and is not something we  
could BCP about IMHO. If a private entity wishes to follow these  
ideas then that's fantastic, but not what this BCP is about.

> what the ASRG situation might be.

I think this is just draft preamble, required for discussion here.

> Web site it's anyway bogus.

It's entirely conceivable that a DNSBL's public presence might be  
purely a yahoo-groups mailing list, or NANABL, or some-such. With  
FAQs and listing criteria regularly published to such locations.

> other URLs for its policy.

There are major problems with this. What if you decide to stop  
running the DNSBL? See section 3.2. I see no reason to remove this  
section.

>>    a specific country or geographic region

Good catch. Thank you.

> You address this later, but IMO no fixed limit also here is clearer.

We've mulled over this a lot. Gone back and forth. In the end we said  
6 months because if we put no limit on then it's no help - a DNSBL  
could just set the limit at 30 years.  6 months is reasonable for a  
long listing, and this is very well covered by the last point in this  
section - that a temporary listing can easily be extended by (for  
example) receiving more spam from this IP/range.

> for users getting their IPs from spam-supporting organizations."

Even the organisation can change hands. See above.

>>    Removals SHOULD be possible in the absence of the list  

Yup.

> that the idea ?   Was that concept already tested anywhere ?

It has been discussed both here and in many other places.

> redirection (moved permanently) to the more persistent URL.

Not sure what you mean here. Hopefully you're agreeing with what I  
said above.

> limit it as good as you can).

list != result. We're not talking about the result IP here. Just what  
can be present in the DNSBL.

> Indeed, and anything else is just wrong.

Possibly/probably yeah. But this BCP doesn't cover that.

> s/most/many/ and s/for/of/

I think "most" is fine. The second change is correct.

> You should also mention that lists SHOULD

Good point. We'll consider adding that. It's a good test for DNSBL  
validity.

> Nice draft, I like it, thanks,

Thanks for your comments. Very useful.

Matt.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 8 Feb 2007 22:31:27 -0500

> must be willing and able to pay.

I guess better wording might be: "but a private DNSBL restricts who  
has access to querying the list."

> I don't think there are any certain unchanging attributes of IP  

I'd like to get more comment on that. Even international ISPs assign  
IP ranges within their country boundaries.

> In that case you expect to come into conflict with people who are  

I strongly believe this is covered by the verbiage in this section.  
Should a criminal spammer find himself listed in the SBL (for  
example), he should be allowed to immediately request removal, and be  
granted that. As soon as he spams, he should be immediately relisted.  
And the limits on removals be made harder for him/her - see the  
second to last sentence in that first paragraph. The intention is to  
make innocent listings easy to remove, and criminal listings harder  
to remove.

> clients that generate more traffic when a DNS server goes away?

A typical example of shutting down a DNSBL would involve setting the  
TTL to a very high value, to limit the number of queries that result.

> the message, but can still be useful.

I'm not sure we want to venture into that cesspool :-) But I'm  
willing to be persuaded otherwise.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Feb 2007 20:21:07 -0800

> How are admins supposed to evaluate this ?  Sounds bogus for me.

Perhaps whether a particular geographic area or type of enterprise
is being served?

> related to any incident in the last five years.

This is not something one should believe from the DNSRBL operator,
so why make this a requirement?

> proposals of a third party to make blocking decisions".

It might even be better to only call this a blocklist or black-hole
list, rather than a blacklist.  These two areas provide grounds
for meaningless legal tussles designed to waste money.  Who is
blocking is an important concept to clarify, as well that a block-list
is not "blacklisting" as often defined in the law.

> Web site it's anyway bogus.

It might become a required strategy to not rely upon web sites when they
become DDoS targets.  It seems contacts should be generalized to allow
greater flexibility.

> other URLs for its policy.

There are TXT records that might accompany the IP address information  
that
can provide contact information.  Of course it would be rather painful
should the contact information be an 800 phone number.

> You address this later, but IMO no fixed limit also here is clearer.

Frank is right.  6 months does not make much sense.  Such a set
interval can be rather easily gamed.  A good operation will apply
different criteria for various networks regarding such intervals as well
as requests for delisting.  The level of cooperation varies widely and
this too affects these parameters.

> for users getting their IPs from spam-supporting organizations."

How about:

A listing should not extend beyond what the operator has determined
to be beyond that offering a reasonable expectation that the
address is likely to be under different administration.  The operator
may make exceptions based upon various factors, such as the past
behavior of the network's management across the related addresses.

> ACK, and that upper limit could be worse than six months.

s/exponential backoff/exponentially extended periods/

>>    Removals SHOULD be possible in the absence of the list  

Agreed.

---

---

This would be a problem only when zone transfers are used to distribute
data.

> opposite (never listed), without ever returning 127.0.0.1 as a result.

Just exclude 127.0.0.1 to prevent exploits that might rely upon an
unexpected self references from an otherwise trusted domain.

---
---

s/as listing open relays/as only listing open relays/

---

---

It is not possible to disclose _any_ email information without also
disclosing where the message was obtained.  It is simply impossible
to fully redact a message to provide such an assurance of
non-disclosure.

How about:

An operator should maintain an audit trail for their own private
use.  This information should _not_ be made public unless the
entity making the request is considered trustworthy.

In response to Tony:

A list closed to only those that enter into a contract is not a
"public" DNSRBL.  A contract supersedes casual expectations
expressed in this document.

-Doug

---

From: Bill Cole <[email-masked]>
Date: Thu, 8 Feb 2007 23:25:41 -0500

Just a couple of minor quibbles:

>    level domain to 127.255.255.255.

s/to/to a hostname that resolves to/

It's amazing how many people think that's it's OK to point an NS 
record at an IP address...

>   The TTL for that record should be

One week is NOT the maximum value for a TTL. One week is the top 
value that BIND will honor. TTL's can in theory be about 68 years 
(2147483647.)  Alternate wording:

    The TTL field for the NS record and the A record it points to should
    be set to 604800 (one week) because larger values are not universally
    honored.

-- 
Bill Cole
[email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 8 Feb 2007 23:44:36 -0500

On 8-Feb-07, at 11:21 PM, Douglas Otis wrote:

> Frank is right.  6 months does not make much sense.

Please re-respond in light of my response to Frank here.

> This would be a problem only when zone transfers are used to  

... which covers all public DNSBLs, surely? Or at least those that  
have any hope of becoming popular (i.e. those that follow best  
practices). I don't see any reason you'd want to remove this section.

> s/as listing open relays/as only listing open relays/

Good.

> to fully redact a message to provide such an assurance of

Hence why this is a SHOULD not a MUST. It's a tricky line - compare  
for example the disclosure given by PSBL (almost full spamtrap hit  
contents) vs SBL. Both presumably maintain an internal audit trail,  
but one is public and one is private, but both are reasonably well  
run DNSBLs.

Matt.

---

From: Daniel Feenberg <[email-masked]>
Date: Fri, 9 Feb 2007 07:46:40 -0500 (EST)

On Thu, 8 Feb 2007, Matt Sergeant wrote:

> I strongly believe this is covered by the verbiage in this section. Should a 
> criminal spammer find himself listed in the SBL (for example), he should be 
> allowed to immediately request removal, and be granted that. As soon as he 
> spams, he should be immediately relisted. And the limits on removals be made 
> harder for him/her - see the second to last sentence in that first paragraph. 
> The intention is to make innocent listings easy to remove, and criminal 
> listings harder to remove.
>

Is this always desirable? Does anyone here have any statistics about how 
long a spammer can spam on average before being picked up by DNSBLs? My 
impression from our use of Spamhaus is that detection is slow. On our 
system with about a 1,000 active mail accounts only about 1% of spam 
source IP addresses were seen more than once in the test week, suggesting 
to me that it would be difficult to tell if spamming had ceased in less 
than several months unless one had a very large set of spam traps.

If removal must be automatic, doesn't that unnecesarily give the spammer 
twice as long on the IP address? It seems like that would double the 
amount of uncaught spam. I would have thought that confirming a delisting 
with the ASN abuse contact or providing reverse name look to a non-generic 
host name would be reasonable precaustions a DNSBL might wish to impose 
before delisting an address, and that in any case it should be up to list 
policy.

There is a principle of statistics that if your detector sees only a small 
fraction of events, then variation in the rate is mostly random, and not 
evidence of variation in the underlying process.

Daniel Feenberg

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Feb 2007 14:47:13 +0100

> I think we entirely cover that under 2.2.1. Please let us know if
> you think we don't.

Yes, I read it top down, and the first definition sounded like "it's
only about 'B' as in 'bl[ao]ck'".  Later you have "or anything" with
a 'B' as in 'based'.  IP-based geo-location - as far as you believe
in it - can be completely unrelated to 'bl[oa]ck'.

If you want to cover the latter maybe state it earlier, before 2.2.1.
It's certainly a nice example why decisions to block "countries" by
IP could indicate a dangerous degree of ignorance on the side of the
list user.  The location could be wrong, it could change any time,
and if users block complete countries they MUST NOT send any abuse
reports to mailboxes in this country while they block the replies.

That's a general principle, if users block something they MUST NOT
send mails to the (from their POV) blackholes, replies won't work.
You could recommend that users blocking IPs should also refuse to
transport messages to the blackhole.

> :-) Not sure how we could encode that in a BCP.

How about simply removing (7) and (9) ?  Or replace it by a general
advice "try to find and evaluate opinions of third parties about the
list in question".  My interpretation of (7) would cover "OPM is for
IRC geeks, therefore it can't be good".  And that's wrong.  For (9)
I got "read NANAE", but admins should not waste time there, unless
they really like it.

  [about "allows a third party to make blocking decisions"]
>> actually a list does NEVER make blocking decisions for a list
>> user, because nobody is forced to use it.  How about "uses the

> Not sure which part you think is badly worded here. Please elaborate.

- If a system or network administrator allows a third party to make
- blocking decisions for its network, then the administrator MUST
[...]
+ If a system or network administrator uses the proposals of a third
+ party to make blocking decisions, then the administrator MUST
[...]

>> s/through a mechanism such as/on/  No nonsense please, if it has
>> no Web site it's anyway bogus.

> purely a yahoo-groups mailing list, or NANABL, or some-such.

No, this is not entirely conceivable for a DNSBL with its own zone.
If it can answer queries for 2.0.0.127.dnsbl.example "hosts", then
it can also answer a query for host dnsbl.example, and they can
then arrange that "GET dnsbl.example HTTP/1.0" returns something
useful.  If it's a FAQ explaining how to use a YahoGroup or NANABl
it's not ideal, but acceptable as least common denominator.

It's a good convention, it should be recommended.  My attempts to
convince Jeff that say http://multi.surbl.org should work, and that
http://surbl.org (without "www" label) should of course also work,
failed.  But maybe he'll believe it if you state it as SHOULD... :-)

A low hanging fruit, please don't miss it.  It also simplifies the
documentation of tools querying DNSBLs, "... queries x.y.example,
for technical listing details see http://y.example".  If it's not
predictable where a DNSBL has at least a HTTP redirection to its
policy it only makes the maintenance of such tools more difficult.

 [upper limit for a listing]
> We've mulled over this a lot. Gone back and forth. In the end we
> said 6 months because if we put no limit on then it's no help - a
> DNSBL could just set the limit at 30 years.

Yes, I'm not very happy with RFCI listings where the evidence is
several years old (of course RFCI is a set of RHSBLs today, no more
DNSBL, and likewise SURBL is no real DNSBL, but most parts of your
draft also work for RHSBLs).

But "6 months" is still an unnecesary magic number.  If it's the
stated listing policy to note "postmaster@ bounced 2003-04-01, and
will be listed until they request it in a MAIL FROM postmaster@, and
click on an URL in the reply", then that's as it is, not nice, but
also not unreasonable.  Maybe what you really want is that lists
MUST publish the upper limit in their policy (?)

> this is very well covered by the last point in this section -
> that a temporary listing can easily be extended by (for example)
> receiving more spam from this IP/range.

Yes, a second case where reading the I-D bottom up could be better
than top down <gd&r>  If you insist on a magic number 6 months is
certainly long enough, maybe already too long.

> Even the organisation can change hands. See above.

Caveat emptor.  If a tainted IP is worthless, this could be a part
of the "excommunication after XAB" concept.  Maybe only RIRs can
clean tainted IPs.  Of course users need to know that they're in
for a fundamentalistic armageddon with this approach.

  [127.255.255.255]
>> Was that concept already tested anywhere ?

If the "namedroppers" and similar cabals like it it's fine.

 [RFC 1918]
> list != result. We're not talking about the result IP here.

Sorry, I got that wrong.  If a DNSBL lists private IPs in addition
to the known 127.0.0.2 test entry it should be very clear about it
in its policy.  Maybe repeat this as "security consideration", it
could cause havoc.  Please add an informative reference to RFC 3330,
it has a nice fresh overview of all special IPv4 addresses.  There
ought to be something similar for IPv6, but I don't know where.

> I think "most" is fine. The second change is correct.

I try to use "combined lists" where possible, limiting the number
of DNS queries, and for combined lists 127.0.0.2 is only one of the
positive responses.  Proposed text:

| In particular, DNSBLs use a positive response of 127.0.0.2 or
| other values in the 127.0.0.0/8 range excluding 127.0.0.0/31
| (see RFC 4632 for the notation).

>> You should also mention that lists SHOULD support 127.0.0.2 as
>> "always listed" test entry, and 127.0.0.1 for the opposite (never
>> listed), without ever returning 127.0.0.1 as a result.

> Good point. We'll consider adding that. It's a good test for DNSBL

Yes, that's the idea.  DNS based tools won't directly check q=ns to
catch any 127.255.255.255 condition.  Two test queries (127.0.0.2
as listed, 127.0.0.1 as not listed) could detect "osirusoft" stunts.
Or whatever "monkeys" finally did for its formal net suicide.

Frank

---

From: Bill Cole <[email-masked]>
Date: Fri, 9 Feb 2007 09:31:40 -0500

[...]

>... which covers all public DNSBLs, surely?

I think not. DNSBL operators seem to be very fond of rbldnsd, which 
does not implement zone transfers. I can't speak for how Spamhaus 
moves zones to its authoritative servers or in from primary sources 
like the CBL, but their data feeds to big users are via rsync of 
rbldnsd data.

HOWEVER, Mr. Otis is missing a more important aspect.

Putting a DNSBL right on a registered domain means that the roots for 
the registry-level domain (i.e. the gtld-servers.net machines for a 
.com) can be put in a bad spot for a shutdown. The recommended 
shutdown procedure (as well as simply wiping out the zone) leaves any 
ongoing DNS burden primarily on the nameservers for the parent zone 
of the DNSBL, and it would be bad for DNSBL operators to dump that on 
others.

-- 
Bill Cole                                  
[email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 9 Feb 2007 10:14:50 -0500

On 9-Feb-07, at 7:46 AM, Daniel Feenberg wrote:

>> I strongly believe this is covered by the verbiage in this  
>> section. Should a criminal spammer find himself listed in the SBL  
>> (for example), he should be allowed to immediately request  
>> removal, and be granted that. As soon as he spams, he should be  
>> immediately relisted. And the limits on removals be made harder  
>> for him/her - see the second to last sentence in that first  
>> paragraph. The intention is to make innocent listings easy to  
>> remove, and criminal listings harder to remove.
>
> Is this always desirable?

No. That's why it's a SHOULD.

> If removal must be automatic, doesn't that unnecesarily give the  
> spammer twice as long on the IP address?

Technically yes. But the majority of spammers aren't going to go  
through the removal process, simply because they don't want to end up  
having that discussion.

A good example of a DNSBL that honours immediate removal requests is  
the CBL. One of the very first DNSBLs (the one that became MAPS RSS)  
also did this.

> It seems like that would double the amount of uncaught spam. I  
> would have thought that confirming a delisting with the ASN abuse  
> contact or providing reverse name look to a non-generic host name  
> would be reasonable precaustions a DNSBL might wish to impose  
> before delisting an address, and that in any case it should be up  
> to list policy.

Absolutely. This BCP is just a list of recommendations for that  
policy (especially the SHOULD parts). We think automatic removals are  
best practice because they help keep FPs low, but not every DNSBL  
will agree.

Matt.

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 9 Feb 2007 10:46:37 -0500

On 9-Feb-07, at 9:31 AM, Bill Cole wrote:

> does not implement zone transfers.

My bad - I consider a zone transfer in this day and age to be an  
rsync :)

> Putting a DNSBL right on a registered domain means that the roots  
> for the registry-level domain (i.e. the gtld-servers.net machines  
> for a .com) can be put in a bad spot for a shutdown. The  
> recommended shutdown procedure (as well as simply wiping out the  
> zone) leaves any ongoing DNS burden primarily on the nameservers  
> for the parent zone of the DNSBL, and it would be bad for DNSBL  
> operators to dump that on others.

Right - this was our original intention.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Feb 2007 10:36:24 -0800

On Feb 9, 2007, at 6:31 AM, Bill Cole wrote:

>>> This would be a problem only when zone transfers are used to
>>> distribute data.
>>

When a DNSBL is successful at blocking bad actors controlling perhaps  
thousands of systems, defending against a DDoS becomes a major  
concern.  Even the mention of SPF in this document indicates an  
extreme naiveté about DDoS risks.  I had hoped to make a presentation  
in MAAWG about this concern, but the board decided this might upset  
investments made by key promoters of Sender-ID.  Anyone should be  
able to register their SMTP path.  An inherently safe approach would  
be to first authenticate the SMTP client, and then associate various  
originating domains with SMTP client names.  A similar strategy could  
indicate the possibility of a DKIM replay.  There are many ways this  
can be safely done and still achieve similar goals.

Although Frank scoffed at the DDoS concerns related to SPF, testing  
scripts feed with various input parameters that parse and expand SPF  
records suggests there should be significant warnings associated with  
this approach.  It would seem that this DNSBL draft might be more  
concerned about seeing DNSBLs go away.  This might be sooner than  
anyone may have wanted.  Having them go away "gracefully" still means  
someone is paying for bandwidth without any benefit.

Zone transfers are unhelpful for two reasons as they are:
   1) not responsive to changing behaviors
   2) prone to attack unless defended by ACLs

Suggestions that web servers should be used and share the same name  
server as that of the DNSBL places even greater burdens upon those  
attempting to defend their service.  Why not mention the use of TXT  
records as a means of noting contact information?  Why must this be  
done via a web site?  Why avoid flexibility?  Where is the  
compassion? : )

> for a .com) can be put in a bad spot for a shutdown.

There are many labels involved in a BL transaction using  
d.c.b.a.example.com.  When example.com wants to gracefully shutdown  
as described (although this is not likely to achieve the desired  
result of stopping undesired transactions), this can be done at 'a'  
labels just as well.  These labels must be avoided within any shared  
zone anyway.  The statement about where the zone should exist is not  
needed.  The wording used simply indicates a lack of consideration  
given related threats.

> The recommended shutdown procedure (as well as simply wiping out  
> the zone) leaves any ongoing DNS burden primarily on the  
> nameservers for the parent zone of the DNSBL, and it would be bad  
> for DNSBL operators to dump that on others.

Returning records for each transaction will quickly cause removal of  
DNSBLs likely embedded in some script that an MTA operator may not  
even be aware of.  An announcement that DNSBL 'X' is about to stop  
functioning in this manner should get operators attention.  Those  
ignoring the warning will quickly make corrections thereafter.   
Otherwise, expect wasted traffic to continue for years.  This  
sentence mentions SPF, where this is to be considerate of DNS TLDs?   
What about being considerate to the Internet as a whole?

I posted slides presented to the ISOI II at:
http://www.sonic.net/~dougotis/isoi/

These slides are similar to those presented at the DNS-OP WG.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 9 Feb 2007 15:35:22 -0500

On 9-Feb-07, at 1:36 PM, Douglas Otis wrote:

> Even the mention of SPF in this document indicates an extreme  
> naiveté about DDoS risks.

Not really. The mention of SPF should go - it was a bad choice. The  
rest of your email seemed to have nothing whatsoever to do with this  
draft, but perhaps if you want to re-word it without getting all  
wrapped up in the presence of three letters in the draft then it  
might be clearer what you're trying to say.

Matt.

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 09 Feb 2007 16:17:48 -0500

[FYI: I'm mostly just observing, letting the discussion run...  But this
deserved comment in terms of the intent behind the BCP]

> thousands of systems, defending against a DDoS becomes a major concern.

Yes, but I don't think anything in the BCP predisposes compliant
operators putting themselves at risk of DDOS or any other hazard more
than is minimally necessary to provide the service in the first place.
As a general principle, we tried to avoid anything that would do that.

> It would seem that this DNSBL draft might be more
> concerned about seeing DNSBLs go away.  This might be sooner than anyone
> may have wanted.  Having them go away "gracefully" still means someone
> is paying for bandwidth without any benefit.

DNSBLs going away ungracefully has been a source of considerable adverse
press about them.  The suggested process appears to be the best way to
reduce bandwidth (both for the DNSBL and third parties) without listing
the world.  You seem to prefer the blacklist the world concept
(wildcarding results).  That's a VERY VERY bad idea because reality
causes everyone shutting down that way to be perceived as irresponsible
idiots, and damages the reputation of DNSBLs in general.  The ripples of
the OSIRUS and Monkeys shutdowns are still reverberating and smear all
subsequent DNSBLs.

The intent of the described process is this:

1) The registered domain remains useful and unflooded with DNS queries
(whether regular queries or wild resolvers).  (This was an issue with
both Osirus and Monkeys)
2) The TLD servers aren't flooded (for each query or wild resolvers)
3) the world isn't blacklisted
4) The user of the DNSBL eventually notices, without suffering a
complete loss of email.

By doing the DNSBL's base zone below the registered domain, you can have
a NS server separate from the registered domain.  You can shut down
such a DNSBL by setting the DNSBL's NS to point somewhere in 127/8
(other than 127.0.0.0/24, say[+]).  Since the NS TTL has been set high,
a DNSBL query won't requery it (off the registered domain's NS) very
frequently.  Since no NS responds from the 127/8 address, the query
times out.  Causing the user's email to be delayed by the query timeout,
not 100% blacklisted.  The user's admins eventually notice the delay,
and remove the entry.

It's been suggested that setting the DNSBL's NS record to "." would do
the same, but there seems to be indications that some resolvers don't
handle that well.

One of the things we have to consider is that once a DNSBL becomes
popular, its name becomes somewhaet of a deadzone for a very long time.
 If you let the registered domain expire as a way of killing the DNSBL,
wildcarding (perhaps by a domain squatter acquiring the domain, or
Verisign deploying whatever that was again) will have catastrophic
results.  In some cases, you might have to keep the domain registered
forever to avoid something nasty.

[Try doing DNSBL queries against letter transpositions of "spamhaus.org"
some day.  You should find several typosquatters wildcarding to their
web sites which means 100% blacklisting to some DNSBL query clients].

[blars.org appears to have simply been allowed to expire recently.  But
it's way too much a marginally used DNSBL to draw conclusions on what
would happen if, say, spamhaus.org went away.]

You did mention that the TXT record should include contact and/or
explanatory info (as in a link).  We obviously forgot that, and it
should be added as a "SHOULD" or at least "RECOMMENDED".

I'm not sure what the discussion about zone transfers is all about.  I
don't think many DNSBLS support real DNS zone transfers anymore.  An
AXFR transfer of a DNSBL like the XBL is hideously expensive.  Most
DNSBLs have settled on rsync, and other forms (various DNS protocol
methods, wget, ftp etc) have been disappearing over time.  It might be
worth mentioning rsync as the "defacto standard DNSBL bulk transfer
mechanism", but leave it at that.

[+] Putting the NS on 127.0.0.1, say, could be extremely dangerous - the
MTA using the DNSBL may be coresident with a DNS resolver that returns
wierd results that we can't predict the MTA can handles properly.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 09 Feb 2007 23:14:31 +0100

Douglas Otis wrote:

> Why not mention the use of TXT records as a means of
> noting contact information?

IIRC the name of that record is RP or similar, not TXT.

> Why must this be done via a web site?

Because http is quite popular for transporting more
than 400 bytes.  Nothing against gopher or whois, but...

> http://www.sonic.net/~dougotis/isoi/

Comparing the size of the message with the size of the
final queries is bogus.  The attacker has to sustain
those queries from his own name server, and with that
it's a factor near 9 (11 or 12 queries to the attacker,
100 queries to the victim).

The a * b * c * d stuff ignores caches, it's nonsense.

As an attacker with 102,400 bots I wouldn't bother to
figure out who checks SPF and how their DNS caches work,
and bet on ordinary "call back verification".  Or let
the bots flood the victim directly with bogus queries.

And it won't surprise me if some SPF implementations
already have a "NXDOMAIN processing limit" to catch
your convoluted attempts based on malicious MX records.

Terminate policies with "+all" is also bullshit, the
fastest way to get a PASS for any IP is to use only
"v=spf1 +all".  Of course that's a really bad idea
for somebody planning to stay on a white list, but
some spammers might like the cheap PASS.

Frank

---

From: John Levine <[email-masked]>
Date: 9 Feb 2007 23:10:50 -0000

>don't think many DNSBLS support real DNS zone transfers anymore.

Until recently, MAPS distributed its DNSBLs by AXFR and IXFR.  If you
happen to have a DNS server that does IXFR, it's not a bad way to do
DNS updates.  If you don't (like me), AXFR is dreadful.

MAPS recently changed their setup and now tell me just to query their
servers via a long name that includes a hash of my account number,
which I do via a funky local cache that reformats the data on the fly
into something easier for my mail servers to use.  I don't know of
anyone who distributes DNSBLs other than by rsync or FTP of files of
CIDR ranges.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Feb 2007 15:13:04 -0800

On Feb 9, 2007, at 1:17 PM, Chris Lewis wrote:

>>> I think not. DNSBL operators seem to be very fond of rbldnsd,  
>>> which does not implement zone transfers. I can't speak for how  
>>> Spamhaus moves zones to its authoritative servers or in from  
>>> primary sources like the CBL, but their data feeds to big users  
>>> are via rsync of rbldnsd data.
>
>> When a DNSBL is successful at blocking bad actors controlling  
>> perhaps thousands of systems, defending against a DDoS becomes a  
>> major concern.
>
> operators putting themselves at risk of DDOS or any other hazard  
> more than is minimally necessary to provide the service in the  
> first place. As a general principle, we tried to avoid anything  
> that would do that.

Few seem to consider this aspect of providing BL services.

>> It would seem that this DNSBL draft might be more concerned about  
>> seeing DNSBLs go away.  This might be sooner than anyone may have  
>> wanted.  Having them go away "gracefully" still means someone is  
>> paying for bandwidth without any benefit.
>
> DNSBLs going away ungracefully has been a source of considerable  
> adverse press about them.  The suggested process appears to be the  
> best way to reduce bandwidth (both for the DNSBL and third parties)  
> without listing the world.  You seem to prefer the blacklist the  
> world concept (wildcarding results).  That's a VERY VERY bad idea  
> because reality causes everyone shutting down that way to be  
> perceived as irresponsible idiots, and damages the reputation of  
> DNSBLs in general.  The ripples of the OSIRUS and Monkeys shutdowns  
> are still reverberating and smear all subsequent DNSBLs.

Those offering a free service are not likely concerned about earning  
DNSBLs a bad reputation, especially they are bombarded by an ill  
considered scheme designed to keep the SMTP client nameless.

There is a similar conversation on nanog about maps.vix.com.

Here is a link to a possible solution.  The point is not to be  
"graceful" but to get the transactions to stop.  This requires some  
level of pain, but block all messages would be rather extreme.   
Suggesting that BL should forever return some type of safe response  
for time immemorial is not a good solution either.

http://www.merit.edu/mail.archives/nanog/msg04555.html

> By doing the DNSBL's base zone below the registered domain, you can  
> have a NS server separate from the registered domain.  You can shut  
> down such a DNSBL by setting the DNSBL's NS to point somewhere in  
> 127/8 (other than 127.0.0.0/24, say[+]).  Since the NS TTL has been  
> set high, a DNSBL query won't requery it (off the registered  
> domain's NS) very frequently.  Since no NS responds from the 127/8  
> address, the query times out.  Causing the user's email to be  
> delayed by the query timeout, not 100% blacklisted.  The user's  
> admins eventually notice the delay, and remove the entry.

Perhaps.  This delay would be 35 seconds or so.  Many that query list  
of lists quit after some timeout hoping some information has been  
obtained.  Even this might not be noticed.  Perhaps a list of NS  
would attract greater attention.  As been mentioned, this requires a  
different structure.

> It's been suggested that setting the DNSBL's NS record to "." would  
> do the same, but there seems to be indications that some resolvers  
> don't handle that well.

And not nice.

> popular, its name becomes somewhaet of a deadzone for a very long  
> time.  If you let the registered domain expire as a way of killing  
> the DNSBL, wildcarding (perhaps by a domain squatter acquiring the  
> domain, or Verisign deploying whatever that was again) will have  
> catastrophic results.  In some cases, you might have to keep the  
> domain registered forever to avoid something nasty.

Review the referenced nanog message.  There might be a better solution.

> I'm not sure what the discussion about zone transfers is all  
> about.  I don't think many DNSBLS support real DNS zone transfers  
> anymore.  An AXFR transfer of a DNSBL like the XBL is hideously  
> expensive.  Most DNSBLs have settled on rsync, and other forms  
> (various DNS protocol methods, wget, ftp etc) have been  
> disappearing over time.  It might be worth mentioning rsync as the  
> "defacto standard DNSBL bulk transfer mechanism", but leave it at  
> that.

The concern was about where the zone is located within the domain.   
This section is not needed.

> [+] Putting the NS on 127.0.0.1, say, could be extremely dangerous  
> - the MTA using the DNSBL may be coresident with a DNS resolver  
> that returns wierd results that we can't predict the MTA can  
> handles properly.

Agreed.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Fri, 9 Feb 2007 15:26:30 -0800

On Feb 9, 2007, at 3:10 PM, John Levine wrote:

>> about.  I

... which is a shame, as they're both really bad ways of doing it, but
they work, they're easy to kludge together from existing tools and
scale way better than AXFR.

I have seen a couple of blacklists fairly recently that do still use  
AXFR, but
they were way, way out in the long tail - probably entirely unused
by anyone other than their operators. If they ever became popular
their operators would switch to rsync pretty quickly, I suspect.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Feb 2007 16:06:44 -0800

On Feb 9, 2007, at 2:14 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> Why not mention the use of TXT records as a means of noting  
>> contact information?
>

There are also TXT records that may accompany the A record.  Often  
this indicates a contact method.

> Because http is quite popular for transporting more than 400  
> bytes.  Nothing against gopher or whois, but...

Whatever gets used must be robust against DDoS attack without costing  
a fortune.  Other solutions might be more effective, so why rule them  
out.

> Comparing the size of the message with the size of the final  
> queries is bogus.

The attacker is sending spam anyway.  Even email traffic should not  
be considered part of the attack overhead.  This means the  
amplification is actually much much greater!

> The attacker has to sustain those queries from his own name server,  
> and with that it's a factor near 9 (11 or 12 queries to the  
> attacker, 100 queries to the victim).

The SPF macro language allows the same SPF script to utilize local- 
part elements of an email address to cause any subsequent lookup to  
occur.  These scripts can enjoy a very long TTL and not be re- 
queried.  The MX records and their targets then enjoy the difference  
between a negative cache TTL, where in many cases the number needed  
to seed an attack would not be many per local resolver.  The reality  
this problem is actually worse than the numbers listed and virtually  
free to the attacker, unlike most direct attacks, or even spoofed  
recursive attacks.

> The a * b * c * d stuff ignores caches, it's nonsense.

Queries are randomized by the local-part as needed.  Attacking  
queries will not be found within an cache.  This is not nonsense.

> As an attacker with 102,400 bots I wouldn't bother to figure out  
> who checks SPF and how their DNS caches work, and bet on ordinary  
> "call back verification".  Or let the bots flood the victim  
> directly with bogus queries.

SPF allows an attack to be reflected off of some ISPs resolvers at  
virtually no cost to their own resources.  These attacks are done at  
the behest of the attacker when recipients attempt to process their  
SPF scripts.  The attacker will still be able to send the same number  
of spams, while also completely melting down some targeted network.   
There will be very little evidence indicating how the attack is  
happening.  The domains being queried or their victims might not be  
found in any message.

> And it won't surprise me if some SPF implementations already have a  
> "NXDOMAIN processing limit" to catch your convoluted attempts based  
> on malicious MX records.

In in the libraries I reviewed, many don't even limit the number of  
targets being accessed.  What is a good limit for NXDOMAINs for SPF  
scripts?  How can it be determined whether these scripts have been  
upgraded?  Change the version of the script?  Wildcard MX or SPF  
records could be the next ploy, where the game continues unabated.   
This SPF attack is virtually free to the attacker thanks to SPF's  
macro features.  Why not simply authenticate the SMTP client and then  
associate various originating domains?  One transaction and  
absolutely _no_ risk to the Internet.

> Terminate policies with "+all" is also bullshit, the fastest way to  
> get a PASS for any IP is to use only "v=spf1 +all".  Of course  
> that's a really bad idea for somebody planning to stay on a white  
> list, but some spammers might like the cheap PASS.

bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45  
ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177  
ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22  
ip4:69.156.197.234 ip4:66.241.131.163 +all"

The goal could be to list the IP addresses being used without SPF  
causing messages to be mysteriously lost, or to encourage use of very  
dangerous SPF script parsers.

Executing script from anonymous sources is a basic problem.  It is  
clear that MAAWG's Sender policy does not care about DDoS problem  
either.  It can't always be about avoiding complaints and making  
money.  Validate the SMTP client and this problem disappears.  A  
simple scheme for associating domains provides a safe means for  
registering paths or authorizations of DKIM signatures.  Providers  
must be willing to be held directly accountable for the messages they  
send by name.

-Doug

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 09 Feb 2007 19:54:35 -0500

> considered scheme designed to keep the SMTP client nameless.

Those offering a free service do everyone else trying/using the same
thing a grave disservice by screwing up.

> Here is a link to a possible solution. 

Look closer, Doug.  It's the same solution.

It should be, because the guy who introduced it in that posting to
NANOG, is the same person who introduced it where we saw it ;-)

---

From: "Chris Lewis" <[email-masked]>
Date: Fri, 09 Feb 2007 20:01:01 -0500

> NANOG, is the same person who introduced it where we saw it ;-)

Whoops, not quite, it takes into account that you shouldn't put IPs in
NS records.  A worked example like the NANOG one using 127 addresses
would perhaps be best for the BCP.  Should touch base with Jon to see
why he used 192.0 instead of 127.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Feb 2007 17:12:10 -0800

On Feb 8, 2007, at 8:44 PM, Matt Sergeant wrote:

>>> I don't get the idea of an arbitrary magic number "6 months".   
>>> For a list with say bogon IPs it would be "as long as necessary",  
>>> unlimited.  You address this later, but IMO no fixed limit also  
>>> here is clearer.
>>

> "6 months is reasonable for a long listing, and this is very well  
> covered by the last point in this section - that a temporary  
> listing can easily be extended by (for example) receiving more spam  
> from this IP/range."

Listing intervals depend upon several factors.  One might be related  
to who manages the ASN.  Regularly enabling dormant IP addresses  
within a large, poorly managed network would be a very bad choice.   
What is the justification for 6 months?  A period that represents  
typical IP ownership is not likely 6 months.  Many of these systems  
are compromised and can be retasked to send spam once the IP address  
drops off a popular block list.  How is 6 months reasonable for a  
long listing?  Why not state a goal rather than setting some  
arbitrary period not based upon any information or rationale.

>> It is not possible to disclose _any_ email information without  
>> also disclosing where the message was obtained.  It is simply  
>> impossible to fully redact a message to provide such an assurance  
>> of non-disclosure.
>

Publicly listed messages likely represent a sacrificial source.   
There lies the rub.  What happens when a spammer has an above average  
IQ?  Your listed, but we can show you why?

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 9 Feb 2007 20:28:02 -0500

On 9-Feb-07, at 8:12 PM, Douglas Otis wrote:

>> listing can easily be extended by (for example) receiving more  
>> spam from this IP/range."
>
> Listing intervals depend upon several factors.  One might be  
> related to who manages the ASN.  Regularly enabling dormant IP  
> addresses within a large, poorly managed network would be a very  
> bad choice.  What is the justification for 6 months?

We decided to pick an upper limit. We picked the most respected DNSBL  
(Spamhaus' SBL) to give us that limit - 6 months (for ROKSO SBL  
listings). A spamhaus listing will drop off if the ROKSO spammer  
stops spamming for 6 clear months.

Remember we're not saying you have to wait the 6 months before re- 
checking listing criteria. If the event (e.g. spamming) re-occurs  
before that six months is up (say at month 3) you reset the timeout  
period.

So a spammer suspends spamming from an IP for 6 months to wait out  
the timeout just to start spamming again, and you think that would be  
a bad thing? Frankly I think the internet community would be glad of  
the 6 month reprieve (and of course the subsequent relisting).

> A period that represents typical IP ownership is not likely 6  
> months.  Many of these systems are compromised and can be retasked  
> to send spam once the IP address drops off a popular block list.   
> How is 6 months reasonable for a long listing?  Why not state a  
> goal rather than setting some arbitrary period not based upon any  
> information or rationale.

The goal is stated. If it needs to be clarified we should do that.

>> Hence why this is a SHOULD not a MUST. It's a tricky line -  
>> compare for example the disclosure given by PSBL (almost full  
>> spamtrap hit contents) vs SBL. Both presumably maintain an  
>> internal audit trail, but one is public and one is private, but  
>> both are reasonably well run DNSBLs.
>
> There lies the rub.  What happens when a spammer has an above  
> average IQ?  Your listed, but we can show you why?

Do you have an objection to this point being a SHOULD? Clearly DNSBLs  
maintain and even display audit trails and retain effectiveness. I'm  
lost by your argument here. The point of this section is that an  
audit trail is a valuable thing when there's a complaint about a  
listing, or some other issue, so even if it's not public the audit  
trail really should exist.

I sincerely hope you're not suggesting that the MAPS dnsbl's don't  
maintain audit trails, even if they're not publicly available.

Matt.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Feb 2007 18:03:03 -0800

On Feb 9, 2007, at 5:28 PM, Matt Sergeant wrote:

> We decided to pick an upper limit. We picked the most respected  
> DNSBL (Spamhaus' SBL) to give us that limit - 6 months (for ROKSO  
> SBL listings). A spamhaus listing will drop off if the ROKSO  
> spammer stops spamming for 6 clear months.

Spamhaus is a very good organization.  The fact they use 6 months  
does not mean everyone should use 6 months.  For those using multiple  
lists, having different intervals increases protection when policies  
vary.  There are a vast number of IP addresses controlled by bad  
actors where playing a waiting game would be made easier when DSNBL  
operators standardize this rather fundamental criteria.  Not stating  
this interval has much more merit than stating it would ever have.   
What problem is being solved?

Those managing the list will likely adopt policies that minimize the  
administration of the list in most cases.  The draft already says  
that repeated occurrences can exponentially extend this interval.   
Would an occurrence within the same 6 months be counted as one?  Does  
the IP address need to be removed from the list before repeated  
offenses are counted?

> the timeout just to start spamming again, and you think that would  
> be a bad thing? Frankly I think the internet community would be  
> glad of the 6 month reprieve (and of course the subsequent relisting).

When nothing has changed with respect to the IP address ownership,  
why not apply intervals according to the general management of the  
address space, rather than a pedantic treatment of each IP address  
individually?

> The goal is stated. If it needs to be clarified we should do that.

DNSBL operators should mimic Spamhaus policies?  Don't suggest there  
is some magic period.

>>>> impossible to fully redact a message to provide such an  
>>>> assurance of non-disclosure.
>>>
> Do you have an objection to this point being a SHOULD? Clearly  
> DNSBLs maintain and even display audit trails and retain  
> effectiveness. I'm lost by your argument here. The point of this  
> section is that an audit trail is a valuable thing when there's a  
> complaint about a listing, or some other issue, so even if it's not  
> public the audit trail really should exist.

An audit trail should exist.  There are considerations not covered in  
this draft about what can be made public.  Those considerations  
should be included.  This could brace users when they hear something  
that they don't want to hear.  "I can't show you the message."

> maintain audit trails, even if they're not publicly available.

Don't worry, we are keeping storage companies in business. : )

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 10 Feb 2007 03:12:26 +0100

Douglas Otis wrote:
 
> There are also TXT records that may accompany the A record.
> Often this indicates a contact method.

If you're talking about TXT records accompanying DNSBL listings
they're generally URLs, the exp= in SPF is a similar idea.

> Whatever gets used must be robust against DDoS attack without
> costing a fortune.  Other solutions might be more effective,
> so why rule them out.

URLs are fine, they work for everybody, and you don't need I18N
considerations for http, it's a solved problem.  I'm a "whois" 
fan, but there are cases where "http" has a few advantages.

> The attacker is sending spam anyway.  Even email traffic should
> not be considered part of the attack overhead.  This means the

No, it means you've to compare queries answered by the attacker
with queries sent to the victim.  And that's a factor 9 with mx-
mechanisms in SPF, no matter what the attacker does.

> The SPF macro language allows the same SPF script to utilize
> local-part elements of an email address

There's no such thing as "SPF scripts".  You've enumerated the
macros in your PDF, they're all derived from the input IP, the
checked address, and the HELO identity.

The PTR stuff might appear to be a bit obscure, but actually it
is what any MTA checking reverse DNS does, once per session.
And completely unusable for any kind of attack.

> The MX records and their targets then enjoy the difference
> between a negative cache TTL

Whatever they enjoy or not, there's a limit of ten names per
MX record in SPF evaluations.  With different local parts the
attacker can cause queries to different bogus MX records on
his own server (per mail).  So he got rid of 1 of 11 queries
sent to his own server, if it's the same cached SPF policy.

He still has to answer the ten MX queries, each with 10 names
in the domain of the victim.  But in your PDF you say a*b*c*d,
one of that is used local parts, another is recipients per
mail.  With an assumption that all recipients check SPF at
their MUA, clearly against a recommendation in RFC 4408.

Ingnoring that - the number of local parts and recipients is
still irrelevant for the amplification of at most 10 queries
per MX.  The attacker can drop the complete SPF business and
try to abuse "call back verification".

> queries will not be found within an cache.  This is not nonsense.

The "randomized" stuff are mx:%{l}.attacker.example mechanisms,
queries to the attacker.  One of your a*b*c*d factors was the
number of recipients of the same mail, the same local part.

> The attacker will still be able to send the same number of
> spams, while also completely melting down some targeted network.

While combining spam with DDoS attacks might be a fine art, I'd
pick a more direct approach and try to either spam or DDoS, not
some combo depending on an unknown number of recipients checking
SPF behind their border MX, against several SHOULDs in RFC 4408.

> In in the libraries I reviewed, many don't even limit the number
> of targets being accessed.  What is a good limit for NXDOMAINs
> for SPF scripts?

Evaluation => library.  SPF policies aren't affected by your
convoluted attack recipes, nobody uses ten mx-mechanism each with
ten names, and implementations were always encouraged (SHOULD) to
limit their efforts in addition to the MUST limits.  No working
policy needs to be "upgraded", talking about many non-existing 
names in MX records was and is always a bad idea.

> Why not simply authenticate the SMTP client and then associate 
> various originating domains?

The recommended SPF HELO check comes before the MAIL FROM checks.

If you don't like the latter you can still do the former, it has
the nice feature to work everywhere, not only at the border.  Of
course receivers could impose their own rules on HELO without
checking what the alleged sender proposes.  But receivers trying
to follow the RFC 2821 rules might like a kind of permission to
be stricter offered in a "v=spf1 a -all" or similar policy.

> ip4:69.156.197.234 ip4:66.241.131.163 +all"

A bogus policy, so what ?  Anybody can claim to be HELO bell.ca
or to send MAIL FROM:<[email-masked]>

> The goal could be to list the IP addresses being used without
> SPF causing messages to be mysteriously lost

SPF doesn't lose mails mysteriously.  A FAIL detected at the
border is simply rejected.  The policy shown above will attract
spammers to abuse bell.ca whereever it pleases them.  If their
goal is to publish obscure lists of IPs they better dont't use
"v=spf1", they could say "our ips" without "+all" at the end.

> Executing script from anonymous sources is a basic problem.

Yes, fortunately SPF is no script, although you apparently argue
that MX records are a fundamental security problem.

Frank

---

From: Bill Cole <[email-masked]>
Date: Fri, 9 Feb 2007 22:15:57 -0500

At 8:01 PM -0500 2/9/07, Chris Lewis  imposed structure on a stream 
>why he used 192.0 instead of 127.

I believe his idea is that it would always go out on the wire for any 
machine instead of into the possibly less uniform world of loopback 
handling.

I am not sure that makes a significant difference, except that in 
some environments the packet on the wire to a 192.0.2/24 address will 
elicit an explicit response rather than go off into nowhere, while on 
many (most?) hosts a packet to a 127/8 address other than 127.0.0.1 
will stay on the machine and get no response. On the good side, a lot 
of packets aimed at 192.0.2/24 on a path through default gateways may 
be noticeable to someone who can slap the mail admin to attention.

-- 
Bill Cole
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Sat, 10 Feb 2007 17:34:38 -0800

> mechanisms in SPF, no matter what the attacker does.

SPF records staging an attack may have very long TTLs and utilize
local-part components of an email-address for generating subsequent DNS
transactions.  The macro expansion of SPF scripts allows the _same_
record to generate different attacking transactions.  SPF macro
expansion of local-part elements into subsequent DNS transactions is a
tremendous gift provided to an attacker.

This macro expansion feature eliminates further consumption of an
attacker's resources.  SPF allows attacks to be virtually free and
impossible to stop or defend against.  Nonexistent targets of MX records
is just _one_ means to stage an SPF facilitated attack.

Your calculations continue to overlook the likely difference between the
TTL of the MX record versus the negative cache TTL of bogus target A
records, and the advantages obtained from label compression.  Once the
negative caching period has elapsed, the attack sequence can then reuse
seeded MX records published with long TTLs.  Such an attack can continue
for hours, where the overhead needed to seed the sequence will be fairly
small in comparison, and can be neglected.

> There's no such thing as "SPF scripts".

SPF records will often appear completely meaningless without input
parameters and their related macro expansion.  SPF records include
commands that transform character strings, reorder label sequences, mix
different elements of the various input parameters, overlay DNS
transactions with CIDR masks, test existence of A records, include or
redirect the processing of a series of SPF record transactions,
etcetera, etcetera.

Describing SPF as anything less that a scripting language would be a
misrepresentation.  While this language is limited, it provides powerful
capabilities that can effectively stage DDoS attacks or greatly assist
in poisoning DNS caches. 

> You've enumerated the macros in your PDF, they're all derived from the
> input IP, the checked address, and the HELO identity.

The checked "address" could be for the PRA.  The script might be run
once again for the MailFrom, and perhaps one more time for a DKIM
domain.  Limits established for SPF processes are for each "address"
being independently checked.  The PRA, MAILFROM and DKIM domains
represent a possibility for a long list of names checked per message.

> And completely unusable for any kind of attack.

I agree.  Validating just the SMTP client is unlikely to result in
dangerous amplifications.  However, SPF scripts attempt to collect
addresses used by _all_ SMTP clients that might be utilized by an
originating domain.

A safe way to associate thousands of different SMTP clients with that of
some originating domain would be by "named reference".  This can be done
within one small and safe transaction. Alas, this is far from true with
SPF's demand for an entire IP address set.

> MX record in SPF evaluations.

Many SPF script parsers fail to limit even the number of names resolved
in MX records.  Even so, there are ten MX records being processed with
perhaps 10 or more targets each.

> With different local parts the attacker can cause queries to different
> bogus MX records on his own server (per mail).  So he got rid of 1 of
> 11 queries sent to his own server, if it's the same cached SPF policy.

This would be true only the _first_ time the MX record is used.

> in the domain of the victim.

Label compression unfortunately works in favor of an attacker, in
addition to differences between negative caching TTLs and the TTL of the
MX records.  MX records can be reused without causing added overhead for
the attacker after negative caching of its bogus targets have expired.
This is what was meant by "seeding" the attack, and why the calculations
still underestimate the risk.

> But in your PDF you say a*b*c*d, one of that is used local parts,
> another is recipients per mail.  With an assumption that all
> recipients check SPF at their MUA, clearly against a recommendation in
> RFC 4408.

This number includes all MSAs (including MUAs). Where is the
recommendation against checking SPF at the MUA in RFC 4408?

Here is the _only_ text mentioning MUAs:

2.4.  Checking Authorization
...
   Typically, such checks are done by a receiving MTA, but can be
   performed elsewhere in the mail processing chain so long as the
   required information is available and reliable.

2.5.5.  SoftFail
...
   The domain owner wants to discourage the use of this host and thus
   desires limited feedback when a "SoftFail" result occurs.  For
   example, the recipient's Mail User Agent (MUA) could highlight the
   "SoftFail" status, or the receiving MTA could give the sender a
   message using a technique called "greylisting" whereby the MTA can
   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
   first time the message is received, but accept it the second time.

8.1.  Macro Definitions
...
   The "r" macro expands to the name of the receiving MTA.  This SHOULD
   be a fully qualified domain name, but if one does not exist (as when
   the checking is done by a MUA) or if policy restrictions dictate
   otherwise, the word "unknown" SHOULD be substituted.  The domain name
   may be different from the name found in the MX record that the client
   MTA used to locate the receiving MTA.

10.2.  SPF-Authorized E-Mail May Contain Other False Identities

   The "MAIL FROM" and "HELO" identity authorizations must not be
   construed to provide more assurance than they do.  It is entirely
   possible for a malicious sender to inject a message using his own
   domain in the identities used by SPF, to have that domain's SPF
   record authorize the sending host, and yet the message can easily
   list other identities in its header.  Unless the user or the MUA
   takes care to note that the authorized identity does not match the
   other more commonly-presented identities (such as the From:  header
   field), the user may be lulled into a false sense of security.

Section 10.2 even seems to require SPF checking be done at the MUA.
Prohibitions of MUA checking is not within the security consideration
section either.  It has not stopped MUA plugins like Spamassassin, or
those for Thunderbird, Outlook or Outlook express either.  

To quote Wietse Venema:
        "Junk mail is war. RFCs do not apply."

> Ignoring that - the number of local parts and recipients is

Don't ignore label compression (where nefarious tricks might also be
used), and of course, the differences between negative caching and the
TTL of reused MX RRs.  Greatly extending negative caching will create
other problems. 

Whether there are random queries for bogus MX, SPF, or A records, the
attack is made virtually free with SPF.  Why would someone want to
expose themselves by attacking using other methods, when SPF allows the
attacker to completely hide, where even logs are not likely to assist in
tracing the source of the virtually free attack?

> number of recipients of the same mail, the same local part.

In the MX record attack example, the "random" query would likely repeat
after a negative caching period.  Other attacks may never need to repeat
and would still not expend any of the attacker's resources beyond the
initial record queries. 

> SPF behind their border MX, against several SHOULDs in RFC 4408.

A direct attack would expose which systems are compromised.  Direct
attacks provide valuable information, especially for those wanting this
information.  The baseline of the example attack starts at 508 Kbit/msg
where the message would be sent anyway.  Use of SPF script parsers is
easily detected by bad actors, where recipients using SPF script parsers
are made well known.  The macro language of SPF even facilitates this
canvassing effort as well.

> names in MX records was and is always a bad idea.

Sigh. The attack is staged by a bad actor.  The bad actor creates the MX
records with perhaps 20 or more victim targets.  Many of the SPF script
parsers will attempt to resolve all targets for each of the 10 MX
records.  They might attempt to do this once for the PRA, and when that
fails, attempt to do this again for the MAILFROM.  There might even be
another attempt to process one or more DKIM domains.  Each MAILFROM and
DKIM script can happily end with '+all'.

> be stricter offered in a "v=spf1 a -all" or similar policy.

Alas, v=spf1 does not provide a scope definition nor would this prevent
bad actors from listing all scopes.  SPF represents an extreme danger
for the Internet as a whole.

> or to send MAIL FROM:<[email-masked]>

This allows the listing of IP addresses to permit white-listing by those
providers who _insist_ on using SPF records for this purpose, such as
AOL.  This was the reason given for the comment made in the
presentation.

> spammers to abuse bell.ca where ever it pleases them.  If their

Some MTAs may check SPF before issuing DSNs.  Acceptance may have been
based upon the PRA, where the DSN checking might occur after a message
has been forwarded, and thereby rejected.  These messages may then
mysteriously vanish as a result.

SPF offers virtually no recipient protection, as it often checks unseen
headers.  SPF can not be safely applied at the MUA, however there are
those who will try such an unsafe practice.  SPF/Sender-ID is simply
unsafe from several perspectives.

Providers should adopt conventions for using APL records (RFC3123), and
avoid using TXT records altogether, especially SPF records.

> that MX records are a fundamental security problem.

No, the macro capability of the SPF script language is a _security_
threat!  Scripts often accept input parameters and remain in their
original form.  When run, scripts are then "interpreted" a "command" at
a time.  This definition becomes clearer after substituting "mechanism"
and "macro" used by SPF for the word "command".  SPF is truly a
scripting language.  Why say otherwise?

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 12 Feb 2007 12:16:37 -0500

On 9-Feb-07, at 9:03 PM, Douglas Otis wrote:

>>> months.  Many of these systems are compromised and can be  
>>> retasked to send spam once the IP address drops off a popular  
>>> block list.  How is 6 months reasonable for a long listing?  Why  
>>> not state a goal rather than setting some arbitrary period not  
>>> based upon any information or rationale.
>>
> DNSBL operators should mimic Spamhaus policies?  Don't suggest  
> there is some magic period.

Our belief: There needs to be a sensible maximum time of listing  
should the entry no longer meet the listing criteria.

We think 6 months is a sensible maximum. This BCP is in NO WAY  
suggesting that an IP/range shouldn't ever be listed for longer than  
6 months, but that if your listing criteria is no longer met then the  
entry should time out after a maximum of 6 months.

Clearly we can state this better. I'll try and get Nick to use  
something from the above paragraph.

>> complaint about a listing, or some other issue, so even if it's  
>> not public the audit trail really should exist.
>
> An audit trail should exist.  There are considerations not covered  
> in this draft about what can be made public.  Those considerations  
> should be included.  This could brace users when they hear  
> something that they don't want to hear.  "I can't show you the  
> message."

Good point. How about:

    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 administrator's possession relating to the
    listing; e.g., a DNSBL administrator 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 the DNSBL's spam trap.

Matt.

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 12 Feb 2007 13:21:37 -0500

Matt Sergeant wrote:
>>>> How is 6 months reasonable for a long listing?  Why not state a goal
>>>> rather than setting some arbitrary period not based upon any
> Our belief: There needs to be a sensible maximum time of listing should
> the entry no longer meet the listing criteria.
> 
> suggesting that an IP/range shouldn't ever be listed for longer than 6
> months, but that if your listing criteria is no longer met then the
> Clearly we can state this better. I'll try and get Nick to use something
> from the above paragraph.

Good idea.  I can see that that section is being misunderstood.
>> this draft about what can be made public.  Those considerations should
>> be included.  This could brace users when they hear something that
>> they don't want to hear.  "I can't show you the message."
> 
> Good point. How about:
> 
>    that might assist spammers, such as the contents of an email received

I like.  Just change the last "the" to "a".

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 11:11:31 -0800

On Feb 12, 2007, at 9:16 AM, Matt Sergeant wrote:

> suggesting that an IP/range shouldn't ever be listed for longer  
> than 6 months, but that if your listing criteria is no longer met  
> then the entry should time out after a maximum of 6 months.

6 months is not a sensible maximum in may cases.   If an interval  
must be mentioned, why not say a year or less.  A year is likely to  
be a typical interval for service purchases.  Most spam sources are  
compromised systems.  Increasing the block cycle rate will just  
increase the number of times a compromised system can spew spam  
before being once again blocked.  When the owner of the IP address  
actually wants to send valid email, they can make a request to  
expedite a removal process in most cases.  What makes 6 months sound  
reasonable????

>    by the DNSBL's spam trap.

Better. Chris is right about changing to "a DNSBL spam trap".

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 12 Feb 2007 14:42:56 -0500

On 12-Feb-07, at 2:11 PM, Douglas Otis wrote:

> expedite a removal process in most cases.  What makes 6 months  
> sound reasonable????

6 months is entirely arbitrary. As is your suggestion of "a year or  
less". You have to pick what sounds sensible and that sounded  
sensible to the authors and those who run public DNSBLs that we  
consulted.

---

From: "Chris Lewis" <[email-masked]>
Date: Mon, 12 Feb 2007 14:43:50 -0500

Douglas Otis wrote:
> 6 months is not a sensible maximum in may cases.   If an interval must
> be mentioned, why not say a year or less.  A year is likely to be a
> typical interval for service purchases.  Most spam sources are
> compromised systems.  Increasing the block cycle rate will just increase
> the number of times a compromised system can spew spam before being once
> again blocked.  When the owner of the IP address actually wants to send
> valid email, they can make a request to expedite a removal process in
> most cases.  What makes 6 months sound reasonable????

We have to remember that DNSBLs have very widely varying expiration
intervals, based upon how they list and in some cases sheer size.
SpamCop's initial expiration is a day or two.  But some DNSBLs are forever.

I believe that listings, absent "later redetection of malicious
behaviour", should have a timeout.  For a SBL-ish list, 6 months of "no
repeat behaviour" is a reasonable max.  For a "straight compromise"
DNSBL (like CBL, ORDB etc) it hardly makes sense to hold entries so
long, especially when so much of it is dynamic, or at least, not nearly
as long lived as a stationary MTA.

But aside from things like geo-based DNSBLs, I think all DNSBLs should
have some sort of timeout (again, absent repeat detections).  Otherwise,
we litter IPv4 with IP space that's difficult to use.  I pity the poor
people who have to reuse AGIS space...

I don't think we want to litter the BCP with stuff like that.  I'd like
to avoid it.  But I think saying that a reasonable timeout is a good
idea.  Matt's altered wording is better I think.

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 12 Feb 2007 15:14:13 -0500 (EST)

...
>>>> Publicly listed messages likely represent a sacrificial source.  There 
>>>> lies the rub.  What happens when a spammer has an above average IQ?  Your 
>>>> listed, but we can show you why?
>>> 
>>> maintain and even display audit trails and retain effectiveness. I'm lost 
>>> by your argument here. The point of this section is that an audit trail is 
>>> a valuable thing when there's a complaint about a listing, or some other 
>>> issue, so even if it's not public the audit trail really should exist.
>> 
>> An audit trail should exist.  There are considerations not covered in this 
>> draft about what can be made public.  Those considerations should be 
>> included.  This could brace users when they hear something that they don't 
>> want to hear.  "I can't show you the message."
>
> Good point. How about:
>

I think there is positive value in diversity of audit trail policy. If all 
DNSBLs have no audit trail, then spammer's can't listwash, but it is also 
true that operators of websites and MTAs with security problems will not 
receive useful information about what is going wrong, and this may 
delay corrections. If for instance, a webmaster is responsible for 
multiple web pages that generate email, and only one is defective, it 
helps to know which one.

If some DNSBLs have detailed audit information available that will help 
such sources, without giving spammer's the ability to listwash all 
spamtraps.

Since the best outcome is achived by a mix of policies, it hardly seems 
necessary to anoint one as "best".

Daniel Feenberg

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 13:38:15 -0800

On Feb 12, 2007, at 12:14 PM, Daniel Feenberg wrote:

>> information in the DNSBL administrator's possession relating to  
>> the  listing; e.g., a DNSBL administrator 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 the DNSBL's spam trap.
>
> I think there is positive value in diversity of audit trail policy.  
> If all DNSBLs have no audit trail, then spammer's can't listwash,  
> but it is also true that operators of websites and MTAs with  
> security problems will not receive useful information about what is  
> going wrong, and this may delay corrections. If for instance, a  
> webmaster is responsible for multiple web pages that generate  
> email, and only one is defective, it helps to know which one.
>
> If some DNSBLs have detailed audit information available that will  
> help such sources, without giving spammer's the ability to listwash  
> all spamtraps.
>
> Since the best outcome is achived by a mix of policies, it hardly  
> seems necessary to anoint one as "best".

I read "selectively accessible" as meaning both trap and content  
redaction.  This means clever spammers may not produce an audit trail  
visible to the public.  It might be good to mention this somewhere.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 14:28:20 -0800

On Feb 12, 2007, at 11:42 AM, Matt Sergeant wrote:

>> must be mentioned, why not say a year or less.  A year is likely  
>> to be a typical interval for service purchases.  Most spam sources  
>> are compromised systems.  Increasing the block cycle rate will  
>> just increase the number of times a compromised system can spew  
>> spam before being once again blocked.  When the owner of the IP  
>> address actually wants to send valid email, they can make a  
>> request to expedite a removal process in most cases.  What makes 6  
>> months sound reasonable????
>

A year is likely to be a typical interval for bulk service  
agreements.  Why not punish negligent network providers?  Why should  
providers be able to assume their negligence will be quickly expunged?

A period regarding IP address acquisition offers a valid basis for  
some conditioned maximal value.  What justification, beyond the  
SpamHaus policy, is available?

Why not seven years as used by Fair Credit Reporting Act?  Longer  
periods are more likely to ensure future abuse is prevented.  Credit  
agencies are not required to even generate reports in less than one  
year without compensation.  A provider's negligence then hurting next  
year's customer seems like a good incentive to ensure abuse is  
quickly stopped.  There are ample tools available to track abuse  
emerging from a network.  Affecting the bottom line offers powerful  
corrective incentives.  The AGIS address space has been impaired by  
the number of blocks made using BGP.  This is an example where some  
blocks will be very long, complete, and appropriately reflect prior  
negligence.

Why not hold the provider's accountable beyond a typical contract  
period?  Why suggest a BCP that takes the sting out of negligence?

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Mon, 12 Feb 2007 22:46:59 -0500

On 12-Feb-07, at 5:28 PM, Douglas Otis wrote:

> A year is likely to be a typical interval for bulk service agreements.

I'm not sure why you keep persisting on this point. If the criteria  
for the DNSBL is something like "a known spammer has service on this  
IP/range" then after (or before) the timeout period the DNSBL must re- 
check that the spammer still has service on that IP/range, and  
confirm that indeed the spammer does. Thus the listing is extended  
beyond the 6 month period. It could last forever for all we care, as  
long as the listing criteria STILL EXISTS.

I'll repeat myself again: this BCP in NO WAY forces delisting after  
the timeout period. It makes that clear - you just choose not to read  
that part for some reason.

I'm done arguing this with you now. We'll discuss between the authors  
if we think 6 months is the wrong time period but you haven't  
presented any decent argument for it IMHO.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Feb 2007 21:57:48 -0800

On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote:

>> agreements.
> for the DNSBL is something like "a known spammer has service on  
> this IP/range" then after (or before) the timeout period the DNSBL  
> must re-check that the spammer still has service on that IP/range,  
> and confirm that indeed the spammer does. Thus the listing is  
> extended beyond the 6 month period. It could last forever for all  
> we care, as long as the listing criteria STILL EXISTS.

There are at least two entities to be considered with respect to a  
reasonable listing duration.  One might be the individual entity  
administering the system directly associated with the IP address.   
Another would be the entity providing the IP address and routing from  
their ASN.  The duration of any listing must consider the behavior of  
_both_.  A high density of bad actors within an ASN SHOULD extend  
duration well into a year and be sure to cover a typical contract  
period.   The goal of the DNSBL operator is often to alter the  
behavior of the network provider.  In such cases it is pointless to  
focus upon individual IP addresses when the network provider is truly  
negligent.

> the timeout period. It makes that clear - you just choose not to  
> read that part for some reason.
>
> I'm done arguing this with you now. We'll discuss between the  
> authors if we think 6 months is the wrong time period but you  
> haven't presented any decent argument for it IMHO.

On the contrary.  You have not presented cogent arguments as to why 6  
months is a suitable listing duration, especially when a provider is  
negligent.  Individual treatment of IP addresses must be predicated  
upon the provider enforcing an AUP policy that precludes spamming.   
Any provider that offers unlimited services to spammers should never  
expect IP address delisting within an interval as short as 6 months.   
This is being far to generous.  In the case of individual IP  
addresses within a well managed ASN, a request can be made to  
expedite delistings.  Again, when the typical contract is by the  
year, automatic delisting within six months is still likely too soon.

While a six month duration might be selected as a means to reduce  
delisting requests, a poorly managed ASN should still delay a  
delisting over a much longer period.  Incidents of abuse can not  
always be considered by individual IP addresses, but in conjunction  
with the ASN as a whole.

Please don't say this should be based upon what _sounds_ reasonable.   
Perspectives differ between network and email providers, and those  
operating DNSBLs.  The goal of DNSBL operators is to reduce the tide  
of spam, which ironically is not always a shared motivation,  
especially when charges are by bits per second.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 13 Feb 2007 09:21:48 -0500

On 13-Feb-07, at 12:57 AM, Douglas Otis wrote:

> Another would be the entity providing the IP address and routing  
> from their ASN.  The duration of any listing must consider the  
> behavior of _both_.  A high density of bad actors within an ASN  
> SHOULD extend duration well into a year and be sure to cover a  
> typical contract period.   The goal of the DNSBL operator is often  
> to alter the behavior of the network provider.  In such cases it is  
> pointless to focus upon individual IP addresses when the network  
> provider is truly negligent.

Nothing in this draft prevents this.

> Individual treatment of IP addresses must be predicated upon the  
> provider enforcing an AUP policy that precludes spamming.  Any  
> provider that offers unlimited services to spammers should never  
> expect IP address delisting within an interval as short as 6  
> months.  This is being far to generous.  In the case of individual  
> IP addresses within a well managed ASN, a request can be made to  

Nothing in this draft prevents this.

> always be considered by individual IP addresses, but in conjunction  

Nothing in this draft prevents this.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Feb 2007 11:02:02 -0800

On Feb 13, 2007, at 6:21 AM, Matt Sergeant wrote:

>> to alter the behavior of the network provider.  In such cases it  
>> is pointless to focus upon individual IP addresses when the  
>> network provider is truly negligent.
>

,---
|For more aggressive spammers (e.g., those operating their
|own ISP) the temporary period MAY be as much as six (6) months.
|However, longer periods SHOULD NOT be used since it is possible
|that an IP address or domain can change hands, possibly being
|allocated to a non-abusive user.
'---

The foremost goal of a DNSBL is to prevent spam!  This is largely  
accomplished by changing the behavior of the _network_ providers  
(ISPs).  The typical maximal duration SHOULD bridge contracts and  
impact the _network_ provider's revenue.  This makes the the DNSBL  
effective at changing the behavior of the network provider.  Of  
course, cooperative providers deserve continuous evaluation, but is  
draft is written from an obtuse perspective of individual IP  
addresses and has ignored the role of the network providers.

What is the goal of the DNSBL?  There are at least two entities  
involved in sending spam, email and network providers.  DNSBL needs  
to ensure that preventing spam remains in everyone's mutual interest  
and is prohibited within the network provider's AUPs.  A short  
duration of 6 months is not likely to cover a typical contract _as  
stated in the draft_!  If anything, this alone justifies a longer  
maximal listing duration when the provider permits spam.

How about:

To affect network providers that permit spam as evidenced by a high  
percentage of spam sources within their ASN, the maximal listing  
duration SHOULD BE a period of one year or more.  This is to  
specifically affect their ability to profit from spam.  When the  
provider is otherwise effective at prohibiting spam, the maximal  
duration SHOULD BE less than an year, where a duration of six months  
is likely adequate.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 13 Feb 2007 14:39:54 -0500

> |allocated to a non-abusive user.

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

---

From: Matt Sergeant <[email-masked]>
Date: Tue, 13 Feb 2007 14:48:57 -0500

> |   still exists, then the timer for determining timeouts MAY be

Maybe I could put this better as: What is the purpose of stating that  
listings should time out?

The purpose is to ensure that DNSBL owners continue to check the  
reason for listing. Otherwise they aren't solving the spam problem,  
they are just listing because they're too lazy to check.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Feb 2007 14:57:10 -0800

On Feb 13, 2007, at 11:48 AM, Matt Sergeant wrote:

> Maybe I could put this better as: What is the purpose of stating  
> that listings should time out?
>

,---

Matt,

The percentage of abusive IP addresses within an ASN must determine  
the duration established in listing specific IP addresses within the  
ASN.  The goal is to stop the source of spam, which can only happen  
when network providers enforce AUPs prohibiting spam.  Some DNSBLs  
ignore listed sources over a period as necessitated by overall spam  
volumes.  Revisiting traffic sooner than an interval effective at  
stopping a network provider's behavior requires significant  
expenditures by DNSBL operators.  Audit trails and network bandwidth  
have a cost.

What justifies increasing the costs of DNSBLs to facilitate marketing  
of services by a spam friendly network provider, as this draft  
suggests?  Even credit agencies are not required to issue a report in  
less than a year without compensation.  Why ensure a spam friendly  
provider's next customer is not affected by the provider's  
negligence?  How will this reduce the level of spam?

This draft's recommended practice allows providers to ignore spam, as  
it ignores the role a network provider must play in stopping spam.

-Doug

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 14 Feb 2007 11:46:56 +0100

I think that this I-D would benefit from additional paragraphs of 'stating the
obvious'.

Specifically, you assume a detailed knowedge of what a DNSBL is and make
reference to various fields therein; I think you should summarise in two or
three sentences what DNS records there are likely to be containing what data.

Second, perhaps before that, you should explain who uses a DNSBL and how, even
though, or perhaps because, such people are not the target audience - currently
you only mention the why; again one paragraph of two or three sentences.

Finally, you assume a detailed knowledge of (r)DNS and zones - again, I think
that you should explain more and include a normative reference to the relevant
RFC.

I think too that most of your existing references are normative, ie something
that must be understood if the I-D is to make any sense.

Tom Petch

---

From: Bill Cole <[email-masked]>
Date: Wed, 14 Feb 2007 09:02:24 -0500

At 9:57 PM -0800 2/12/07, Douglas Otis wrote:
>On the contrary.  You have not presented cogent arguments as to why 
>6 months is a suitable listing duration, especially when a provider 
>is negligent.

Because the BCP does not say that and you are inventing that concept 
by not reading carefully enough.

If the listing criteria remains true, the entire paragraph talking 
about 6 months is completely irrelevant.

>provider enforcing an AUP policy that precludes spamming.

Says who?

That appears to be fodder for listing policy of a specific DNSBL, not 
for an operational BCP document.

There are DNSBL's that are insensitive to ISP policy or its 
enforcement. The CBL is an example, and it is arguably the most 
useful primary DNSBL in operation, with only the aggregates that 
include it being more comprehensive.

>year, automatic delisting within six months is still likely too soon.

This would only make sense if you believed the BCP prohibits listing 
standards that look at ASN-level behavior as a contributing factor to 
a listing. I don't think it does.

For example, one could operate a DNSBL where a listing is documented 
to mean "This address space has a history of being assigned by its 
RIR-registered owner to people with 4-letter surnames."  When that 
DNSBL listed the space I use, and I found it untenable to remain in 
the space because of the geniuses who think all DNSBL's mean the same 
thing, the 6-month clock would not start. What would start the 
6-month clock would be AT&T  going bankrupt and returning the block 
to ARIN.

>always be considered by individual IP addresses, but in conjunction 

There's nothing in the BCP that requires listing standards to ignore 
ASN behavior, or to include ASN behavior. That is a detail that is 
out of scope for the BCP, but including ASN behavior as a factor in a 
particular list (e.g. something like SPEWS but run competently and 
rigorously to documented testable standards)

>of spam,

Not always. Historically the goals have seemed to include defaming 
creditors, making political statements about the ethics of various 
network operators, and demonstrating the clue deficiencies of the 
mail technical community.

In that last class of DNSBL, the target members have been people who 
think all DNSBL's are about the same things.

-- 
Bill Cole                                  
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 10:49:06 -0800

On Feb 14, 2007, at 6:02 AM, Bill Cole wrote:

>> On the contrary.  You have not presented cogent arguments as to  
>> why 6 months is a suitable listing duration, especially when a  
>> provider is negligent.
>
> Because the BCP does not say that and you are inventing that  
> concept by not reading carefully enough.
>

Listing policies regarding duration must consider behaviors of  
specific IP addresses and that of that of the network provider  
associated with the ASN.
,---
|For more aggressive spammers (e.g., those operating their
|own ISP) the temporary period MAY be as much as six (6) months.
|However, longer periods SHOULD NOT be used since it is possible
|that an IP address or domain can change hands, possibly being
|allocated to a non-abusive user.
'---

This statement ignores network provider's role, and rewards bad  
behavior by ensuring their ability to market IP addresses within  
their poorly managed ASN.  The goal is not about making DNSBLs  
essential by coddling spam-friendly providers, as this statement  
recommends.  The goal of the DNSBL is to convince network providers  
it is in their interest to enforce AUPs that prohibit spamming.  I  
hope you agree.

> That appears to be fodder for listing policy of a specific DNSBL,  
> not for an operational BCP document.

This draft states that bad behavior of the network provider SHOULD be  
accommodated by ensuring their ability to market their IP address  
space.  Best Current Practices of a DNSBL is to convince network  
providers they SHOULD enforce AUPs prohibiting spamming.  As such,  
the BCP must consider the level of abuse from the ASN of the network  
provider as a significant factor in establishing the duration of a  
block listing.  The current draft insists on the opposite, and this  
can NEVER be considered a BCP!

> include it being more comprehensive.

The CBL of abuseat.org is an automated listing that specifically  
excludes intended SMTP clients.  The goal of the CBL is to prevent  
proxy and infected related abuse.  You are not saying that Spam is  
okay as long as it is intended, or that this represents a best practice?

>> Any provider that offers unlimited services to spammers should  
>> never expect IP address delisting within an interval as short as 6  
>> months.
> This would only make sense if you believed the BCP prohibits  
> listing standards that look at ASN-level behavior as a contributing  
> factor to a listing. I don't think it does.

Carefully read the last sentence of the quoted text.   Limiting the  
duration of a listing to 6 months is specifically to ensure the  
network provider's ability to market address space.  When network  
providers are spam-friendly, the duration of the listing SHOULD  
extend beyond the typical service contract.  Don't think of DNSBLs as  
only stopping abuse after it arrives.  Well managed DNSBLs prevent  
spam from ever being sent, and stopping spam at the source represents  
a Best Best Practice.

> For example, one could operate a DNSBL where a listing is  
> documented to mean "This address space has a history of being  
> assigned by its RIR-registered owner to people with 4-letter  
> surnames."  When that DNSBL listed the space I use, and I found it  
> untenable to remain in the space because of the geniuses who think  
> all DNSBL's mean the same thing, the 6-month clock would not start.  
> What would start the 6-month clock would be AT&T  going bankrupt  
> and returning the block to ARIN.

This is irrelevant.  Again, there are two actors benefiting from  
spam.  One actor might be the network provider selling an IP address  
and network bandwidth.  There is also the bad actor that might  
briefly be able to send spam from a network provider that enforces an  
AUP prohibiting spam.  Whether a block duration should extend beyond  
the typical contract duration should depend upon whether there is a  
substantial amount of spam abuse emerging from the ASN.  Resources  
are required to track abuse.  These resources should be reserved for  
those network providers attempting to enforce an AUP prohibiting spam.

>> always be considered by individual IP addresses, but in  
>> conjunction with the ASN as a whole.
>
> There's nothing in the BCP that requires listing standards to  
> ignore ASN behavior, or to include ASN behavior. That is a detail  
> that is out of scope for the BCP, but including ASN behavior as a  
> factor in a particular list (e.g. something like SPEWS but run  
> competently and rigorously to documented testable standards)

DNSBL best practices should consider ASN behavior when establishing a  
listing duration.  ASN behavior must not be out of scope in any DNSBL  
best practices draft.  SPEWS considers the behavior of the network  
provider, and recognized the futility of attempting to play wack-a- 
mole with IP addresses alone.  Network providers must enforce AUPs  
that prohibit spamming, if spam is to be abated.  Considering ASN  
behavior is clearly a best practice.

>> Please don't say this should be based upon what _sounds_  
>> reasonable.  Perspectives differ between network and email  
>> providers, and those operating DNSBLs.  The goal of DNSBL  
>> operators is to reduce the tide of spam,
>
> In that last class of DNSBL, the target members have been people  
> who think all DNSBL's are about the same things.

The best practices for the operation of a DNSBL is to be effective at  
abating spam from being sent in the first place.  Spam is a vector  
for infection either directly or indirectly by offering dangerous  
links.  Spam can lead to DDoS attacks (especially with SPF/Sender-ID  
being used by the recipients).  At more than 80% of the current email  
traffic, spam has dramatically placed the resource burden onto the  
recipient.  The industry and the Internet internationally must  
prohibit spamming.  The CAN-SPAM law must be changed to prohibit  
spamming.  The best practices of a DNSBL should be aimed specifically  
at convincing network provider to enforce AUPs that prohibit  
spamming, which is a tool still allowed by CAN-SPAM.

Blocking durations should not be based on personal grudges, dislikes,  
or politics.  Policies should be consistently applied, not by  
treating each IP address individually, but in conjunction with the  
ASN as a whole.  Any DNSBL policy worth its salt must consider how to  
persuade the cooperation of network providers.  Such persuasion can  
only occur when ASNs as a whole plays a role in DNSBL policies.

-Doug

---

From: Bill Cole <[email-masked]>
Date: Wed, 14 Feb 2007 14:27:23 -0500

At 10:49 AM -0800 2/14/07, Douglas Otis wrote:
>their poorly managed ASN.

As Matt and I have already pointed out, you are ignoring what the 
draft actually says in favor of believing that it says something you 
feel like arguing with. Feel free to do so wherever you like. I won't 
bother you with responses you refuse to even read.

-- 
Bill Cole                                  
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 11:59:18 -0800

On Feb 14, 2007, at 11:27 AM, Bill Cole wrote:

> draft actually says in favor of believing that it says something  
> you feel like arguing with. Feel free to do so wherever you like. I  
> won't bother you with responses you refuse to even read.

No where within this entire draft is the role of the network provider  
mentioned or properly considered.  This represents a _major_  
shortcoming in a draft purporting to provide advice to DNSBL  
operators!  The note Matt referenced pertains to condition continuing  
with respect to a _specific_ IP address.  This ignores the role of  
the network provider.  While listings are indeed of individual IP  
addresses, policy should not be limited to individual IP addresses.   
The entire ASN _must_ be considered.

Do you understand what is meant by ASN?

Do you agree network providers plays a significant role in abating spam?

It is completely absurd to recommend spam-friendly ISPs have their IP  
addresses delisted promptly.  What incentive is there for spam- 
friendly ISPs to change their behavior?  Shouldn't this aspect of  
policy be considered in any DNSBL best practices?

-Doug

---

From: "Peter Bowyer" <[email-masked]>
Date: Wed, 14 Feb 2007 20:13:07 +0000

On 14/02/07, Douglas Otis <[email-masked]> wrote:
> operators!

That's presumably because the draft addresses the operational
processes of a DNSBL, not its policies. Your points are advice on
policy - which, however sensible, are not within the scope of the
draft as currently written.

> The note Matt referenced pertains to condition continuing

If that's part of the published policy of the DNSBL, and hence the
users of the DNSBL are expecting it, then certainly. But again, this
is policy, not process.

> Do you understand what is meant by ASN?

A little disingenuous, perhaps?

> Do you agree network providers plays a significant role in abating spam?

Not relevant within the scope of the draft.

> addresses delisted promptly.

The recommendation is that DNSBL operators have a refresh cycle, where
they delist IPs that no longer meet their published criteria. If the
operator has a policy of persistent listing as you suggest they
should, then the refresh cycle will not result in de-listing because
the criteria still apply. No problem there?

> What incentive is there for spam-

No, because it's not part of operational best practice, it's part of
the operator's policy-making process - which is subjective,
politically-charged, and doesn't belong in the BCP.

Peter

-- 
Peter Bowyer
Email: [email-masked]

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 15:18:13 -0500

On 14-Feb-07, at 2:59 PM, Douglas Otis wrote:

> No where within this entire draft is the role of the network  
> provider mentioned or properly considered.

Correct. That's as it should be. The creator of a DNSBL decides its  
listing criteria. The draft does not hope to mandate on listing  
criteria, and nor should it.

> The note Matt referenced pertains to condition continuing with  
> respect to a _specific_ IP address.

It seems to say "listing", not "IP address". I think you need reading  
glasses :~)

Matt.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 14:06:38 -0800

Matt,

This draft however recommends a delisting policy (interval) that  
_specifically_ ignores the behavior of the ISP.

> It seems to say "listing", not "IP address". I think you need  
> reading glasses :~)
>

A DNSBL listing is by IP address.  This uses references similar to a  
reverse IP address lookup for PTR records.  Surely you know that.

I have not suggested that IP addresses be grouped by ASN, only that  
DNSBL delisting intervals be structured to induce the cooperation of  
network providers.  Longer listings also reduce DNSBL resource  
expenditures, which is appropriate when the next network provider's  
customer, if there is one, is also likely to spam.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 14:30:12 -0800

On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote:

>> provider mentioned or properly considered.  This represents a  
>> _major_ shortcoming in a draft purporting to provide advice to  
>> DNSBL operators!
>

A delisting interval is strictly related to DNSBL policy.  The draft  
is not describing how to delist, but specifically when.  This is  
about policy.  Nothing but policy.

>> The note Matt referenced pertains to conditions continuing with  
>> respect to a _specific_ IP address.  This ignores the role of the  
>> network provider.  While listings are indeed of individual IP  
>> addresses, policy should not be limited to individual IP  
>> addresses. The entire ASN _must_ be considered.
>
> users of the DNSBL are expecting it, then certainly. But again,  
> this is policy, not process.

A delisting interval is purely about policy, especially when it  
specifically seeks to ignore the behavior of network providers.   
Short listing intervals for spam friendly network providers (as noted  
by the ASN as a whole) is recommending a bad practice.  Don't be  
pedantic about IP addresses only to ignore the role of the network  
provider.

> A little disingenuous, perhaps?

Don't you think this definition belongs in a BCP related to DNSBLs?

> Not relevant within the scope of the draft.

Network providers and their behavior are not relevant to a DNSBL  
operator?

If this draft is attempting to mandate that the role played by  
network providers are to be ignored, then yes.  If this draft is  
attempting to define best practices aimed at abating spam, then  
absolutely not.  Network provider's roles are significant.

>> It is completely absurd to recommend spam-friendly ISPs have their  
>> IP addresses delisted promptly.
>
> The recommendation is that DNSBL operators have a refresh cycle,  
> where they delist IPs that no longer meet their published criteria.  
> If the operator has a policy of persistent listing as you suggest  
> they should, then the refresh cycle will not result in de-listing  
> because the criteria still apply. No problem there?

Who said anything about a persistent listing?  This is about an  
automatic delisting interval policy to favor those network providers  
that enforce an AUP that prohibits spamming.  A automatic delisiting  
that extends beyond their typical contract period can act as an  
incentive for the network provider to change their policy.

>> What incentive is there for spam-friendly ISPs to change their  
>> behavior?  Shouldn't this aspect of policy be considered in any  
>> DNSBL best practices?
>
> No, because it's not part of operational best practice, it's part  
> of the operator's policy-making process - which is subjective,  

Then remove the nonsense about when to delist, and then don't fail to  
mention the role ASN plays with respect to the _operation_ of a DNSBL.

-Doug

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 17:32:50 -0500

On 14-Feb-07, at 5:30 PM, Douglas Otis wrote:

> A delisting interval is strictly related to DNSBL policy.  The  
> draft is not describing how to delist, but specifically when.  This  
> is about policy.  Nothing but policy.

Lets be more specific then: Your posts are all about listing  
criteria. This draft does not (and never will with me as an author)  
mandate listing criteria. That way lies madness.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 17:36:53 -0500

> _specifically_ ignores the behavior of the ISP.

You are the only person who thinks that. Everyone else can see that's  
not the case.

> A DNSBL listing is by IP address.  This uses references similar to  
> a reverse IP address lookup for PTR records.  Surely you know that.

We use the term "listing" in the draft to indicate a particular  
listing for a particular criteria. If the criteria causes the DNSBL  
to list a particular ASN for bad behaviour then the listing would  
consist of the range(s) belonging to that ASN.

> DNSBL delisting intervals be structured to induce the cooperation  
> of network providers.

That's a policy decision that the DNSBL can make. Nothing in this  
draft prevents that.

> Longer listings also reduce DNSBL resource expenditures, which is  
> appropriate when the next network provider's customer, if there is  
> one, is also likely to spam.

Sure. So there are two scenarios here to look at:

1) The listing is for the spammer. As long as he's spamming the  
listing remains. When he stops spamming we suggest that the maximum  
remaining time his IPs be listed is 6 months. Anything else is unfair  
to innocent parties who end up on a spammer's old IPs.

2) The listing is for the ASN/ISP for providing service to spammers.  
If the ISP stops signing up spammers then the listing will time out 6  
months after the ISP stops signing up spammers. If they clean up  
their act we see no reason they should continue to be blocked.

Whether the listing is for the spammer's individual IPs or for the  
ASN as a whole is, and should be, ENTIRELY up to the owner of the  
DNSBL. In no way do I advocate this BCP telling people what criteria  
they SHOULD use for their DNSBL, that way lies madness.

---

From: "Peter Bowyer" <[email-masked]>
Date: Wed, 14 Feb 2007 22:52:31 +0000

> mandate listing criteria. That way lies madness.

Absolutely. Diversity of policy amongst DNSBLs is good. Mandating
process in order to make a given DNSBL's policy transparent and
demonstrably adhered to is good. Mandating the policy is bad.

Peter

-- 
Peter Bowyer
Email: [email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 15:44:13 -0800

On Feb 14, 2007, at 2:36 PM, Matt Sergeant wrote:

> You are the only person who thinks that. Everyone else can see  
> that's not the case.

,---
| For more aggressive spammers (e.g., those operating their
| own ISP) the temporary period MAY be as much as six (6) months.
| However, longer periods SHOULD NOT be used since it is possible
| that an IP address or domain can change hands, possibly being
| allocated to a non-abusive user.
'---

Restated:

"Aggressive spammers operating their own ISP SHOULD NOT be blocked  
longer than 6 months following cessation of abuse, because the IP  
address might be subsequently allocated to a non-abusive user."

When an ASN contains a high percentage of spammers, the likelihood  
that the next user (customer) is also a spammer is more likely than  
not.  Policies and histories should not be limit to specific IP  
addresses, but measured by ASNs as well.  The ASN measurement should  
be a factor in determining the duration before delisting, and not  
solely that of the IP address alone.

> consist of the range(s) belonging to that ASN.

At times, a complete ASN might be listed.  However, this does not  
change the erroneous statement made regarding a _policy_ of when to  
delist.

>> I have not suggested that IP addresses be grouped by ASN, only  
>> that DNSBL delisting intervals be structured to induce the  
>> cooperation of network providers.
>

"However, longer periods [more than 6 months] SHOULD NOT be used  
since it is possible that an IP address or domain can change hands,  
possibly being allocated to a non-abusive user."  Damn, if that is  
not stipulating a listing policy that ignores the behavior of the  
network provider.

How about this for replacing the two offensive sentences:
,'''
: Blocked IP addresses should be reassessed on some regular basis.
: The rate and criteria used to reassess a blocked IP address
: should consider the number of sources within the ASN, as well as
: the abuse cessation interval from the specific IP address.  In
: some cases, no assessment over an interval may be used to reduce
: an expenditure of resources.  For ASNs where there is not a
: prevalence of IP addresses issuing spam, an automatic delisting
: interval should be adjusted to avoid unnecessary delisting requests.
'...

This would avoid a BCP paper that stipulates policy.

> remaining time his IPs be listed is 6 months. Anything else is  
> unfair to innocent parties who end up on a spammer's old IPs.

Almost.  Looking a the density of abuse within an ASN provides a good  
indication as to whether their next customer will also be a spammer.   
The idea is to make spam friendly ISPs look less attractive to  
spammers.  This is not about treating all of their customers as if  
they are spammers, only that the delisting interval should carefully  
consider measurements of the ASN when determining their automatic  
delisting interval.

> 2) The listing is for the ASN/ISP for providing service to  
> spammers. If the ISP stops signing up spammers then the listing  
> will time out 6 months after the ISP stops signing up spammers. If  
> they clean up their act we see no reason they should continue to be  
> blocked.

Only in the most extreme cases would ASN listing be reasonable.  BCP  
for DNSBLs should elucidate the role ASNs might play.  ASNs are  
extremely important when the DNSBL is noting ISP policy, for example.

> DNSBL. In no way do I advocate this BCP telling people what  
> criteria they SHOULD use for their DNSBL, that way lies madness.

Please understand that saying when to delist is really the same as  
saying when to list.   If you want to avoid saying when to list, then  
by all means avoid saying when to delist.  That aside, there should  
also be a section that describes the role of the ASN.

-Doug

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 14 Feb 2007 18:46:44 -0500 (EST)

> mandate listing criteria. That way lies madness.

Consider dsnbl.noprimes.org.

How often do you think it's reasonable to require me to check whether
a given number has turned composite while I wasn't looking?

Seth

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 18:55:50 -0500

> a given number has turned composite while I wasn't looking?

Quoting the BCP:

    not change...

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 14 Feb 2007 19:06:47 -0500 (EST)

>    With the exception of DNSBLs that that are based on data that does

On the other hand, "I have received spam from <ip>" is data that does
not change (once true).

Seth

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 20:16:29 -0500

> On the other hand, "I have received spam from <ip>" is data that does

I'm not sure whether you're just trying to be contrary of if you have  
a real point. If the latter please state it more clearly.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 14 Feb 2007 20:33:36 -0500

> a given number has turned composite while I wasn't looking?

With today's processors, it should be easy to go thru 2^^32 numbers in
six months.  But I think you'd be forgiven in assuming that the
prime/nonprimeship of a number won't change spontaneously.

Or, are you expecting some to do so? ;-)

DNSBLs aren't punishment methods.  First and foremost they're methods on
blocking abuse.  If a bad actor isn't acting bad enough to be obvious
that they're abusing for a period of six months, the loss of a listing
means nothing in the scheme of things, and soon corrected if it turns
out to be wrong/being gamed.

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 14 Feb 2007 20:35:42 -0500

> On the other hand, "I have received spam from <ip>" is data that does

Then a 6 month timeout wouldn't apply, would it?

Entirely aside from the fact that a DNSBL listing on that basis would,
in the fullness of time, list just about every IP in existance.

Everybody leaks.

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 14 Feb 2007 20:42:35 -0500 (EST)

> a real point. If the latter please state it more clearly.

"Facts that don't change" isn't quite what I'd want to say; true facts
can become irrelevant or outdated (that is, useless) while remaining
true.

Seth

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 14 Feb 2007 21:13:32 -0500

> can become irrelevant or outdated (that is, useless) while remaining

True enough. That portion of the BCP is aimed at DNSBLs such as  
blackholes.us and Steve Champion's Enemies List, which are basically  
targeted at static data. Though to be honest after having the  
discussion here I'm not sure that even matters much - because the  
listing criteria just continues to exist for those DNSBLs.

If you have better wording we'd appreciate assistance.

Matt.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Feb 2007 23:15:22 -0800

> out to be wrong/being gamed.

DNSBLs are to block messages, which in itself might be considered a form
of punishment.  There is a cost that is not being considered in the
draft.

Maintaining records of spam received, as recommended, represents a
sizable expense.  When a particular ASN does not enforce AUPs that
prohibit spamming, then ignoring traffic from their listed IP addresses
for some extended period offers significant savings in storage, servers,
and network bandwidth.  The difference is significant.

When the ASN is large and offers bandwidth without enforcement, each
delisting has the effect of making their service more attractive to
spammers, even if only for a brief period.  Changing accounts is the
spammers' cost of doing business.  When an ASN lacks self enforcement
and hosts a high density of spammers, a best practice should be to pause
the logging of abuse for some period, and delay the individual IP
address' delisting.  Concerns about the next user of ASNs that lack
enforcement rightfully diminishes.  There is a good chance the next user
will also be a spammer anyway.

A recommendation for maximal delisting interval of 6 months for ASNs
that make an effort to enforce anti-spam AUPs is not a problem for DNSBL
operations.  However, the current draft wishes to ignore spam-friendly
behavior of some ASNs, and that would constitute a bad practice from the
perspective of economically running DNSBLs, as well as ensuring DNSBLs
remain effective at abating spam.

The network provider plays a critical role in abating spam.  When the
network provider is not a partner in abatement, it is unfair and costly
to allow those without enforcement to consume additional resources in
order to maintain a constant automatic delisting interval.  ASNs that
enforce anti-spam AUPs deserve these limited resources.  A best practice
MUST consider the behavior of the network provider as denoted by the
ASN.  This should be part of any DNSBL best practice.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Feb 2007 07:41:03 -0800

> long as the listing criteria STILL EXISTS.

The network provider owns the IP address.  They own an entire range of
IP addresses as determined by their ASN.  The entity that is spamming is
often NOT the network provider, but instead is one of their customers.
Only in very rare cases would a listing be based upon the ASN.  Listing
criteria often requires monitoring for spam from a specific IP address.
Monitoring for spam has a cost.

> that part for some reason.

The suggested text requires that these IP addresses be monitored in
order to delist within the interval being recommended, unless of course
the entire ASN is being listed, which is rare.

> presented any decent argument for it IMHO.

The premise that 6 months is okay seems based upon Spamhaus suggesting
that this their policy.  There are a few differences with respect to
what Spamhaus can do and what an enterprise working with United States
can do.  England, where Spamhaus resides makes spamming illegal.  There
is also a substantially different liability with respect legal fees when
being sued in the United States versus England as well.

Every listing by a company that has residence within the United States
must be prepared with a full set of records tracking everything related
to the ASN, the IP address, complaints, replies, etc. This tracking
system is likely to be much larger and far more expensive as a result.
I wish the spam laws for the United States were more like that found in
England.  They are not however.  Please don't suggest that this draft is
NOT dictating a listing policy and then recommend when an IP address
should be delisted!

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 15 Feb 2007 13:16:38 -0600

Hello all,

I'm new to the list. A lot of familiar names here. If you don't know
me, I've created a few different DNSBLs, mostly back they were
lovingly crafted out of shell scripts using stone knives and
bearskins. Lately I've started cataloging dead DNSBLs and writing up
DNSBL reviews on www.dnsbl.com, a site of mine.

Forgive me if I'm rehashing something already talked about; didn't
seem that way to me from my cursory research.

One thing that strikes me as missing from the BCP is some guidance on
usage and implementation in spam filtering and blocking applications.
In particular, technical guidance regarding whether or not a DNSBL
actually exists and can be queried. As I am learning from diving back
in to the thick of DNSBL-related things lately, I see
- Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com
years after the RBL moved away from that FQDN.
- Other lists randomly vanishing with no warning and continuing to get
DNSBL traffic for years
- Blars, for example, vanished in December and now lists the world.
- LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting
hits years later, resorting to listing the world.
- The occasional ignorant sod who queries something like
random.dnsbl.maps.com which causes unwanted traffic (and potential
unwanted mail blocking) from various sites. (You'll note that maps.com
has a wildcard, for example.)

Maybe this is outside of the scope, and if so, I apologize. But if
appropriate, it seems wise to have some guidance included about how to
avoid these situations, preferably recommended that checks be
implemented in software to confirm that a list an application is
checking actually exists and really is a DNSBL. It not only protects
ignorant DNSBL users from themselves (which I grant some folks
probably don't care much about), but it helps reduce pain for anyone
who gracefully shuts down a DNSBL (and their upstream, and the root
zones, depending on how it's done).

In the future, I'd love to be able to point to something RFC-like that
says what best practice is in this area, and be able to point that out
to companies who try to build a marketing strategy around selling
fancy rackmount anti-spam devices that are actually just linux boxes
with SpamAssassin and DNSBL support on them.

Would love to hear your thoughts and feedback.

Regards,
Al Iverson
-- 
Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com
Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission
is granted only to this lists's owners to redistribute to their sub-
scribers and to archive this message on site(s) under their control.

---

From: Stephanie Erin Daugherty <[email-masked]>
Date: Thu, 15 Feb 2007 15:07:46 -0500

> DNSBL reviews on www.dnsbl.com, a site of mine.
Good to see that you are still around. :) I think I remember at least a 
couple of
those stone knife and bearskin lists.

> has a wildcard, for example.)
One of the best pieces of advice I can give for this is to put a DNSBL 
on a domain specifically registered for the purpose -- while it's 
possible to run one within a subdomain, I would recommend strongly 
against it, getting rid of the query traffic if you later shut down is 
truly next to impossible, and if you have a dedicated domain, it's 
easier to kill the nameservers for it that it would for a domain that 
has to remain active even after the DNSBL dies. In other words, a DNSBL 
on a domain pretty much poisons it for years to come with substantial 
volumes of traffic.

Needless to say, this also places a special responsibility on DNSBL 
operators for making sure that their domain registrations stay active 
and secure - if allowed to expire prematurely, the impact to downstream 
users can be significant, and if allowed to be hijacked malicious 
entries could be placed which may result in a denial of service to 
legitimate users.

> checking actually exists and really is a DNSBL.
A standard "listed" test entry and standard "not listed" test entry are 
a good way to test that. Standard practice right now usually uses  
2.0.0.127.dnsbl.example.com or some variant as the "always listed" 
address - adding a requirement for a "never listed" address would be a 
good way to implement an additional check to make sure the DNSBL is 
still active, and hopefully that it's not listing the world. I'm not 
sure that we have a standard convention for a "never listed" test 
address (one that should always return a whitelist record or NXDOMAIN 
depending on the type of list.)

---

From: Steve Atkins <[email-masked]>
Date: Thu, 15 Feb 2007 12:40:22 -0800

On Feb 15, 2007, at 12:07 PM, Stephanie Erin Daugherty wrote:

>
> A standard "listed" test entry and standard "not listed" test entry  
> are a good way to test that. Standard practice right now usually  
> uses  2.0.0.127.dnsbl.example.com or some variant as the "always  
> listed" address - adding a requirement for a "never listed" address  
> would be a good way to implement an additional check to make sure  
> the DNSBL is still active, and hopefully that it's not listing the  
> world. I'm not sure that we have a standard convention for a "never  
> listed" test address (one that should always return a whitelist  
> record or NXDOMAIN depending on the type of list.)

1.0.0.127.

There. We have an always listed and a never listed address that are  
already done by the vast majority of blacklists[1]. All we need is  
client side support for those two checks and we're done.

Cheers,
   Steve

[1] OK, I run two blacklists and neither of them supports both of  
those records, but they're kinda special cases...

---

From: "Al Iverson" <[email-masked]>
Date: Thu, 15 Feb 2007 16:27:52 -0600

On 2/15/07, Stephanie Erin Daugherty <[email-masked]> wrote:

> has to remain active even after the DNSBL dies.

I agree that it is probably unwise to use a DNSBL domain for anything
else, or to expect to be able to reclaim it when done with the DNSBL.

The recent shutdown of ORDB makes me suspect that abandoning the
domain after you're done with the DNSBL might not be good enough.
Here's why.

If I'm recalling this correctly, what happened was that ORDB killed
the DNSBL and left the domain configured with no nameservers in place.
This left the queries to die at the .org root level, and it basically
pounded the .org infrastructure flat. One of the folks in charge of
.org reached out to an anti-spam community and was able to reach back
to the blacklist maintainers and some other folks, to come up with a
plan to solve it. But, things definitely sucked for a few days, and
not every situation like this is so quickly resolved. And I assume the
fix simply siphons the traffic off to somebody else's network, instead
of actually stopping it.

So, leaving the domain behind definitely helps the network that
previously hosted the DNSBL, but it could potentially just push gobs
of queries upstairs.

(Some of this detail came from a discussion on a private mailing list;
I got permission from the person behind that discussion to reference
it here. I woudl also add that this isn't a shot at the ORDB folks;
more than anything it just highlights that there isn't a BCP to handle
these kind of things.)

Regards,
Al Iverson

---

From: Matt Sergeant <[email-masked]>
Date: Fri, 16 Feb 2007 10:21:56 -0500

On 15-Feb-07, at 3:40 PM, Steve Atkins wrote:

>> A standard "listed" test entry and standard "not listed" test  
>> entry are a good way to test that. Standard practice right now  
>> usually uses  2.0.0.127.dnsbl.example.com or some variant as the  
>> "always listed" address - adding a requirement for a "never  
>> listed" address would be a good way to implement an additional  
>> check to make sure the DNSBL is still active, and hopefully that  
>> it's not listing the world. I'm not sure that we have a standard  
>> convention for a "never listed" test address (one that should  
>> always return a whitelist record or NXDOMAIN depending on the type  
>> of list.)
>
> 1.0.0.127.
>

Yup, this was suggested earlier in this thread (before it diverged  
into the timeout thread) and I think it's a worthwhile addition to  
the DNSBL.

---

From: SM <[email-masked]>
Date: Tue, 20 Feb 2007 16:11:36 -0800

>    1.  What is the intended use of the list?

DNSBLs don't always specify SMTP blocking as the intended use.  Maybe 
this should be "What is the listing policy?"

>    7.  What are the demographics and quantity of the list's user base?

Such information is rarely published.  Point 8 is a better guideline.

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

Shouldn't this be a MUST so that the user has better guidance in 
choosing a DNSBL?

>    available even if the DNSBL zone file is not available. See also

If a DNSBL ceases operations, the domain registration may lapse or 
else the web server is unreachable.  The above requirement is 
generally not followed.

>    set at the maximum allowed period of one week.

Using a broadcast address may have unintended consequences.  I 
suggest using 192.0.2.2.

Some DNSBL operators list the entire Internet because they keep 
receiving queries years after the DNSBL has ceased operation.  It may 
be better to include a note for people implementing DNSBL features in 
their software to prevent such behavior.  They could use a test point 
to determine whether the DNSBL is still active.  This is the best way 
to avoid excessive DNS queries.

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Tue, 20 Feb 2007 20:12:38 -0500

> Such information is rarely published.  Point 8 is a better guideline.

I think the intent here is not that the DNSBL publishes it (they often
don't know), but the user should consider this - eg: do other site like
me use it?

> Shouldn't this be a MUST so that the user has better guidance in

This is compromise wording.  Some DNSBLs can't publish full criteria,
because that would allow spammers to avoid it.  Rather than get into
quibbles over what constitutes "criteria", soften it a bit to SHOULD.

> Using a broadcast address may have unintended consequences.  I suggest
> using 192.0.2.2.

Which would have lower risk?  Somewhere in upper 127, or 192.0?
> receiving queries years after the DNSBL has ceased operation.  It may be
> better to include a note for people implementing DNSBL features in their
> software to prevent such behavior.  They could use a test point to
> determine whether the DNSBL is still active.  This is the best way to
> avoid excessive DNS queries.

Part of the issue about this is John's DNSBL protocol BCP.  We perhaps
shouldn't get too far into detail of this, unless we subsume John's.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 20 Feb 2007 17:31:11 -0800

On Feb 20, 2007, at 5:12 PM, Chris Lewis wrote:

>> suggest

The values used in the example given in nanog:

Used the address space defined in rfc3330
	 192.0.2.0/24         Test-Net

While it would be nice to establish a test method, the test should be  
both the return of an RR and that of an NXDOMAIN just incase the  
network provider decides to intercept NXDOMAINs.  Depending upon test  
vectors being installed in the various MTAs at this point is likely  
too late.  The example using several NS records should generate  
enough pain to induce removal of the defunct DNSBL.

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 20 Feb 2007 21:45:54 -0600

> don't know), but the user should consider this - eg: do other site like

In your opinion, how is that easily determinable?

Al

---

From: SM <[email-masked]>
Date: Wed, 21 Feb 2007 10:51:56 -0800

>don't know), but the user should consider this - eg: do other site like

Generally DNSBL operators don't publish such information.  The 
information is also not published in comparative evaluations.  Your 
question "Do other sites like me use it?" is more to the point.  The 
Guidance for DNSBL users questions are straight-forward except for question 7.

>Which would have lower risk?  Somewhere in upper 127, or 192.0?

The 192.0.2.0/24 block is assigned as "TEST-NET".  It should not 
appear on the public Internet (RFC 3330).  Pointing the DNS NS record 
to 192.0.2.2 will cause a query timeout.  The DNSBL user may notice 
the slow down in mail delivery and take appropriate action.  The 
purpose is not to cause any harm.  In my opinion, 192.0.2 should have 
a lower risk than the upper 127 as it is not associated with the 
loopback address.  I suggested 192.0.2.2/32 as it makes troubleshooting easier.

Thank you for the clarifications.

Regards,
-sm

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 21 Feb 2007 16:31:40 -0500

SM wrote:
> Generally DNSBL operators don't publish such information.

In addition to not really knowing, most DNSBLs will be reluctant to
publish the info even if they knew it.  While (the better) DNSBLs would
probably like to, parading the security measures of other sites is, er,
"poor form".

> The
> information is also not published in comparative evaluations.

I've seen it, but not published.

> Your

Nick - I think i like this suggestion...

For Al: how would the prospective user know?  Google works ;-)

> The 192.0.2.0/24 block is assigned as "TEST-NET".  It should not appear
> on the public Internet (RFC 3330).

But it may occur locally.  Wouldn't want your DNSBL queries to go off to
a test DNS server.  Tho, perhaps it's unlikely to result in a listing...

> Pointing the DNS NS record to
> 192.0.2.2 will cause a query timeout.

Most 127s would as well, would they not?

> The DNSBL user may notice the
> slow down in mail delivery and take appropriate action.  The purpose is
> not to cause any harm.  In my opinion, 192.0.2 should have a lower risk
> than the upper 127 as it is not associated with the loopback address.  I
> suggested 192.0.2.2/32 as it makes troubleshooting easier.

Thanks for the discussion.

---

From: SM <[email-masked]>
Date: Wed, 21 Feb 2007 14:54:12 -0800

>I've seen it, but not published.

What's important is not what we see but what the DNSBL user can see 
so that they can make an informed decision.

>a test DNS server.  Tho, perhaps it's unlikely to result in a listing...

Yes, it may occur locally.  But it's not like the DNSBL operator is 
pointing the NS to the user's loopback (127/8).

>Most 127s would as well, would they not?

Yes it would.

Regards,
-sm