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