It’s time to turn the opt-out model of email on its head to fix it.

I wanted another Apple HomePod speaker for our home. Found it online for in-store pickup at my local Electronic Express. I added it to the cart, checked out as a guest, and forgot about it.

A couple of years later, I received a spam message addressed to: electronicexpress-0921@k3bert.net. I was confused; I didn’t create an account with them. Why am I receiving spam?

I looked up the address on Have I Been Pwned and found out that in Feb of 2023, Eye4Fraud, an online fraud protection system used during payment transactions, was breached and the data made available to hackers.

The forgotten email came back to life until I created an inbox rule to delete any messages sent to electronicexpress-0921@k3bert.net permanently. Opt-out.

And then there was the time I decided to sign up for updates to my Alma Mater, CU. I opted to receive alum emails at cualumni@k3bert.net related to the engineering school, from which I graduated.

I received my first few updates, but then there was a shift. It wasn’t just updates on the School of Engineering; the emails were now boosters for the Alumni Association and covered other clubs and associations within the university. And then, to make matters worse, someone from the Alumni Association started calling. Their whole job is traveling around meeting alumni to “catch up,” which I’m fairly sure means asking for money.

I tried to opt-out through my mail preferences, but the emails and calls kept coming in.

I created an inbox rule to delete any messages sent to cualumni@k3bert.net permanently. Opt-out and blocked the phone number.

And then there was Verizon and Heritage Bank and Trust. For a few years, we did business with these companies until we stopped and permanently closed our accounts. Or at least we thought.

But, for months after closing the accounts, we still received monthly statements of our accounts. Confused, I called several times, explaining the accounts were closed and that there was no need to send us statements anymore. They agreed. The emails kept coming.

I created an inbox rule to delete any message sent to their aliases permanently. Opt-out.

Today, AI agents are augmenting and supercharging inbox rules and, if you decide, will take over your entire inbox for you. But what’s the difference between an AI agent managing your inbox for you versus you manually managing the rules? Other than out of sight, out of mind, it’s still opt-out.

In the immortal words of Buzz Lightyear: “This isn’t flying, it’s falling with style.”

And personally, I’m not all that comfortable with an AI agent crawling through my inbox and noticing who I shop or bank with, what credit cards I have, when I received my tax return, or when I pay my utility bills. This is all personal information that I would like to keep personal.

For years, I’ve been trying to manage the 1,390 unread messages like most everyone else. Giving out my email, receiving unwanted messages, trying to opt-out, giving up, and waving the white flag.

And now, I’m tinkering. I’ve started an experiment with my personal k3bert.net domain that, if successful, I’ll transition the domain my wife and I share for all our household accounts.

The experiment started with a declaration of email bankruptcy, archiving off all my messages into cold storage. And a gate slotted in front of the domain that inspects all senders and aliases, comparing them to an allowed list. When a new email arrives and the sender is not in the allowed list, I have a choice to allow the email to land in my inbox; in other words, I opt-in.

And then something caught my attention. The green highlight text I chose for the site was difficult to read.

I have good color perception. In fact, Charlotte has crowned me the official paint color picker when it comes to decorating our house. So, I figured if the text was difficult for me to read, the roughly 8% of men with red-green color vision deficiency would struggle to read it also.

That wasn’t ok with me.

I was aware of the accessibility guidelines published by the Web Content Accessibility Guidelines (WCAG), but never had to worry about building with them. So I was surprised when I handed the problem off to my AI agent, and it threw up a sample page showing that indeed, the emerald-600 (hex #059669) green color I selected for the website failed the standard.

Standard? What standard? Up until now, my choice of colors was always based on taste and if it reads fine, ship it. I had no idea that the standard specified a way to calculate the contrast and grade it as a means to quantify accessibility usage of your application.

Every color has a computable relative luminance, which is a fancier and more accurate way of saying “how bright it actually reads to the eye.” Take two colors, compare their luminance, and you get a contrast ratio. Identical colors give you 1:1, invisible against themselves. Pure black on pure white gives you 21:1, the ceiling. Everything else falls somewhere in between, and the formula gives the same answer every time, for every viewer, regardless of taste.

My green, emerald-600, measured 3.77:1 against white. WCAG’s baseline standard for normal text is AA, and AA requires 4.5:1. My “fine, it’s just a light green” accent color was failing the accessibility standard I didn’t know existed.

There are two levels worth knowing; AA is the baseline most sites are expected to hit: 4.5:1 for normal text, 3:1 for large text (think 18-point-plus, or bold at 14-point-plus). AAA is the stricter tier, not usually a legal requirement but the one that gives you real margin instead of a bare pass: 7:1 for normal text, 4.5:1 for large. My original green wasn’t even clearing the low bar.

I went with the recommended emerald-800 (hex #065f46), a 7.68:1 ratio. Not a bare pass over the AA line, but clear of AAA too, with real margin to spare.

Because the color lived in one config token instead of being copy-pasted into forty places, changing it fixed the accent color across the entire app in one shot: CSS, every transactional email, account and billing pages, badges. All of it, except three admin-only internal tools I left alone on purpose, because nobody outside my team ever sees those.

The part I want to hand you isn’t the story. It’s that this is checkable, right now, on whatever you’re running, without asking anyone’s opinion:

1. Chrome DevTools — inspect any text, click the color swatch next to color in the styles panel, and it shows you the live ratio plus AA/AAA pass or fail, along with a suggested color that would pass. Fastest option, already installed.

2. WebAIM Contrast Checker (webaim.org/resources/contrastchecker) — paste in two hex codes, get the ratio and pass/fail for both normal and large text. It’s the tool most accessibility writeups point to first.

3. Lighthouse (also built into Chrome DevTools) — audits a whole page at once instead of one pair of colors at a time, so it’ll surface every low-contrast spot you didn’t think to check.

4. An AI coding assistant — ask it to build you a side-by-side comparison tool for your candidate colors, with real computed ratios. It’s not a shortcut around the standard; it’s a fast way to see the standard applied to your actual palette, which is exactly what got me here.

You already have a website, an app, a newsletter template, something with text on a background. Open DevTools, click your accent color, and read the number. If it says fail, you now know something concrete instead of something you assumed.

That’s what happened to me today.

“Hey Kevin, I signed up for your service, but I can’t login. Here’s my email address I’m trying to log in with and the device/browser I’m using. Can you help?”

I had 10 minutes before Charlotte and I were to head out for an appointment, so the pressure was on.

Check the logs, yep, there were the three login attempts made. But no indication of an error in the process nor that they received the message saying the magic link the app sent them to failed.

This was going to require intuition and an educated guess.

The difference in the time that the token was created and the time it was used was only a dozen seconds. That seems quick, too quick.

An AI prompt later, the working theory was developed. Somehow, the token for the magic link was already used before my friend could click the link in the email. But, why?

AI had an idea. I didn’t, this was outside of any experience level. I’ve been around a lot of systems in my career, but authentication and authorization mechanisms was an area I didn’t spend a lot of time in.

The most likely cause was that an email security scanner/pre-fetch was loading the link in the email and because the way the /auth end point was written, it was validating the token with the pre-fetch which in turn told the system that the token was valid, and no longer needed and discarded.

That all happened between the email being delivered and the time my friend clicked the link. When they clicked the link, they received the unfriendly message that they couldn’t login.

And to add insult to injury, there was no way in the app for them to reach out and ask for assistance. Luckily, they had my number.

This was the theory, it was easily tested and confirmed.

The fix is simple, don’t validate the token when the /auth end point is called. Instead, put an intermediary step requiring the user to click the link in the email, load a new page with another button to select to finish the login process.

Yes, the solution adds a bit of friction to the process, there’s an extra click now. But, it eliminates any pre-fetch or inadvertent previewing of the page assuring that the token will work when the user intends it to work.

So, the embarrassment is real, I have no way of knowing how many other people have had the issue, more than I’m willing to admit to b/c I can see the similar usage patterns.

The embarrassment was replaced with gratitude quickly b/c someone took the time to say, something wasn’t right and brought it to my attention.

This isn’t about not trusting what AI builds. That’s too easy, and it sidesteps the real responsibility. I understood the design. What I didn’t have was the experience to know there was a gap in it. And building alone means there’s no one else around to catch what you don’t know to look for.

The counter to that is building a system that expects surprises and handles them gracefully. For me, that means an easy way for someone to reach me when something breaks, and auditing every critical process that could stop a user dead and hardening those first.

What tips or techniques do you build with to handle the unexpected surprises that will inevitably hit your system?