Who should people use instead? I switched to USAA because of their good reputation after bad experiences.
I’ve heard good things about Farmers and USAA. Never anything positive about another.
17,114 karma · joined September 26, 2014
Carolina Code Conference https://carolina.codes
Carolina Code Cast (tech podcast) https://blog.carolina.codes/podcast
I’ve heard good things about Farmers and USAA. Never anything positive about another.
Say I decide to open a pirate themed gym called Slimmer Ye Timbers and buy the domain slimmeryetimbers.com.
If I want to setup a website, I will go to a hosting company, set something up, go into the DNS and point a couple of records for the top level domain and the www subdomain to the hosting company.
If I want to receive email sent to argh@slimmeryetimbers.com I need to setup a mail server (Google, Outlook, web host may offer one, could setup an open source one, etc) and once it's setup I go to the DNS to point an MX record at the mail server.
So far, if people try to lookup my website or send an email TO me everything is pretty straightforward.
Now, if I want to send email that says it's FROM argh@slimmeryetimers.com is where things get weird. Because I don't have to do anything.
Any server, anywhere can just do it and every mail server that receives a message saying it's from that domain has to try to figure out if it really is or isn't. This is where antispam rules come in. Without DMARC, SPF & DKIM in place receiving mail servers will build up trust in different IP addresses, typically from vendors who go out of their way to prevent email abuse specifically to protect the reputation of those IP addresses. The receiving mail server my do a reverse DNS lookup to see if the hostname matched. They might see if the MX server used by domain is the same server sending the message along with a ton of other algorithmic hoops to make a good judgement. Even with DMARC, SPF and DKIM in place they may still use those rules.
DMARC, when strictly enforced with p=reject, let's you signal the receiving mail server that all mail claiming to be from your domain can be validated and if it can't be validated that message isn't from you and can be discarded. All that DMARC does is say that if you receive a message from this domain, it should pass either SPF OR DKIM for this domain as well.
So let's say, for example that I'm using both Google Workspace and Sendgrid for email for slimmeryetimbers.com. I'll setup Gmail for my main professional email for myself and my staff and I'll setup Sendgrid to send email from the website (responses to contact forms, etc).
For SPF it can be pretty simple, a single TXT record:
"v=spf1 include:_spf.google.com include:sendgrid.net ~all"
Both Google and Sendgrid publish DNS records with the IP address of their servers and keep them up to date, so adding that include is all that we have to do.
DKIM is more complicated. Google will provide you with a DKIM record to put under a subdomain that includes the public DKIM key. Once they have verified it's setup, they will sign every email sent from your account with the private key that only they know. When a receiving server gets the message they will see that the message has been signed by DKIM and it will point to the subdomain where the public key was stored. By following the instructions from the signature in the email and using the public key, they can verify that the message was actually signed by the private key and hasn't been tampered with.
If we then setup Sendgrid they will give you their own DNS records for DKIM that work for their own private key. In both of these situations, we never get our hands on the private key because we are using a 3rd party service that doesn't disclose it. Sendgrid issues 2 CNAME records that point to DKIM public key records on their DNS so that they can control them. They'll send out messages signed with one private key and then later switch to a different private key while the original key and it's public record is changed, transparently without you having to deal with it.
If we were to setup our own mail servers, we would have access to it though. It's also entirely possible for somebody with access at an email company to go steal the private keys of their customers and sell them, or just use them. It's possible for those services or our mail servers to be hacked/compromised and the keys be stolen. Built in rotation process helps with this. It's the same reason that Let's Encrypt issues secure certificates that expire after 90 days (sometimes less). Just key rotation.
That was long but I hope it helps?
As a receiving mail server, they have no way of knowing how many different parties are legitimately sending email on behalf of your domain.
SPF is per domain. You setup a DNS record at the domain (or subdomain) level that lists all of the IPs (or a DNS reference to a list of those IPs) that are authorized to send email on your behalf...but, that breaks with mail forwarding and mailing lists.
SPF is much simpler, absolutely. DKIM requires a private key to sign outgoing messages from every mail server sending mail on your behalf.
2. This is a rather famous story about it happening.
https://www.wired.com/2012/10/dkim-vulnerability-widespread/
I have no idea how widespread the issue is today but I had to do some analysis on it when I worked for dmarcian ahead of the Anti-Phishing Working Group conference and we found that a significant percentage of email from known malicious IPs associated with reported phishing was passing DKIM. Key rotation removes the problem. Many services like ProtonMail and Sendgrid will set you up with 2 CNAME's for your DKIM keys so that they can rotate them for you automatically.
3. Domains send emails from multiple servers. Sometimes dedicated email servers, Google/Outlook, Sendgrid, email marketing tools, etc. A receiving system has no way to validate whether any of the tools sending email claiming to be from your domain are actually from your domain. The first time you look at a DMARC report for a domain that's been around for a while, you will typically see that 90% or more of the messages claiming to be from your domain weren't from you at all.
1. You have to set it up on every sending server. It's easier today but it wasn't always
2. You have to periodically rotate each of the keys that you setup because they can be cracked/stolen. Soon as somebody steals your key, they can impersonate anyone sending email from your domain.
3. Receiving email servers have no way of knowing if a message they received without a DKIM signature is supposed to include a DKIM signature, so simply not including one creates a scenario where receiving mail servers have to guess if the message was really from you.
When you use them together and have a DMARC policy that requires one of them or the other for successful delivery, it's the best current solution.
Between Tesla, SpaceX, X, Boring Co and Neuralink they probably want the capability internally for a lot of different applications.
If the whole data centers in space thing works out AND people keep protesting/blocking data center build outs on land SpaceX will eventually dominate the entire AI industry just based on escaping scarcity.
Might have to do something like that for a verse on the next Carolina Code Conference shirt. Been trying to figure out a good way to pull in cybersecurity.
Horizontal scaling for DB typically means distributing the write load across instances either via sharding or master-master. I could be wrong of course, but that’s how I read it.
MySQL is very good at master-master out of the box.
Nonissue.
The EC provides a failsafe by capping the max impact of a single state in the event of an anomaly.
In other words, you can’t talk about abolishing the EC without a national voter ID law.
Usually there will be one or two tables that grow at a dramatically faster rate than everything else and I have always found that those belong in a separate data store.
I believe you can do this with the pg-trickle extension.
2023 - Don't Stop Believing
https://github.com/brightball/carolina-code-conf-lyrical-cha...
2024 - Bohemian Rhapsody
https://github.com/brightball/carolina-code-conf-lyrical-cha...
2025 - All Star
https://github.com/brightball/carolina-code-conf-lyrical-cha...
You can see the final version of the shirt here.
https://blog.carolina.codes/i/148154944/youre-an-all-star
We're a little low on PR's this year unfortunately though. I don't know if it's all the AI or something else but we usually have about a dozen entries by now and we've only got 2 for some reason this year.
Spending is the only problem.
If we account for only these two things, it is catastrophic.
1. Interest on the debt when we don’t have a balanced budget to stop growing that debt will spiral out of control.
2. When any part of that spending which is creating inflation already must then increase to pay for the inflation that it is causing, we are circling the drain. That is a death spiral.
We need extreme, Javier Milei level cuts to the federal government.
This is basic economics.
Yes, excessive federal spending is bad.
2024 - $6.8 trillion in spending
$1.3 trillion Defense, $323 billion of which is veteran support (pensions, retirement, medicare, etc).
Discretionary spending is a misnomer that assumes all of the other spending levels just have to be maintained as is, are without fraud, run efficiently and impossible to reform.
Cut 20% across the board from every agency for starters (including Defense). That gets us back from $7.5 trillion to $6 trillion. Then do it again 2 years later and get us back to $4.8 trillion. Then do it again.
States have limited budgets and must balance it all the time. Companies as well. There's no reason the federal government cannot do exactly the same thing.
"Wealthy people" didn't cause the US government to spend an extra $3.5 trillion a year over a decade ago and this idea of raising taxes more on those people wouldn't even begin to address the spending problem.
The average federal budget from 2010 to 2020 was $4 trillion. This year it is $7.5 trillion. There's quite a lot to cut.