Administrators will see a new error message stating: Plugin mysql_native_password reported: ''mysql_native_password' is deprecated and will be removed in a future release. Please use caching_sha2_password instead.

The problem is: there is currently no known way to convert users to the new method without knowing the user's password, and how many folks will remember their database passwords? It just takes a simple line of SQL to convert the account, but finding all of the passwords and their use cases will be a nightmare.

To identify the users on the system who need to be updated, execute the following SQL on your MySQL server:

SELECT user, host, plugin from mysql.user WHERE plugin='mysql_native_password';

And then using the user's password, convert the authentication from mysql_native_password to caching_sha2_password with the following SQL:

ALTER USER '<USERNAME>'@'<HOST>' IDENTIFIED WITH caching_sha2_password BY '<PASSWORD>';

You'll obviously replace USERNAME, HOST, and PASSWORD with the appropriate values.
 

First, in modsecurity I block problematic country .TLDs, which I know is anti-social, but it prevents lots of headaches for my current business use case. This doesn't prevent a determined hacker from using a VPN for attacks in another country (like US), but it does cut down on much of the noise so that the system administrator can focus on actual hack attacks.

In the crs-setup.conf file I block the problematic TLDs:

SecAction \
 "id:[your rule ID may vary!],\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.high_risk_country_codes=RU CN RO UA ID YU LT EG BG TR PK MY AF IQ IR KP SA SC SY VA AE IL IN'"
 

And for spam control, in my postfix main.cf file, my configuration for the smtpd_sender_restrictions line looks like this (the last part is what is relevant by adding a PCRE list of domains):

smtpd_sender_restrictions  = permit_mynetworks, permit_sasl_authenticated, reject_unauthenticated_sender_login_mismatch, check_sender_access pcre:/etc/postfix/reject_domains

And in the /etc/postfix/reject_domains file I block each of the domains that are most likely to produce spam:

/\.xyz$/ REJECT We reject all .xyz domains due to spam
 

Note: Since the /etc/postfix/reject_domains file is not hashed, there's no need to run the postmap command after changes (unlike helo_access and other hashed files).

Once your Postfix changes are complete, you need to restart or reload Postfix with a command similar to:

sudo service postfix reload

Since Postfix is technically an MTA, you shouldn't really use it as your primary spam-fighting solution. I use many other tools such as SpamAssassin as Bayesian milters to fight spam, but you can head much of it off from the start by blocking domains and TLDs that are problematic for you!