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

[Douglas Otis <dotis at mail-abuse.org>]

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