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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg