> AWS designs and implements their foundational services holistically.

I’d say they implement their services circularly. The outage-inducing circular dependency between Dynamo and Route53 is not a “holistic” design.

SendGrid and their competitors are already the very definition of “sender pays” for email. “Sender pays” is how they make money. This isn’t a problem of monetary incentives.

The problem is that companies get their SendGrid credentials compromised via password re-use or phishing.

I mean the carrier pays the recipient , so Twilio and sendgrid bear some cost

They understood just fine. But because that cost passes through to the sendgrid customer, it wouldn't motivate sendgrid to stop enabling spam.

currently the costs are too low to affect policy. that's my point. and the recipients are making extremely high margins on ads, so they don't have much reason to push back, either.

For any reasonable email fee, sendgrid can continue passing it on to the customers and not care.

If you make the fee super high, then many email workflows completely break and sendgrid goes out of business.

I don't think there's a number where it does what you want and incentivizes sendgrid to be careful.

(And you might say to seek a middle ground, but I don't think there is one. My guess is that "too low for sendgrid to care much more about a couple percent of mail from hacked accounts" and "too high for sendgrid to still attract customers" probably overlap.)

spam volume is 10000x-1e6x higher rate, so even small fees would impact them much higher than legit senders.

These are the accounts of legit senders being coopted to send very targeted spam. I don't think you can distinguish it by volume, because the volume needed to make these schemes work is just a fraction of the basically-legitimate volume these services process.

The real bulk bulk spam is a different issue entirely.

It never was FIPS-approved and likely will never be. The wireguard protocol used by Tailscale uses ChaCha20 for encryption which is not FIPS approved.

Interesting. What is the FIPS version of wireguard?

> What is the FIPS version of wireguard?

IPsec or TLS-based overlays which use AES encryption and NIST-approved ECC curves or (gasp) RSA for key exchange and authentication. They generally suck in comparison with wireguard, which is a clean-sheet modern cryptographic protocol.

There are some forks that are not compatible with regular wireguard, for example from wolfssl. Or just classic mTLS.

We’re calling these organized criminals vendors now?

I can confirm terrible video quality on 1Gb/s Xfinity connection in Chicago area. The NFL streaming picture quality looks like RealPlayer on a 56kbps modem from 1998. The ball becomes invisible as soon as it is passed or kicked! Blocky and ghosting artifacts. Not a network issue, every other site/app working great, it’s simply Netflix falling over during a live event again.

For an opposite datapoint: I had no issues with either game that I noticed. Denver area.

You know you don’t have to give it permission to a whole zone right?

My DNS provider has per-record permissions, but you could delegate a subdomain even if your DNS provider lacks per-record permissions.

OCSP stapling adds two more signatures to the TLS handshake. Bad enough with RSA keys but post-quantum signatures are much larger. OCSP stapling was always a band-aid.

If the server must automatically reach out to retrieve a new OCSP response for stapling every 7 days, why not just get automatically a whole new certificate which is simpler and results in a lots less data on the wire for every TLS connection?

This is more about reputation than “custom domains”. I’ve had <realname>.com registered since 1996. Hosted at free Google Workspace account for 15+ years. They added SPF and then DKIM/DMARC as those thigs evolved. Never had spam reports in all that time; delivery is better than $dayjob’s 30-year-old domain.

Reputation is everything in email delivery.

I set all that stuff up for mine, and used a reputable mail server (FastMail), and even went through steps particular to Microsoft and Google. Google started accepting my emails, but my employer's Microsoft Exchange system kept sending my stuff to spam. How many other people would just not receive my stuff? It's impossible for me to know. If you want to reach out to strangers, any false positives will hurt you.

That might be from a Microsoft feature to prevent phishing that blocks display name spoofing. I get hit with that when I email from my personal to work email… the display name portion of the FROM address matches my work so it trips this filter.

Obviously they can only do this for unique-enough names and so this filtering could never work for “Joe Miller” but it does stop the dozens of phishes we see per day that are FROM our CEO’s first and last name but with a Gmail email address.

I don't think it's anti-phishing. If it is, then it's a broken rule. I have registered FastMail as my mail server properly with my DNS (MX record, I think) and also done the other authentication stuff. This is not a case of merely setting the FROM field, as many people do. You can set the FROM field of a message to anything if your mail server allows this. The receiver might reject this, but it is/was a common way to configure your mail client in the past because of stuff like email forwarding. Lots of people use 3rd party mail providers whose servers are not under the same domain as the mail being served. I think most people with custom domains do not run their own mail servers, and thus point their MX entries at a 3rd party mail provider just like I do.

I don't know why this stuff would be rejected. I went through several debugging steps online and didn't get anywhere with it. Every tool said I had set it up correctly.

> Of course I still bill the time it would have taken me but for a professional it can be a great improvement.

Isn’t this basically the definition of fraud?