When my catch-all email intercepted a Stripe verification and restaurant reservation for a non-existent address, every pattern screamed “fraud.” The timing was suspicious, the authentication perfect, the setup textbook. But here’s the problem with security analysis: when you’re looking for attacks, everything looks like an attack. This is probably just someone who can’t type on a phone keyboard – and that’s exactly the kind of assumption that security-minded people need to challenge in themselves.
This morning I received two emails within 30 seconds of each other, both addressed to [email protected] – an address that doesn’t exist. One was a Stripe Link verification request. The other was a reservation confirmation for two people at Garfish Manly in Sydney for tomorrow afternoon.
My first instinct was: this is obviously fraud. Someone’s running an automated script to test stolen credit cards and book fake reservations. The timing was too perfect, the email address too generic, and the whole thing felt like textbook reservation fraud.
I was wrong. Or at least, probably wrong.
The Technical Facts
Both emails passed every authentication check:
SPF: PASS
DKIM: PASS
DMARC: PASS (p=reject - the strictest policy)
Origin: Amazon SES (legitimate infrastructure)These weren’t phishing attempts. Stripe and SevenRooms actually sent these emails. Someone really did initiate a Stripe Link verification and book a restaurant reservation using [email protected].
The Stripe email came from [email protected] at 06:51:48 UTC, sent via their standard Amazon SES infrastructure with proper DKIM signatures. The SevenRooms email arrived 30 seconds later from message.sevenrooms.com, also properly authenticated. The reservation was for “Erika Chesworth,” two people, Saturday lunch service.
Why I Initially Called It Fraud
The pattern seemed obvious: automated attack targeting restaurants with fake reservations, using non-existent email addresses to avoid detection. The 30-second gap between emails suggested a script moving through a checkout flow. The choice of farm@ as an email prefix felt like dictionary-attack territory – generic enough to be plausible, specific enough to avoid immediate suspicion.
Plus, I run a catch-all email system on littlebig.co precisely because I want to see what hits my domain. When you operate this way, you develop pattern recognition for abuse. This looked like abuse.
Why I’m Probably Wrong
Because “[email protected]” is almost certainly a typo.
Someone booking a restaurant reservation on their phone probably meant to type [email protected] or [email protected] or any number of common email providers. Mobile autocomplete, muscle memory, or simple inattention led them to littlebig.co instead. It happens.
The 30-second gap between emails? That’s not suspicious – that’s exactly what a normal checkout flow looks like. Enter your payment details (Stripe sends verification), complete the booking (restaurant sends confirmation). Perfectly ordinary.
The reservation itself is modest: two people for a Saturday lunch. If you’re running reservation fraud at scale, you don’t book 2-person lunch slots. You book high-value dinner reservations for large parties to maximize the no-show penalty revenue or test higher credit limits.
The Real Problem
Here’s what actually matters: if this is a legitimate reservation, “Erika Chesworth” thinks she has a confirmed booking but never received the confirmation email. She’ll show up tomorrow expecting a table, possibly without the reservation details, and the restaurant may or may not have her in their system properly.
If it’s fraud, the restaurant loses a lunch slot and potentially processes a chargeback.
Either way, somebody needs to know.
What I’m Actually Doing
I’m sending Garfish Manly a simple email explaining the situation: this address doesn’t exist, I received the confirmation, something’s wrong. Not “this is definitely fraud” but “you should probably verify this directly with the guest.”
If it’s a typo, they can call Erika and get a working email address. If it’s fraud, they’re alerted before the no-show happens. Win-win.
What This Teaches About Security Theater
My immediate jump to “this is fraud” illustrates a problem with security analysis: when you’re looking for attacks, everything looks like an attack.
The reality is that most anomalies in your logs aren’t sophisticated threats. They’re typos, misconfigured systems, users who don’t understand how email works, or automated scanners doing routine reconnaissance that will never escalate to actual exploitation.
The trick is maintaining enough skepticism to investigate without enough paranoia to waste time on ghosts. I run Wazuh SIEM, CrowdSec, and monitor twenty WordPress installations precisely because I want to know when something strange happens. But knowing something strange happened doesn’t automatically mean you know what it means.
The Catch-All Decision
Running a catch-all email configuration on your business domain is a choice with tradeoffs. You gain visibility into what’s hitting your infrastructure – typos, probes, automated systems trying to reach standard addresses. You lose the natural filtering that comes from only receiving mail to addresses that actually exist.
For me, the visibility is worth it. I want to know when someone mistypes my domain or when automated systems are testing addresses. But I also have to accept that most of what the catch-all catches is noise, and distinguishing signal from noise requires actual analysis.
In this case, I almost let pattern recognition override common sense. “Farm@” plus timing plus my security mindset nearly convinced me this was definitely fraud when it’s probably just someone who can’t type on a phone keyboard.
Technical Reference
If you’re investigating similar incidents, here’s what to check:
Authentication headers: SPF, DKIM, and DMARC will tell you if the email actually came from who it claims. All three should pass for legitimate services. In this case, both Stripe and SevenRooms passed cleanly.
Timing analysis: Consider whether the timing makes sense for legitimate use. 30 seconds between payment verification and booking confirmation is normal checkout flow, not necessarily automation.
Content analysis: Look at what was actually booked. High-value reservations with large parties are more suspicious than modest bookings.
Infrastructure patterns: Check if your logs show similar attempts to other non-existent addresses. A single incident could be a typo. Multiple systematically-generated addresses suggest reconnaissance or attack.
The base rate: Most weird things that happen aren’t attacks. They’re mistakes. Start with that assumption and look for evidence that contradicts it, not the other way around.
I’ll update this if Garfish Manly gets back to me with what actually happened. For now, consider it a reminder that security analysis requires actual thinking, not just pattern matching.
Update [pending]: Awaiting response from restaurant to confirm whether this was typo or fraud.
