It really depends on how paranoid you want to be. Removing their SSH keys and changing the root password will prevent casual snooping by rack-monkeys. If they need to change any hardware other than a drive they'll have to shut down the machine and you'll probably notice the gap in uptime. Keeping crucial data encrypted at rest will likely prevent pulling a mirrored drive and copying it. If that isn't enough security then you'll need to colocate and physically lock down the hardware yourself.
Text is wonderful, but note that the one keyword not found in this text is 'parse'. How much extra work is generated writing parers for text that would have been so much easier to deal with if it had just been generated in a structured binary format? You still get the pleasure of designing a new wheel with every format.
It's not about writing a parser, it's about figuring out what the content is supposed to be in the first place. With plain text you can see what's a number, what's a string, what's an expression, etc... I'd rather try to figure out how to parse "2 7 + 3 -" than see a file with
If it were easy to see what's a number and whats a string, type confusions a la YAML's fun wouldn't exist:
Is "no" a string, a country, a boolean?
Is 0 a boolean, a number, or char[48]?
This is specifically an area that "text" is quite bad and is the source of much woe. Your provided example would be parsed by most parsers today as a string, since it mixes spaces (non-numeric) and surrounds it with quotes.
In fact, given well-defined binary, it is rather simpler to turn it into "text" than the reverse. It seems like you've forgotten that "0x32 0x20 0x37 0x20 0x2A..." is literally what is in that file you would view. Plain text is, after all, just one example of a binary format.
This misunderstands what I was trying to get across. The string is the file content, not a string in a file (so: a short snippet of source code), in text format; what followed was (an attempt at) a plausible binary tokenization.
I agree that the string "no" is ambiguous (though infamous as a somewhat pathological case), but at least it can be seen in context without having to spelunk a binary definition.
Unless it's a different encoding from 50 years ago so you can't figure out how to parse 27+3
And you can easily make the opposite example: you'd rather figure out that .ext means format X that you already have an app for, where date is unambiguous courtesy of the format designers rather that make some common mistake trying to figure out where month is in 5/6/79
Edit: for those unfamiliar with the intricacies of SMTP, the first three lines sent are HELO, MAIL FROM:, and RCPT TO:. The From: address that you see in your mail client is actually another header that gets sent once the server provisionally accepts the message based on the first three headers. It's the difference between the return address on the envelope of a paper letter, and an address printed on the letterhead of the actual letter.
I recently tried bouncing mail during the header phase when DMARC didn't align, but it rejected more legit emails than SPAM. Most of the junk we've been getting passes DMARC and has an unsubscribe link.
> Most of the junk we've been getting passes DMARC and has an unsubscribe link.
You say that like its a problem.. its a formidable solution!
Has worked for me for many years now: Just fail2ban-style block (groups of) relays that attempt to send an unsubscribe-link destined for a mailbox that never ever subscribes to anything. Those malicious-compliance folks add these unsubscribe links everywhere because they determined that its a cheap method for reducing blocks. That makes them reliably stand out whenever they hit strictly human-to-human mailboxes that simply never have any reason to "unsubscribe". Its like a honeypot, and all it took was a strict policy about what a tiny fraction of mailboxes can and cannot be used for.
I'll have to ponder the method you describe. I know I could implement that on my own mailboxes and some automated endpoints, but not sure how that would work for other users on our domain.
Your suitable mailboxes will be very distinguishable by grepping for past triggers per original/unexpanded recipient. Most older destinations would have thousands of non-spam hits, the suitable ones will have 0-3 with an obvious quick fix. For me it was department-level to-whom-it-may-concern aliases: All the mailing lists and web service signups use the appropriate department/employee name, yet much of the incoming mail sent by humans - and: much of the mailing-list-impostors - comes through one of the aliases that merely clarify the topic/location but end up in the same boxes anyway.
DMARC doesn't really do much to prevent general spam. It prevents spoofing the from address, which provides some protection against phishing, but if the email is from the domain it claims to be, it can pass DMARC whether or not it is spam.
DMARC is for authenticating the sender, not filtering spam.
Spammers are quite proficient at using authentication, whereas legitimate users are stuck in the 2000s wondering why their forwards don't work anymore.
The big changes I've seen over my lifetime have been tooling and materials. I remember when framers did everything with a hammer, a circular saw, and a speed-square. Now we have nail guns and cordless impact drivers and miter saws. Fiberglass batt insulation is still a thing, but now there's also urethane spray foam. We have engineered beams and OSB sheathing pre-coated with a moisture barrier. There's a lot of things that all add up to better performance and less manual labor.
