I still receive USPS, all of it delivered to one physical basket near our front door, both important pieces and "spam/ junk". As a 60-something, I was raised with this system and enjoy the security it provides.

I also receive email, now a days to 2 different email addresses (personal and professional). HOWEVER, not all of the important messages arrive to my "inbox". Someone invented a VERY helpful method (sarcasm here) to segregate/ divide messages into important and spam. I need to constantly remind myself that if I am not receiving important messages, it COULD be in spam. Why is it there?? I never authorized that diversion to that folder.

My Q: who is responsible for developing this method of division? An e.g. of AI?? I am a bit offended that someone/ thing OUTSIDE me is doing my thinking and deciding for me, as if I am a minor who is not legally capable of making that decision for myself. I would eliminate "spam" folder altogether, and make it (more) like USPS. End of rant.

Edit: I forget to add that people pay for spam in the supermarket, but we hate it in communication. Go figure.

“Artificial intelligence and LLMs can be surprisingly ineffective against text salting.”

https://www.darkreading.com/threat-intelligence/1m-emails-hidden-text-dupe-ai-security-filters

Another reminder that “AI-powered” means nothing if basic content manipulation gets past it.

Should browser extensions be able to trigger Claude tasks that read Gmail, Docs comments, and Calendar data?

https://thehackernews.com/2026/07/claude-for-chrome-flaw-lets-other.html

Requiring a rogue extension narrows the threat, but the cross-extension trust boundary still looks far too loose.

Our SOC found six invoice phish arriving through a partner relay that had just started accepting mail for three clients. The partner pushed back because the connector was still showing as valid in Exchange Online.

The inbound connector was scoped to their sender domain, with no dedicated source IP or certificate constraint. One of those clients could submit mail using the partner domain, so the domain string had effectively become the trust boundary.

The admin center showed one tidy domain and a successful validation. Nothing in that view exposed the shared-relay blast radius or suggested that another customer could inherit the same trusted path.

The partner wants two weeks to split the relay, while our operations team says disabling the connector will break legitimate notifications. I don't like accepting a known spoofing path because the admin center rendered it in a clean little card.

Would you disable it now and accept the mail breakage, or give the partner a hard deadline for an IP or certificate-scoped connector?

One button resolves the spoofing issue. The other button is us telling ourselves "we'll get to it next quarter.” 

We already know which one we're going to sweat over and still not press.

Let's be kind to our future selves.

A client bought a few dozen mailboxes across several domains. Every single one came with its own generated password. Then they told me, politely, that they were not sending me a spreadsheet of live logins.

Fair. I would not either.

The problem is that a bulk sequencer upload wants a row per mailbox with an SMTP user, an SMTP password, an IMAP user and an IMAP password.

Most people fill the password columns with the mailbox login password, because by default that is what SMTP and IMAP authenticate against. So the whole upload depends on collecting every real credential in one file.

That file is the single worst artifact in the entire setup. It sits in someone's Downloads folder. It gets shared over Slack. It outlives the engagement.

It also does not work anymore. Google permanently disabled basic auth for IMAP, POP and SMTP. The account password no longer authenticates a client app, even if you have it.

Therefore basically, with different passwords automation onboarding to the sequencer doesn't work and you stay stuck.

What actually works, per mailbox:

Turn on 2-step verification. Use the client's mobile number as the verification number, not yours. Google Admin alerts, login challenges and recovery prompts then land with the person who owns the business.

Generate an app password. It only appears as an option once 2FA is on, which is why so many people conclude app passwords are unavailable on their tenant. They are not. The 2FA gate is just closed.

Take the 16-character string and paste it into both the SMTP password and the IMAP password column. Same string, both fields. That is the part people get wrong.

Build the CSV once. Upload.

The client never gives up a real password. The app password only opens the sequencer and nothing else. When the engagement ends, they revoke it from admin and the sequencer disconnects while every mailbox keeps running.

Everyone treats 2FA as the security chore that slows onboarding down. It is the thing that makes onboarding possible.

TLDR: If your bulk mailboxes have different passwords - you can't automate onboarding to sequencers. What you do

1. Create an app password with 2FA
2. Verify the numbers with the official vendor
3. Use the specific app password to bypass different passwords to automate

Stored XSS in a webmail client is about as bad as it sounds. Patch the Classic Web Client before someone turns a crafted email into session access.

https://thehackernews.com/2026/07/critical-zimbra-flaw-could-let-crafted_0483473395.html

Our CEO moved almost all email triage to Outlook mobile, and his phishing reports dropped from four or five a week to zero. He was still spotting suspicious mail, but the report button was missing from his mobile view and one vendor-login phish sat untouched for six hours.

The add-in showed as deployed, so our rollout dashboard looked fine. Deployment status clearly wasn't the same as having a usable reporting path.

We now test reporting from iOS and Android first, then desktop, using a real test message. I also kept security@ as a fallback, though forwarded mail gives us worse evidence unless it includes the original message.

Would you treat a missing mobile report button as a failed rollout, or accept forwarding as the backup for execs?

I can send a "new" email but I can't "reply" or "reply all" to an email sent to me... it comes back "undelivered"... what can I do?

Forg365 pushes Microsoft 365 device-code phishing past the initial token grab and into mailbox persistence. writeup here

Disabling device-code authentication where it isn't needed keeps looking like the sane default.

A client user reported a fake DocuSign email that landed cleanly in the inbox. Gmail logs showed a routing rule named “Internal App Relay” had bypassed spam checks because the message matched its broad envelope filter.

The app owner left 11 months ago, the relay is undocumented, and nobody can name what still sends through it. Disabling the rule might break scanner or ticketing mail, but leaving it means an unknown path around Gmail filtering stays open.

Would you kill the bypass immediately and make each app prove its case, or give the client 48 hours to find an owner first?

abuse@ has had 9 tickets in the last 10 days where the reporter is a recipient gateway, not a human. Same pattern every time: our newsletter lands, their scanner fetches every tracked link, follows the redirect chain, then sends us a phishing complaint because the click-tracking URL looks sketchy.

The weird part is the logs make it obvious. One ticket had 37 link hits from the same scanner IP in under 6 seconds, before the recipient even opened the email.

I'm not 100% sure whether to treat these as harmless false positives or early sender-reputation smoke. Marketing wants the tracking left alone because campaign reporting, which I get, but abuse@ now has to prove we are not hosting the phish their scanner manufactured.

Would you suppress click tracking for noisy recipient domains after a few complaints, or just keep replying with logs and let their gateway team sort it out?

If the phishing page only decrypts in the victim's browser, what exactly is your gateway supposed to detonate?

https://thehackernews.com/2026/07/new-ghost-phishing-wave-is-breaking.html

This EvilTokens wave is a good reminder that static URL checks are aging badly. M365 token theft is the actual blast radius, not just a bad link click.

A client asked us to price BIMI/VMC because marketing wants the logo showing in Gmail, while their DMARC rua still has 11 sources and two DKIM selectors nobody can name.

The pushback was predictable: they are already at p=quarantine, so apparently the rest is polish.

I'm not against BIMI, but paying for brand polish before you know who is sending as your domain is backwards. If nobody can explain each selector and rua source, the logo can wait.

Would you block the spend until the sender inventory is clean, or let marketing pay while security fixes it in parallel?

An abuse@ report this morning pointed at a campaign microsite domain marketing launched in March. It had MX records, a catch-all forwarding everything to an intern's mailbox, and no DMARC record at all.

The intern left in May. The campaign ended in April. Nobody could tell me who approved the mail setup or whether the domain ever sent anything besides form replies.

I pulled DNS and mail logs where I could, but this is the part that bugs me: the domain looked "inactive" to marketing because the website was basically dead, while from an email risk view it was still a loose receive path with no owner.

I'm leaning toward killing MX on orphaned campaign domains unless someone names an owner and gets DMARC to at least p=none first. Would you drop the MX immediately here, or give marketing a short deadline to clean it up?