Coder Legion - Recent posts tagged emailsecurity

@fuck.it - email with attitude

Tue, 13 Oct 2026 20:35:25 +0000

fuck.it is invite-only email for people who want a memorable address without becoming the product.
We built fuck.it around a simple idea: email should be something you pay for directly, not something subsidized by advertising, tracking or selling access to your data.
Every account gets an fuck.it email address with webmail plus IMAP and SMTP access so it works with standard email clients.

What you get

No advertising
No tracking pixels
No selling user data
Invite-only registration
IMAP and SMTP support
Webmail
Calendar, contacts and tasks
Encrypted connections
German-hosted infrastructure
Multiple storage plans up to 1 TB

Why invite-only?
Open signup attracts bots, spammers and scammers. That eventually hurts everyone on the platform through abuse, reputation damage and worse deliverability.
fuck.it deliberately avoids the free-for-all model. New users need an invitation before they can create an account.

Who is it for?
People who care about privacy, independence and having an email address nobody forgets.
It is not trying to replace every productivity platform on earth. It is email with attitude, built around a straightforward paid relationship between the service and the user.
Website: https://fuck.it

Is Paying for Email Worth It? What Your Money Actually Buys

Tue, 13 Oct 2026 20:29:52 +0000

"If you're not paying for the product, you are the product."

It's a great line. It's also doing a lot of work for people selling things, including us. So let's take it apart properly: what free email actually costs you, what paying actually buys and where even we think paying is the wrong answer.

We sell paid email. Read accordingly. We've still tried to write the version we'd want to read before spending money.

Somebody pays for every inbox. The only question is who and how.

TL;DR

Somebody pays for every inbox. The only question is who, and what they want in return.
Mainstream free mail runs partly on advertising and the data profile that makes it work. Gmail, Outlook, Yahoo, GMX, mail.com: somebody other than you is helping pay the bill.
The ad-free free tiers are paid for too, by the subscribers of the same company. Which rather makes the point.
Inbox data has been sold. Yahoo and AOL scanned more than 200 million inboxes for commercial advertising data, and free email apps have built six-figure datasets from what their users received and bought.
Your inbox is extraordinarily valuable data and AI makes it more useful than ever. What governs its use is a policy, not an architecture, and the settings are confusing enough that even security researchers got them wrong in public.
Email services simply end. Providers have been shutting down and offloading mailbox products for years, and a mailbox nobody pays for directly is the easiest kind to cut.
Paying puts you and the provider on the same side. Your subscription is the revenue, so the product only has to do one job.
What money doesn't buy: immunity from the law, guaranteed delivery, encryption once your message reaches Gmail, or protection from your own mistakes.
The one thing paying doesn't fix: the address still sits on somebody else's domain. Only your own domain changes that.

Somebody Pays for Every Inbox

Running mail is not free. Servers, storage, spam filtering, abuse handling, deliverability work, engineers: all of it costs money every month, for every mailbox, forever. Nobody absorbs that out of generosity.

So when an inbox costs you nothing, the money is coming from somewhere else, and that somewhere decides what the product becomes.

For mainstream free mail, advertising is part of the economics. Gmail, Outlook.com, Yahoo, GMX and mail.com all show advertising in or around their free email products. Microsoft states plainly that free Outlook is supported by ads. GMX says advertising revenue finances its free service. The targeting models differ, and Google says Gmail ads are based on your wider activity rather than your messages. But in every case somebody other than the person reading the mail is helping pay the bill.

For the ad-free free tiers, the answer is other customers. Proton and Tuta give away a limited free account with no ads and real encryption, and they can do it because their paying subscribers cover the cost. Those free tiers are an argument for paid email, not against it. They exist because somebody pays.

Which leaves one model where the person paying and the person using the inbox are the same: you pay, and the only thing the provider has to get right is your mail.

That's it. That's the entire case for paid email, and everything below is detail.

What Actually Happens to Free Email

Let's be precise, because the vague version is easy to dismiss.

Gmail is the interesting case, because the easy accusation is out of date and the real problem is worse.

Google stopped using message content for ad personalization in 2017. It says it does not use Gmail content to train its Gemini models, and it has repeated that denial every time the claim resurfaces.

Now look at what happened in November 2025. A post claiming Gmail had quietly opted everyone into AI training reached millions of people. A respected security firm wrote it up, then published a correction the next day admitting it had confused Gmail's long-standing smart features with generative model training. Google said it had changed nobody's settings. A proposed class action was filed in California alleging Gemini got access to Gmail, Chat and Meet without proper consent, which remains an allegation rather than a finding.

Here's the part that should bother you regardless of who was right. The controls live in several places and Google documents three separate categories of them. Switching them off also removes things like inbox categorization, Smart Compose and summary cards, so the convenient features and the data access share the same switches. And when professional security researchers looked at the interface and couldn't agree on what it did, several hundred million ordinary users had no chance at all.

That's the actual condition of free email in 2026. Not a confirmed conspiracy. Something more corrosive: a system so complicated that "we don't do that with your mail" has become unverifiable by the person whose mail it is.

Your inbox is extraordinarily valuable data. Contracts, purchases, appointments, arguments, relationships and years of natural-language correspondence, all in one searchable place. AI makes that data more useful than it has ever been.

Google says it does not use personal Gmail messages to train its foundational Gemini models. The concern is broader than training. Depending on your settings, your mail can already be processed to categorize messages, generate replies, summarize threads and power personalized features across Google's products.

"We don't use your mail to train our models" is an important promise. It's also a policy commitment layered over a system that can technically process the mail. The architecture hasn't made the question irrelevant, it has just moved it into a settings menu.

A subscription-funded inbox doesn't need to monetize that processing to pay for the mailbox. That's the difference.

Everyone Else Is in the Same Business

Microsoft. In January 2026 a bug let Microsoft 365 Copilot Chat read and summarize emails that users had explicitly labelled confidential, bypassing the data-loss-prevention rules designed to stop it. Microsoft confirmed it and fixed it. In the same period the European Parliament's IT department switched off built-in AI features on lawmakers' devices, citing the risk of confidential correspondence being uploaded to the cloud. Those were paying enterprise customers with compliance controls turned on. If the guardrails leak there, think about what the free consumer tier looks like.

Yahoo and AOL. The clearest documented case. In 2018 the Wall Street Journal reported more than 200 million inboxes being scanned for commercial data sold to advertisers, sorting people into categories like "frequent traveler" from their receipts and booking confirmations. Only mail from companies, Yahoo said, and you could opt out. It was on by default.

Free email apps. In 2020, Edison Mail, Cleanfox and Slice were all shown to build commercial products out of their users' inboxes: purchase data extracted, aggregated and sold to corporate clients, with one dataset reportedly priced above $100,000. Edison's homepage said "No Ads, Just Mail." Perfectly true. The money came from somewhere else.

And the one nobody warns you about: email services simply end. Telecoms and internet providers have been shutting down or offloading mailbox products for years. Turkcell, for example, says its Mailim service closes completely on 31 October 2026 and that stored data becomes inaccessible after 1 December.

The problem is sharpest when email is bundled into something else. If nobody is paying specifically for the mailbox, it's easy to treat as a cost centre when priorities change. It's always somebody's line item, and line items get cut.

What Free Actually Costs

Forget the monthly price. These are the costs that show up later.

Ads in the place you read your mail. Promotions tabs, sponsored messages, inline units dressed up as email. You've stopped noticing them, which is exactly what makes them valuable.

A profile that outlives the inbox. Even where message content isn't used for targeting, your activity feeds the same advertising machine that funds everything else. The inbox is one input among many.

Deletion for inactivity. Google may delete personal accounts after two years of inactivity. Microsoft closes accounts not signed into for two years. A free account expects you to keep proving you exist, and quietly takes your address back if you don't.

Suspension with no appeal. Automated systems close accounts, sometimes wrongly. When mail, photos and documents all sit behind one free account, a bad automated decision takes all three at once, and your route back is a web form.

Storage you share with everything else. On Gmail, 15 GB covers mail, Drive and Photos together. Fill it with holiday videos and your mail stops arriving.

Changes you don't get a vote on. Gmail is ending Send As for outside addresses in January 2027. Yahoo cut free storage. AI features arrive switched on and the opt-out takes your inbox categorization with it. The product serves a strategy and you're not part of it.

An inbox that keeps becoming something else. Mail was a product. Then a tab in an ecosystem. Now an AI surface. Nobody asked the people reading their mail whether they wanted any of it.

What Paying Actually Buys

Here's the part where paid providers usually get vague. Specifics:

An actual support relationship. Not automatically a good one. Plenty of paid providers have terrible support and some free services do better than they need to. But paying puts you on the other side of a relationship where losing you costs something, and that changes what happens when your account locks on a Friday afternoon.
A business model that points the same way you do. If the money comes from subscriptions, the incentive is to keep you subscribed. If it comes from advertising or ecosystem lock-in, the incentive is to keep you engaged and inside. Neither is sinister. They just produce different products over ten years.
No ads in your inbox. Worth stating plainly, with the caveat below that a couple of free providers manage this too.
Storage built around your account, not an advertising ecosystem. Your mailbox capacity isn't competing with Google Photos or a consumer cloud bundle.
An account that doesn't expire just because you're quiet. A paid mailbox generally isn't going to disappear because you haven't logged in for two years.
The practical features. Proper IMAP, POP3 and SMTP access, so any mail client works. Aliases. Decent attachment limits. Export that isn't a maze. These vary by provider, so check rather than assume.
A provider small enough to care about your complaint. Not always true, but more likely when your subscription is a visible fraction of revenue rather than a rounding error.

What Paying Does Not Buy

Any provider telling you otherwise is selling harder than we are.

It doesn't buy immunity from the law. A provider in any jurisdiction responds to valid legal orders. Paid doesn't mean untouchable, and anyone implying it does is lying to you.

It doesn't buy privacy from the person you're writing to. Send mail to a Gmail address and it lands on Google's servers under Google's rules. Encryption in transit protects the journey, not the destination.

It doesn't buy guaranteed delivery. No provider controls what the receiving server does. Anyone promising inbox placement is promising something they don't own.

It doesn't buy protection from phishing. Good filtering helps. A convincing message from a real address, properly authenticated, still gets through to everybody.

It doesn't automatically buy better security than free. Several free providers have excellent security. Price is not a proxy for engineering.

The Thing Nobody Selling You Email Wants to Mention

Here's the strongest argument against paying us, and against paying any provider for an address on their domain.

If your address is *Emails are not allowed*, you don't control the domain behind it. Google does.

But if your address is *Emails are not allowed*, you don't control that domain either. We do. If we go out of business, get bought by somebody terrible or simply decide to stop, you're moving addresses and telling four hundred accounts about it, exactly as you would be if Google shut Gmail down.

Paying changes the incentives. It doesn't change who holds the domain.

The only setup that genuinely puts your email address under your control is your own domain plus a provider you can replace. Then switching providers is a DNS change and nobody has to update anything. That's the real answer to "my email is infrastructure," and for a basic domain it can cost little more than ten or twenty euros a year, plus the discipline to never let the registration lapse.

It also isn't something we sell. We don't do custom domains, because the whole point of a fuck.it address is that it says fuck.it. If maximum portability is what you're after, we're the wrong shop and you should go buy a domain.

Credit Where It's Due

Two free tiers are worth naming, because pretending otherwise would be dishonest and you'd catch us at it.

Proton Mail and Tuta both offer free accounts with no ads and genuine encryption. Small storage, limited features, and both funded by the people paying for the full version. If budget is the binding constraint, they're a far better answer than an ad-supported inbox.

And Gmail, as a piece of software, is excellent. Best-in-class search, enormous app support, rock solid. We're not going to insult your intelligence by pretending it's badly built. The question was never whether it works. It's what it's for, and who it's for.

When Free Is Good Enough

Stay where you are if:

Email is a utility you think about twice a year.
Nothing load-bearing is attached to the address: no bank, no business, no clients.
The budget genuinely matters. A paid inbox is a luxury next to rent, and anyone implying otherwise is out of touch.
You're on one of the ad-free free tiers above and the storage limit doesn't bite.

When Paying Makes Sense

Your address is infrastructure. It's the recovery key for your bank, your password manager and a few hundred accounts. That deserves better than a free tier and an automated support queue.
You want out of an ecosystem. Separating your email from one company's account system is the first real step, and it's hard to do on a free tier run by that same company.
You need someone to answer. If a week without working email would cost you real money, buy a support channel.
You want the terms to stay still. Paid services change too, but they change with their customers in mind, because customers cancel.
You'd rather pay with money than attention. Perfectly respectable reason, and the honest version of the slogan at the top.

How to Judge a Paid Provider

If you decide to pay, the price is the least interesting question. Ask these instead:

Can you leave? IMAP access and a real export. If getting your mail out is hard, the lock-in is just a different flavor.
Who actually runs it? A named company in a jurisdiction you can find, not a landing page.
What happens if you stop paying? Grace period, read-only access, immediate deletion? Find out before, not after.
Is the storage honest? Shared across services or just mail?
What's the support promise? Email only, response times, and whether a human exists.
What do they claim they can't see? Then check whether the architecture supports the claim, or whether it's a promise in a privacy policy.
How long have they been around, and does the pricing look like a business or a land grab? Services with no revenue model die, and you have to move again.

Where [@fuck.it] Lands

No ads. No tracking. No bullshit. That isn't a slogan we picked because it sounded good, it's a description of our revenue: subscriptions, all of it. There's no second business, no ad network, no profile worth building and nothing to sell to anyone else, because selling you email is the entire company.

What that buys you: a mailbox whose storage isn't shared with a photo library, full IMAP, POP3 and SMTP access, a person on the other end of support, and an account that doesn't expire because you went quiet for a year.

What we won't pretend: we can't give you a custom domain, so your address lives on our domain and depends on us continuing to exist. We can't promise anything about legal process that any other provider can't. If portability above all else is what you're after, go buy a domain.

But let's be honest about what you'd be giving up. Nobody has ever raised an eyebrow at a gmail.com address. Nobody ever will. Ours is the best domain on the internet and the only one that tells people something about you before they've read a word. There's a reason you remember it.

An address on your own domain says you own a domain. An @fuck.it address says something else entirely.

See plans →

Sources & further reading:

Related reads:

This article was originally published on the [@fuck.it] blog at https://fuck.it/blog/is-paid-email-worth-it and is republished here by the author. [@fuck.it] is a privacy-focused, subscription-funded email service by Paradise Circus, Inc. — no ads, no tracking. Facts and product details are accurate as of October 13, 2026; check the original for the latest version.

I Built a Bulletproof Personal Email and Identity System for the Price of a Coffee a Year.

Sun, 13 Sep 2026 18:14:52 +0000

I quit Gmail. Not dramatically — no manifesto, no LinkedIn post about "digital sovereignty." I just got tired of being the product in a relationship I never signed up for, tired of knowing that somewhere in a Mountain View data center there's a shockingly accurate profile of me built from thirteen years of subject lines, and tired of the fact that my entire digital identity — every password reset, every "verify it's you" — routed through a single company that owes me nothing and could nuke my account for a TOS violation I'll never fully understand.

So I rebuilt it. Properly, as an engineer, not as someone who read one privacy blog and panic-deleted their contacts. What follows is the actual architecture: the domain, the mail routing, the encrypted mailbox, the hardware keys, and the self-hosted photo/file layer that finally let me tell Google Photos to get lost too. I'm also going to correct a popular myth along the way, because half the "de-googling" guides floating around right now are recommending a setup that's been dead since 2023 and don't seem to have noticed.

Let's build it properly.

First, Let Me Kill a Myth: "Free Custom-Domain Corporate Email" Mostly Doesn't Exist Anymore

If you've read any de-googling guide from the last few years, you've seen some version of this recipe: buy a domain, bolt it onto a free-tier business email suite from whatever regional Google Workspace competitor was fashionable that year, get real custom-domain mailboxes at zero cost, done. It used to work, for a bunch of different providers, and half the tutorials still floating around online are reheating a version of that trick from an era that's already over.

The honest 2026 landscape: Google Workspace killed its free custom-domain tier years ago and never brought it back. Microsoft 365 never had one. Most "free business email" providers that still advertise a genuinely free custom-domain tier cap you hard — a handful of users, a few gigabytes, webmail-only with no real IMAP/POP access, meaning no Outlook, no Apple Mail, no third-party client. Fine for a solo side project, not something you want to build your actual identity on. I'm mentioning this loudly because nothing kills your credibility as "the security guy" faster than shipping someone a setup guide built around a free tier that got quietly gutted three years ago.

So here's the actual, currently-true architecture, and it's honestly better than any single free-tier suite anyway, because it doesn't depend on one company's continued generosity.

The Architecture

your-domain.com (registered, DNS on Cloudflare)
        │
        ▼
Cloudflare Email Routing  (free, forever, forwards mail — no mailbox of its own)
        │
        ▼
Proton Mail  (the real, encrypted mailbox — zero-access, custom domain optional)
        │
        ▼
YubiKey / FIDO2 hardware key  (guards the front door to everything above)

Three moving parts, one hardware key protecting all of them. Let's go through each layer, because the interesting engineering is in why each piece sits where it does, not just in the click-here-click-there setup steps you can already find in eleven other tutorials.

Layer 1: The Domain, and Why the Registrar Matters More Than You Think

Buy a domain. Doesn't matter much which TLD, but do yourself a favor and register it directly through Cloudflare Registrar, which sells at wholesale/cost pricing with no markup, no upsell renewal traps, and it lands your DNS on Cloudflare's infrastructure by default — which you need anyway for Email Routing in the next step.

Two settings people skip that you shouldn't:

WHOIS privacy — on by default with most modern registrars now, but verify it. Your name and home address do not need to be a whois lookup away from anyone who's curious.
Registry lock / registrar transfer lock — this stops someone from social-engineering their way into transferring your domain out from under you. Your entire identity system is built on top of a domain name. Whoever controls the domain controls the DNS. Whoever controls the DNS controls where your mail goes. This is your actual root of trust, and it deserves more paranoia than the mailbox does.

Layer 2: Cloudflare Email Routing — The Free Plumbing

This is the part that's genuinely free, forever, no asterisk. It is not a mailbox — I want to be precise here because a lot of tutorials get sloppy about this and it causes confusion. Email Routing receives mail addressed to anything at your domain and forwards it to a real, existing inbox you already control. There's no login, no storage, no IMAP server sitting on Cloudflare's side.

Setup, for real this time:

1. Add your domain to Cloudflare (nameservers must point to Cloudflare)
2. Dashboard → Email → Email Routing → Enable
3. Cloudflare auto-adds the MX and SPF TXT records for you
4. Add a "Destination address" — this is where mail actually lands
   (verify it: Cloudflare emails you a confirmation link)
5. Create routing rules:
     *Emails are not allowed*     → forward to → your Proton Mail address
     *@your-domain.com       → catch-all  → same destination (optional)

The free tier gives you 200 routing rules per domain and 200 destination addresses per account, with a 25 MiB inbound message cap — genuinely generous limits that most humans will never bump into. The one thing to understand clearly: this is receive-only. Hit reply and your message goes out from whatever mailbox you're actually forwarding into, not from a magic Cloudflare SMTP server. That's fine, because the next layer is where sending actually happens.

Layer 3: Proton Mail — Your Actual Mailbox, Not Just a "Backup Channel"

Here's where I'm going to gently push back on the brief I was given, because architecturally it doesn't quite hold up: Proton Mail isn't really a "backup secure channel" sitting behind something else — it's the actual encrypted mailbox doing the real work. Cloudflare Email Routing has nowhere to forward mail to unless something on the other end is actually storing and encrypting it. Proton is that something.

Two ways to wire it up, depending on how much you want to spend:

$0 path: free Proton Mail account as the destination for Cloudflare's forwarding rules. You receive at *Emails are not allowed*, it lands zero-access-encrypted in Proton, and you reply from your @proton.me address (or configure Gmail/whatever client-side "send as" trickery you like — it's the same limitation Cloudflare has, just one layer removed).
~$4–5/month path: Proton Mail Plus (or Unlimited) supports native custom domains — full two-way send-and-receive as *Emails are not allowed*, no forwarding hop needed at all, Proton handles your domain's MX directly. This is the cleaner setup if you want your custom address to be indistinguishable from a "real" hosted mailbox, and it skips Cloudflare Email Routing for mail entirely (you'd still likely keep Cloudflare as your DNS host for everything else).

Zero-access encryption means Proton's own infrastructure can't read your mail content even if compelled to — this is architecturally different from Gmail, where Google absolutely can and does read metadata and content for ad targeting, ML training, and "safety" scanning, whatever their current PR phrasing for that is this quarter.

Layer 4: The YubiKey, and What FIDO2/WebAuthn Actually Is Under the Hood

This is the part every de-googling guide name-drops and almost none actually explain, so let's fix that.

A YubiKey isn't "a password, but physical." It's a hardware implementation of public-key cryptography for authentication. When you register the key with a service, the key generates a unique public/private keypair for that specific domain — the private key never leaves the hardware, ever, under any circumstances, not even during authentication. The service stores the public key. To log in, the service sends a challenge, your key signs it with the private key, and the service verifies the signature. Nothing secret ever crosses the network. There is no password to phish, because there's no password in the exchange at all — just a domain-bound cryptographic signature that a phishing site literally cannot forge, because it can't reproduce your domain's cryptographic challenge context.

That domain-binding is the entire point, and it's why WebAuthn/FIDO2 is considered close to phishing-proof in a way SMS codes and even TOTP apps aren't — a fake login page at proton-login-secure.com can absolutely trick you into typing a TOTP code, and that stolen code works. It cannot trick your YubiKey, because the key checks the actual origin before it signs anything, and it will simply refuse to respond to a domain it wasn't registered against.

Practical setup:

Buy two. One you carry, one that lives somewhere safe (a drawer, a safe deposit box, not "in a drawer next to the first one"). Register both as separate security keys everywhere. Losing your only key locks you out of your own life; losing one of two is a Tuesday.
Register it on Proton (Account Settings → Security → Two-factor authentication → Security keys), on Cloudflare (this protects your DNS — arguably your most important account of all, per the root-of-trust point above), on GitHub, and on your password manager.
One honest nuance worth knowing, because it'll make you sound sharp in a security discussion rather than someone who just read the marketing page: Proton's "FIDO2" support is, more precisely, U2F running under the FIDO2 umbrella — you still authenticate with username and password plus the key, not a full passwordless discoverable-credential flow the way Google or Microsoft now support natively. It's still genuinely phishing-resistant and worth using; it's just not the fully passwordless flavor some competitors ship. Small distinction, but the kind of thing that separates "I read a blog post" from "I actually understand what I deployed."

The Password Manager You Still Need

A hardware key protects logins that support it. Everything else — every random SaaS tool, every forum, every one-off account — still needs a strong, unique password, and you still need somewhere to keep them. Bitwarden (or its self-hostable fork, Vaultwarden, which runs happily on a Raspberry Pi) supports FIDO2/WebAuthn as an unlock method itself, so your entire password vault ends up gated behind the same hardware key guarding your mail. One key, one consistent security model, instead of a different app-based 2FA scheme for every service you own.

De-Googling the Rest: Files and Photos

Email was never the whole problem. Google Photos and Google Drive are the other two legs of the stool, and 2026 finally has a clean, boring, mature answer for both — you just need two different tools, because they solve two different problems and pretending one tool does both is how people end up disappointed.

Immich replaces Google Photos specifically. It's the closest like-for-like clone that exists: native iOS and Android apps with automatic background backup, CLIP-based natural-language search ("photos of a dog on a beach" actually works), on-device-adjacent face recognition, timeline and map views. AGPL-3.0, open source, sitting north of 100,000 GitHub stars as of mid-2026. Budget real resources for it — figure roughly 1.5–2GB of idle RAM and more under load for the ML workers doing face/search indexing; this is not a Raspberry Pi project unless you're patient.
Nextcloud replaces Google Drive, Calendar, and Contacts — a general-purpose self-hosted platform rather than a photo-specific app. Its own Photos app exists but is, by every current comparison, the weakest part of the suite; if photos are your main goal, don't lead with Nextcloud for that job.

The honest, slightly annoying truth: run both, side by side, on the same box if it has the RAM. They don't conflict, they solve different problems, and "one self-hosted app to rule them all" is a myth in this ecosystem the same way "one language to rule them all" is in ours. Nextcloud handles your documents and calendar; Immich handles your camera roll. You now maintain two databases and two upgrade paths instead of one, and that is the actual, non-negotiable cost of self-hosting — nobody hands you Google's engineering team for free, you're trading their maintenance burden for your own.

The Part Nobody Mentions: Don't Self-Host the Mail Server Itself

I want to head off the inevitable next question, because I can feel some of you already reaching for postfix and a fresh VPS: do not run your own SMTP server for this. I've written about self-hosting plenty of things on this blog, and mail is the one category where I will talk you out of it every single time. Port 25 is blocked outbound by default on most major cloud providers specifically because of spam abuse. A brand-new IP has zero sending reputation and lands in spam folders by default. Getting off the major blocklists once you're on them is a slow, humiliating, manual process involving web forms and goodwill. Proton and Cloudflare have already spent years building and defending the sending reputation you're borrowing — let them keep doing that job. Self-host your files, your photos, your git repos, your home automation. Don't self-host your mail's deliverability reputation; you will lose that fight against Gmail's spam filter and you won't even get a good war story out of it.

What you should configure yourself, regardless of which mail path you pick: SPF, DKIM, and DMARC records on your domain. These are the DNS records that tell the rest of the internet "only these servers are allowed to send mail as me," and without them your domain is a much easier target for someone to spoof *Emails are not allowed* in a phishing email sent to your own contacts. Both Cloudflare Email Routing and Proton's custom domain setup walk you through adding these automatically — just don't skip the step because the wizard finished without complaining.

What This Actually Costs

Domain: roughly $10–15/year, depending on TLD
Cloudflare Email Routing: $0, forever
Proton Mail: $0 (free tier, forwarding path) or ~$50–60/year (custom domain, native send-and-receive)
Vaultwarden self-hosted, or Bitwarden free tier: $0
Two YubiKeys: roughly $50–60 total, one-time, and they'll outlive several phones

Total: somewhere between the price of a domain name alone and the price of a decent dinner out, once a year, for a mail and identity system where no single ad-funded company holds the keys to your entire digital life. Not bad for an afternoon of DNS records and one very satisfying moment of finally deleting the Gmail app off your phone.

Second Project Back: A Phishing Email Analyzer (Still a Beginner, Still Learning)

Tue, 28 Jul 2026 13:26:36 +0000

Second Project Back: A Phishing Email Analyzer (Still a Beginner, Still Learning)

A little while ago I wrote about coming back to documenting my work after a long quiet stretch, starting with a small IOC enrichment tool. This is the next entry in that same habit — a phishing email analyzer, built for the same reason: phishing makes up the overwhelming majority of L1 SOC tickets, and I wanted to actually understand the mechanics behind the checks analysts run every day, instead of just knowing the term "SPF/DKIM/DMARC" without having implemented any of it myself.

Same disclaimer as last time: this isn't a novel tool. Proper email security gateways and existing phishing analysis tools do this far better, with years of edge cases baked in that I haven't encountered yet. This is a beginner project built to learn by doing, not a claim that I've built something the industry needs.

What It Does

Upload a raw .eml file (or paste the raw source), and it:

Extracts headers and flags mismatches between From, Reply-To, and Return-Path
Actually verifies SPF against DNS records and the real originating IP
Cryptographically verifies the DKIM signature against the sender's public key
Checks DMARC policy
Flags lookalike/typosquatted domains
Hashes attachments and checks them against VirusTotal and MalwareBazaar
Spits out a incident report I can paste straight into a case writeup

The Part That Actually Taught Me Something

Building the SPF/DKIM checks is where I learned the most, mostly by getting things wrong first.

Received headers are in reverse order. I assumed — like reading anything else — that the first Received: header at the top of an email would be the first hop, chronologically. It's the opposite. Mail servers prepend new Received headers as the message moves along, so the top one is the most recent hop and the bottom one is closest to the original sender. My first version of the origin-IP extraction logic was quietly reading the wrong end of the chain and flagging the recipient's own mail server as "suspicious." Small thing, but a wrong assumption like that would have made every result in this tool backwards if I hadn't caught it.

SPF checks the Return-Path domain, not the From domain. This one surprised me. The visible "From" address is what a human reads, but SPF authentication is actually evaluated against the envelope sender — the Return-Path — which the recipient never even sees by default. That's exactly why Reply-To/Return-Path spoofing works as an attack in the first place: the part a human trusts (From) isn't the part the mail server verifies (Return-Path). Getting this distinction right in code meant actually understanding why the attack works, not just detecting that it happened.

Trusting a pre-computed result is a trap — same lesson as my last project's MalwareBazaar issue, different context this time. It would've been much faster to just read the Authentication-Results header the receiving mail server already left behind, stating whether SPF/DKIM/DMARC passed. But that header is written by some mail server in the delivery chain — and if the whole point of the tool is catching sophisticated spoofing, trusting a self-reported result defeats the purpose. So this version does the DNS lookups and DKIM signature verification itself, independently.

What's Still Rough (On Purpose, Documented, Not Hidden)

SPF include: mechanisms (third-party senders like include:_spf.google.com) aren't recursively resolved — the tool flags them for manual review instead of chasing the chain down. Proper recursive SPF resolution is a project on its own.
DMARC organizational domain lookup is simplified — a fully correct version needs the Public Suffix List to know where the real organizational boundary sits (think .co.uk vs .com), which I haven't implemented yet.
Homograph detection is edit-distance based against a fixed brand list, not a comprehensive Unicode confusable-character database.

None of these are hidden in the code — they're commented directly where the simplification happens, partly so I remember what to improve, partly because I'd rather be upfront about where the tool's edges are than let it look more complete than it is.

Why Keep Writing These

Same reason as before — the value isn't in looking finished, it's in having an honest record of what I understood well enough to build versus what I'm still learning. If the SPF/Return-Path distinction was new to me, it's probably new to other people making the same jump from development into security, and that's worth writing down plainly rather than only presenting the polished result.

Next up is likely a home SIEM lab, and probably a case where I actually run one of my own tools against a real (safely sourced) phishing sample instead of the fabricated test email I used to build this one.

Muhammad Abdullah — learning SOC analysis, building things along the way.
GitHub: m-abdullah-06

Set Up a Free Professional Email Address With Gmail and Cloudflare. Even If You Don't Own a Domain

Fri, 08 May 2026 18:17:20 +0000

Tired of using a plain @gmail.com for business, newsletters, portfolios, or professional emails? You can set up unlimited custom email addresses eg:yourname[at]yourdomain.com completely free, with no monthly fees for Google Workspace or similar services.

This guide became super popular after a viral X (Twitter) thread, but many people get stuck because they don't have a domain yet, or they try the wrong SMTP settings for sending emails.

This complete beginner-friendly tutorial covers everything from getting your first domain (free or very cheap) → setting up incoming mail with Cloudflare → sending from Gmail. No tech experience needed, follow along step by step.

Why This Setup Is Awesome (and What to Know)

Pros

Totally free after you get the domain (domain can cost $0 to $12/year)
Unlimited email addresses/aliases (e.g., info@, support@, yourname@)
Emails arrive in your regular Gmail inbox
Send emails from your custom address directly in Gmail (web, mobile app, etc.)
Perfect for creators, freelancers, students, indie hackers, or side projects

Limitations

Cloudflare handles receiving only, and we use Gmail to send
Outgoing emails use Gmail's servers → good deliverability, but not perfect for massive cold emailing (may hit spam folders sometimes)
Gmail free account limit: \~500 emails/day
For super high volume or perfect branding, you could add a cheap SMTP service later

If you're just starting, this is one of the best zero-cost setups in 2026.

Step 0: Get Your Domain Name (Free or Super Cheap Options)

You need a domain name first (like yourname.com). Here's how to get one easily:

Option 1: Free for Students (Best if Eligible)

If you're a student (university, college, bootcamp, etc.):

Go to education.github.com/pack
Sign up or log in with your GitHub account → verify student status (usually with school email or ID)
Once approved (usually instant or 1 to 2 days), scroll to the "Domains" section
Choose an offer:

Namecheap: Free 1-year .me domain (great for personal sites/emails)
Name.com: Free 1-year on extensions like .dev, .app, .live, .studio, .rocks, etc.

Redeem the offer → follow their instructions to register the domain
Done! You get a real domain for free for 1 year (renewal is usually cheap afterward).

Option 2: Very Cheap for Anyone (\~$1 to $10 First Year)

Popular beginner-friendly registrars with promos (as of February 2026):

Namecheap (recommended for simplicity): Often $0.99 to $6.49 for first-year .com, .site, .online, etc. Use promo codes like 99SPECIAL for 99¢ domains or check current deals at namecheap.com/promos. Free WHOIS privacy included.
Porkbun: At-cost pricing, beginner dashboard, often $5 to $10 for .com.
Cloudflare Registrar (if you plan to use Cloudflare anyway): At-cost renewals, no markup (\~$10 to $11/year for .com).
Hostinger or Wix: Sometimes bundle a free domain for 1 year with cheap hosting (but you don't need hosting here, just the domain).

Steps to register (example with Namecheap):

Go to namecheap.com
Search for your desired name (e.g., rdjarbeng.com or mybrand.online)
Add to cart → apply any promo code at checkout
Create account → pay (credit card, PayPal, etc.)
After purchase, you'll get login access to manage the domain

Tip: Choose .com, .me, .dev, or .app — they look professional and are widely accepted.

Step 1: Add Your Domain to Cloudflare & Enable Email Routing (Incoming Mail)

Cloudflare is free and secure. It will handle receiving emails and forward them to your Gmail.

Go to dash.cloudflare.com and sign up for a free account (email + password).
After logging in, click Add a site (or Onboard a domain).
Enter your domain (e.g., yourdomain.com) → Continue.
Cloudflare scans your existing DNS (if any) → select the Free plan → Continue.
Cloudflare gives you two nameservers (something like ns1.cloudflare.com and ns2.cloudflare.com).
Go back to your domain registrar (Namecheap, Porkbun, etc.):

Find "Nameservers" or "DNS" settings
Change from default to Custom → paste the two Cloudflare nameservers
Save

Wait 5 to 60 minutes (sometimes up to 24 hours) for changes to propagate → refresh Cloudflare dashboard until it says "Active".
In Cloudflare dashboard → select your domain → go to Email → Email Routing.
Click Get started or Enable → Cloudflare adds the needed MX records automatically.
Go to Email → Routes or Custom addresses → Create address.
- Enter email: e.g., *yourname[at]yourdomain.com* (or info@, hello@, etc.)
- Destination: your real Gmail address (e.g., *yourname[at]gmail.com*)
- Save
Test: Send an email to your new custom address → it should appear in Gmail within seconds!

Note: You can create unlimited addresses, all forwarding to the same Gmail (or different ones).

Step 2: Prepare Gmail to Send (Must-Do: App Password)

Gmail needs extra security for sending from custom addresses.

Go to myaccount.google.com/security
Turn on 2-Step Verification if not already enabled (use your phone).
Search for App passwords → click it.
Select app: Mail
Select device: Other (name it e.g., "Custom Email")
Generate → copy the 16-character password (save it somewhere safe, no spaces).

Step 3: Add Your Custom Email to Gmail (Send From It!)

Important: Do not use Cloudflare's server for sending. Use Gmail's.

Open Gmail → click the gear icon → See all settings → Accounts and Import tab.
Under Send mail as → click Add another email address.
Fill in:

Name: Your name or brand
Email: *yourname[at]yourdomain.com*
Uncheck "Treat as an alias" → Next

SMTP settings:

SMTP Server: smtp.gmail.com
Port: 587
Username: Your full Gmail (e.g., *yourname[at]gmail.com*)
Password: The App Password from Step 2
Use TLS: Yes (usually default)

Click Add Account.
Gmail sends a verification code to your custom email → it forwards to Gmail inbox.
Find the code → enter it → verified!

Now compose emails in Gmail → click the "From" dropdown → choose your custom address.

Step 4: Boost Deliverability (Optional but Helpful DNS)

In Cloudflare DNS → add/update these TXT records:

SPF (prevents spam flags):

v=spf1 include:_spf.mx.cloudflare.net include:_spf.google.com ~all

(Name/Host: @)

DMARC (monitor reports):

v=DMARC1; p=none; rua=mailto:*yourname[at]gmail.com*

(Name/Host: _dmarc)

No DKIM from this free setup, which is normal.

Testing & Tips

Send test emails to friends → check inbox/spam.
Set your custom address as default in Gmail if you want.
Mobile: Works perfectly in Gmail app.
Stuck on verification: Regenerate App Password (common issue).
Propagation slow: Wait and refresh, normal for new domains.

Alternatives If You Need More

Zoho Mail free tier: Full features + DKIM (limited storage)
Paid SMTP (e.g., SMTP2GO free tier) for better sending reputation
Self-hosted if advanced

This Cloudflare + Gmail trick is still one of the top free email hacks in 2026. Share your custom email or any questions in the comments below.

Happy emailing!

Media mentions:

Also posted on dev.to for Richard Djarbeng

PS: Got this email, 5th March, 2026 from someone who was able to follow this tutorial and set up their professional email:

Glad to know this post helped someone

Why 74% of repeat ransomware victims say they have too many security tools, and what to do about it.

Sun, 10 Aug 2025 04:45:43 +0000

Security Tool Sprawl: How 'More Protection' Actually Creates More Ransomware Risk

Barracuda's 2025 research reveals a troubling paradox: organizations with the most security tools are getting hit hardest by ransomware

In cybersecurity, more isn't always better. While organizations continue adding security tools to their arsenals, hoping to build impenetrable defenses, new research from Barracuda Networks reveals a troubling paradox: the companies with the most security tools are often the most vulnerable to ransomware attacks.

According to Barracuda's 2025 Ransomware Insights Report, based on a survey of 2,000 IT and security decision-makers worldwide, 74% of organizations hit by multiple ransomware attacks say they're "juggling too many security tools," while 61% report their tools don't integrate properly. This fragmentation isn't just an operational headache, it's creating blind spots where attackers can hide and thrive.

The Repeat Victim Problem

The statistics paint a stark picture of persistent vulnerability. Among the 57% of organizations that experienced successful ransomware attacks in the past year, 38% were hit multiple times. This isn't random bad luck, it's a pattern that reveals fundamental security gaps that persist even after an initial compromise.

"The findings make it clear that ransomware is an escalating threat, and fragmented security defenses leave organizations immensely vulnerable," said Neal Bradbury, Barracuda's chief product officer. "In many cases attackers can move through victims' networks, gaining access to devices, data and more without being detected and blocked."

The correlation between security sprawl and repeat attacks suggests that organizations aren't learning from their first encounters with ransomware. Instead of addressing underlying architectural issues, many victims add yet another security tool to their stack, further complicating an already fragmented environment.

One of the most revealing findings concerns email security, a fundamental layer of protection that remains surprisingly weak across many organizations. Only 47% of ransomware victims had implemented email security solutions, compared to 59% of organizations that avoided attacks entirely.

This gap is particularly concerning given that 71% of organizations that suffered email breaches were also hit with ransomware, clearly demonstrating the connection between these attack vectors. Yet many organizations still don't make this connection, treating email security as a nice-to-have rather than a critical foundation for ransomware prevention.

The same pattern emerges across other security fundamentals: 48% of ransomware victims had network monitoring in place compared to 59% of non-victims, and only 45% had security awareness training versus 51% of unaffected organizations. These aren't exotic security measures—they're basic protections that many organizations have somehow overlooked while chasing more sophisticated solutions.

Beyond Encryption: The New Ransomware Playbook

Modern ransomware attacks have evolved far beyond simple data encryption. Barracuda's research reveals that today's attacks are multidimensional campaigns designed for maximum impact and leverage. Only 24% of successful attacks involved data encryption, while 27% included data theft, 27% involved publishing stolen data, and 29% saw attackers install additional malicious payloads.

This evolution reflects a more sophisticated approach to extortion. Rather than simply locking files and demanding payment, attackers now steal sensitive data before encryption, giving them multiple pressure points. They threaten to expose confidential information, contact customers and partners directly, and even threaten individual employees, tactics experienced by 22%, 21%, and 16% of victims respectively.

The psychological pressure campaign extends well beyond the initial attack. Attackers routinely threaten to alert authorities or the press (21% of cases) and deliberately target backup systems to eliminate recovery options, a tactic used against 19% of victims.

The False Promise of Ransom Payments

Despite the expanded attack surface, many organizations still view ransom payments as a viable option. The research shows that 32% of victims paid attackers to recover their data, with the rate rising to 37% among organizations hit multiple times.

However, paying doesn't guarantee recovery. A sobering 41% of organizations that paid ransoms failed to recover all their data. Sometimes decryption tools don't work, attackers provide only partial keys, or files become corrupted during the encryption and decryption process. In some cases, attackers simply take the money and disappear.

This reality underscores why 65% of ransomware victims who successfully recovered their data did so using backups rather than paying attackers, a reminder that fundamental security practices often outperform expensive reactive measures.

The Business Impact Beyond Recovery

The consequences of ransomware extend far beyond immediate recovery costs. Barracuda's research found that 41% of victims experienced brand and reputation damage, while 25% lost existing customers and another 25% lost new business opportunities.

These long-term impacts explain why ransomware remains so lucrative for attackers and why the threat continues to grow. Organizations in healthcare (67% attack rate), local government (65%), and retail (61%) face particularly high risks, though no industry or company size appears immune.

A Path Forward: Integration Over Addition

The solution isn't necessarily buying more security tools, it's making existing tools work together effectively. As Adam Khan, Barracuda's VP of Global Security Operations, noted during our interview, organizations need to focus on fundamentals rather than chasing the latest security technology.

AI-powered Security Operations Centers are emerging as one promising approach, using automated research and investigation to reduce manual workloads while providing better visibility across fragmented security stacks. However, the technology is only as effective as the underlying security architecture it's built upon.

For development and engineering teams, the key lesson is clear: security effectiveness comes from understanding how attackers actually operate, not from accumulating the maximum number of defensive tools. Organizations need to think like attackers, identifying the paths of least resistance through their environments and closing those gaps systematically.

The most effective defense remains a combination of solid fundamentals—email security, network monitoring, endpoint protection, and regular backups—implemented as an integrated system rather than a collection of point solutions. In the war against ransomware, coordination beats accumulation every time.

Concise list of Angular essentials

Fri, 06 Jun 2025 22:32:55 +0000

The foundational concepts, tools, and best practices you need to know to be productive with Angular, whether you're a beginner or brushing up.

Angular Essentials

1. TypeScript

Angular is built on TypeScript. Understanding TS features like interfaces, classes, types, and decorators is fundamental.

2. Modules (`NgModule`)

Organize app features.
Root module = AppModule.
Feature modules for separation of concerns.

@NgModule({
  declarations: [...],
  imports: [...],
  providers: [],
  bootstrap: [AppComponent],
})
export class AppModule {}

3. Components

Core building blocks of UI.
Use the @Component decorator.
Must declare them in a module.

@Component({
  selector: 'app-hello',
  templateUrl: './hello.component.html',
})
export class HelloComponent {}

4. Templates & Data Binding

{{}} interpolation
[property] binding
(event) binding
[(ngModel)] two-way binding

5. Directives and blocks

Structural: *ngIf, *ngFor
Attribute: [ngClass], [ngStyle]
Custom directives with @Directive
@if, @for, @switch

6. Services & Dependency Injection

Business logic & API calls go here.
Reusable and testable logic.
Inject with constructor-based DI.

@Injectable({ providedIn: 'root' })
export class ApiService {
  constructor(private http: HttpClient) {}
}

Define routes in RouterModule.
Handle dynamic params, guards, lazy loading.

const routes: Routes = [
  { path: 'home', component: HomeComponent },
];

8. HTTP Client

Use HttpClientModule for API calls.
Supports observables.

this.http.get('/api/data').subscribe(data => ...);

9. Forms (Template-Driven & Reactive)

Template-driven: ngModel, simple forms
Reactive: FormBuilder, Validators, reactive patterns

10. Lifecycle Hooks

ngOnInit, ngOnDestroy, ngOnChanges, etc.
Useful for subscriptions, timers, cleanup.

11. Pipes

Format data in templates (| date, | uppercase)
Create custom pipes for custom formatting

12. Testing (Jest or Karma + Jasmine)

Use TestBed for unit/component tests
Mock services and inputs

Recommended Tools

Angular CLI (ng new, ng serve, etc.)
Angular DevTools (Chrome Extension)
ESLint + Prettier
VSCode Angular Snippets

Best Practices

Use lazy loading for feature modules
Structure folders by feature, not type
Avoid logic in templates
Strongly type everything
Use RxJS for reactive patterns

The Sender Policy Framework: Bare Bone Essentials

Tue, 20 May 2025 03:05:57 +0000

Background

Email is part of our daily lives; everyone who works in an organization or uses the internet frequently has opened an email account at least once in their lifetime. But this technology, invented in the 90s, wasn’t created for widespread use and was not designed with security in mind. This makes impersonation easy, and that was why a protocol such as SPF was developed.

SPF is an email authentication protocol designed to combat email address forgery, also called spoofing. Attackers use spoofing to disguise their emails so that recipients think the email is coming from a legitimate source. SPF allows administrators to publish hosts in their DNS TXT records, specifying which hosts can send email from that domain. SPF is just one of several email authentication mechanisms. Other mechanisms, such as DMARC and DKIM, are also used for authenticating email.

According to RFC 7208, SPF once had a dedicated record type, but the developers of the protocol found it easier to use TXT to implement SPF records, and the old record type was deprecated.

Example of an SPF Record

SPF record types are in-depth, and we wouldn’t be able to cover all of them here. We’ll look at a single record and break down what it means. Take a look at the record below:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

v=spf1: Declares SPF version 1 (required).
ip4:192.0.2.0/24: Authorizes all IPs in the 192.0.2.0 subnet to send mail.
include:_spf.google.com: Authorizes Google’s mail servers. For instance, if sending through Google Workspace.
-all: Fails any sender not explicitly listed (hard fail).

This is a straightforward example to explain how SPF works. There are certainly more complex records depending on how many sending servers are listed.

How a Receiving Mail Server Verifies SPF

This is a multistep process with lower-level granular details, but here it is at a high level:

The server accepts the incoming connection and reads the MAIL FROM (envelope sender) command.
It isolates the domain portion of the envelope sender address to know which domain’s SPF policy to check.
The SPF engine performs a DNS TXT lookup for that domain, searching for a record beginning with v=spf1.
The server parses the SPF string into its mechanisms (e.g.,ip4,include,mx,a) and qualifiers (+,-,~,
?).
Each mechanism is evaluated in order against the sender IP address.
These steps produce an evaluation result, and based on that result, the server can either accept or reject the mail.

Here is the flow chart of the process;

Conclusion

That's SPF at its core.There is still more to cover and learn if we want to go down the rabbit hole.SPF is a simple, DNS-based way to make impersonation harder.It’s free to implement.
By publishing an accurate ' v=spf1 ' record, you take the first step toward protecting your domain from spoofed mail.Remember, SPF alone won’t stop every phishing or spoofing attempt, so it works best in concert with DKIM and DMARC.Once your SPF record is live, monitor it regularly (using tools or scripts) and update it whenever you add or remove sending services.A well-maintained SPF policy lays the groundwork for a stronger, more reliable email ecosystem.

Coder Legion - Recent posts tagged emailsecurity

@fuck.it - email with attitude

Is Paying for Email Worth It? What Your Money Actually Buys

TL;DR

Somebody Pays for Every Inbox

What Actually Happens to Free Email

Everyone Else Is in the Same Business

What Free Actually Costs

What Paying Actually Buys

What Paying Does Not Buy

The Thing Nobody Selling You Email Wants to Mention

Credit Where It's Due

When Free Is Good Enough

When Paying Makes Sense

How to Judge a Paid Provider

Where [@fuck.it] Lands

I Built a Bulletproof Personal Email and Identity System for the Price of a Coffee a Year.

First, Let Me Kill a Myth: "Free Custom-Domain Corporate Email" Mostly Doesn't Exist Anymore

The Architecture

Layer 1: The Domain, and Why the Registrar Matters More Than You Think

Layer 2: Cloudflare Email Routing — The Free Plumbing

Layer 3: Proton Mail — Your Actual Mailbox, Not Just a "Backup Channel"

Layer 4: The YubiKey, and What FIDO2/WebAuthn Actually Is Under the Hood

The Password Manager You Still Need

De-Googling the Rest: Files and Photos

The Part Nobody Mentions: Don't Self-Host the Mail Server Itself

What This Actually Costs

Second Project Back: A Phishing Email Analyzer (Still a Beginner, Still Learning)

Second Project Back: A Phishing Email Analyzer (Still a Beginner, Still Learning)

What It Does

The Part That Actually Taught Me Something

What's Still Rough (On Purpose, Documented, Not Hidden)

Why Keep Writing These

Set Up a Free Professional Email Address With Gmail and Cloudflare. Even If You Don't Own a Domain

Why This Setup Is Awesome (and What to Know)

Step 0: Get Your Domain Name (Free or Super Cheap Options)

Option 1: Free for Students (Best if Eligible)

Option 2: Very Cheap for Anyone (\~$1 to $10 First Year)

Step 1: Add Your Domain to Cloudflare & Enable Email Routing (Incoming Mail)

Step 2: Prepare Gmail to Send (Must-Do: App Password)

Step 3: Add Your Custom Email to Gmail (Send From It!)

Step 4: Boost Deliverability (Optional but Helpful DNS)

Testing & Tips

Alternatives If You Need More

Media mentions:

Why 74% of repeat ransomware victims say they have too many security tools, and what to do about it.

Security Tool Sprawl: How 'More Protection' Actually Creates More Ransomware Risk

The Repeat Victim Problem

The Email Security Blind Spot

Beyond Encryption: The New Ransomware Playbook

The False Promise of Ransom Payments

The Business Impact Beyond Recovery

A Path Forward: Integration Over Addition

Concise list of Angular essentials

Angular Essentials

1. TypeScript

2. Modules (NgModule)

3. Components

4. Templates & Data Binding

5. Directives and blocks

6. Services & Dependency Injection

7. Routing & Navigation

8. HTTP Client

9. Forms (Template-Driven & Reactive)

10. Lifecycle Hooks

11. Pipes

12. Testing (Jest or Karma + Jasmine)

Recommended Tools

Best Practices

The Sender Policy Framework: Bare Bone Essentials

Background

Example of an SPF Record

How a Receiving Mail Server Verifies SPF

Conclusion

2. Modules (`NgModule`)