DEV Community: TiltedLunar123

Your firewall log knows a connection happened and nothing about what it carried

TiltedLunar123 — Wed, 19 Aug 2026 11:21:13 +0000

Security Operations is the biggest domain on Security+ SY0-701, at 28 percent. Threats and Vulnerabilities is 22. Security Architecture is 18. A good share of that biggest domain is scenario questions where something has already gone wrong and you have to say which data source can answer the question in front of you.

Most people study the attacks and skip the artifacts. Then the exam hands them a breach and four log types, and asks which one saw it. Can you say why three of them could not have?

Every log is a witness with a fixed vantage point

The question is never which log is best. It is which log was standing somewhere that it could have seen the thing being asked about. Read the options that way and most of them eliminate themselves.

Here is the vantage point of each source, and, more useful, the boundary where it goes blind.

Firewall logs. A connection was allowed or denied between two addresses and ports at a particular time. That is the whole story. It does not know what traveled inside the connection, and if the traffic was encrypted then nothing about the payload was ever available to it. Very good for "did this host ever talk to that address." Useless for "what did the attacker run."

Endpoint and OS security logs. Processes that started, and accounts that logged on. Privileges that got used, on that machine. This is where "what did the attacker actually do" lives, and it is where you find which account was used. It is blind to any host that was not running an agent, which is the second half of most exam scenarios.

Application logs. The event in the application's own terms. There is no other source that knows which query ran or which record was touched. Blind to everything happening outside that application.

IDS and IPS logs. A signature matched. Notice what that sentence claims and what it does not. It tells you what the sensor thinks it saw, which is a claim about a pattern rather than a statement about impact. A high severity alert on a blocked attempt and a high severity alert on a successful one look much the same in the log.

Network flow logs. Who talked to whom, and how much. This is the source for exfiltration volume questions, because it can show three gigabytes leaving at two in the morning without knowing a byte of what was in it.

Packet captures. Everything, at the cost of storage and of having decided to capture before the incident. When a question offers a capture, check whether the scenario ever said anyone was capturing. Often it did not, and that is the trap.

Metadata. Headers without content. In an email scenario that is the routing and the addresses, with none of the message body.

The test that resolves most of these items

Read what the question is trying to establish. Then ask whether the artifact was positioned to observe that specific thing. If the question is about content and the artifact only records connections, that option is wrong, no matter how sensible it looks sitting in the list.

Two traps live in the gap between those two sentences.

The first is picking the source with the most data instead of the one with the right vantage point. Packet capture is the most complete answer on paper and the wrong answer most of the time, because nobody had it running.

The second is treating an absence of events as evidence that nothing happened. A host with no logging agent produces no events, whether or not it was compromised. Exam scenarios lean on this. So does real work.

Why firewall logs are the ones people misjudge

Of all of these, the firewall log is where I see the most confusion, and I think the reason is that people learn firewalls as a concept and never read a rule set as a document.

A rule set is evaluated in order. The first rule that matches wins, and everything below it never runs. So a broad allow sitting above a specific deny means the deny is decoration, and the log will faithfully record the traffic being permitted with no hint that a rule further down was meant to stop it. Read as a list of decisions, those entries make sense. Read as a mystery, they do not.

The fastest way to fix that is to work an actual rule set rather than read about one. I built a free firewall exercise that runs in the browser with no account, at secplusmastery.com/security-plus-pbq. It is mine, so weigh it accordingly. Professor Messer's free SY0-701 series and Jason Dion's practice exams come at the same ground from the other direction.

One study move worth the time

Pull the V7 objectives from CompTIA's Security+ page. The form there hands them over along with a practice test, in exchange for an email address. Find the objectives that deal with data sources and investigations. For each source listed, write one sentence saying what it can prove and one saying where it goes blind.

Fourteen sentences, maybe twenty minutes. It converts a memorized list into a decision you can make under a clock, which is the only form of it the exam will accept.

Deleting 5,000 promotional emails freed less space than deleting 40

TiltedLunar123 — Mon, 17 Aug 2026 10:20:13 +0000

Every Gmail cleanup tool, mine included, shows you a count of messages. Google's storage bar shows you bytes. People assume those two numbers track each other. They barely do, and the gap is why a satisfying afternoon of deleting can leave the storage bar where it started.

Here is the arithmetic, with the assumptions stated so you can argue with them.

A marketing email is mostly HTML and links to images hosted elsewhere. Call it 50 KB, which is generous. Five thousand of them comes to roughly 250 MB. There is also the email with a 25 MB video attached, and that single message is worth 500 promotional emails. Forty messages like it is around a gigabyte, which is 20,000 promotional emails.

So the sweep that clears five thousand things and the sweep that clears forty things can free wildly different amounts of space, and the forty usually wins by a factor you would not guess.

Two goals wearing the same clothes

There is a reason this keeps surprising people. "Clean my inbox" is really two jobs wearing one label.

The first job is findability. Too much mail means you cannot find the thing you need, and the fix is volume, so you delete or archive the thousands of low-value messages. Count is the right unit here. Clearing 5,000 promotions genuinely helps, and the storage bar sitting still is irrelevant to whether it worked.

Bytes are the second job. Google says you are full and you want that to stop. Here the message count is the wrong unit entirely (forty of them can settle it).

Most cleanup advice quietly optimises the first and gets judged on the second.

Querying for bytes instead of messages

Gmail's documented operators for this are size:, larger:, smaller:, has:attachment and filename:. The ones that matter here are larger: and smaller:, which take values like larger:10M.

Do not try to get an exact size for each message. Gmail will not give you one in the list view, so any precise total you compute is a reconstruction. Work in tiers instead:

larger:25M
larger:10M smaller:25M
larger:5M smaller:10M

Three searches, three counts. Multiply each count by its floor and you have an "at least N MB" figure that is defensible, which is the most honest number available to you.

Then attribute it to a sender

This is the step that gets skipped, and it is the one that turns a measurement into an action.

Take the larger:10M results and look at who sent them. Heavy mail is almost never scattered randomly, it clusters. There is usually one office scanner that mails a PDF of everything it touches, and one service that attaches a report every Monday. My own worst offender was a single thread where six people replied to a 30 MB deck and every reply carried the deck along with it.

That clustering is the useful part, because a sender is something you can write a rule about. A single 22 MB email is not a rule, it is a chore. Cross the two:

larger:10M from:scanner@example.com

Now you have a target that has a name and a count (plus a reason it exists in the first place).

The guardrail this needs more than promotions do

Attachments are the one place where the thing you delete may be the only copy in existence. Nobody has ever regretted deleting a 2023 flash sale. People do regret deleting the only copy of a signed lease.

So put a floor on it:

larger:10M from:scanner@example.com older_than:1y

And run it as a count first. The ordering that works: measure by tier, then attribute by sender, and only then delete oldest first behind an age floor. Trash gives you about 30 days of grace if you get it wrong, which is a safety net rather than a plan.

The short version: if the storage bar is the thing bothering you, stop counting messages. Go find the forty.

If you would rather not run three searches and tally them by hand, the extension I build does the tier walk and the sender attribution for you and shows the whole ranked list for free: Gmail One-Click Cleaner. Full disclosure, it is mine. The numbers it reports are floors, for the reason described above.

Every official way to delete your own Discord messages, and where each one stops

TiltedLunar123 — Sun, 16 Aug 2026 10:21:36 +0000

I went looking for this after deciding to clear years of my own posts out of a server I had stopped using. The answer turned out to be more restricted than I expected, and the restriction is written down in Discord's own privacy policy rather than buried in some undocumented behavior.

Route 1: delete them by hand

Hover a message, click the three dots, Delete, confirm. That works, and it is the only route Discord actually endorses.

There is no multi-select. No shift-click a range, no "delete all my messages in this channel", no bulk action of any kind for your own history.

For thirty messages that is fine. For four years in a chatty server it is not a workflow, it is a hobby.

Route 2: leave the server

Does nothing at all to your messages. They stay in the channels, still attributed to you, still searchable by everyone who is still in there.

This is where the clause that matters lands. Discord's privacy policy says you can edit or delete any message you have sent "if you still have access to the space where you posted it."

That conditional does most of the work in this entire topic. Deletion is not a right attached to the message, it is attached to your current access. Leave the server, get kicked, get banned, or watch the channel get deleted, and your own words are permanently out of your reach. There is no "my messages" view that spans servers you are no longer in.

The practical consequence is a sequencing one. If you are thinking about leaving somewhere, the cleanup has to happen before you go, and there is no undo afterwards.

Route 3: delete your account

This is the one people assume is the nuclear option. It isn't.

Discord's privacy policy describes account deletion as permanently deleting identifying information and anonymizing other data. Your messages are the other data. They stay in the channels where you posted them, and what goes away is the connection between them and you. The account renders as a deleted user, the content sits where it was.

Whether that is enough depends completely on what you were worried about. If the worry is your name sitting next to old posts, it helps. If the worry is the content itself, because you posted an address or a phone number or something you regret in a public server, deleting your account does not remove any of it.

The policy is also explicit that content may be retained, and that in limited circumstances there is a legal obligation to keep certain information even after you delete it or your account.

Route 4: request your data

Under Data and Privacy in User Settings you can request a copy of your data. It is worth knowing what this actually is: it sits under accessing your information in the privacy policy, not under deletion. It is an export. You get an archive of your own messages, which is genuinely useful as a record, and nothing on Discord's side changes.

Requesting your data before you delete anything is a good idea. Mistaking it for a deletion is not.

What that leaves

Add those up and the picture is fairly clear. You have a real deletion right, it is scoped to spaces you can still reach, and the interface for exercising it is one message at a time.

So anything that clears history at any scale is necessarily doing the same per-message delete the interface does, from a session that still has access. There is no bulk endpoint to call and no OAuth scope that grants this, which is why everything in this category runs out of your own browser session instead of as a normal integration.

I ended up writing one, because I wanted the archive and the cleanup in a single pass. Clearline is free and MIT licensed. It connects to a Discord tab you already have open, lets you filter by text or date range, shows you the matched messages before anything happens, then exports and deletes. It only ever touches messages you wrote yourself. The token stays in the browser, there is no account and no server behind it, and the permissions are storage plus discord.com.

The caveat is on both listings and it is a real one: automating a user account is against Discord's terms of service. That applies to everything in this category, and pacing the requests lowers the odds of trouble without removing them.

The part worth keeping, though, has nothing to do with tooling. If there is a server you are planning to leave, do the cleanup first. That clause about still having access is the only piece of this that cannot be worked around later.

On Security+, an access control question is really asking who is allowed to say yes

TiltedLunar123 — Fri, 14 Aug 2026 10:35:28 +0000

Access control models are one of those objectives that look like pure memorisation and then turn up as a scenario where four acronyms all sound defensible. DAC, MAC, RBAC, ABAC, rule-based. Everyone learns the expansions. Then the question describes a company doing something perfectly reasonable and asks which model that is. So which is it? The expansions do not help you here, because every one of them is about controlling access.

There is one question that sorts them, and it has nothing to do with what the model does. Ask who or what gets to make the decision, and whether anybody is able to overrule it.

DAC: the owner decides

Discretionary means at somebody's discretion, and that somebody is whoever owns the resource. You made the file, so you pick who reads it. Windows NTFS permissions work this way. So do Google Drive share links. Simple enough.

The tell in a scenario is a person granting access to their own stuff without asking anyone. "A user shares a folder with a colleague." That is DAC. Nothing more to it. The security complaint about DAC is baked right into the definition, too, because the decision sits with whoever happens to own the object, and owners can be talked into things.

MAC: the system decides, and the owner cannot override it

Mandatory means the policy is not up for negotiation. Access comes from labels. The resource carries a classification, the subject carries a clearance, and the system compares the two. If your clearance does not reach the label you do not get in, and neither the owner nor your manager is able to hand it over.

Scenario tells: classification levels, clearances, anything that smells of government or defence work, SELinux.

There is a better tell than any of those, though. Did the file owner try to share something and get refused? That is MAC. Under DAC the owner would have succeeded.

RBAC: your job decides

Permissions attach to roles rather than to people. You are in the role, so you inherit the permission set that comes with it. A new nurse starts, gets put in the Nursing role, and can now do everything the last nurse could do.

What is the tell here? A job title or a department doing the work. "Members of the accounting team can access the general ledger." Notice that the permission belongs to accounting and not to a named human. That is also why RBAC is the expected answer on questions about onboarding and offboarding at scale, and on permission creep, since the fix for somebody who has accumulated access across three different jobs is roles.

ABAC: the conditions decide

Attribute based access control evaluates properties at the moment of the request. Department, device, location, time of day. Policies get written as combinations, so a rule might allow finance staff on a corporate device during business hours and nobody else.

This is the model people miss, and the tell is very easy once you have seen it. If the scenario contains a condition that could differ between two requests from the same person, it is ABAC. Same employee, allowed at 10am from the office laptop and denied at 11pm from a personal phone. Nothing about their role moved in those thirteen hours. The attributes did.

Rule-based: one rule set, applied to everybody

The rules here have nothing to do with who you are, and they apply across the board. Firewall access control lists are the everyday example. A packet arrives, the list gets evaluated top down, first match wins, and nobody's job title enters into it anywhere.

This is where the model questions and the network questions meet. It is worth practising the mechanic rather than the definition, because firewall rule ordering is also a favourite performance based question, and the thing that catches people out is not syntax at all. A broad permit sitting above a specific deny means the deny never gets reached. The rule is right there in the config and it may as well not exist. If you want reps on exactly that, I built a free browser based firewall PBQ with no account needed at Security+ PBQ practice. Fair warning, the site is mine.

The distractors that are not models at all

Least privilege, separation of duties and job rotation all show up in the answer options for these questions. They are principles. There is a real difference, and the exam leans on it in order to build distractors that feel correct.

A question asking which access control model is in use has an answer that is one of the five above. One that asks which principle was violated is a different beast wearing similar clothes. So read the stem for the word model. Every time.

The short version

Ask who says yes.

The owner says yes: DAC.
The label says yes: MAC.
The job says yes: RBAC.
The conditions say yes: ABAC.
The rule list says yes: rule-based.

If two options still look right after that, go looking for the override. Whether the owner is able to hand out access separates the first two. Whether the answer changes between two requests from the same person separates the middle two.

Gmail's Promotions tab is a guess your cleanup rule treats as a fact

TiltedLunar123 — Wed, 12 Aug 2026 10:21:35 +0000

Almost every Gmail cleanup starts with the same rule:

category:promotions older_than:6m

It reads like a filter on a property of the message, when what it really filters on is a prediction, and bulk delete treats predictions and facts exactly the same way.

What category actually is

Google's help page is blunt about it. Gmail "automatically sorts your emails into these categories", and if you find something in the wrong one, "you can move it. Over time, this helps Gmail learn your preferences and sort your email more accurately."

Read that second sentence again. Slowly. It is describing a classifier that has been training on your behavior for as long as you have had the account, which means your category:promotions and mine do not hold the same kinds of mail, and neither one matches the shape either of us would draw on a whiteboard.

That is fine while you are searching, though only because a search is read only and being wrong costs you a scroll. It stops being fine the moment the same string drives a delete, since now every misfiled message is gone and you never read the batch it left in.

The mail that gets caught

The predictable casualties are order confirmations and receipts, since those arrive looking exactly like the mail around them. The classifier reads sender shape as much as content, and a receipt from a big retailer arrives through the same marketing pipes as that retailer's newsletters, so it lands next to them and your rule takes both.

Will you notice? Almost certainly not, and that is the actual problem. Four thousand newsletters and eleven receipts look identical as a number on a progress bar.

Two things in Google's own docs that fix most of this

First, there are more categories than the tabs show you. Google's operator reference lists two beyond the familiar five, and they hold roughly the receipt and booking mail you least want to lose. Subtract them:

category:promotions older_than:1y -category:purchases -category:reservations

One line. It removes the worst class of mistake before anything moves, and it does that because you are naming the exceptions instead of hoping the classifier got them right.

Second, archived mail does not appear in categories. Google states that plainly on the same help page. It is easy to miss. Every category based sweep silently skips everything you already archived, which on an old account is usually the largest pile you own. Run a big cleanup and watch your storage number barely move? This is normally why.

Size searches avoid the trap entirely. That is because size is a real property of a message rather than an opinion about it:

has:attachment larger:10M older_than:1y

The rule I would actually give you

How do you tell a safe operator from a risky one? Split them into two buckets, because the difference is not subtle once you look for it.

Facts about the message: larger:, older_than:, has:attachment, from:. These stay true no matter what any model thinks, so automate them freely. No caveats.

Opinions about the message: category:, is:important. These are guesses that get personalized to you while they quietly drift over time. Use them anyway, though run them read only the first time. Sort oldest first and page through looking for reference numbers, because that is exactly where the receipts hide.

Then protect at the subject level for words like invoice and confirmation, since those catch the receipts that slipped categories entirely.

And whatever does the deleting, make sure it labels the batch before it moves it. Gmail gives you no batch undo, so once four thousand messages are sitting in Trash beside mail you binned yourself, nothing tells them apart. The label applied on the way out is the only thing that makes the run reversible.

That last point is the one I care most about, and it is why the cleaner I build tags every run before touching anything and keeps a recovery log with one click restore. Full disclosure, that one is mine: Gmail One-Click Cleaner. The mailbox report and the storage breakdown are free, and the source sits on GitHub if you would rather read it than trust it.

The operators above are yours either way. Run them read only tonight and see how much of your Promotions tab is genuinely promotional.

Deleting your own Discord history is a rate limiting problem, not a delete problem

TiltedLunar123 — Tue, 11 Aug 2026 09:53:03 +0000

Discord lets you delete a message. One message. Hover over it and pick delete from the menu. Now do that four thousand times. Enjoy your afternoon.

I built a browser extension to do it properly, and the interesting part was not the deleting. Deleting is a single HTTP call. The interesting part is everything around it, because three constraints show up immediately and each one bends the design.

There is no API for this

Start here, because it shapes the rest. Discord has no OAuth scope letting an application read or delete your own message history. Bot tokens do not help either. A bot can manage messages in a server that invited it. Different problem, different permissions. It certainly cannot go and read your DMs from 2019.

So anything in this category works from the session your browser already holds. Worth being blunt about rather than glossing over, because a user should understand it before installing anything. In Clearline the session is read from an open Discord tab, and only when you click Connect. It then stays in that tab's memory. It is never written to storage. Ever. And discord.com is the only host the extension can reach at all, which is enforced at build time rather than by policy.

If you are evaluating any tool that does this, those are the two questions: where does the token live, and what else can this thing talk to?

Authorship has to be checked on every single message

The naive version is simple enough: search for messages by me, then delete them all.

The problem is that search returns things attributed to you that nobody can delete. Join notices and similar system messages carry your name. They come back in results. They also refuse every delete you send at them. Nobody is allowed to remove them.

Count those in the total and you have promised someone 4,000 deletions. The run then finishes with a stack of failures and a headline number that never made any sense in the first place. Bad experience. Worse still, it teaches people to ignore the failure report, which is the one thing you want read.

So the count has to exclude them up front. Clearline names them separately and leaves them alone rather than promising more than it can deliver. The report afterwards also separates what failed from what was skipped, since those are entirely different things, and lumping them together buries the handful of genuine errors underneath a wall of items that were never eligible for deletion in the first place.

The rate is the actual engineering problem

So what actually breaks first? You can write a loop that deletes 4,000 messages. It works. For a while. Then you start collecting 429s. Keep going and you earn an IP block that lasts an hour.

So every request goes through one queue, one at a time, with a delay between writes that the user cannot lower. Rate limit responses get read and honoured rather than retried blindly. Four in a row stop the run outright. Why stop, rather than simply back off further? Because at that point you are not unlucky. You are being told to stop, and continuing to generate them is precisely what turns a slow but entirely survivable job into an address that cannot talk to Discord for the next hour.

And the subtler version of the same bug? Two tabs. A second tab is a second queue. The service sees the sum. All that careful pacing is now running at exactly double the rate you designed. Clearline allows one working tab at a time; a second tells you so and offers to take over.

What falls out of all this

Once you accept that runs are slow and interruptible, the safety design mostly writes itself. You cannot reach the delete button without first seeing a count and the messages behind it. Runs over a hundred ask you to type the count back. Any run can be paused or stopped mid flight.

Order matters most at the end. The export is saved before the first deletion rather than alongside it, so that if the export is going to fail, it fails while the messages still exist. That ordering is the single most important decision in the whole thing, and it is the one I would keep if I had to throw out every other safeguard.

The honest caveat

Automating a user account is against Discord's terms of service, and people do get actioned for it. Careful pacing lowers the odds. It does not remove them. If losing the account would be a serious problem, export first and decide afterwards whether the deletion is worth it.

Clearline only ever touches messages you wrote yourself. It is free and MIT licensed. There is no account and no server behind it, and no telemetry anywhere in it.

It is not affiliated with, endorsed by, or connected to Discord Inc.

Security+ SY0-701 names three SSO protocols, and Kerberos is not one of them

TiltedLunar123 — Sun, 09 Aug 2026 10:43:11 +0000

I went through the official SY0-701 objectives document looking for the authentication protocols, expecting the usual lineup. Kerberos is not in it.

No objective mentions it, and neither does any sub-bullet. The acronym list at the back runs to 322 entries and includes things as obscure as Work Order and Gnu Privacy Guard, so I checked there as well, on the assumption that a protocol that old and that widely deployed had to be sitting somewhere in the document. It is not. The word appears nowhere.

That surprised me enough to go through the rest of the authentication material line by line, comparing every protocol I had been taught to expect against what the document actually lists. So what is really in there?

What the document says

Objective 4.6, identity and access management. Under single sign-on there are exactly three entries, and they are LDAP (Lightweight Directory Access Protocol), OAuth (Open Authorization) and SAML (Security Assertions Markup Language). Nothing else sits under that heading.

Objective 3.2, securing enterprise infrastructure. Port security has two sub-bullets, 802.1X and Extensible Authentication Protocol. They sit together because they work together.

Objective 4.1, common security techniques. Wireless security settings list WPA3, then AAA and Remote Authentication Dial-In User Service, then cryptographic protocols and authentication protocols.

So RADIUS is there. Once, in a wireless context. TACACS+ turns up only in the acronym list, never attached to an objective. Kerberos is absent.

The caveat, before anyone books an exam on this

CompTIA prints a disclaimer near the front saying the example lists are not exhaustive and that other technologies may appear on the exam. That disclaimer is real and you should take it seriously.

So is this a permission slip to skip Kerberos forever on the strength of a ctrl+F? No.

What it gives you is a map of where the weight sits. That is a different thing, and confusing the two is how people end up with a very confident and very wrong study plan.

Why your study material disagrees

Security+ has been through a lot of versions. Study material gets inherited and lightly reworded, then resold. A large amount of the authentication content floating around was written for older objectives, or borrowed wholesale from networking courses where the RADIUS versus TACACS+ comparison genuinely is a headline topic.

That is how you end up three days out from your exam memorising ticket-granting-ticket flow diagrams. The exam you booked lists LDAP, OAuth and SAML. You are revising for a different one.

I have watched people do this with ports too. How many do you actually need? Somebody learns sixty of them because a video said to, when the objectives name a handful.

What to study instead, and the shape of the question

The SSO three. The trap here is treating OAuth as authentication. Look at what the letters actually stand for: open authorization. SAML is the one carrying an authentication assertion, and LDAP is the directory you query. A scenario about letting a partner company's staff in without creating accounts for them is pointing at federation and SAML. A scenario about an app acting on a user's behalf without ever holding their password is pointing at OAuth. Same family, different jobs.

802.1X and EAP. Learn them as a pair, because the objectives list them as one. 802.1X is the framework that decides whether a port opens. EAP carries the actual authentication conversation inside that framework. Question shape: a device plugs into a wall jack and lands nowhere until it proves who it is.

RADIUS. It is filed under wireless settings, alongside WPA3. Learn it in that context.

The technique, which is the part worth keeping

Download the objectives PDF. It is free, it sits on CompTIA's own site, and almost nobody studying for this exam has actually opened it.

Then search the document before you commit a week to anything. A term that appears in an objective is core. One that shows up only in the acronym list needs nothing beyond knowing what it stands for. Anything missing from the document altogether? That goes in your last-week pile.

This works in both directions, which is the useful part, because it also catches things you were about to skip. Attestation sits in 4.6 and I would bet most candidates could not define it.

The one thing the document cannot tell you

Objectives are a list of topics. Nothing more. They cannot show you what a performance-based question feels like when the clock is running and you are being asked to configure something rather than recognise a term.

That format is worth meeting before exam day rather than during it. Professor Messer's free series is the standard no-cost path for the content, and Jason Dion's practice sets are the usual paid one. For the PBQ format specifically I built a free firewall one that needs no account, at secplusmastery.com/security-plus-pbq. Full disclosure, that one is mine.

Go and read the objectives document. It takes an hour and it will probably delete something from your study plan.

Gmail search can't tell you how big an email is, so every exact storage number is a guess

TiltedLunar123 — Fri, 07 Aug 2026 09:47:00 +0000

Gmail will not tell you how big an email is. It will only tell you one thing: whether that email is bigger than a number you picked.

That sounds like a small distinction. It is not, because it is the reason that every "you can free up 2.3 GB" figure you have ever seen in a mail cleanup tool is really a guess wearing a decimal point.

The search index answers yes or no

Gmail search gives you size operators. larger:10M and smaller:5M both work, and so does size:1000000 if you would rather think in bytes (most people never touch any of them, which is a shame, because they are genuinely useful).

But look at what comes back. A list of messages. That is it. Not one of them carries a size anywhere in the result row. You asked a threshold question, so you got a threshold answer: these are the ones over your line, and that is all.

So if larger:10M returns 40 messages, what do you actually know? Only that those 40 messages account for at least 400 MB between them. The real figure could be 400 MB; it could just as easily be 3 GB, if a handful of them turn out to be 200 MB video attachments. Search will not tell you which, because you did not ask a question that it can answer that precisely.

So what do you report instead?

Once you accept that, the honest unit changes. Not totals. Floors.

"At least 400 MB" is a true statement that you can act on. "You will free 437 MB" is a number somebody made up, by picking a plausible average and then multiplying by it. The average is doing all of the work there, and nobody ever tells you which average they used.

I care about this because I maintain a Gmail cleanup extension, and it was very tempting to print the nicer number. Precise figures feel more trustworthy, though they are also the easiest thing in the whole product to be quietly wrong about. And you would never find out, because you cannot check Gmail's arithmetic either.

Walking the tiers without double counting

Here is the part worth stealing regardless of what tool you use. You can get a much better floor by walking down in tiers instead of asking one question:

larger:25M
larger:10M -larger:25M
larger:5M -larger:10M

The negation is the whole trick. Every message over 25 MB also matches larger:10M, and larger:5M as well, so three plain searches would count your very worst offenders three times over and hand you a wildly inflated total. Excluding the tier above means that each message lands in exactly one bucket.

Now the floor gets tighter. Everything in bucket one is worth at least 25 MB; everything in bucket two, at least 10 MB; and so on down the list. Multiply each count by its tier and total it up; what you have at the end is a defensible minimum rather than a vibe.

But who is actually doing this to you?

Counts are interesting; names are actionable. So bolt a sender onto each tier:

larger:5M -larger:10M from:reports@somevendor.com```

Run that across your top few senders and the picture usually resolves fast. It is rarely a thousand small things; it is one automated report with a PDF attached, arriving every Monday for four years, or a family member who sends photos as attachments instead of links.

Two caveats worth naming, because they bite people. Ready?

Deleting does not free anything until Trash empties, which Gmail does on its own after about 30 days. And the quota you are fighting is not Gmail's at all, although it looks like it is, because it belongs to your Google Account and is shared with Drive and Photos. Clearing 2 GB of mail while Photos quietly grows is a treadmill.

## If you would rather not run the searches by hand

The tier walk is a handful of searches and a bit of multiplication, so doing it by hand is completely reasonable. I automated it because I got tired of retyping the negations, and because attributing each tier by sender gets tedious past about five senders (which is roughly where it stops being fun and starts being data entry).

That became the Storage X-ray in Gmail One-Click Cleaner, which is free to scan and reports every figure as an "at least", for exactly the reason above. Full disclosure, it is mine: https://chromewebstore.google.com/detail/bmcfpljakkpcbinhgiahncpcbhmihgpc

Either way, the useful idea is free. When a tool quotes you a precise storage number pulled from Gmail search, ask where the precision came from. Search did not hand it to them.

SPF, DKIM and DMARC on Security+: only one of them checks the address your users see

TiltedLunar123 — Wed, 05 Aug 2026 10:20:55 +0000

Three DNS records show up together on SY0-701, and most study material lists them as email authentication and then moves on. That grouping is what makes the questions hard, because the questions are almost always about the difference between them, and specifically about which one does the thing the other two cannot.

Here is the short version. SPF and DKIM both validate something the recipient never looks at. DMARC ties the check to the address displayed in the mail client.

SPF answers a narrow question: was this server allowed to send. It is a TXT record on your domain, and it lists the IP addresses and hosts that are permitted to send mail for it. A receiving server takes the message, looks at the sending IP, and compares it against that list.

The part that decides exam questions is which address SPF checks. It checks the envelope sender, the address in the MAIL FROM command, also called the Return-Path. That is not the From line your users read. The two are frequently different, and forwarding services break the connection between them on purpose.

Does SPF stop spoofing? No. A message can pass it cleanly and still display whatever the attacker wants in the From field. SPF was never designed for that.

DKIM answers something else. Was this message altered, and does the sender hold the key. The sending server signs a set of headers and the body with a private key and attaches the signature. The public key sits in DNS at selector._domainkey.yourdomain. The receiver pulls that key, verifies the signature, and now knows the message was not modified in transit and that whoever sent it holds the private key for that domain.

Also useful. Also not what people assume.

A valid DKIM signature tells you which domain signed the message. It does not require that domain to be the one in the From header, which means an attacker who controls a throwaway domain can sign their own spoofed message with their own key and have it verify perfectly. The signature is valid. The mail is still fake.

DMARC binds the check to the visible From. That record lives at _dmarc.yourdomain. It adds two things neither of the others has.

First, alignment. Why does that word matter so much here? Because DMARC requires that the domain in the From header, the one the human reads, matches the domain that passed SPF or DKIM. That single requirement is what turns two technical checks into a control that is very hard to spoof past.

Second, a policy. DMARC tells receiving servers what to do when alignment fails, using p=. Setting it to none means monitor only and deliver anyway. Quarantine means treat the message as suspicious, which in practice is the spam folder. Reject refuses it outright. A rua= address collects the aggregate reports that receiving servers send back to you.

So what does this look like on the exam? The scenario is usually some version of this. Employees are receiving messages that appear to come from an executive at their own company, asking for something urgent, and you have to say what should be implemented.

Both SPF and DKIM will sit there in the option list, and both of them are real controls that a real organization should absolutely have deployed, which is exactly why they work so well as distractors. Neither is the answer. Neither one acts on the address in that message. DMARC does.

The second common shape is a misconfiguration question. The organization has all three deployed, spoofed mail is still landing in inboxes, and you have to say why. The answer is usually p=none, which is monitoring rather than enforcement. Publishing a DMARC record and leaving the policy at none is very common in the real world, and it blocks nothing.

The deployment order is worth knowing even outside the exam, in order to understand why so many domains sit at p=none forever. Publish SPF and DKIM first. Then publish DMARC at p=none and leave it alone. Read the aggregate reports for a few weeks, because they will show you legitimate senders you forgot about, like the invoicing tool nobody remembers setting up. Every one of those breaks the day you move to reject if it is not aligned. After that comes quarantine, and only then reject.

That is the whole enforcement story, and it comes down to one tag in one record.

I run p=quarantine on my own domain for exactly that reason. Going straight to reject means finding out which of your own services was misconfigured by having your mail bounce.

The trap with this material is that it is easy to read and hard to apply, which is the general shape of Security+. You can recite what all three records do and still pick SPF on the spoofing question, because the question does not use the word alignment anywhere in it. It describes a symptom and expects you to work backwards to the control.

What fixes that? Reps on the scenario wording rather than more reading. Professor Messer covers this in his objectives series for free, and Jason Dion's banks are good for timed practice. I build practice for SY0-701 as well, so full disclosure on that one. If you want to see what the simulation style items look like without making an account, there is a free one here: https://secplusmastery.com/security-plus-pbq

Gmail keeps deleted mail for 30 days, and most people waste all 30 of them

TiltedLunar123 — Tue, 04 Aug 2026 09:35:51 +0000

A bulk inbox cleanup goes perfectly well right up until somebody asks you to forward the receipt from that flight in March. Then you find out what your undo actually looks like, which is usually the first time you have thought about it.

Gmail gives you a safety net here. Most people burn it in the first five minutes without noticing.

Delete is a move, not a deletion

When you delete a message, Gmail puts it in Trash. Google's own documentation says you can find and recover messages there "up to 30 days after deletion", and after that the message is permanently deleted.

There is a second half to that, and it is the half that surprises people who are cleaning up to free space. Messages sitting in Trash still count against your quota. Google says it plainly, that "until you permanently clear items in these folders, they count against your storage limit".

So what does deleting 20,000 messages actually free? Nothing, on its own. Emptying Trash is the step that frees the space, and that same step is the one that destroys your 30 days.

That is a genuine tradeoff rather than a trick. You just want to make the choice on purpose instead of finding out later.

The 30 days only help if you can search them

Trash is searchable like anything else. The operator is in:trash, and it scopes a query to the Trash folder alone.

There is also in:anywhere, which widens a search to include Trash and Spam alongside your normal mail. That one is worth knowing because Gmail's default search quietly excludes both.

Put an operator in front of whatever you deleted with and you get your recovery query. Something like in:trash from:airline.com, or in:anywhere has:attachment larger:5M. Select what comes back and hit Move to. Pick a destination. Done.

None of that is hard. So why do people lose mail they could have pulled straight back out of Trash?

A count is not a record

The tool tells you 18,432 messages were deleted. Which 18,432? That number tells you how many left and absolutely nothing about which ones, and by the time anybody asks you a specific question about a specific email you have no way to answer it.

Thirty days of recovery are worth very little when you cannot describe what you are recovering.

The fix takes about four seconds per sweep. Write the query down as you run it. If you deleted with older_than:2y category:promotions, then that exact string with in:trash in front of it is your undo instruction, and it will still work three weeks later when you have forgotten the whole afternoon.

Keep them in a note. That single note, which takes almost no effort to maintain and which you will never once open on ninety-nine sweeps out of a hundred, is the entire difference between a 30-day safety net and a 30-day countdown you have no way to use.

Do the steps in the reversible order

Cleanups go wrong because people run them backwards. The order that works puts every irreversible thing at the end.

Unsubscribe first, because it stops the inflow and deletes nothing at all. Then delete by sender or by size and work biggest first, one query at a time. Write each query down as you go. Then go look at what actually landed in Trash and confirm it is what you meant. Only then empty Trash, and only for the sweeps you have checked.

Most people start at the last step. It is the only one they cannot take back.

Where a tool helps

Step three is the tedious one, and it is the reason I ended up building Gmail One-Click Cleaner. It keeps a Recovery Log of what each run touched and gives you one-click Restore off the back of it, so keeping the record is the tool's job rather than something you have to remember at 11pm.

You do not need it though. Gmail's own operators cover most of what is above at no cost, and knowing in:trash and in:anywhere will get you out of nearly every hole a cleanup can put you in.

Just decide which 30 days you are spending before you empty that folder.

SQL injection, XSS, and buffer overflow look identical on Security+ until you find one detail

TiltedLunar123 — Tue, 04 Aug 2026 09:26:49 +0000

Domain 2 questions about application vulnerabilities have a shape that catches people out. The stem describes something that happened, and four vulnerability names sit underneath it. Every one of those names is a real thing that really exists, so none of them are wrong in the general sense.

Knowing what SQL injection is will not get you through the question, because what the question wants is for you to look at a described behavior and put the right name on it. Definitions do not survive that. You can recite the definition of cross-site scripting word for word, sit down in front of a stem that never once uses the word script, and have no idea which of the four names in front of you is the one they mean.

The detail that decides it is almost always the same one.

Where does the untrusted input end up?

Professor Messer describes an injection attack as one where "an attacker can easily add additional malicious code to input that is going to a server or a client device". That is the family. The specific name depends on where the input lands.

SQL injection: the input lands inside a database query. The stem will mention a login form or a search box or a URL parameter, and then something the application should never have returned. Whole tables coming back. A login that succeeded without a password.

Cross-site scripting: the input lands in somebody else's browser. Messer puts the mechanism plainly, saying that XSS "takes advantage of the trust that the browser has for different websites". The victim in an XSS stem is a user rather than the server. Watch for that. If the damage happens to a person who visited a page, you are looking at XSS even when the word script is absent.

Buffer overflow: the input lands in memory. Messer again, "you're adding information into a particular area of memory reserved for a variable, but you're putting more information than that variable can hold". The tell in a stem is a size or a length. A field that accepted more than it should have. A crash. An application that suddenly started running something nobody asked it to run.

Race condition: nothing lands anywhere. There is no payload of any kind in a race condition stem, no crafted string and no oversized field and no malicious link, which is exactly why so many people read straight past it.

Reflected or stored? That one is a question about the link

XSS splits two ways and Security+ does ask which one. The split turns on where the payload was sitting before it ran, and severity has nothing to do with it.

Non-persistent XSS is also called reflected, and it arrives inside the request. Messer describes a site "configured in a way that would allow people to run scripts inside of these user input blocks". A stem that hands you a crafted link over email is the reflected kind, and it works one victim at a time.

Persistent XSS is the stored kind, and it was saved on the site before anybody visited. Messer's example is an attacker who posts a message to a social media site with the payload inside it, so the payload now sits on the site waiting. A stem where every visitor to a page gets hit, with no link anywhere in the story, is stored.

One clicked link, one victim. One saved post, everybody who loads the page.

A race condition does not look like an attack

This is the one that gets skipped. Messer defines it as "when two events happen at nearly the same time with an application, and the application doesn't take into account that these two conditions may be operating simultaneously".

Time-of-check to time-of-use is the version the objectives name. The application checks a value and then uses it. Something changes in the gap. Messer's worked example is a bank transfer where deposits post immediately and withdrawals do not, so a balance gets read before it was updated and an account ends up showing 50 dollars that is not really there.

Where is the attack in that? Both operations were legitimate. No input was malformed. The flaw is the gap.

So the trigger is timing. Two things happening at once, or a value read before it was written.

The wrong answers are controls for a different question

Once you have named the vulnerability, the remediation half of the question usually offers you four real controls.

Input validation is the answer for injection and for XSS, and it does nothing at all for a race condition. Locking, or making the check and the use one atomic operation, is what answers the race. Bounds checking and memory-safe languages answer the overflow.

Then there is the option that shows up everywhere. Patch the application, or apply the latest update. That option is never false, though it is almost never the control being tested, because the question described one specific weakness and wants the control for it.

The drill that fixes this

Take a batch of Domain 2 questions and cover the answer options with your hand, then read the stem and write the vulnerability name from the stem alone.

When you cannot, ask the two questions in order. Where did the input go, and who got hurt? It went to a database or a browser or into memory. If it went nowhere at all, you have a race condition.

If you want stems to run this on, the free diagnostic at secplusmastery.com/diagnostic will show you where Domain 2 sits for you, and the full question set at secplusmastery.com is built around scenarios instead of definitions.

Try it on ten questions tonight and count how many you name right.

Read the attack first when a Security+ question is about stored passwords

TiltedLunar123 — Mon, 03 Aug 2026 09:32:24 +0000

Password storage sits in domain 1.4. On paper it is three vocabulary words: hashing, salting and key stretching. People learn all three definitions and lose the points anyway. The exam almost never asks what salting is. It describes an attack and asks what you should have done about it. Salt and key stretching answer two completely different attacks.

A hash alone is not the finish line

Professor Messer's wording is worth keeping. A cryptographic hash "is used to represent data as a short string of text". It also goes by message digest or fingerprint. And "this cryptographic hash is not encryption."

That last part gets skipped a lot. Encryption is built to be reversed by whoever holds the key. A hash has no key and no reverse. That is the whole reason it fits password storage: the server can check you without ever keeping the thing you typed.

So systems store "a hash for all of the passwords". Or a hash plus a little extra information called a salted hash. The extra information is where this gets interesting. A plain hash has a problem that has nothing to do with weak math: the same input always produces the same output. Two people who picked the same bad password get the same row in the file. Crack one and you have cracked both. The algorithm is fine. This is a property of it, and it is one an attacker can build a business on.

Salt removes the shortcut

Salt is "random information that we add during the hashing process to modify or randomize the resulting hash". The detail that matters for the exam is that "every user gets a different random salt to go along with their password."

The attack it kills is the rainbow table. Messer calls that "a pre-compiled set of every possible input and the series of hashes associated with those inputs". Somebody spent the compute once and wrote all the answers down. Now they look hashes up instead of calculating them. Add a random per-user salt and "these rainbow tables will no longer work", because the table was built for the password alone and not for the password plus your own random string.

Here is what people get wrong. Salt is not a secret. It sits in the database right next to the hash. It has to, or the login check could not run. So what if the attacker dumped the whole table and holds every salt? Salting still worked. That table is dead either way. Slowing anybody down was never the promise.

Key stretching goes after speed

Key stretching takes the other job. Messer describes it as doing the work over and over: "you may want to hash a password, then hash the hash of that password", and keep going from there.

Read that as buying time rather than adding secrecy. Nothing about the stored value got more secret. It got more expensive. A user logging in pays the cost once and never notices (which is the whole design). Somebody running a dictionary through a stolen file pays that same cost on every single guess, which is why a rig that would have chewed through the entire candidate list in an afternoon can end up grinding away at the exact same wordlist for weeks. Same hardware and the same password; wildly different amount of the attacker's year gone.

The decision you are actually making

Label the attack before you read the options. There are only two shapes here.

Attacker using something precomputed? Two accounts falling together because their hashes matched? The shortcut is the problem, so salting. The stem tips its hand with words like rainbow table and precomputed and lookup.

Attacker already holds the file and is grinding through candidates? Speed is the problem, so key stretching. Look for brute force or offline cracking or a dictionary attack.

Then there are the options that show up in both questions and are wrong in both. Encrypting the password database sounds strong and is largely a shell game, since the key has to live somewhere on that same server. Tighter complexity rules are a policy control. They change nothing about how the stored value is protected. A longer hash output doesn't slow anyone down either.

A well-written question will sometimes hand you a combined answer that is correct. Real systems do both, while the stem that names one attack wants the one control that removes it.

Drilling it

Take a blank card. Write "precomputed table" and "raw guessing speed" on one side. Put salt and key stretching on the other. Run every password question you own through that order. Attack first. Control second. If you catch yourself picking a control because it sounds like the stronger one, you have skipped the step the question was testing.

The habit is worth more than the vocabulary. A lot of 1.4 works this way, where two controls both look right until you say out loud which attack the scenario is describing. Want a quick read on whether that skill is there yet? The free diagnostic at https://secplusmastery.com/diagnostic is built out of scenarios rather than definitions, and the practice questions and labs at https://secplusmastery.com run on the same idea.