I use FDM for this. Appropriate parts of my “.fdm.conf”:

# Where the bad stuff goes.
action "spam" mbox "%h/Mail/spam"

# Some attachments indicate spam just by existing.
$bad_ext = "*.xlsm"
match attachment any-name "*.xlsm" action "spam"

# Run through spamassassin if not too large.
match size < 500K action rewrite "/usr/local/bin/spamc" continue

# If spamassassin thinks it's spam then good enough for me.
match "^X-Spam-Status: Yes" in headers action "spam"

Requires an actual hardware error. Almost all implementations, including all open source SSH implementations, check that the signature is valid thus preventing a cosmic ray induced bit flip from triggering this issue and any related issue.

What effect do hardware errors have on Ed25519?

RSA is fine. It isn’t like you will have to worry about the length of the keys for SSH.

Just get it working locally without TLS/ssl. You probably want to set this:

c2s_require_encryption = false

If you are hoping to talk to people outside your domain you will have to figure out what to do about server to server communications.

I am making a distinction between a rate limited login password (which would be secure with something like “Karma27!”) and a password that protects encrypted disk data (which would need to be something like “Swipe Stapling Mortally Eloquence Obliged”). It sounds like you are planing to just use the login password for encrypted disk data encryption, which in general won’t work as the sort of thing that people use in that case can be trivially cracked.

You can do some password stretching, but that only gets you a factor of thousands improvement.

If the attacker can attack your password hashes at full speed (they get access to the disk) then you would need a fairly hefty password or a random passphrase with a fair number of words in it. That fact can make the sort of protection you seem to be hoping for impractical in many cases.