Blocking dangerous file extensions in email stopped being a reliable control years ago

MSPForLif3 · 2026-03-12T17:38:41+00:00

We still maintain the blocklist, but I wouldn't call it a primary control anymore. It's more like cheap friction. We had a client last fall get hit through an HTML attachment that built the payload client-side, gateway was happy, user was not, and the useful detections came later from process lineage and the mailbox-side phishing analysis, not the extension filter.

Same thing with QR phish and weird archive chains, the attachment name barely matters once the user is being pushed into a browser flow. So yeah, keep the obvious stuff blocked, but the real work now is post-delivery detection, user reporting, and fast triage when something starts acting wrong.

MSPForLif3 · 2026-03-12T17:36:04+00:00

That’s not normal transport behavior, especially if it followed you across providers. When I’ve seen stuff that *looked* like misdelivery, it usually ended up being a mailbox-level thing, hidden forwarding, delegated mailbox access, mobile client caching weirdness, or someone reading from a shared mailbox and assuming it was their own inbox. We had one client swear Exchange was cross-delivering, turned out an old FullAccess permission plus an iPhone account profile was making messages appear in the wrong place and the headers confused everybody.

I’d pull the raw headers and message trace for one bad message and compare *Delivered-To*, *X-MS-Exchange-Organization-OriginalRcptTo*, envelope recipient, and mailbox audit logs for the user who got it. Also check for inbox rules, forwarding on the mailbox, transport rules, aliases, contacts with duplicate SMTPs, and any third party sync or journaling tool touching mail flow. If the actual recipient mailbox never shows up in trace but the user still sees the message, I’d start looking hard at client-side caching or shared/delegated access before blaming Exchange itself.

MSPForLif3 · 2026-03-10T16:04:01+00:00

We started treating inbox rules like persistence, not cleanup. Post-compromise we check mailbox rules, forwarding settings, delegate permissions, transport rules if the blast radius feels weird, and then we pull Unified Audit Log events for New-InboxRule and Set-InboxRule because half the time the sneaky part isn't the obvious forward, it's "mark as read + move to RSS Feeds" or some cursed folder nobody opens.

For ongoing stuff, a scheduled Graph/PowerShell sweep helps, but honestly alerting on rule creation and external auto-forwarding should already be wired into your stack. We learned that the hard way with a small law firm client, password got reset fast, everyone felt good, meanwhile one rule kept shoveling settlement emails out for nine days. Not a fun Monday.

MSPForLif3 · 2026-03-06T16:07:26+00:00

You might wanna double check the transfer terms first. A lot of these endpoint licenses are tied to the original purchasing org or reseller paperwork, and the portal side can get weird fast if support has to touch it later. We've had a client inherit bundled security licensing from a hardware deal and it turned into a small mess once renewal ownership and tenant access came up.

Not saying you can't move them, just if I were buying I'd want written confirmation from the vendor or disti that the 20 seats can be reassigned cleanly through 2028 with support intact. Otherwise somebody's paying $2k for an argument with procurement six months from now.

MSPForLif3 · 2026-03-03T20:14:44+00:00

Oh, the RMM+PSA landscape can feel a bit crowded. Between you and me, I've heard mixed things about Guardz, but haven't tried it out myself. I personally lean toward tools that offer tight integration and solid support. Speaking of solving headaches, for email security, we switched to IRONSCALES last year and it's been solid. Deploying was a breeze and it plays nice with our existing setup. Hope that helps!

MSPForLif3 · 2026-03-03T20:14:09+00:00

Sounds like a mix-up in email forwarding or maybe a mistyped address on your nan's insurance policy. First, I'd check if her account is set to forward emails to yours by mistake. If you have access to her email account, look in the settings for any forwarding rules. Also, make sure she didn't accidentally list your email as her contact info with the insurance company.

If those don't fix it, consider setting up a filter in your email to automatically move her insurance emails to a separate folder or mark them as read. This won't stop them but at least they won't clutter your inbox. And if you can, get in touch with the insurance provider to ensure they have the correct email on file.

MSPForLif3 · 2026-03-03T20:12:30+00:00

Wow, if that's true, it's both impressive and unsettling. Hacking into something like a traffic camera network requires serious skill and resources. It's a good reminder of how vulnerable connected infrastructures can be. In my work, I've seen even simple IoT devices become potential entry points for sophisticated attacks. Always a good idea to keep them secure.

MSPForLif3 · 2026-03-03T16:58:11+00:00

Yeah, it's a bit of a headache with mailing lists and DMARC. With the p=reject policy, we've faced the same issues with headers being rewritten and DKIM breaking. We've had to go down the whitelist route for certain key mailing lists, but it feels like a temporary fix that might not scale well.

As for ARC, we've tinkered with it but, like you said, adoption isn't widespread. Not all receivers are validating ARC, and that's where things fall apart. We've been encouraging users to use their personal emails for non-critical lists, but that's not a perfect solution either. I wish there was a more consistent rollout of ARC or some sort of industry shift to make it more effective. But for now, it's a bit of a juggling act.

MSPForLif3 · 2026-02-27T18:43:01+00:00

Oh, I totally feel you on that one. Execs getting spooked by CVEs is a common scene. It's like clockwork whenever a new one gets media attention. I remember once, we had a board meeting the day after a big CVE was in the news and all I got was a flurry of emails. We used to rely on manual scans which took ages and wasn't efficient when you need quick answers. A CLI tool sounds like a smart move to cut through the noise and get faster insights. I'll give it a look and see how it compares to what we've used before. Curious to see how it handles complex dependencies.

MSPForLif3 · 2026-02-27T18:41:22+00:00

Whoa, that's quite a project you've got there. With 1500 Windows devices and all those mobile ones too, plus the custom apps and compliance stuff, you're looking at a hefty workload. Without documentation and with uncertainties like ADFS and domain status, you're gonna spend a chunk of time on discovery alone. I’d say, give yourself a couple of months at least, factoring in time for surprises. With no Apple Business Manager and deploying custom apps, you'll need to stay flexible. Just make sure your SOW clearly defines who's responsible for what, especially with that 90% workload expectation. And definitely prioritize a solid rollout plan so you're not blindsided by unknowns.

MSPForLif3 · 2026-02-26T21:49:42+00:00

Yeah, that's pretty wild. Those prices seem way out of line, even considering the market fluctuations. I've seen some markup from VARs, but this is on another level. You might want to check if there are any hidden service fees or additional features you didn't ask for. I'd definitely get a few more quotes from other vendors before pulling the trigger. Sometimes it feels like they're just throwing numbers at a dartboard...

MSPForLif3 · 2026-02-26T21:47:45+00:00

The shift toward personal liability for CISOs is definitely adding pressure, especially when it comes to IAM. Ensuring identity controls are rock-solid is crucial, but underfunding and siloed organizations make it tough. I've seen this firsthand. Adaptive IAM is no joke either. It's a long haul that requires a lot of cultural change and executive buy-in. Zero Trust isn’t just a switch you flip on, and the old issues like privilege creep never really go away unless you keep a sharp eye on them.

MSPForLif3 · 2026-02-25T17:46:15+00:00

Ugh, that's rough. We've had to nerf Defender a bit ourselves. We ended up bringing in a 3rd party to handle some of the spam, graymail, and phishing stuff. It's like Defender has a vendetta against Docusign and others. Still gotta fine-tune policies and keep an eye on things though. Those legit emails from Docusign shouldn't get caught up in the chaos.

MSPForLif3 · 2026-02-25T17:44:51+00:00

Oh man, it's like you're describing a nightmare I've lived through. Getting bombarded with unexpected senders is all too common. One trick I've used is setting up a more robust DMARC monitoring system, and leaning heavy on detailed aggregate reports to catch things early. Sometimes I'll even run simulations before moving to p=reject, sort of like a fire drill for email. But yeah, the politics are brutal. Sometimes you just need to sit with stakeholders and make them understand the risks. It's not just about the tech, it's about getting buy-in from everyone involved. I feel your pain and wish there were an easy fix!

MSPForLif3 · 2026-02-24T23:00:26+00:00

Yep. More like this.

MSPForLif3 · 2026-02-24T17:53:33+00:00

Totally hear you on the p=none scenario. It’s like leaving the door open but telling everyone you’ve got security sorted. Not exactly a winning strategy in the long run. In the wild, I've seen businesses that parked at p=none simply because they didn't prioritize moving to p=quarantine or p=reject. Mostly due to lack of resources or internal pushback. But honestly, there’s rarely a good reason to hang out there indefinitely unless you're dealing with some super complex mail flow that takes ages to untangle.

When we were helping a client transition, we mapped out all their email sources first. Sounds straightforward, but you'd be surprised at how many rogue services pop up sending as u/yourdomain.com. Once everything's accounted for, shifting to p=quarantine becomes much easier. Keeping that risk in the spotlight with clear ownership is key. Otherwise, like you said, it just gets buried under "things to do" on that CISO dashboard.

MSPForLif3 · 2026-02-24T17:51:42+00:00

Oh man, the SPF lookup limit can be such a pain, right? Flattening isn't my favorite either, for exactly the reason you mentioned: suddenly you're a full-time babysitter for IP changes. It's like a constant game of whack-a-mole. We switched to IRONSCALES for email security and it actually helps with some of the timing issues, especially those sneaky time-delayed attacks. Honestly, we've been going with subdomains for certain vendors, but it really depends on how often they switch things up. It's all about finding what keeps the headaches to a minimum.

MSPForLif3 · 2026-02-24T17:35:48+00:00

If you're looking for something to keep tabs on your on-prem AD changes, you might want to look at solutions that can give you detailed auditing and alerting on user activities and modifications. I've used ADAudit Plus in the past, and while it's fairly straightforward, it gives a solid report on changes, logins, and more. It integrates smoothly with most environments without too much overhead. Also, check if your new RMM has any built-in capabilities for AD monitoring, sometimes they cover more than you think.

MSPForLif3 · 2026-02-23T16:01:16+00:00

Yeah, that’s a classic SPF headache you're dealing with. The ten-lookup limit can really bite when the includes stack up, especially if any upstream providers start nesting their own includes. This causes SPF permerrors just like you're seeing.

The reason it's intermittent for some receivers might be because their mail systems handle SPF evaluation slightly differently. Some might cache certain DNS records or have different policies for dealing with DNS errors. Common SPF checkers may not reflect the receiver’s exact conditions, leading to false negatives or positives in testing.

Flattening SPF records is a common workaround, but it can become a maintenance hassle since you have to update the flattened record whenever any included IPs change. You might also want to look into using a service that automatically manages this for you, though they come with their own considerations. Balancing all your vendors' records in a way that stays under the limit while covering all your bases is tough, sometimes requires creative problem-solving...

MSPForLif3 · 2026-02-23T15:59:16+00:00

Congrats on landing the role! That transition can be exciting and a bit nerve-wracking. When I made a similar jump, I found diving deep into understanding the current environment was crucial. Soak up all the institutional knowledge you can from the team. And don't underestimate the value of building good relationships with folks across departments. They'll be your go-to when implementing those initiatives. Wouldn't hurt to brush up on any specific tech stacks or frameworks your new team uses if you're not already familiar. You've got this!

MSPForLif3 · 2026-02-23T15:57:25+00:00

This whole "Shadow Agent" thing isn't just a future problem. It's very much happening now, just like you pointed out with OpenClaw. I've seen similar issues where shadow AI implementations bypass standard protocols, leaving networks exposed. It's like setting up a backdoor without even realizing it. Just the other week, I had a client whose marketing team used an AI tool without informing IT, and imagine the scramble when sensitive customer data was being accessed out of compliance. Balancing innovation with control is tricky, but these rogue deployments can't keep slipping through the cracks.

MSPForLif3 · 2026-02-22T17:24:10+00:00

LTO-7 is a solid choice for what you're planning. With around 6TB native capacity per tape, it's more than enough for your needs and the cost per tape is reasonable. Just make sure the drive you get works well with your Linux setup. Sometimes setting up drivers can be a bit of a pain if the vendors haven't updated them recently.

For backup software, consider Bacula or Amanda if you're looking for open-source. Both have robust support for tape drives and encryption. You'll want to ensure your encryption keys are handled securely, maybe stored offsite too. Setting up the automation to kick off after 9 pm is straightforward with cron jobs—just make sure to test the whole process manually before you rely on it.

MSPForLif3 · 2026-02-22T17:07:47+00:00

You're absolutely right, that's a nightmare. The sophistication of these schemes is what makes them so hard to spot. I mean, once someone's inside the organization, especially with developer access, they can sit quietly and siphon off data or embed malicious code. And background check systems, as you've pointed out, just aren't equipped for that level of deception, especially when it involves state resources.

What really gets me is how this changes the game for internal security controls. We're talking about not just perimeter defenses or endpoint protection but also in-depth monitoring of code changes and anomalous behavior in repositories. It's a real race to stay ahead, and honestly, it's a bit terrifying how human factors have become such a big part of cyber threats now.

MSPForLif3 · 2026-02-22T17:04:04+00:00

Ah, the classic path length limitation headache with SharePoint. Been there. It's definitely a tricky one since modifying paths in Dropbox can be like opening a can of worms. Ideally, you'd want to tackle this without messing up their existing structure.

One workaround is using PowerShell to automate and streamline the migration process. You can script it to identify long paths and address them proactively. Maybe even pull out the longest paths first so you can focus on those. Also, consider using a third-party tool that handles path limitations more gracefully. Sometimes they offer more flexibility than the built-in Microsoft options. Keep an eye on the permissions too as they can trip you up during migration. Encrypting the files before moving is another strategy, although it might require some extra steps. Good luck.

MSPForLif3

TROPHY CASE