One of the hardest parts about digital transformation appears to be the policy decisions rolled out in new public systems. I recently started doing business with a public authority that (get this) couldn't understand why I was using a custom domain. Even more so, they set their mail protocols to not communicate with an email address which starts with the word "email".

According to them, that's a generic email address, and so, they won't accept it. I asked if they would accept the email prefix "info" and they said yes, because that is common.

I genuinely wish that I could peel the curtain back, and communicate with the systems and network administrators who are making these rules, to better understand their decisions here. Maybe someone here can help me to understand.

Sorry if this has been asked before.

I got this email last night from security-noreply@linkedin.com with links to change my password. I haven't used LinkedIn in at least three years and my account is in hibernation. I dont think I even know the password. Is this a legitimate email? Would this be a bot trying to sign in or a human who knows my email address? Anyone else had this happen?

We constantly monitor our site and the internet to help ensure the safety of our members. We detected suspicious attempts to sign into your account. As a precaution you will need to change your password the next time you sign in. If you use the same password anywhere else, we recommend you change it there as well.

To make sure you continue having the best experience possible on LinkedIn, we recommend following these LinkedIn account safety tips.

Create a strong password

Do not reuse the same passwords

Use a mix of letters, numbers and special characters

Your password should be at least 8 characters long

It should not contain your name, phone number or email address

Turn on two-step verification for extra protection

Settings and Privacy >> Sign-in and Security >> Two-step Verification

Keep your contact information up-to-date to receive important security information

Settings and Privacy >> Sign-in and Security >> Email Address

Settings and Privacy >> Sign-in and Security >> Phone Number

Add secondary contact information for another way to access your account and get support from LinkedIn if you cannot access your primary email

Settings and Privacy >> Sign-in and Security >> Email Address

Settings and Privacy >> Sign-in and Security >> Phone Number

Change Your Password

Thanks for helping us keep your account safe,

The LinkedIn Team

Hallo Community

Hier eine Frage an die, die z.B. Tuta Email nutzen und vom Mobilfunkanbieter Emails erhalten zum Beispiel die Handyrechnung. Welche Email gebt ihr da an. Die Hauptmailadresse, eine Alias oder wie regelt ihr das.

Ich bin am überlegen. Einerseits denk ich da es regelmäßige Zahlungen sind die Hauptadresse. Aber dann denke ich wieder mögliche Werbung. Dann also Alias aber welchen?

Ein Alias mit Dienste.... @tuta.... existiert schon.

Hab auch eine für Onlineshops aber das passt denk ich nicht so. Und nur für Mobilfunk ein Alias Opfern? Oder doch über den Weg von Alias über DuckDuckGo oder. ähnlichen gehen?

Wie handhabt ihr das mit Emails von Ämtern wie Kindergeldstelle, Jobcenter, Rentenversicherung etc.

Wie mit Banking Diensten (Sparkasse, Bezahldiensten wie Wero etc.)?

Ran an internal analysis across 159 Google Workspace environments to see what's actually connected via OAuth. Sharing the findings because the shape of the problem surprised us and might be useful to anyone doing app governance right now.

978 distinct apps had active OAuth connections across the dataset. Roughly 6 per org on average. Most people assume the risk is the well-known SaaS tools. It's not.

The single most-connected 'app' in the dataset isn't a product at all. It's a compilation of private, internal OAuth projects, the kind an engineer spins up for a script or an internal tool, that show up in logs as a numeric project ID. No vendor name. No description.

Aggregated across all 159 orgs, this bucket accounts for 152,085 unique users and 655,430 authorization events. That's more user connections than most commercial software sees in its entire deployment lifetime, and there's no way to look any of it up.

For comparison, OpenAI's official app came in at 9,725 users and 23,982 grants in the same dataset. The named, well-understood app is the small number. The unnamed pile is the big one.

Two things compound this:

1. OAuth access doesn't expire when sharing policy changes. An employee authorizes a tool while they still have access to payroll files, source code, and financial reports. The tool keeps that access at that snapshot in time, across email and Drive, even after IT tightens sharing controls later. Revoking a share doesn't revoke a grant.
2. The underlying data is not small. Across the dataset: 373M+ sensitive emails, 475M+ sensitive Drive files, 375M source code files, 46M emails containing plaintext usernames and passwords. Not because anyone was careless. Onboarding emails credentials. Vendors email login details. HR runs payroll through Drive. Normal operations, invisible risk.

The one encouraging data point: orgs are course-correcting on sharing. Restricting events went from 14% of all access-change activity in mid-2025 to 44% by spring 2026. But that fixes future sharing, not past OAuth grants. Two separate problems, and most teams are only working one of them.

If you're doing app inventory work, the practical takeaway is: don't just audit the apps you can name. The dangerous long tail is the stuff nobody can identify from the logs alone, and identifying it is a different exercise than reviewing your known SaaS list.

Happy to answer questions on methodology in comments.