ietf-asrg
[Top] [All Lists]

Re: [Asrg] New draft draft-irtf-asrg-bcp-blacklists-01.txt

2008-03-25 12:48:51
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).

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