Re: Re: DNSBL BCP v.2.0

On Feb 8, 2007, at 4:27 PM, Frank Ellermann wrote:

> Nick Nicholas wrote:
>
>>    7.  What are the demographics and quantity of the list's user  
>> base?
>
> How are admins supposed to evaluate this ?  Sounds bogus for me.

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

>>    9.  What do your peers or members of the Internet community say
>>        about the list.
>
> They all say it's bad for various conflicting reasons, none of them
> 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?

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

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.

>>    These guidelines address public DNSBLs only and do not apply to
>>    privately operated DNSBLs.
>
> s/do/may/ ?  Some proposals should also make sense for private lists.
>
>>    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.

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.

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.

>>    future. For more aggressive spammers (e.g., those operating their
>>    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.

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.

>>    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.
>
> Add "unless it's the stated list policy to cause collateral damage
> 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.

>>    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.
>
> ACK, and that upper limit could be worse than six months.
>

s/exponential backoff/exponentially extended periods/

>> 2.2.5.  Removals SHOULD Be Possible in Absence of List Administrator.
>
>>    Removals SHOULD be possible in the absence of the list  
>> administrator.
>
> Delete this line.

Agreed.

---
3.3. Content of DNSBL Zone File SHOULD Be Limited.

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

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

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

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

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

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

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




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