Well then, that answers that. It lets me know an huge area where volunteers to try and build a sustainable system for filter list. With individual maintainers, it is easy to maintain the enough control so that advertisers don't just start taking over the block lists to effectively sabotage the pihole. But it also really limits the potential, and can cause the whole thing to end when a key maintainer steps abandons their role, or can no longer dedicate the time needed.
It seems the problem here is there are different types of filtering people need. There basically adblock type filtering. Meaning blocking inline ads from showing in the page. There is cookie type blocking, which means keep advertisers from being able track your activity. Then there is content type blocking. For example, even if I click on it, don't open a page for gambling.
Any URL that ends in with click is implied to be a content type blocking. OpenDNS is evidence that is possible to do at a DNS level. But it is not a one size fits all. Every single user can have a custom list of what they block and allow. And every family will want to block different things. And sometimes we find the categories don't quite mean what we thought it did. For example, maybe we intended to block just porn, but suddenly find any sight talking about breast cancer is also blocked because of breast images. So it needs to be easy to tweak and customize those settings.
Someday, pihole might well be able to handle those categorizations. But for now it is best left to setting a site that does handle it like opendns handle it.
Now if each list has a different maintainer, that means each list owner needs to have a meeting of the minds what they are trying to block, and what they aren't trying to block. If I receive a e-mail from a spammer, it would be tempting to thing I want to block the dns lookups for every single link in their e-mail. And for the most part, if the dns lookups are unique enough, that would actually be appreciate by the average user. But this is going into the realm of content based filtering. The links in that e-mail are not something that are popping up as I browse a webpage. They are links I'm clicking on. Whether it is bait and switch, or I really know what I'm clicking on, I'm taking an action indicating I want to see that content. So blocking outside the context of a content filter is a bad idea.
But here is where it gets worse. As soon as we put CNAME lookups we are suddenly not just blocking that particular spammer's links. Now we are blocking everything pointing to the same service provider. So if I'm hosting my website on freeshell.org, and some other website hosted there starts a spamming campaign, suddenly legitimate access to my website is being blocked. What was probably a mildly in appropriate content filter, has suddenly become a shot gun taking down huge sections of the web is a single blast.
Ideally, the way to solve that is to actually have an indication not just what is being blocked. But why. And what is the appropriate level of blocking. Is this really intended to be shot-gun? Maybe in some cases you need that shot-gun, because the advertisers will regularly rotate the CNAME entries they are using. And if the same advertiser his using thousands of CNAME's the only sane way to block them is with the shot-gun approach.
I would actually find it surprising though if these click* links are examples of that. For example if they are using the Sales Force Marketing campaign extension, they can't just arbitrarily change a link designed to click into their promotion, to a link design to collect tracking data. The API simply won't allow that, unless they have exploited a security hole.
Until there is actually some sort of flag on the gravity records indicating which should be subject to cname's, I would suggest a more useful default is to leave CNAME filtering off. As having normal everyday activities blocked by default will trash the reputation of the project.