One of my old physical servers finally died and I had to move the Subversion server to a new machine.  This resulted in the ssh host key changing, so if you get this error:

svn: E170013: Commit failed (details follow)
svn: E170013: Unable to connect to a repository at URL 'svn+ssh://svn@svn.limedaley.com/...'
svn: E210002: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file.
svn: E210002: Network connection closed unexpectedly

You'll need to run these commands to fix it:

ssh svn@svn.limedaley.com

Which will output "Warning: Possible DNS spoofing detected", and that is okay (note, that this error protects you from getting spied on so normally if you see this error, it means someone has hacked your network and/or DNS server, and so you normally don't want to follow these instructions, but in this case, it is expected.

In the long warning message, it should say something like:

ssh-keygen -f "/home/jondaley/.ssh/known_hosts" -R "svn.limedaley.com"

And you can manually run that command, or edit out the line that has the host key for svn.limedaley.com.

Then you can run your svn command like normal.  It should warn you that you are connecting to an unknown host and ask you to verify the fingerprint, which is:

The authenticity of host 'svn.limedaley.com (74.118.138.75)' can't be established.
ECDSA key fingerprint is SHA256:YyG0ezKHFS61i8JC0AyK5HXXZAFyGEyLgrZh29kqDeY.

And as long as that matches, you are all set!

I recently noticed that unblocked spams had gone up and that our mail server was getting error reports from a spam checking service konwn as "validity". Which is yet another list that tries to promote good internet behavior by listing good and bad actors.  However, reportedly, they have changed their free service layer from a reasonable number of hits down to 13 per hour.  This causes three rules to be hit in the default configuration of SpamAssassin to be hit: RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, and RCVD_IN_VALIDITY_SAFE, two of which are negative rules (negative means a good email), and thus emails that would have otherwise been tagged as spam were now being marked good.