ietf-asrg
[Top] [All Lists]

Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

2008-03-25 12:39:24
More seriously....

Should this document explain some of the differences between a manually
updated list and an automated/reputation-based list?

Suggested updates/changes to existing text are in square brackets:

Abstract

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

[ . . . ]

1.  Introduction

1.1.  DNS-Based Reputation Systems

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

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

   The first publicly available DNSBL using the Domain Name System (DNS)
   for distributing reputation data about email senders emerged in 1997,
   shortly after spam became a problem for network operators and email
   administrators.  This pioneer DNSBL focused on identifying known spam
   sources situated at static [(unchanging}] IP addresses.  Due to the
broad adoption
   of this DNSBL, it had a devastating impact on [these] 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.

[ . . . ]

2.1.  Transparency

[ . . . ]

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

[ . . . ]

3.3.  DNSBLs SHOULD Provide Operational Flags

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

   [Other results, such as 127.0.0.3, may have different meanings.]
This
   [o]perational flag usage and meaning SHOULD be published on the
DNSBL's
   web site.

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

[ . . . ]

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg

<Prev in Thread] Current Thread [Next in Thread>