New draft draft-irtf-asrg-bcp-blacklists-01.txt

[John Levine]

We finally have a revised draft of the BCP for blacklists.  Take a look
and see what if anything merits changes.

Keep in mind that this is a separate document from the one that describes
how blacklists work.  Both are linked from the wiki
http://wiki.asrg.sp.am.

Regards,
John Levine, johnl@..., Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---------- Forwarded message ----------
Date: Mon, 24 Mar 2008 17:18:00 +0000 (UTC)
From: Internet-Drafts@...
To: i-d-announce@...
Newsgroups: iecc.lists.ietf
Subject: I-D Action: draft-irtf-asrg-bcp-blacklists-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

  Title           : Guidelines for Management of DNS Blacklists for Email
  Author(s)       : C. Lewis, M. Sergeant
  Filename        : draft-irtf-asrg-bcp-blacklists-01.txt
  Pages           : 14
  Date            : 2008-03-24

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

The document will seek BCP status.  Comments and discussion of this
document should be addressed to the asrg@... mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[Ale2008]

John Levine wrote:
> We finally have a revised draft of the BCP for blacklists.  Take a look
> and see what if anything merits changes.

As a newbie, I post my opinion in the hope that it can be a useful feedback.


|                         a private DNSBL is used solely by an
|   organization for its own use and the data is not made available
|   publicly.

I would drop "solely". Even if the data cannot be looked up, there may be
forwarding agreements. For example, Hotmail allows postmasters to subscribe
in order to be informed about spam reports related to their IP addresses.

|   This document is also intended to provide guidance to DNSBL
|   administrators so that [...]

Why "also", isn't it the primary purpose? (I'd say there is no substantial
difference between DNSBL operators and administrators.) Rather, I would
mention there that the document also provides guidance for DNSBLs users,
in view of the section that follows.

BTW, a section is missing about end users' role in reacting to bounces.

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

That they are working properly is too difficult to assess, for a user.

I would add two points to that list:

* If at all possible, system admins should allow their customers to configure
   which DNSBLs they want to disable for their mail, if any.

* System admins should make sure they don't lock out their own customers. (This
   sounds obvious, but since the corresponding recommendation is made for DNSBL
   admins...)

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

Some DNSBLs mention that removal requests should come from the person in
charge. Who is that? IMHO, the person in charge for an IP address is the
one mentioned in the corresponding whois record at the relevant RIR. It may
be worth establishing (confirming or denying) that point.

BTW, is it a good practice to send listing/removal notices to the relevant
postmaster or abuse addresses?

| 2.2.3.  Removals SHOULD Be Prompt
|
|    Requests for removal SHOULD be honored without question. [...]

That section apparently assumes more about a DNSBL's policy than the rest of
the BCP. For example, a previous section considers listings associated with
geographic information. Aren't there valid exceptions for automatic delisting?

| 2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting

"Criteria for Listing and Delisting SHOULD be symmetrical." Sounds better?

| 3.4.  Shutdowns MUST Be Done in a Graceful Fashion

Since it has been mentioned that commercial DNSBLs exist, it may make sense
to recommend that they use adequate renewal methods. (For example, Trend Micro
is still missing a credit card based self-renewal web page.)

_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[John Levine-2]

>As a newbie, I post my opinion in the hope that it can be a useful feedback.

Thanks for taking a look.

>
>|                         a private DNSBL is used solely by an
>|   organization for its own use and the data is not made available
>|   publicly.
>
>I would drop "solely". Even if the data cannot be looked up, there may be
>forwarding agreements. For example, Hotmail allows postmasters to subscribe
>in order to be informed about spam reports related to their IP addresses.

That's not a DNSBL, that's a feedback loop (FBL).  They're not related.

> I would mention there that the document also provides guidance for
>DNSBLs users, in view of the section that follows.

I'll defer to Chris, but I don't think that's the intention at all.
This is about how to run a DNSBL, not about how a user at some ISP
interacts with the people at his ISP who manage the mail.

>* If at all possible, system admins should allow their customers to configure
>   which DNSBLs they want to disable for their mail, if any.

In my experience, although admins are hardly infallible, users tend to
make much worse decisions.  I cannot tell you how many inane arguments
I've had from users saying "you need to whitelist this IP" when
whatever the problem was had nothing to do with IP blacklisting.

>* System admins should make sure they don't lock out their own
>   customers. (This sounds obvious, but since the corresponding
>   recommendation is made for DNSBL admins...)

Not a bad thing to mention.  Eircom, the large Irish ISP, has exactly
this problem, a mail system that roaming users can't use due to their
sloppy use of DNSBLs.

>| 2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available
>
>Some DNSBLs mention that removal requests should come from the person in
>charge. Who is that? IMHO, the person in charge for an IP address is the
>one mentioned in the corresponding whois record at the relevant RIR. It may
>be worth establishing (confirming or denying) that point.

That is much more true in some cases than others.  In ARIN territory,
it's fairly rare for space to be SWIPed down to the individual network
customer.

>| 2.2.3.  Removals SHOULD Be Prompt
>|
>|    Requests for removal SHOULD be honored without question. [...]
>
>That section apparently assumes more about a DNSBL's policy than the rest of
>the BCP. For example, a previous section considers listings associated with
>geographic information. Aren't there valid exceptions for automatic delisting?

Good point, worth a little clarification.

>| 2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting
>
>"Criteria for Listing and Delisting SHOULD be symmetrical." Sounds better?

But it's not right.  In particular, DNSBLs that list due to observed
behavior, e.g. hitting spamtraps, usually stop paying attention to
delist requests for IPs that keep relisting themselves.

>| 3.4.  Shutdowns MUST Be Done in a Graceful Fashion
>
>Since it has been mentioned that commercial DNSBLs exist, it may make sense
>to recommend that they use adequate renewal methods. (For example, Trend Micro
>is still missing a credit card based self-renewal web page.)

Way out of scope here.  If your Trend subscription expires, that's not the
same thing as the list being shut down.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[Chris Lewis-2]

John Levine wrote:

>> As a newbie, I post my opinion in the hope that it can be a useful feedback.
>
> Thanks for taking a look.
>
>> |                         a private DNSBL is used solely by an
>> |   organization for its own use and the data is not made available
>> |   publicly.
>>
>> I would drop "solely". Even if the data cannot be looked up, there may be
>> forwarding agreements. For example, Hotmail allows postmasters to subscribe
>> in order to be informed about spam reports related to their IP addresses.
>
> That's not a DNSBL, that's a feedback loop (FBL).  They're not related.

Still, dropping "solely" isn't a bad idea.  I keep thinking "fish, yum" ;-)

>> I would mention there that the document also provides guidance for
>> DNSBLs users, in view of the section that follows.
>
> I'll defer to Chris, but I don't think that's the intention at all.
> This is about how to run a DNSBL, not about how a user at some ISP
> interacts with the people at his ISP who manage the mail.

The target is DNSBL operators and DNSBL users - DNSBL users are
typically mail server admins - or at least, that's how we're intending
it.  If it's not clear, we can fix that.  I consider end-users twiddling
their own DNSBLs to be out of scope.  Does this need to be clarified?

>> * If at all possible, system admins should allow their customers to configure
>>   which DNSBLs they want to disable for their mail, if any.
>
> In my experience, although admins are hardly infallible, users tend to
> make much worse decisions.  I cannot tell you how many inane arguments
> I've had from users saying "you need to whitelist this IP" when
> whatever the problem was had nothing to do with IP blacklisting.

That is site policy.  Out of scope.

As for reacting to rejections - I pondered adding a fairly general
section on "filtering BCP" (eg: reject not bounce etc), which could
include how an end user reacts to a rejection message, but that's a
whole new can of worms, and I'd just like to get _this_ BCP done and out
of the way before attempting something like that.

Now that I finally know how to do RFC formatting myself, perhaps I'll do
more of these things... ;-)

>> * System admins should make sure they don't lock out their own
>>   customers. (This sounds obvious, but since the corresponding
>>   recommendation is made for DNSBL admins...)

> Not a bad thing to mention.  Eircom, the large Irish ISP, has exactly
> this problem, a mail system that roaming users can't use due to their
> sloppy use of DNSBLs.

Yup.  Should put in something specifically about "READ the terms and
conditions and suitability for a given purpose.  Eg: don't block your
own users with a PBL".

>> | 2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be Available
>>
>> Some DNSBLs mention that removal requests should come from the person in
>> charge. Who is that? IMHO, the person in charge for an IP address is the
>> one mentioned in the corresponding whois record at the relevant RIR. It may
>> be worth establishing (confirming or denying) that point.

> That is much more true in some cases than others.  In ARIN territory,
> it's fairly rare for space to be SWIPed down to the individual network
> customer.

I think it better to leave that up to the DNSBL instructions page.

It certainly isn't advisable in general to hit postmaster@DNSBL etc.
They may be completely different entities not related to each other.
Might be worth saying "read the contact instructions dammit!" ;-)

>> | 2.2.3.  Removals SHOULD Be Prompt
>> |
>> |    Requests for removal SHOULD be honored without question. [...]
>>
>> That section apparently assumes more about a DNSBL's policy than the rest of
>> the BCP. For example, a previous section considers listings associated with
>> geographic information. Aren't there valid exceptions for automatic delisting?
>
> Good point, worth a little clarification.

Will take that under advisement ;-)

>> | 2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting

>> "Criteria for Listing and Delisting SHOULD be symmetrical." Sounds better?

> But it's not right.  In particular, DNSBLs that list due to observed
> behavior, e.g. hitting spamtraps, usually stop paying attention to
> delist requests for IPs that keep relisting themselves.

We're trying to avoid pure symmetry to give some room for DNSBLs to
offer additional instructions not entirely symmetrical with the given
listing, but at the same time, try to heavily discourage the extremes
(DNSBLs acting like a protection racket).

>> | 3.4.  Shutdowns MUST Be Done in a Graceful Fashion
>>
>> Since it has been mentioned that commercial DNSBLs exist, it may make sense
>> to recommend that they use adequate renewal methods. (For example, Trend Micro
>> is still missing a credit card based self-renewal web page.)
>
> Way out of scope here.  If your Trend subscription expires, that's not the
> same thing as the list being shut down.

Agreed.
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[David Nicol]

On Tue, Mar 25, 2008 at 11:47 AM, Chris Lewis <clewis@...> wrote:

>  The target is DNSBL operators and DNSBL users - DNSBL users are
>  typically mail server admins - or at least, that's how we're intending
>  it.  If it's not clear, we can fix that.  I consider end-users twiddling
>  their own DNSBLs to be out of scope.  Does this need to be clarified?

you never know who is going to suddenly become a mail server admin.

I would think a good imaginary reader for this document would be a
literature professor who had a volunteer geek set up a mailing list system
on their home computer which has a dynamic IP and through the magic
of dyndns.org, the whole system works just fine for several years until
one day, after an ice storm, Dr. Nadagik's box loses the DHCP lottery
and is inconvenienced by drawing a nomber formerly occupied by
a neighbor with poor download hygiene and a tendency to have his decrepit
equipment compromised by operators of global anonymous botnets.

Dr. Nadagik's IT staff is long gone, and she decides to figure out what
is going on, as several of the presitigious members of her mailnig list are
no longer getting their messages even though they are still subscribed,
and the list server logs, which she has never actually had occasion to
read before now -- have  some new text in them mentioning a numbered
RFC, whatever that is.
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[J D Falk]

David Nicol wrote:

> I would think a good imaginary reader for this document would be a
> literature professor who had a volunteer geek set up a mailing list
> system on their home computer which has a dynamic IP and through the
> magic of dyndns.org, the whole system works just fine for several
> years until one day, after an ice storm, Dr. Nadagik's box loses the
> DHCP lottery and is inconvenienced by drawing a nomber formerly
> occupied by a neighbor with poor download hygiene and a tendency to
> have his decrepit equipment compromised by operators of global
> anonymous botnets.

Oh, woe betide the poor server whose DHCP, after failure, doth return
askew!  Hast thou so quickly dismissed thy geekly intern, and through
forgetful folly neglect to request that full documentation be laid upon
thy hand?  And now, poor fool, finding much email rejected through past
actions solely of thy neighbor, seek you enlightenment from this poor
RFC?  'Tis but feeble illumination ye shall find here, alas, for 'tis
solely through pedantry and endless argumentation were such as this
writ.  Another intern, methinks, must thou now seek -- and unto that
fresh and welcoming mind deliver such best practices as to make
dizziness ensue.

_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[John Levine-2]

>Oh, woe betide the poor server whose DHCP, after failure, doth return
>askew!  Hast thou so quickly dismissed thy geekly intern, and through
>forgetful folly neglect to request that full documentation be laid upon
>thy hand?  And now, poor fool, finding much email rejected through past
>actions solely of thy neighbor, seek you enlightenment from this poor
>RFC?  'Tis but feeble illumination ye shall find here, alas, for 'tis
>solely through pedantry and endless argumentation were such as this
>writ.  Another intern, methinks, must thou now seek -- and unto that
>fresh and welcoming mind deliver such best practices as to make
>dizziness ensue.

You understand, of course, that this means that now we're going to ask
you to rewrite the whole BCP.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Mar 25, 2008, at 9:47 AM, Chris Lewis wrote:

> John Levine wrote:
>>> As a newbie, I post my opinion in the hope that it can be a useful  
>>> feedback.
>>
>> Thanks for taking a look.
>>
>>> |                         a private DNSBL is used solely by an
>>> |   organization for its own use and the data is not made available
>>> |   publicly.
>>>
>>> I would drop "solely". Even if the data cannot be looked up, there  
>>> may be
>>> forwarding agreements. For example, Hotmail allows postmasters to  
>>> subscribe
>>> in order to be informed about spam reports related to their IP  
>>> addresses.
>>
>> That's not a DNSBL, that's a feedback loop (FBL).  They're not  
>> related.
>
> Still, dropping "solely" isn't a bad idea.  I keep thinking "fish,  
> yum" ;-)
>
>>> I would mention there that the document also provides guidance for
>>> DNSBLs users, in view of the section that follows.
>>
>> I'll defer to Chris, but I don't think that's the intention at all.
>> This is about how to run a DNSBL, not about how a user at some ISP
>> interacts with the people at his ISP who manage the mail.
>
> The target is DNSBL operators and DNSBL users - DNSBL users are
> typically mail server admins - or at least, that's how we're intending
> it.  If it's not clear, we can fix that.  I consider end-users  
> twiddling
> their own DNSBLs to be out of scope.  Does this need to be clarified?
>
>>> * If at all possible, system admins should allow their customers  
>>> to configure
>>>  which DNSBLs they want to disable for their mail, if any.
>>
>> In my experience, although admins are hardly infallible, users tend  
>> to
>> make much worse decisions.  I cannot tell you how many inane  
>> arguments
>> I've had from users saying "you need to whitelist this IP" when
>> whatever the problem was had nothing to do with IP blacklisting.
>
> That is site policy.  Out of scope.
>
> As for reacting to rejections - I pondered adding a fairly general
> section on "filtering BCP" (eg: reject not bounce etc), which could
> include how an end user reacts to a rejection message, but that's a
> whole new can of worms, and I'd just like to get _this_ BCP done and  
> out
> of the way before attempting something like that.
>
> Now that I finally know how to do RFC formatting myself, perhaps  
> I'll do
> more of these things... ;-)
>
>>> * System admins should make sure they don't lock out their own
>>>  customers. (This sounds obvious, but since the corresponding
>>>  recommendation is made for DNSBL admins...)
>
>> Not a bad thing to mention.  Eircom, the large Irish ISP, has exactly
>> this problem, a mail system that roaming users can't use due to their
>> sloppy use of DNSBLs.
>
> Yup.  Should put in something specifically about "READ the terms and
> conditions and suitability for a given purpose.  Eg: don't block your
> own users with a PBL".
>
>>> | 2.2.2.  A Direct Non-Public Way to Request Removal SHOULD Be  
>>> Available
>>>
>>> Some DNSBLs mention that removal requests should come from the  
>>> person in
>>> charge. Who is that? IMHO, the person in charge for an IP address  
>>> is the
>>> one mentioned in the corresponding whois record at the relevant  
>>> RIR. It may
>>> be worth establishing (confirming or denying) that point.
>
>> That is much more true in some cases than others.  In ARIN territory,
>> it's fairly rare for space to be SWIPed down to the individual  
>> network
>> customer.
>
> I think it better to leave that up to the DNSBL instructions page.
>
> It certainly isn't advisable in general to hit postmaster@DNSBL etc.
> They may be completely different entities not related to each other.
> Might be worth saying "read the contact instructions dammit!" ;-)
>
>>> | 2.2.3.  Removals SHOULD Be Prompt
>>> |
>>> |    Requests for removal SHOULD be honored without question. [...]
>>>
>>> That section apparently assumes more about a DNSBL's policy than  
>>> the rest of
>>> the BCP. For example, a previous section considers listings  
>>> associated with
>>> geographic information. Aren't there valid exceptions for  
>>> automatic delisting?
>>
>> Good point, worth a little clarification.
>
> Will take that under advisement ;-)
>
>>> | 2.2.4.  SHOULD Have Similar Criteria for Listing and Delisting
>
>>> "Criteria for Listing and Delisting SHOULD be symmetrical." Sounds  
>>> better?
>
>> But it's not right.  In particular, DNSBLs that list due to observed
>> behavior, e.g. hitting spamtraps, usually stop paying attention to
>> delist requests for IPs that keep relisting themselves.
>
> We're trying to avoid pure symmetry to give some room for DNSBLs to  
> offer additional instructions not entirely symmetrical with the  
> given listing, but at the same time, try to heavily discourage the  
> extremes (DNSBLs acting like a protection racket).

Some BL policies do not adhere to the dubious philosophy expressed in  
section 2.2.1  and  2.2.3.

2.2.1.  Listings SHOULD Be Temporary

2.2.3.  Removals SHOULD Be Prompt

Automatic de-listing can be highly counter productive in controlling  
IP address ranges previously producing substantial levels of abuse.  
Requiring owners of an address range to request de-listing establishes  
points of contact to better deal with likely events of future abuse.  
Automatic de-listing, from that standpoint, is less effective at  
curbing abuse.  Automatic de-listing also enables a range of IP  
addresses to operate individually over a detection and listing  
process, which may involve substantial review and owner notification.  
The possible use of owner notification is fully lacking from draft, as  
well as provider indemnification, which represents a different and  
perhaps more responsible means for dealing with abuse.  Automated  
detection and listing although conceptually attractive, is limited and  
often is gamed by abusers.

Sections 2.2.1 and 2.2.3 should be removed or changed to represent  
only one possible mode of operation.  Six months is not a "sensible  
maximum".  This period depends upon how the BL is administered and  
their internal policies.

>>> | 3.4.  Shutdowns MUST Be Done in a Graceful Fashion
>>>
>>> Since it has been mentioned that commercial DNSBLs exist, it may  
>>> make sense
>>> to recommend that they use adequate renewal methods. (For example,  
>>> Trend Micro
>>> is still missing a credit card based self-renewal web page.)
>>
>> Way out of scope here.  If your Trend subscription expires, that's  
>> not the
>> same thing as the list being shut down.
>
> Agreed.

The Trend process requires a P.O. and a contract for valid reasons not  
covered by this draft. : (

-Doug



_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[Al Iverson-3]

On Tue, Mar 25, 2008 at 2:36 PM, Douglas Otis <dotis@...> wrote:

>  Some BL policies do not adhere to the dubious philosophy expressed in
>  section 2.2.1  and  2.2.3.

Could you elaborate upon the relevancy of that fact? I'm not seeing
why it matters.

>  2.2.1.  Listings SHOULD Be Temporary
>
>  2.2.3.  Removals SHOULD Be Prompt
>
>  Automatic de-listing can be highly counter productive in controlling
>  IP address ranges previously producing substantial levels of abuse.
>  Requiring owners of an address range to request de-listing establishes
>  points of contact to better deal with likely events of future abuse.

I think these should stand as is. I think they cover "it's not
suitable to remove your IP address at this time" eventualities just
fine.

Regards,
Al Iverson

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

[J D Falk]

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@...
https://www.ietf.org/mailman/listinfo/asrg

[Matthias Leisi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A couple of remarks from the perspective of an operator of a DNS-based
whitelist (dnswl.org), including some general remarks:

* Large portions of this document apply equally to black- and whitelist.
Therefore it may make sense to enlarge the scope to explictly cover
whitelists as well. The general notion of "DNS-Based Reputation Systems"
would profit even more if whitelists would be explicitly included.

* 2.2.1 Listings SHOULD be temporary: IMO this section should be dropped
- - it describes a certain policy which may or may not fit the purpose of
a particular DNSBL.

* 2.2.3 Removals SHOULD be prompt: Similar to the item above, automated
removals may or may not be a good idea. Considering an Spamhaus-SBL-type
list, this SHOULD for automated removals does not make much sense.

* 3.1 DNSBL Query Root Domain SHOULD be a subdomain: It should be
defined how best to differentiate multiple (possibly related) DNSBLs
under a common domain ("purposeA.dnsbl.example.com" and
"purposeB.dnsbl.example.com" vs. "dnsblA.example.com" and
"dnsblB.example.com").

* 3.2 DNSBLs SHOULD be Adequately Provisioned: For public use, that
should rather be a MUST. "Redundancy" should further be clarified
(number, net-topological location and vendor/versions of software).

* Addition to 3.2 and redundancy: nameservers should provide appropriate
glue records, possibly in different TLDs to protect against single-TLD
issues.

* 3.4 Shutdown: Add an item 5 warning against directing nameserver
lookups at some third-party unrelated to the DNSBL operation (eg an ISPs
nameserver), and noting that such behaviour is similar to inflicting a
dDoS).

* 3.5 Listing of special...: "MAY list loopback" vs. "MUST NOT list
127.0.0.1" - does this make sense?

* Proposal: 3.8 Protect against misconfiguration by users: Common types
of misconfigurations include

- - Using wrong (sub-) zones for querying (4.3.2.1.example.com instead of
4.3.2.1.dnsbl.example.com)
- - Downloading a local mirror of the data, but failing to set up the
local nameserver infrastructure appropriately, and thus keeping querying
public nameservers
- - Downloading a local mirror of the data, but misconfiguring the local
nameserver infrastructure to query a locally invented zone name
(4.3.2.1.dnsbl.local) at the public nameservers.
- - Misconfigured local nameservers to not do meaningful caching, thus
heavily increasing load on public nameservers.

To protect against such misconfiguration, DNSBL operators SHOULD make
efforts to contact administrative contacts to remedy the situation, but
SHOULD also prepare to take appropriate steps to protect the operative
infrastructure (ie, to block abusive users from causing further damage).

- -- Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)

iD8DBQFH6W41xbHw2nyi/okRAiBMAJ4vI+s+Mn6TrPssOhIB02BOgdZ+ywCeP3q/
r6ctnRgoqQ+Wp3w17OQXgkg=
=XuL7
-----END PGP SIGNATURE-----
_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[J D Falk]

Matthias Leisi wrote:

> * Large portions of this document apply equally to black- and
whitelist.
> Therefore it may make sense to enlarge the scope to explictly cover
> whitelists as well. The general notion of "DNS-Based Reputation
Systems"
> would profit even more if whitelists would be explicitly included.

Call it "DNS-Based Binary Reputation Systems," and I'd agree.  The full
range of reputation systems in use today is much too broad to fit into
DNS, or into this document.

> * 2.2.1 Listings SHOULD be temporary: IMO this section should be
dropped
> - - it describes a certain policy which may or may not fit the purpose
> of a particular DNSBL.

It fits most DNSBLs, though, as a best practice.

> * 2.2.3 Removals SHOULD be prompt: Similar to the item above,
> automated removals may or may not be a good idea. Considering an
> Spamhaus-SBL-type list, this SHOULD for automated removals does not
> make much sense.

Most DNSBLs aren't the Spamhaus SBL.  This is a best practice for just
about everything else.

_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[Douglas Otis]

On Mar 25, 2008, at 12:28 PM, Al Iverson wrote:

> On Tue, Mar 25, 2008 at 2:36 PM, Douglas Otis <dotis@...>  
> wrote:
>
>> Some BL policies do not adhere to the dubious philosophy expressed  
>> in section 2.2.1  and  2.2.3.
>
> Could you elaborate upon the relevancy of that fact? I'm not seeing  
> why it matters.

This was expanded upon in text you deleted by stating not all BLs  
depend upon full list automation.  Some lists attempt to audit  
networks and provide notifications to afford opportunities to remedy  
issues.  Establishing co-operative relationships often involves time.  
The time expended means such efforts can easily be gamed, especially  
when de-listing is automatic at set intervals or acted upon  
automatically from any request.  Keep in mind, some organizations  
structure their BL services differently.  Some offer BLs run in the  
manner suggested by the current version of the draft and others do  
not.  Trend happens to do both.  The difference between these two  
approaches is rather dramatic in respect to abating UCEs.  Neither  
management style offers a perfect system.  Each offer a level of  
service better suited to a range of individual needs.  This draft  
wrongly assumes only one approach should be used, and that is simply  
wrong in many cases.  Each of these approaches benefits the Internet  
overall, but no one should assume that one approach is always better  
than the other in every case.

Justifying a listing and de-listing policy should consider all factors  
involved.  This draft concludes de-listing interval of 180 days is  
sensible without a basis to support the claim.  It is not enough to  
say this policy has been used by company X, Y or Z.  Control on  
behaviour is the result of many differing policies.  It would be wrong  
to conclude one approach is somehow better than another.  They all  
play different roles and serve different needs.  One size does not fit  
all.  It is a myth the solution to spam is simply a matter solved  
through automation and standardized policies.  It hard to explain just  
how wrong that perspective is.

>> 2.2.1.  Listings SHOULD Be Temporary
>>
>> 2.2.3.  Removals SHOULD Be Prompt
>>
>> Automatic de-listing can be highly counter productive in  
>> controlling IP address ranges previously producing substantial  
>> levels of abuse. Requiring owners of an address range to request de-
>> listing establishes points of contact to better deal with likely  
>> events of future abuse.
>
> I think these should stand as is. I think they cover "it's not  
> suitable to remove your IP address at this time" eventualities just  
> fine.

It does not help the cause to have these "SHOULD" statements which, in  
the end, will likely prove highly counter productive.  While  
automation helps, it is not a complete solution, nor will automation  
ever be.  Automation can and is being gamed.

-Doug






_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg

[sm-7]

At 14:27 25-03-2008, Matthias Leisi wrote:
>* 2.2.1 Listings SHOULD be temporary: IMO this section should be dropped
>- - it describes a certain policy which may or may not fit the purpose of
>a particular DNSBL.

It is better that listings be temporary as IP addresses can be
reassigned.  There is nothing in that recommendation that prevents
the operator from relisting the IP address.  Such a recommendation
prompts the operator to review the listings for correctness.

>* 3.5 Listing of special...: "MAY list loopback" vs. "MUST NOT list
>127.0.0.1" - does this make sense?

Yes.

Regards,
-sm

_______________________________________________
Asrg mailing list
Asrg@...
https://www.ietf.org/mailman/listinfo/asrg