The cryptography is standard AES-128 in OCB3 mode. It's been around long enough, and has had enough security scrutiny to at least discover a few minor DoS vulnerabilities, that it isn't entirely unreviewed.
It's client-side, so works even if the remote system is totally hung and did not clearly disconnect.
For example, running `systemctl suspend` will not terminate active SSH connections before putting the destination machine into a sleep state, and thus Ctrl+C (which isn't processed by SSH) will do nothing until the remote host is woken up by some mechanism.
True. But if you asked me what Route 53 does I wouldn’t be able to tell you without checking. Cloud DNS, OTOH,
is a pretty descriptive product name. I’m not saying you disagree, just reiterating the point that AWS naming is just a little too silly and clever for its own good ;)
The vast minority of utilities in the United States, by number of customers served, are investor-owned; publicly-owned and co-operative utilities only cover 50m people.[1]
Theoretically, the grid is supervised by the California Public Utilities Commission, which has wide latitude to set standards and regulations for PG&E and others. The Public Utility Code is the highest law in the state of California[2], so IMHO a large part of the blame for PG&E's failures fall on CPUC's failed oversight[3][4]
When I self-hosted email I used Spamhaus to as a block list and Spam Assassin to filter the rest. Gmail users made up the biggest chunk of spam that got through but it was never from Google/Gmail domains, it was almost always from a Gmail user with a custom domain.
I wonder if SPF / DKIM / DMARC have improved this.
Google domains doesnt make it quite as easy as other hosting providers, and to be honest if they were super serious about email abuse they should encourage every domain to use it.
There is a marketing company that is constantly adding me to new spammy lists they are creating. They are using AWS SES / SendGrid / other reputable providers.
The emails all pass SPF/DKIM/DMARC and filing abuse reports seems to get me taken off the list I complained about but I quickly get added to a different one.
I am this close to auto-blocking anything from these large providers and switching to allow-listing the legitimate domains that can send me e-mail.
I feel this. Because of a Google Group I briefly followed one of my email addresses got incorrectly associated with my Kickstarter account on some marketing list somewhere and gets added to so much "legitimate" marketing lists for fly-by-night Kickstarters. It's really frustrating and the accident of it being a "wrong" email at least makes it somewhat easier to manage (though I worry if I ignore that mailbox too much I may miss the rare once in a few years important email to it).
For a while MailChimp was the only one of the major/reputable providers I trusted the Unsubscribe button on because they had a "I did not sign up for this button" that supposedly dinged the mailing list owner's reputation with them, but more than that would supposedly make it a bit tougher for the next mailing list to just dump that email in without a verification step or a cool off period.
That button disappeared recently and I guess MailChimp no longer cares either. Shame.
> For a while MailChimp was the only one of the major/reputable providers I trusted the Unsubscribe button on
Mailchimp is up there with Marketo and Sendgrid for me. Getting unsubscribed from something I never opted into… well I still haven't figured out how to do that.
SPF does not protect you from a pown smtp server (neither DKIM/DMARC, then SPF is "enough" for self-hosted smtp servers, and does force you to use DNS (the SMTP protocol works without DNS).
Spammers use vpn nowadays. This make these spammhaus like services useless. They change IPs every week.
Most mail protection models against spam don't work.
I have an idea of a method that could help reduce spam and undesirable mails. It would be free for non-spammers and spammers would pay.
The problem is that I'm not sure if people would be ready to adopt it. There is also many different ways to execute, and I'm not sure which one to pick.
Then the spam is coming from the email servers which are used to relay that spam. Headers can be forged, so the source before the spam server can't be trusted as real.
With Sonic I have to use their servers for outbound stuff since they block outbound SMTP without a static IP (and they don't offer static IPs with fiber). It's a price I'm willing to pay since I typically don't see false positives (and ye I check my logs periodically) with Spamhaus.
Unfortunately I've moved to Proton and the increase in spam is pretty damn frustrating.
Spamhaus is blocking by IP which can be an smtp server or a client. The SMTP protocol does not allow to distinguish a sending SMTP server from a client.
By using a VPN, you "randomize" the IP address and thus make spamhaus and equivalent services useless. I created my own IP blacklist and tracked it.
The only method I found to filter my spammers is to reject mails from hosts without a name. This eliminated 80% of spam, but it won't last long.
Which doesn't even make sense, given it was abolished by Nazi Germany "when Hitler's distaste for the supposedly "Jewish-influenced" script saw it officially discontinued"
If you have teams in Israel, you at least can cheat a bit on Sunday v.s Friday.
And having at least one daytime rotation agree that "well, you're expected to be on-call during business hours on Saturday" isn't nearly as crazy as "you can't relax at any time during the weekend".
Or just, like... allow people to have a Sun/Mon weekend (or Mon/Tue, or whatever) instead of Sat/Sun.
There are plenty of people who would be happy with that and plenty more who would accept that arrangement if it came with extra compensation.
Instead, particularly at big companies, people get hired with some generic comp. package and then it's luck of the draw whether you have an on-call rotation or not, and if you do whether it's onerous or not.
The cryptography is standard AES-128 in OCB3 mode. It's been around long enough, and has had enough security scrutiny to at least discover a few minor DoS vulnerabilities, that it isn't entirely unreviewed.
For the cipher itself, see https://en.wikipedia.org/wiki/OCB_mode#Attacks