Subject: Re: [Asrg] 7. Best Practices - DNSBLs

From: "Chris Lewis" <[email-masked]>
Date: Wed, 13 Aug 2003 15:59:19 -0400

Matt Sergeant and I have been working in fits and starts on a BCP for 
DNSBLs since before the FTC Spam Panel.  Matt is going to be redrafting 
this thing in BCP format over the weekend, but we thought it would be 
useful to post the guts as-is for comments.

This is POD format and contains some editorial commentary which'll be 
collapsed into the text eventually.  You may want to consider them 
discussion points.

=head1 Guidelines for DNS Blacklists

These guidelines are ideas for how a well run DNS blacklist might work. 
Some DNS blacklists are considered by this author to be too aggressive 
and too difficult to get out of, so we put together these guidelines to 
try and put together a set of best practices for how to run a DNS 
blacklist. Ultimately we hope to put together some software for running 
a large scale DNS blacklist in an open manner. We may also maintain a 
list of compliant blacklists.

=head1 The Guidelines

=head2 Truth in Advertising

The criteria for listing should be carefully described (on the 
blacklist's web site, see below).  You should be honest and never enter 
a listing that doesn't meet the criteria.

In other words, be direct and honest as to what the listing criteria 
are, and never mix in other entries.  No spite listings [Footnote 3].

=head2 Getting out of the list should be the reverse of getting in

If all things listed in your criteria for listing are cleared up then 
there should be no reason to not remove the IP address. No I<extra> 
rules for de-listing.

=head2 There should be a web page that I<only> details the listing criteria

Often DNS blacklists put their listing criteria mixed in with lots of 
technical information about using the blacklist. This can confuse end 
users, so a page on its own should be dedicated to detailing why the IP 
address was blacklisted.

=head2 Collateral damage should be a last resort

Extending a blocking to try and achieve action from the owning ISP 
should only be performed after contacting the owning ISP about the 
current block and requesting action, and waiting a reasonable delay for 
the ISP to fix the problem.

Any policy for collateral damage must be clearly documented on the L<< 
listing criteria|/There should be a web page that I<only> details the 
listing criteria >> page.

=head2 Listings should be temporary

Listings should all be temporary (suggested default listing period: 24 
hours L</Footnote1>) so that if your blacklist doesn't get around to 
removing the entry then it times out at some point in the future. For 
more aggressive spammers (e.g. those running their own ISP) the 
temporary period can be as much as 6 months, but we recommend no longer 
than that as at some point the IP address will change hands, likely 
going to a non-spammer.

=head2 There must be a direct non-public way to request removal

A removals email address should be listed on the blacklist's web site. 
This should be a direct email address and not a pointer to post on a 
newsgroup or on a public mailing list.

=head2 There should be a non-email way to request removal

We recommend providing a web form to allow removal requests. This is 
required because the removals address probably uses the blacklist that 
the user is trying to get out of. Bounces from the removals address 
should point to this web form if they possibly can.

=head2 Removals must be prompt

The preferred way of doing this is I<removal without question>. This 
allows people to ask and get their IP address removed immediately, but 
does not prevent the blacklist owner re-listing their IP address at a 
later time (subject to seeing more spam, or re-checking the IP address 
security). A re-listing due to a false removal request may result in a 
longer timeout (i.e. a penalty).

Assuming the above is not possible and no listing reasons remain, 
removal at anyone's request must be prompt. By this we mean within at 
least 3 days B<maximum>, but a period of less than 24 hours is preferred.

=head2 Removals must be possible in the absence of the list maintainer

If removals cannot be automated (via robot re-testing) then there should 
be multiple list maintainers so that a removal request can be processed 
if the list owner is on vacation or otherwise unavailable.

=head2 Audit Trail

A blacklist B<must> maintain an audit trail for all listings. The 
blacklist B<should> make this audit trail web accessible.

=head1 Security fault blacklists special rules

Some blacklists list IP addresses that are insecure in various ways 
(e.g. open relays, open proxies). These are some recommendations for 
these systems:

=head2 No automated probes

The blacklist will not automatically probe for insecure systems. The 
reason for this is that there is little agreement in the community as to 
whether or not this should be allowed. So we err on the side of caution.

Listing should therefore be "spam in hand" from a spamtrap address, or 
"email in hand" based on either a non-automated test, or a test 
instigated by receiving an email from the tested IP address.

=head2 Reasonable re-scan periods

If the blacklist uses re-scans to determine whether the listing should 
timeout or not, the re-scan period should be reasonable. Scanning should 
occur no more often than once every 24 hours (this fits in with the 
L<expiry period|/Listings should be temporary> above L</Footnote1>).

=head1 Footnotes

=head2 Footnote1

The default timeout and re-scan period of 24 hours is contentious here. 
I like the default timeout being 24 hours, but scanning IPs every 24 
hours is considered a bit too often by some. More input needed on this.

[CRL] For systems that do rescans, expiration is moot.  For systems that 
do not do rescans, expiration should probably be no more than a week or 
two past last "active spam indication" (ie: spamtrap hit).

Probably what we need to stress is that anybody doing subjective public 
blacklisting should have a spamtrap-like facility sufficiently large to 
make spamtrap hits likely for any continuous spamming activity to be 
noticed.

=head2 Footnote2

Default timeout of 24 hours is fine - for the first test.  Decrease the 
frequency of relaytests - and after a while (say 4..5 tests) block the 
IP for keeps, or till such time as its admin gets in touch.
   --srs

=head2 Footnote3

Unless spite listings is the raison-d'etre of the blacklist.  Seriously, 
there's nothing wrong with a blacklist doing this AS LONG AS this is 
clearly stated in the criteria.  But, if the blacklist is "open relays", 
it should be "open relays _only_" [CRL]

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

---

From: Brad Knowles <[email-masked]>
Date: Wed, 13 Aug 2003 22:34:55 +0200

At 3:59 PM -0400 2003/08/13, Chris Lewis wrote:

>  Listings should all be temporary (suggested default listing period:
>  24 hours L</Footnote1>) so that if your blacklist doesn't get around
>  to removing the entry then it times out at some point in the future.

	Fine, but if the entry is removed and then you discover reason to 
put it back again (maybe because of a re-scan, or whatever), then the 
next timeout should be longer.

	I'd recommend something like a bounded exponential backoff.

>  If the blacklist uses re-scans to determine whether the listing
>  should timeout or not, the re-scan period should be reasonable.

	Again, I'd recommend bounded exponential backoff.

	Moreover, I think I'd probably move someone from the "confirmed" 
list to the "probationary" list immediately, then investigate their 
claims of being cleaned up.  They might have to stay on the 
probationary list for a while before I'd be willing to let them off 
completely.  If they ever came back, they'd stay on the main list a 
lot longer, have to stay on the probationary list a lot longer the 
next time they claim to be cleaned-up, etc....

	Other than that, it seems to be reasonable.  I look forward to 
seeing an expanded version that details tools and methods that can be 
used to run a real-world black list.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

---

From: "Chris Lewis" <[email-masked]>
Date: Wed, 13 Aug 2003 17:30:28 -0400

>     I'd recommend something like a bounded exponential backoff.

A bit further down:

Covers that.  Agree tho, should mention "bounded exponential backoff". 
I've fudged the original a bit.

> claims of being cleaned up.  They might have to stay on the probationary 
> list for a while before I'd be willing to let them off completely.  If 
> they ever came back, they'd stay on the main list a lot longer, have to 
> stay on the probationary list a lot longer the next time they claim to 
> be cleaned-up, etc...

We prefer an instant removal and relist upon subsequent re-detection or 
re-test.  Tho, a delay algorithm on removal (initially zero) is reasonable.

> used to run a real-world black list.

I don't think BCPs should get too specific about methods/tools - 
especially because they're often obsoleted quickly. It's important to 
get the principles laid out.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 14 Aug 2003 00:45:35 +0200

At 5:30 PM -0400 2003/08/13, Chris Lewis wrote:

>  Agree tho, should mention "bounded exponential backoff". I've fudged
>  the original a bit.

	You don't necessarily have to mention "bounded exponential 
backoff" per se.  Maybe better would be to say that the method should 
be adaptive, with increasingly longer timeouts for repeat offenses. 
You could then mention "bounded exponential backoff" as one example 
of such a method.

---

From: Bill Cole <[email-masked]>
Date: Wed, 13 Aug 2003 18:52:49 -0400

At 3:59 PM -0400 8/13/03, Chris Lewis wrote:

>blacklist's web site, see below).  You should be honest and never 
>enter a listing that doesn't meet the criteria.
>

I think this may need expansion to make it clear that accuracy is 
required, not precision. See CBL for an example of an accurate but 
not precise description of listing criteria.

>reason for this is that there is little agreement in the community 
>as to whether or not this should be allowed. So we err on the side 
>of caution.
>
>Listing should therefore be "spam in hand" from a spamtrap address, 
>or "email in hand" based on either a non-automated test, or a test 
>Scanning should occur no more often than once every 24 hours (this 
>fits in with the L<expiry period|/Listings should be temporary> 
>above L</Footnote1>).

I think there needs to be something to address the very real problem 
of destructive scanning. At various points in the past few years 
(notably with ORBZ and with the phase of the attack on a.r.s that 
used open Wingate proxies) the 'white hat' folks have been seen to 
use probes that take down targets. For SMTP relay testing this is a 
multifaceted problem because in some cases (i.e. some versions of 
Notes) it is only machines that do not relay which are crashed, and 
in many cases machines that accept a test message as a result of some 
relay test trick end up ricocheting the message internally until it 
lands in a double-bounce mailbox, and even today some of those are 
human-managed.

If there's going to be a de facto blessing of unauthorized security 
testing at all (I'm quite negative on that entire idea) it seems to 
me that it should at least define a clear and precise boundary on 
those tests. If it is a bad thing for a spammer to use an email 
address he does not own as SMTP sender, can it be justified by the 
claim that one is not spamming but testing (without permission)
a machine that may well end up accepting the 'test' and then bouncing 
it to someone who is neither spamming nor operating a system that 
facilitates spamming?

I realize that a requirement to hold to a strict ethical standard in 
SMTP relay testing is a requirement to not try tricks that spammers 
could and even do use, so it means that a negative result is quite 
uncertain.
-- 
Bill Cole                                  
[email-masked]

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 13 Aug 2003 19:59:30 -0400

At 03:59 PM 8/13/2003, Chris Lewis wrote:

>.................
>Extending a blocking to try and achieve action from the owning ISP should 
>only be performed after contacting the owning ISP about the current block 
>and requesting action, and waiting a reasonable delay for the ISP to fix 
>the problem.
>
>............

Some DNSRBLs work on policy level - listing ISPs that support spammers, 
listing modem pools, etc. What do we do about them?

---

From: Matt Sergeant <[email-masked]>
Date: Thu, 14 Aug 2003 11:32:27 +0100

On Thursday, Aug 14, 2003, at 00:59 Europe/London, Yakov Shafranovich 
wrote:

>> current block and requesting action, and waiting a reasonable delay 
>> for the ISP to fix the problem.
>>
>> Any policy for collateral damage must be clearly documented on the 
>> L<< listing criteria|/There should be a web page that I<only> details 
>> the listing criteria >> page.
>> ............
>
> Some DNSRBLs work on policy level - listing ISPs that support 
> spammers, listing modem pools, etc. What do we do about them?

I assume you mean SPEWS. It's a tricky question, because technically 
SPEWS listing ISPs supporting spammers isn't collateral damage to them 
- that's their entire raison d'étre and would be covered by "Truth in 
advertising". What the above section really applies to is lists like 
the SBL, who have an escalation policy to try and take action against 
particular spammers.

But maybe Chris has a different take on it.

Matt.

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 14 Aug 2003 10:22:58 -0400

> SPEWS listing ISPs supporting spammers isn't collateral damage to them - 
> that's their entire raison d'étre and would be covered by "Truth in 
> advertising". What the above section really applies to is lists like the 
> SBL, who have an escalation policy to try and take action against 
> particular spammers.
> 

Matt, are you scribe now? ;-)

I have a more generic take on this.  It wouldn't be far-fetched, for 
example, for a proxy DNSBL to escalate, say, the ridiculous levels of 
open proxy infestations in some of the Brazilian class B to blocks on 
the Brazilian ISP's mail servers, or, the _whole_ class B (SPEWS has 
done this a couple of times).

As such, "escalations" aren't necessarily coercive per-se, and in some 
cases (such as the Brazilian proxy problem), there is virtually no 
detectable collateral damage actually occuring.

Expanding on that bit:

1) Escalation policies should be described as part of the list criteria 
page.

2) In that description, the escalation policy should be identified as 
either a "collateral damage/coercive" or a "protective" measure (or 
both).  A "collateral damage" escalation is where you deliberately 
target stuff that there's no reason to believe is a spam problem itself 
in order to force the owner to do something.  A "protective measure" 
type escalation is where you're (for example) giving up on individually 
tracking thousands of open proxies within a class B, and just blocking 
the whole thing.

SBL escalations are almost always coercive.  Most SPEWS escalations 
start out "protective", and then become coercive once they get bigger.

3) My take is that it's far more important/useful to pre-warn about 
coercive escalations (because that's the whole point after all) than 
protective ones.

---

From: "Chris Lewis" <[email-masked]>
Date: Thu, 14 Aug 2003 10:33:25 -0400

> listing modem pools, etc. What do we do about them?

I don't see there's an issue with those w.r.t. the DNSBL BCP.

As Matt suggests, tho with a less emotionally loaded/simpler example: if 
your mission is to list DHCP dialup pools, and a particular IP really 
_is_ a DHCP dialup pool, there is no collateral damage or false 
positives by definition.

 From the filter operator's perspective, if they use a dialup pool 
blacklist they're making a policy decision to block dialup pools, not 
necessarily spam per-se.  As such the only FP is when the IP is 
erroneously listed as dialup.

Yes, blocking dialup pools is an effective anti-spam measure. But in 
order to operate without grey areas, the MTA operator (not the DNSBL 
operator) needs to couch it as a dialup block, not a spam block.

This is particularly important with our open relay/proxy blacklisting - 
our policy is simple: we don't accept email from systems that are open 
proxies or open relays, period.  Prevents arguments like "but only 99% 
of the stuff coming from my IP is spam!  Unblock me!".