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