DEV Community: TiltedLunar123

The Security+ Acronyms That Get Confused With Each Other

TiltedLunar123 — Thu, 10 Sep 2026 09:48:36 +0000

The acronym appendix at the back of the SY0-701 objectives lists more than three hundred entries. People often suggest memorizing it, and every study group has someone printing it out. That advice misreads what the exam does with acronyms.

SY0-701 rarely tests what an acronym means. Instead, it gives you a short scenario and four options, two of which are acronyms from the same area, and asks which one fits the scenario. Knowing that RPO expands to recovery point objective doesn't help much on that question. Understanding that RPO measures lost data while RTO measures lost time gets you the answer in about four seconds.

So, the useful way to study is by cluster rather than alphabetically. A cluster is a small group of acronyms sitting close enough together that a question writer can build a believable wrong answer out of one of them. How many are there? Maybe fifteen in the whole exam. Here are five of the most common ones, with the objective each sits under, so you can read the source material.

The four recovery numbers

Objective 5.2 covers all four under business impact analysis; RPO and RTO also appear in 3.4 with resilience and recovery. Two of them are business targets. The other two are post-event observations. That split is the whole cluster. Learn it and the four stop blurring.

RPO looks backward. How much data can you afford to lose? That makes it about backup frequency. RTO looks forward. How long can you afford to be down? Which is a claim about recovery capability, not about backups. MTTR is the average repair time. MTBF is the time between failures.

The stem usually gives it away. Read it twice. A sentence about hourly snapshots points at RPO, and one about a four-hour outage window points at RTO. If the sentence describes something that already happened rather than a business decision, you are in MTTR and MTBF territory.

Federation, and why one of these is not authentication

Objective 4.6 puts SAML, OAuth and OIDC on one line with Kerberos, LDAP and RADIUS. The trap is that people learn the first three as single sign-on protocols and then mix them up under pressure. All three are very commonly confused.

SAML and OIDC both carry identity. They answer who this person is. OAuth on its own does something else. It answers what an application is allowed to reach (authorization), and it was built to let an app touch your data without handing over your password. OIDC sits on top of OAuth 2.0 and adds the identity layer that OAuth left out.

So, a stem describing a third-party app getting limited access to an account points at OAuth, even when the word login appears somewhere in the sentence. A browser redirected to a corporate identity provider, coming back with an assertion? SAML.

The agreement alphabet

Objective 5.3 covers third-party risk, and this might be the least loved cluster; it feels like paperwork rather than security. It is also the one where every option in the question is a real document and only one of them fits the sentence you were given. Read the sentence, not the options.

An SLA carries numbers: uptime and response time, with a penalty for missing the number. An MOU only records that two parties intend to work together, and it is generally not built to be enforced. An MSA sets the terms of a long relationship, while the SOW underneath it says what this particular job is and when it is due. An NDA is about confidentiality and nothing else. A BPA governs a partnership where both parties carry real risk if it goes wrong.

Severity is not priority

CVSS, EPSS and KEV all sit in 4.3. CVSS rates how bad a vulnerability would be if exploited. EPSS estimates how likely exploitation is. KEV is a catalog of vulnerabilities already being exploited in the wild.

Any question that gives you a patch queue and asks what to fix first checks whether you spotted that a severity score alone doesn't set the order. A high CVSS on something nobody is exploiting can wait. A medium that appears on the KEV list goes first.

Four ways to test code

Also in 4.3. This is the cleanest cluster of the five. SAST reads source without running it. DAST attacks the running application and sees nothing of the source. IAST instruments the running application to see both. SCA ignores your code entirely and looks at what it depends on.

The discriminator is almost always in the first clause of the stem. Third-party library with a known vulnerability? That is SCA. No source available means DAST, and a scan that runs before the build has been deployed anywhere is SAST.

How to actually drill this

Reviewing a cluster by reading it is the trap. That is the whole warning. A comparison table feels productive, and what it trains is recognition, an easier skill than the one being tested.

The version that works is slower and more annoying. For each pair in a cluster, write one sentence that only one of the two can answer. Then cover the labels and read your own sentences back. If you wrote a sentence that both acronyms could satisfy, you found the exact gap the question writer is going to aim at, and you found it at your desk instead of in the testing center.

A last word on that appendix. Treat it as a scope boundary; some entries appear only once, in one sub-bullet of one objective. The clusters are where the questions live, and the fastest way to find the rest is to read CompTIA's published exam objectives and look for lines where three or four related acronyms are grouped together. If you would rather practice this the way the exam asks it, there is a free performance-based question here that needs no account. Full disclosure: I built that one.

Gmail's Trash gives back your emails, not your undo

TiltedLunar123 — Tue, 08 Sep 2026 09:40:10 +0000

Deleting mail in bulk is easy. You run a search and hit delete on what comes back, over and over; the whole loop is about forty lines of code.

Undoing this operation turns out to be trickier, and I made a misstep initially because I thought Gmail's Trash folder was already my undo button.

It isn't.

Trash gives back the emails, not the operation

Trash just holds emails for 30 days. So technically nothing is lost, since the messages are still there waiting to be restored.

The issue lies with what you're trying to restore. If you run a cleanup that touches four thousand conversations through twelve different searches, your Trash ends up holding all of them mixed in with whatever you deleted last Tuesday and the thread you dropped on purpose this morning. Nothing marks where one run ends and another begins.

You can restore an email. Can you restore that run? No. And users usually want more than one message back; they want their last five minutes undone.

That gap is the actual feature, because Gmail has no concept of the batch you just ran.

What the log needs to record

The exact search query used
A list of ids actually acted on, not those matched
A timestamp for when the run happened
The point at which restoring stops working

The third and fourth items might seem redundant, but they're crucial. The timestamp is when it happened; the expiry is when the promise runs out, and those two are only the same thing if you assume the retention window never changes.

The distinction between "matched" and "acted on" matters because a run that dies mid-way results in different sets of matched and deleted emails. A log based solely on intent could offer to restore mail that wasn't removed, creating confusion or worse, teaching users the undo button is unreliable.

It has to live on the machine

The extension makes no network calls; it's a deliberate design choice, and it means there is no server-side place to keep a log. The data is stored locally in browser storage, which comes with its own challenges.

The first limit is size. Storing ids for tens of thousands of messages across multiple runs isn't free, and there is no point keeping an entry past the window where it can still do something.

The second one bit me. chrome.storage.local.set replaces the value at a key instead of merging into it, so writing the log for run two silently loses run one. Testing never caught it, because you almost always test the most recent action and that one is always correct. I found it while checking something else entirely.

So the write path has to read the key first and merge into it. Obvious, once you have lost data that way.

Expiry has to be visible

An undo entry outside the retention window is worse than no entry at all; it advertises a capability that won't work at the exact moment somebody needs it. So the log shows when each entry stops working, and anything past that point comes off the list.

It reads like a small detail next to the deletion engine. It is the difference between a guarantee and a suggestion.

The cheaper half is not deleting

All of this is about recovery. The better move is not needing it.

Dry runs are the key here: same query, same counts, nothing actually deleted. Most of the value of an undo system is captured by showing someone the number before they commit to it. The classic disaster isn't deleting the right things and changing your mind; it's thinking a search meant something else.

The same logic applies to protecting starred and important mail automatically. That protection belongs inside the query you count with, not applied as a filter after fetching results. If you exclude items after fetching, the number shown to the user came from a different set than the one the delete call sees, and any retry path can quietly act on the wrong list. The count and the action have to be reading the same thing.

The limit, stated plainly

None of this is a backup. Once Gmail's window closes, a recovery log is just a list of ids for mail that no longer exists. It's a 30 day guarantee, and it should be described as exactly that rather than dressed up as safety.

If you want the tool, it's Gmail One-Click Cleaner on the Chrome Web Store. It runs locally and its source is on GitHub; bulk cleanup is free.

The engine took a weekend. The undo took considerably longer, and it's the part I would keep.

Shadow IT is on the Security+ threat actor list, and there is no attacker in it

TiltedLunar123 — Mon, 07 Sep 2026 09:43:33 +0000

Shadow IT sits on the Security+ threat actor list, right there next to nation-states and organized crime. There is no attacker in it. Nobody is breaking in. It is the finance team paying for a file sharing tool on a company card because the approved one takes four days to grant access.

That placement confused me for a while. Once it clicked, a whole category of exam questions got easier, so it is worth explaining.

What the objectives actually name

Pull up CompTIA's Security+ page and read objective 2.1. The threat actors it lists are nation-states, unskilled attackers, hacktivists, insider threats, organized crime, and shadow IT. Motivations get named separately, things like data exfiltration, espionage and financial gain among others.

Two lists. Most people skim straight past that. The exam treats the actor and the motive as separate axes, and most of the questions that feel unfair are questions where you read one and answered the other.

The list is sorted by capability, not by villainy

Shadow IT belongs there because the list sorts threats by what they can do to you and how much warning you get, which is a very different job from ranking them by how villainous they are.

Ask three things about whoever is in the scenario.

How much money and time do they have? A nation-state has effectively unlimited resources and can wait a year. Organized crime is well funded and impatient, because it needs a return. An unskilled attacker has neither.

How capable are they? This is not the same question. Resources buy tools; sophistication is whether they can build something new. A nation-state writes its own malware and burns a zero day when it needs to. Somebody unskilled is running a tool that another person wrote, and does not necessarily know what it does.

Are they inside or outside? Inside changes everything, because internal actors skip the whole first phase. They already have a badge, an account, and a reason to be there.

Run shadow IT through those three and it makes sense. Internal, no hostile intent, minimal sophistication, and yet there is real exposure sitting behind it: company data in a service nobody vetted, and no logging that your team can reach. A security team cannot protect infrastructure it does not know exists. So the slot is earned on capability grounds rather than on intent.

The stem usually hands you the motive

Here is the pattern worth internalizing. Exam questions rarely say "a hacktivist did this." They describe what happened and what the attacker seemed to want, and you work backwards.

Data quietly copied out over months with no ransom demand and no disruption? Long dwell time and no money motive points at espionage, and espionage points at whoever can afford to be patient. Systems encrypted with a payment demand? That is financial gain, and that is organized crime. A public defacement timed to a news story, where the attacker wants you to know? That is philosophical or political, and it is the loudest actor on the list. Nobody quiet does that.

So the useful question is what this person wanted, and who tends to want that, rather than which of four labels you happen to recognize.

There is a corollary that matters just as much. Two actors can run the exact same technique. Phishing is evidence of nobody in particular, because everyone phishes. What separates them is who got targeted and what happened after the attacker got in.

One wording check before you trust your notes

The current objectives say unskilled attacker. Plenty of study material still says script kiddie.

On its own that is harmless, and the terms mean the same thing. It is worth noticing anyway, because it dates the material you are holding. If the wording lines up with an older version of the exam, check the rest of it before you rely on it, since SY0-701 has been the live version since November 2023 and CompTIA now prints a retirement date of June 11 2027 for the English exam.

Where reading stops helping

You can learn all of this from an article, mine included. What none of it prepares you for is the format that gives people the most trouble on the day.

The performance-based questions are not written like this. They drop you into a task and expect you to produce something from a blank state, so you are ordering a rule set or walking a log until the answer falls out. Recognizing a threat actor from a paragraph is a very different skill from operating an interface under time pressure, and studying the first one harder does not do much for the second.

That is the gap I kept hitting, and it is why I ended up building a firewall PBQ you can just do, free and without an account, so people can find out how the format feels before exam day rather than during it. Full disclosure, that one is mine.

For the reading side, Professor Messer's SY0-701 series is free and covers the whole blueprint. Jason Dion's practice exams are the usual next step when you want to be tested rather than taught. And the objectives PDF is free from CompTIA and is the only real checklist, since every question traces back to a numbered line in it.

Threat actors are cheap points once you stop memorizing six labels and start asking what the person wanted and what they could afford. Two questions. They resolve most of the domain.

CompTIA replaced the Security+ retirement estimate with a date, and it is June 11 2027

TiltedLunar123 — Sat, 05 Sep 2026 17:01:46 +0000

Every CompTIA exam page carries a line called Retirement, sitting in the Exam details block under the launch date and the question count. For most exams it reads the same way: "usually three years after launch," followed by an estimated year in brackets. It is a planning figure, not a promise, and CompTIA says so in the wording.

Security+ does not say that any more.

The SY0-701 page now reads: Retirement: English - June 11, 2027; Japanese, Portuguese, Spanish, and Thai - August 13, 2027. No "usually," no "estimated," no brackets. A date.

That is a small edit to one line on one page, and it is worth more than it looks.

Estimate versus date

The old wording put SY0-701's estimated retirement at 2026, which is this year. If you read that in the spring you would reasonably have concluded the exam was about to disappear and either rushed a booking or quietly decided it was not worth starting. Neither reaction was warranted, because an estimate derived from "three years after a November 2023 launch" is arithmetic, not scheduling.

The published date is a different kind of object. You can put it in a calendar. You can build a study plan backwards from it. You can tell a manager who is deciding whether to fund a voucher next quarter exactly how long the current version is good for.

For comparison, as of today the other two exams in the same family have not changed:

Network+ N10-009, launched June 20 2024, still reads "usually three years after launch (estimated 2027)."
A+ V15, series 220-1201 and 220-1202, Core 1 launched March 25 2025, still reads estimated 2028.

So Security+ is currently the only one of the three you can plan against precisely. If you are sequencing certifications, that is genuinely useful: the one with the firm date is the one whose window you can treat as real.

The retirement line is about the exam, not about you

This trips people up constantly, and the wording invites it.

A retirement date applies to the exam version. It says when you can stop being able to sit SY0-701. It says nothing about a certification you already hold. If you pass SY0-701 tomorrow, you hold Security+ for three years from your pass date, and a new version launching in 2027 does not shorten that by a day. Your renewal clock and the exam's retirement clock are unrelated objects that happen to be measured in the same units.

The practical version: passing early does not cost you anything, and waiting does not buy you anything except a longer wait.

What to actually do with this

Check what version your material is written for. SY0-601 retired a while ago and its content is still in circulation, sold in bundles and posted in study groups, because nothing forces a seller to take it down. The two versions overlap enough to look interchangeable and diverge in the places that decide marks. If a course, a question bank or a PDF does not say 701 somewhere visible, assume it is not.

Do not confuse the retirement date with the last day to book. The outgoing version normally stays bookable for a period after its replacement appears, and CompTIA has published a date rather than a countdown. Treat June 11 2027 as the outside edge of the window, not as a deadline you are racing.

Plan against the objectives, not the calendar. The exam is a maximum of 90 questions in 90 minutes, the passing score is 750 on a scale that runs from 100 to 900, and the five domains are weighted General security concepts 12%, Threats vulnerabilities and mitigations 22%, Security architecture 18%, Security operations 28%, Security program management and oversight 20%. Security operations is more than a quarter of the exam on its own. If you are short on time, that is where the time goes, and no retirement date changes that arithmetic.

The part the date does not help with

Knowing when the exam retires tells you nothing about the thing most people actually lose marks on, which is the performance-based questions.

They sit near the front, they are slower per mark than anything else on the paper, and they ask you to produce rather than recognise. Multiple choice hands you four options and lets recognition do the work. A PBQ hands you an empty firewall table or a set of tiles with nothing to compare against, and recognition has nothing to grab. That gap does not close by rereading, and it does not close by watching video.

Professor Messer's SY0-701 series is free and good on the concepts, and Jason Dion's practice exams will find your weak spots. Neither gives you many real simulations, which is the honest gap in the free material. I built one that runs in a browser with no account, for exactly this: a firewall PBQ you can just do.

Full disclosure, that site is mine. I sat SY0-701 on August 22 this year and passed, studying on it. Because of that, both plans are 50% off with the code PASSED50 through September 6.

All of the exam facts above come from the CompTIA exam pages themselves, which is where I would check again before planning anything on them. Pages move, and this one just did.

Your Gmail cleanup tool found nothing because your mailbox is the wrong shape

TiltedLunar123 — Fri, 04 Sep 2026 09:29:46 +0000

Most inbox cleanup tools ship with the same three searches: promotions, big attachments, anything older than a year. Run one against a mailbox holding 60,000 messages and you can still get a report that says 142 promotional emails and four large attachments. Nothing is broken. The tool asked three questions your mailbox does not answer.

I ran into this building a Gmail cleanup extension, and it took me an embarrassingly long time to see it as a design problem instead of a bug.

Category searches get written before anyone sees your mail

category:promotions, larger:10M, older_than:1y. Those are guesses about what clutter looks like, made by someone who has never seen your inbox. They are good guesses for one kind of mailbox: shopper, newsletter reader, ten years of Black Friday mail.

Plenty of mailboxes are not that. A working mailbox is often tens of thousands of small, ordinary, individually reasonable messages from a few dozen automated senders. Build notifications. Ticket updates. Bank alerts. Delivery notices. School portals. None of it is promotional, none of it is large, and a lot of it arrived last month, so it fails all three searches at once.

category:promotions has a second problem stacked on top. The Promotions tab is a classifier's opinion, not a property of the message. Gmail decides. Anything it decides wrong is invisible to a rule built on that category, and you never notice the miss, because a miss looks exactly like a clean mailbox.

Enumerate senders instead

The question that works on every mailbox shape is not "what category is this" but "who keeps sending me things".

Sender lists survive the shape problem because they assume nothing. A mailbox of 40,000 build notifications and a mailbox of 40,000 retail promos both reduce to a short list of names, and the list is shorter than people expect. Most mailboxes are dominated by a few dozen senders. You can hold that list in your head. You cannot hold 40,000 messages in your head, which is most of why the pile feels unmanageable.

Doing it by hand in Gmail:

Sample. Open a few searches that cut across your mail in different directions rather than by category: older_than:2y, is:unread, after:2026/01/01. Read the sender column, not the subjects.
Count each name that keeps coming up: from:notifications@example.com. Gmail gives you the real total for that search.
Sort your list by that number and work top down.

Step 2 is the one that matters and the one tools get wrong. A page of Gmail results is 50 rows. If something counts what it can see on the page, it is reporting a page, not a mailbox. The number has to come from Gmail's own answer to the from: search.

The trap on the way out

Once you have a ranked list you will want to act on it, and this is where a count quietly stops meaning what you think it means.

Say a row says 4,812 from one sender. You have also, sensibly, told your tool never to touch anything starred, or anything with "invoice" in it. So the run deletes 4,390 and you spend ten minutes wondering where the other 422 went.

Nothing went wrong. The count and the button were measured through different filters. If a row shows you a number, that number has to be measured through the same filters the button applies, or it is describing a mailbox you are not about to modify. The same rule holds by hand: put your exclusions in the search you count with, not only in the delete you run afterwards. from:x -is:starred -invoice is the honest count.

Two things worth keeping

Deleting is not the end of it. A sender that filled your mailbox once will do it again, so whatever you decide about a sender wants to keep applying rather than being a one-off sweep.

And check in:spam from: separately when you audit a sender. Mail that Gmail routed to Spam does not appear in an ordinary from: search at all, so a sender can look like they stopped when they only moved. Be careful what you delete in there, too. Spam has no 30 day Trash window.

I built the sampling and the per-sender counting into the extension because doing it by hand across a few dozen senders is tedious and easy to get wrong. The census and the counts are free and read only. Clearing the senders you tick is the paid part, and it only ever touches senders you ticked yourself. Full disclosure, it is mine: https://chromewebstore.google.com/detail/bmcfpljakkpcbinhgiahncpcbhmihgpc

The by-hand version above works fine without any of that, and it is the part worth taking away either way.

Your Security+ score report lists the objectives you missed, and most people never scroll that far

TiltedLunar123 — Wed, 02 Sep 2026 09:45:13 +0000

Almost everyone who sits a CompTIA exam reads their score report the same way. Find the number, compare it to the cut score, feel something, close the window. On a pass that is fair enough. On a fail it throws away the most useful thing CompTIA will ever hand you for free.

The report does not stop at the number. Under the pass or fail line it says this:

You incorrectly answered one or more questions in the following objective areas:

Then it lists them. Not "Domain 4, Security Operations." The actual numbered objectives with their full titles, the same numbers that appear in the exam objectives document. On a Security+ report that looks like 2.4, 3.1, 4.5 and so on, each with its one line description. I have now seen this on SY0-701 reports and on A+ Core 1 reports, so it is the CompTIA report format generally rather than a Security+ quirk.

That list is a study plan somebody else wrote for you.

What it changes about a retake

Walk into a retake without reading it and your plan is "study harder." Five domains, ninety odd objectives, and no idea which parts actually cost you the exam. Most people respond by rewatching the videos they already understood, because that feels like studying and it is comfortable.

Read it and the plan is different. You have three or four objective numbers. Open the exam objectives PDF, which CompTIA gives away, find those numbers, and look at the sub bullets underneath each one. That is now the whole list of things you need to close. Everything else on the exam you already demonstrated you can do.

The reason it works is that the objectives document is not marketing copy. Every question on the exam maps to a line in it. So an objective number on your score report and a heading in that PDF refer to the same body of material, and the intersection is small enough to actually finish.

The number itself lies to you a little

Security+ passes at 750 on a scale of 100 to 900. That is not 83 percent, and it is not a percentage at all. It is a scaled score, which means the raw count of questions you got right has already been run through a conversion that accounts for the difficulty of the particular form you sat.

Two consequences people get wrong constantly.

First, you cannot work backwards to a question count. Every forum thread has somebody saying "I was three questions off." They do not know that. Nobody knows that. The mapping from raw to scaled is not published and it is not linear.

Second, the distance between your score and the cut is not a distance in questions either. A 723 against a 750 cut is closer than it feels, but closer here means closer in the scaled space, not twenty seven questions.

The same applies elsewhere. A+ Core 1 passes at 675 on 900, Network+ at 720 on 900. Different cuts, same scale, same trap.

Where the report goes quiet

It tells you the objective. It does not tell you the format.

If you lost points inside a performance based question, the report attributes that to whatever objective the PBQ covered. So you can see 1.4 and correctly conclude you are shaky on cryptographic solutions, while the actual failure was that you had never manipulated a drag to match interface under time pressure and burned six minutes on the first one.

That is worth knowing because the fix is different. An objective gap is closed by reading. A format gap is closed by doing the format until it is boring. If your report lists objectives you feel reasonably confident about, that mismatch is the signal, and the honest read is usually that the format cost you rather than the content.

The short version

Open your score report and scroll past the number.
Write down the objective numbers it lists.
Find each one in the exam objectives PDF and study the sub bullets under it, nothing else.
Stop trying to convert your scaled score into a question count.
If the listed objectives are ones you thought you knew, suspect the format rather than the material.

CompTIA hands you a personalised gap analysis after every attempt and charges nothing for it. It is the cheapest thing in the whole certification process and it is the piece people skip.

For the free material: the exam objectives PDF comes straight from CompTIA's Security+ page, Professor Messer's SY0-701 course is on YouTube for nothing, and Jason Dion's practice tests are worth the sale price. Full disclosure on this last one, it is mine. I sat SY0-701 in August and passed, and I built the site I studied on. The performance based question simulator on it is free with no account, which is the piece I could not find anywhere else when I was preparing: Security+ PBQ practice.

You clicked unsubscribe. Nobody checks whether it worked

TiltedLunar123 — Mon, 31 Aug 2026 10:35:54 +0000

Every unsubscribe tool works the same way. You click the button, it sends the request, and the row goes grey. That is the end of it. Gmail does this too. The greyed row means the request went out, and it is very easy to read that as the sender having stopped.

Those are not the same thing, and the gap between them is where the mail keeps coming from.

An unsubscribe is a request, not a switch

The Unsubscribe button Gmail shows next to a sender's name works off the List-Unsubscribe header. When that header is present, Gmail can send the opt-out for you without you ever opening the message. That part is genuinely good, and it beats hunting for the link in the footer, which on a sender who is already ignoring the rules mostly just confirms your address is live.

The header only tells Gmail where to send the request, but what the sender does with it is entirely up to the sender. In the US, CAN-SPAM gives them ten business days to honour an opt-out, so even an honest sender has a legitimate window where mail still arrives. A dishonest one has no technical obstacle at all.

The question worth asking two weeks later is therefore whether they stopped, which is a different question from whether you unsubscribed.

Checking it by hand

Write down the sender and the date you unsubscribed. That is the whole apparatus. Two weeks later, run one search:

from:newsletter@example.com after:2026/08/17

Gmail wants after: in YYYY/MM/DD. If that comes back empty, they stopped.

If it comes back with mail, you have learned something. Now you can delete precisely what arrived after the window closed, rather than nuking the sender's entire history.

Three outcomes people miss

They kept mailing, but it landed in Spam. This is the one that quietly breaks the check. A plain Gmail search does not look in Spam or Trash, so from:them returns nothing and you conclude they stopped. They did not. You have to ask:

in:spam from:newsletter@example.com

Worth knowing before you go tidying up in there: deleting from Spam is not the same as deleting from your inbox. Gmail's control in Spam means gone, with no 30 day Trash window behind it.

They stopped, then started again. Four months later the list gets sold, or the sender migrates to a new platform and reimports an old file. Nobody re-checks a sender they already filed as done, which is exactly why this one survives.

They were never going to mail you in that window anyway. A retailer who mails hard in November and goes quiet in July will look perfectly compliant if you check in July. Silence is not proof. If a sender is seasonal, a clean search says nothing at all, and treating it as a pass is how they end up back in your inbox at Christmas.

Make it a ledger, not a feeling

The reason nobody does any of this is that it is bookkeeping, and bookkeeping loses to a greyed-out row every time. It is two columns though, the sender and the date you unsubscribed, with a third you fill in later when you go back and look. A note file is enough. Even a partial ledger beats the current state, which for most people is a vague sense that they unsubscribed from some things once.

The payoff is that you stop re-deleting the same senders every few months. Deleting mail from a sender who is still mailing you is maintenance work you have signed up for forever. Getting them to actually stop is the thing that ends it.

The version I built

I got tired of doing the bookkeeping, so I put it in a Chrome extension: Gmail One-Click Cleaner. Every unsubscribe it runs is dated, and the ledger is free to keep. After a two week grace window it runs one Gmail search per sender and tells you what actually happened: who stopped, who ignored you, who is landing in Spam where an ordinary search cannot see them, and who stopped and later started again.

It will not invent a verdict from silence either. If a search does not resolve, it says so rather than filing the sender as done.

The extension is open source, and the manual version above costs nothing but a text file. Either way, check the ones you unsubscribed from last month. Some of them did not stop.

RPO, RTO, MTBF, MTTR on Security+: two are promises and two are measurements

TiltedLunar123 — Sun, 30 Aug 2026 10:37:04 +0000

Four acronyms that all describe things going wrong, and every one of them ends in a unit of time. Security+ knows they blur together, and it writes questions that only work if you have them straight.

The fix is not a mnemonic. What helps is noticing that they are not the same kind of number.

Put them on one timeline

Draw a line. Somewhere in the middle, the database server dies. That single point is the incident.

RPO measures backward from it. RTO measures forward from it. MTBF is the gap between this failure and the last one, and MTTR is how long the repair itself took.

Same line. Four different segments. Once you can point at the segment, the question mostly answers itself.

The two you choose

RPO stands for recovery point objective. It is how much data the business agrees it can afford to lose, and it points backward toward the last good backup. Back up every six hours and the worst case is that six hours of work is gone, so a six hour RPO is the most you can honestly claim.

RTO stands for recovery time objective. That one is how long the business agrees it can be down, pointing forward toward the moment service is usable again.

Both are decisions. Nobody measured either one. Somebody in a room decided the company can survive four hours of downtime and one hour of lost orders, and then wrote it down. Which is why they turn up in a business impact analysis rather than on a monitoring dashboard.

The two that get measured

MTBF is mean time between failures: the average run time between one failure and the next. That makes it a reliability number, and it comes out of history. Higher is better.

MTTR is mean time to repair, the average time it actually takes to fix the thing once it has broken. Lower is better.

Nobody chooses these. You collect them. If your server has failed three times in three years, that is your MTBF, whether you like it or not.

The trap

Which two get confused? The question that catches people pairs RTO with MTTR, because both of them sound like "how long until it works again".

RTO is a promise. MTTR is a track record. Those are different species of number, and mixing them is the single most common way to lose one of these items.

Say your RTO is four hours and your MTTR is six. You are not meeting the objective, that gap is the finding, and a question built on those two numbers is usually asking you to spot exactly that. The answer is rarely to buy a faster server. It is that the recovery capability does not match the commitment, so either the capability improves or the commitment changes.

The second trap runs the other way. Given a backup schedule, people confidently work out the RPO and then hand back the same figure for RTO. Backup frequency tells you nothing at all about how long a restore takes. A nightly backup with a 24 hour RPO might still restore in twenty minutes, or it might take two days if the tapes are sitting in an offsite vault.

A scenario, worked

A retailer backs up its order database every four hours. A full restore has historically taken about seven hours. Leadership has signed off on losing at most four hours of orders and being down at most six.

So read the numbers straight off the timeline. The RPO target is four hours and the backup interval is four hours, so that one is met. The RTO target is six hours and the measured restore is seven, so that one is missed.

The finding is the restore, not the backup. That is the whole question, and you can answer it without knowing a single thing about the retailer. Not one thing.

What this looks like on the exam

Expect a short scenario with two or three numbers in it, and four options that each name a different acronym. Which segment of the timeline is the question standing on? That is the entire job, and once you have decided it the arithmetic in the scenario is usually trivial or irrelevant.

So ask two things. Is this number something a person decided, or something the logs reported? Does it point backward toward data, or forward toward service?

That is usually enough to eliminate three of the four options.

Practicing it

These questions reward doing rather than reading, because the confusion only shows up under time pressure. Work scenarios where the numbers are given and the acronym is not, so that you are forced to decide which segment of the timeline you are standing on before you can even name the thing the question is asking about.

Full disclosure, I built this one. There is a free performance-based question at https://secplusmastery.com/security-plus-pbq that runs in the browser without an account. It is a firewall rule ordering item rather than a continuity one, but it drills the same skill, which is reading a scenario for the one detail that decides the answer. The rest of the SY0-701 material is at https://secplusmastery.com if you want it.

Get these four straight and you have picked up free points in a corner of the syllabus most people skim.

Unsubscribing does not delete a single email you already have

TiltedLunar123 — Fri, 28 Aug 2026 11:40:08 +0000

Every inbox cleanup hits the same wall about twenty minutes in. You have deleted a few thousand newsletters, the number went down, and then you notice the same senders are still arriving. So you start unsubscribing instead, and now the number does not move at all.

These are two separate jobs and people keep treating them as one. Unsubscribing is about mail that has not been sent yet. Deleting is about mail that already landed. Neither one does the other's work, but the order you do them in changes how much work there is.

Where Gmail's unsubscribe link comes from

When Gmail shows an Unsubscribe link next to a sender's name, it did not find that link by reading the email. It read a header the sender chose to attach, called List-Unsubscribe. If a sender leaves that header out, Gmail has nothing to show you, and you are back to hunting for grey 8 point text in a footer.

That is worth sitting with, because it reframes the annoyance. "Gmail has no unsubscribe button for this sender" is not Gmail failing you. It is the sender declining to make leaving easy.

There is a second header that matters more: List-Unsubscribe-Post: List-Unsubscribe=One-Click. When both are present, Gmail can send the unsubscribe request itself as a POST, and you never see a landing page at all. Google's own sender guidelines require this of anyone sending more than 5,000 messages a day to Gmail accounts, and say that marketing and subscribed messages must support one-click unsubscribe.

That one requirement explains a pattern you have probably noticed. Some senders drop off the moment you click, and others bounce you to a preference centre that wants you to log in first. The second group is usually either under the threshold or hoping you give up.

Do it in the right order

Unsubscribe first, then delete.

If you delete four thousand newsletters and stop there, you have bought about three months. The senders have no idea anything happened. If you unsubscribe first and then delete, the delete is a one-time job, because nothing is refilling behind you.

People do it backwards because deleting produces a visible number and unsubscribing produces nothing. So the satisfying half goes first, and patience runs out before the half that actually lasts.

The link you should not click

An unsubscribe link inside mail you never signed up for is not an unsubscribe link. It is a delivery confirmation. Clicking it tells the sender that the address is live and that a human reads it, which is the single most valuable thing a list broker can learn about you.

For real spam, report it as spam. That is the signal Gmail uses to change what reaches you, and it costs the same one click.

The header route is safer than the footer link for another reason too. When Gmail sends a one-click unsubscribe, the request goes out from Google rather than from your browser, so you are not loading some arbitrary URL with your email address sitting in the query string.

Pick lists by counting, not by mood

The list you unsubscribe from after one irritating subject line is almost never the one filling your mailbox. Sort senders by how many messages they sent over a window, start at the top, and work down. Most inboxes have a handful of senders responsible for a genuinely surprising share of the volume, and none of them are the one that annoyed you this morning.

That is the part which is hard to do by hand. Gmail will happily show you everything one sender has sent, but it will not tell you how many that is without you paging through and counting.

The tool

I build a Chrome extension for this, Gmail One-Click Cleaner. It has a Mailbox Report that counts your senders before you touch anything, a Storage X-ray for which of them are taking up the space, and bulk unsubscribe that drives Gmail's own controls rather than inventing its own. There are Live, Review and Dry-Run modes, plus a Recovery Log that puts back anything you deleted in one click. The core features are free and the source is on GitHub.

None of that changes the order, though. Unsubscribe first. The deleting is the easy half.

Export your Discord messages in the format you will actually use

TiltedLunar123 — Thu, 27 Aug 2026 11:07:40 +0000

Deleting your own Discord history is one of the few things online that is genuinely permanent. The messages are gone, and there is no trash folder to fish them back out of. So most guides tell you to export first, which is correct and also not very helpful, because they stop before the part that matters: which format, and what you plan to do with it.

Three formats show up in tools that do this, and they are not interchangeable.

HTML is for reading

An HTML export is a self contained page you open in a browser. Messages stay in order, timestamps stay readable, and threads still look like conversations. This is the right choice if the reason you are exporting is that you might want to read something again: a decision that got made in a channel, a recommendation someone gave you, the context around an argument. It is the worst choice if you plan to search across years of messages, because you are back to Ctrl+F on one enormous page.

JSON is for processing

JSON keeps the structure. Message IDs, author IDs, channel IDs, timestamps, attachment URLs. If you want to count anything, chart anything, feed it into a script, or rebuild a timeline, this is the only format that survives the trip. The cost is that raw JSON is close to unreadable, and it is keyed by IDs rather than names, so a channel you remember as general is a nineteen digit number.

CSV is for filtering

CSV opens in a spreadsheet, and a spreadsheet is a surprisingly good message browser. Sort by date, filter by channel, search a column, delete the rows you do not care about. If your actual question is which of these do I need to keep, CSV answers it faster than either of the others. It loses nested structure and it handles multi line messages badly, which is why it is not the archive format.

For most people the answer is HTML plus JSON. HTML because you will actually open it, JSON because it is the one you cannot regenerate later.

The order of operations matters more than the format

Export, then filter, then review, then delete. People collapse the middle two and regret it. Filtering narrows the set. Reviewing is where you catch the thing you did not mean to include. A tool that jumps straight from select a channel to delete everything has removed the only step that was protecting you.

This takes longer than you expect

Discord rate limits message deletion, and it should. Clearing several thousand of your own messages is not a one minute job, and anything promising otherwise is either wrong or about to get your account flagged. Budget the time, leave the tab open, and treat speed claims as a warning sign.

The part that is actually a security question

Anything that manages your own Discord messages needs your session, because Discord does not offer a scoped way to hand a third party permission to delete your messages for you. That makes where does my session go the question worth asking, and you can answer it before you install anything. Read the permissions the extension requests. Check whether the source is published. Check whether the tool talks to any server other than Discord's.

I built one of these, so the disclosure belongs here. Clearline is a free extension for searching, exporting and bulk deleting your own Discord messages. It asks for one permission, storage, which it uses to remember a single tab number. The token stays in tab memory and never leaves the browser, there is no account and no server of mine in the path, and the source is MIT on GitHub so you can check all of that instead of taking my word for it.

It only ever touches messages you wrote. That is a limit rather than a missing feature, and it is the correct one.

On a Security+ firewall PBQ, a correct rule in the wrong row is a wrong answer

TiltedLunar123 — Tue, 25 Aug 2026 09:19:35 +0000

Most people studying for SY0-701 prepare for the firewall PBQ by memorizing port numbers. Then they get one and find the port numbers were handed to them in the requirements, and the thing being tested is something else.

Here is what actually gets graded.

The list is evaluated top to bottom, and it stops

A firewall rule set is not a set. It is an ordered list. The engine walks it from the top, and the first rule that matches the traffic is the one that runs. Nothing below that rule is consulted for that packet.

That one sentence produces most of the wrong answers on these questions. If you write a rule permitting HTTPS from the finance subnet, and three rows above it there is a rule denying everything from that subnet, your rule is correct and it will never execute. It is dead. The grader does not care that you knew 443.

So the working question when you place a rule is not "is this rule right", it is "does anything above this rule already match this traffic".

Specific goes above general

The practical version of the ordering rule: narrow rules on top, broad rules underneath.

If one requirement says block all traffic from the guest network and another says allow the guest network to reach the DNS server, those two conflict on purpose. The exam is checking whether you noticed. The allow has to sit above the deny, because it is the more specific of the two. Put the broad deny first and the exception you were asked for stops existing.

Any time two requirements touch the same source or destination, one of them is meant to be an exception to the other, and the exception goes higher.

There is already a deny at the bottom

Every firewall has an implicit deny as its final behavior. Traffic matching no rule is dropped. You do not have to write that.

People write it anyway, because a deny-all at the bottom feels like closing the door. It is harmless in production and it is a tell on the exam: it says you are treating a rule list like a checklist rather than an evaluation order. There is a practical cost too. If the interface gives you five rows and you spend one on a rule the engine already performs, you may not have room for a requirement you actually needed.

The exception is logging. An implicit deny is silent, so if the requirements ask you to log dropped traffic, an explicit deny at the bottom is doing real work. If they do not, leave the row empty.

Read the requirements as the answer key

The requirements list is not context. It is the marking scheme, written out.

Read all of it before you touch a field. Count the requirements. If there are four, you are looking for four rules, and if you have written six you have invented two. Then work them in the order the ordering rule demands rather than the order they are printed in, because they are almost never printed in the order they need to be applied.

The requirements also hand you the fields. "The web server must be reachable from the internet over an encrypted connection" gives you the destination, the port and the action. You are not recalling 443 from memory. You are reading the word encrypted and picking it off a dropdown.

Partial credit is real, so never leave a row empty

CompTIA says partial credit may be given on performance-based questions. A half-finished PBQ still scores. A blank one is a guaranteed zero, and a wrong answer and an empty box are worth exactly the same thing.

That makes the strategy obvious, and almost nobody follows it: fill every field, including the ones you are guessing on. Stuck between two source addresses? Pick one and move on. Then flag the question, bank the multiple choice, and come back if the clock allows.

One more timing note. PBQs usually load at the front of the exam. Up to 90 questions in 90 minutes means they can eat fifteen of your minutes before you have scored a single easy point, so skip them on the first pass if they are not coming quickly.

Try one

You can read all of this and still freeze the first time you see the interface, because the interface is the part nobody practices. I built a free configuration PBQ in the exam's style: four firewall requirements, graded with partial credit, feedback on every field, no account needed. It is at https://secplusmastery.com/security-plus-pbq

It is mine, so weigh that as you like. Professor Messer's free SY0-701 series and Jason Dion's practice exams are the two things I would put alongside it.

Gmail bulk delete counts conversations, not emails

TiltedLunar123 — Sun, 23 Aug 2026 10:48:23 +0000

Gmail tells you exactly what it is about to do, in a sentence almost nobody reads. You run a search, tick the box at the top of the list, and a small line appears:

Select all conversations that match this search.

Conversations. Not emails. That one word is the difference between a clean inbox and a hole where a project used to be.

A search matches a thread, not a message

In conversation view, Gmail's unit is the thread. A search hits a conversation if any single message inside it matches, and the whole thread comes back as one row.

Most of the time this is harmless, because the mail you want gone does not thread. A newsletter, a receipt, a shipping notification and a no-reply alert are almost always one message each, so one row really is one email. That is why category sweeps behave the way you expect:

category:promotions older_than:1y
from:no-reply older_than:6m

Size sweeps are the ones that bite:

larger:10M older_than:2y
has:attachment larger:5M

A 40 message thread with your team, where one person attached a 12 MB PDF somewhere in the middle, matches larger:10M. It appears as a single row. Select it, hit delete, and all 40 messages go to Trash, including the replies you wrote yourself, because your sent mail lives inside the thread too.

So the row count is not the message count, and the two can differ by an order of magnitude in either direction. You can delete 200 rows and remove 2,000 messages.

Turn conversation view off before a risky sweep

Gmail has a setting for exactly this, and it is reversible and non-destructive.

Settings, See all settings, General, Conversation view: off.

Nothing gets deleted and nothing gets permanently unmerged. The display changes to one row per message, which means the number in the results is the number you are actually selecting. Run the size sweeps with it off, look at what is really there, then turn it back on when you are done.

If you only want one message gone and the rest of the thread kept, Google's route is to open the conversation, find the message, click the down arrow next to Reply at the top right of that message, and delete just that one.

Threading is not what you think either

Subject line alone does not thread two messages. Since 2019 Gmail also wants the incoming message's References header to point at IDs of earlier messages in the thread. Two unrelated emails from the same sender with the same subject often stay separate, and a long thread can split if a client along the way mangles the headers.

The practical consequence is that your mental model of "this is all one conversation" can be wrong in both directions, which is another argument for looking at the flat view before a bulk action rather than after.

The rule that falls out of this

Sender and category based cleanup is low risk because that mail does not thread. Size based cleanup is high risk because big attachments cluster in exactly the long human threads you want to keep.

If you take one thing from this: do your storage recovery by sender first, and only go hunting for large attachments once the easy stuff is gone and you can afford to check each hit individually.

Full disclosure, I build a Chrome and Firefox extension in this space, Gmail One-Click Cleaner. It leans on the same logic: the preset sweeps are the sender and category ones, it shows a Mailbox Report of what it found before anything is deleted, and it keeps a recovery log so a bad sweep is one click to undo. There's a Firefox build as well. It runs locally and never sends your mail anywhere.

But the setting toggle above costs nothing and works whether you use any extension or not. Flip it before your next big delete.