Now that I got my computer set up with buildkit, I had a chance to play further with civix and built a simple "first name = last name" search extension to test this out and practice the basics of civix.
If anyone wants to try it let me know how it goes:
You could find them via groups (or tags) and the custom include/exclude search.
If you have always used CiviCRM for everything then I think you should only need two groups or tags:
All contacts with activities (as activites are created for contributions, membership and events)
If you have migrated data from a previous system or imported ...
We didn't find a great way of dealing with this. I think we found the best approach was to use Drupal Views and VBO and probably civicrm entities so that we could grab the civi records of the users who we wanted to cull, and then delete the civi record and then delete the user record. If I can dig out the View I will share
Take out the $ signs. Smarty variables use $ signs, tokens don't. It is a little bit awkward when they're mixed in the same template.
I don't know the legal answer to the other part of the question, but bulk mailings include it by default.
The same email sent directly from the sender address arrived.
Based on this, there are two lines of investigation that are worth pursing:
One key difference is the sender envelope from address (different from the From: address in the message itself). A CiviMail message sent from CiviCRM uses the domain in the mail account used for bounce processing.
Spitballing as I haven't tried this, but if the CiviGroup Roles Sync module allows you to sync a Drupal role into a CiviCRM group, you could:
Add all blocked accounts to a (new/temporary) Drupal role.
Sync that role to a group in CiviCRM.
Load all contacts in that group in the CiviCRM UI and delete/trash them.
Delete Drupal users (and temp role) if desired.
We also find a lot of spam contacts in civi have a first name which matches the last name. In which case we run this query to find them, export them if need be and let client eyeball them
SELECT civicrm_contact.id, civicrm_contact.first_name,
LEFT JOIN civicrm_email
I use Google ReCaptcha on our User Login and Contribution pages. Problem solved, No more Spam Registrations. It has been working for several months. Plus it is much simpler for the users to check I am not a robot then to do the pictures, letters, numbers mess.
To be clear, the article that you linked to says why it's irresponsible to remove the default jQuery in WordPress. Are you sure that CiviCRM is doing that? My understanding (possibly incorrect) was that Civi just uses its own.
Do you have the console errors that SpamShield was throwing that proves that this is what the error is? This may be a namespacing ...