ietf-asrg
[Top] [All Lists]

Re: [Asrg] Getting group consensus on draft-irtf-asrg-bcp-blacklists

2011-03-01 17:50:57
On 2011/03/01 3:28 PM, John R. Levine wrote:
Now that the kerfuffle seems to have died down, I'd like to see if we
have group rough consensus (which does not mean perfect unanimity) on
the BL best practices overview. Please read through it and say whether
you think it's OK, or if not, what specific language to change.


I still find myself stuck on 2.2.5.  It needs to be removed or changed to not 
pick on negative-reputation lists.

As this BCP already describes, many (most?) DNSBL's are used as part of an 
overall scoring system, rather than just at the MTA level.  As such, removal 
from a negative-reputation list generally has the same net effect as addition 
to a positive-reputation list.  (Actually, ReturnPath is considered quite 
favorably in SpamAssassin.)  Any arguments against paid removal from a neg-rep 
list can be equally applied to paid addition to a pos-rep list.

While I disagree with Claus' particular rhetoric, I somehow feel that everyone 
who argued against him wouldn't be quite as judgemental against a paid 
whitelist like ReturnPath.  Not only that, UCEPROTECT is ultimately free...one 
would only pay for human intervention if the automatic timeframe just isn't 
soon enough.  Sure, I believe the practice of paying to upgrade your reputation 
is slimy at best, but why does the BCP pick on neg-rep lists when they, if 
anyone, SHOULD have evidence of wrong doing?

I'm sorry to pick on ReturnPath...Neil and J.D. have been exceptionally patient 
on the SA list, and RP's accuracy has improved considerably over the years 
(though the clarity of reporting issue still needs resolving)...but, in the 
end, the BCP needs to pick on no-one or pick on everyone that nets the same 
result.

Finally, with IPv6 staring us in the face, the landscape of DNSBL's will 
certainly be changing.  The group needs to decide if dictating business/revenue 
models is even appropriate in a BCP and, if so, needs to elaborate in much more 
detail to avoid what is ultimately picking on one single DNSBL.

-- 
/Jason
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg