When I first came across the topic of email bombing protection, my first thought was pretty simple: isn’t this just another form of spam?
After looking at the problem more closely, I don’t think that’s a good enough way to describe it.
Spam is annoying. Email bombing can be a security problem.
There is an important difference between receiving a bunch of unwanted marketing emails and suddenly getting hundreds or thousands of messages, notifications, authentication codes, calls, or other communications in a short period of time.
The second situation can affect more than my inbox. It can affect my ability to recognize a legitimate security alert, notice a password change, respond to a customer, investigate an incident, or even realize that something more serious is happening in the background.
That is what I found most interesting about the article I read on email bombing protection. The author looks at email, SMS, and phone-call flooding as parts of a larger communication security problem rather than treating each channel as a completely separate issue.
I agree with that idea.
From my perspective as someone learning cybersecurity and spending time experimenting in virtual labs, this is a good example of why security is not always about breaking into a server or exploiting a vulnerability.
Sometimes the attack is against the human being sitting in front of the computer.
And sometimes the goal isn’t to get through the front door.
It is to create so much noise that nobody notices what is happening behind it.
What Is Email Bombing?
Email bombing is basically the intentional or abusive generation of a large amount of email traffic toward a particular person, mailbox, organization, or system.
The important word here is volume.
A normal spam message might be easy to identify and delete. An email bombing incident can be different because the volume itself becomes the problem.
Imagine opening your inbox and seeing hundreds of messages arriving almost continuously.
Maybe they are subscription confirmations.
Maybe they are automated notifications.
Maybe they come from dozens or hundreds of different services.
Maybe most of them aren’t even obviously malicious.
That last part is important.
An email bombing attack doesn’t necessarily require every individual message to contain malware or a phishing link. The attack can work simply by overwhelming the target with legitimate-looking communication.
This makes the problem much more interesting from a cybersecurity perspective.
Traditional email security often asks questions such as:
- Is this message spam?
- Is the sender suspicious?
- Does the message contain malware?
- Does it contain a phishing URL?
- Does the sender have a bad reputation?
- Does the attachment look dangerous?
Those questions are still important.
But during an email flood, I would also want to ask:
Why is this particular user suddenly receiving so much email?
That is a behavioral question.
And behavioral security is where things get interesting.
Email Bombing Is Not Just About Spam
One of the biggest points I took away from the subject is that communication flooding should not automatically be classified as ordinary spam.
The difference is context.
Suppose a company normally receives 500 emails per hour in a customer-support mailbox.
A sudden increase to 1,000 emails might not mean much.
Maybe there is a product launch.
Maybe a website went down.
Maybe a popular post generated a huge amount of traffic.
Now imagine an employee who normally receives 50 emails per day suddenly receiving 2,000 messages within 20 minutes.
That is different.
The volume is abnormal relative to the person’s baseline.
This is where security monitoring can help.
Instead of looking at every message independently, we can look at patterns.
For example:
Normal behavior:
Employee mailbox
|
+-- 30-80 emails/day
+-- Mostly known contacts
+-- Normal business hours
+-- Stable patterns
Potential flooding event:
Employee mailbox
|
+-- 1,500 messages in 20 minutes
+-- Hundreds of different senders
+-- Highly repetitive notifications
+-- Multiple password-reset messages
+-- Unexpected SMS messages
+-- Calls begin shortly afterward
The individual events might not look particularly dangerous.
The combined behavior absolutely deserves investigation.
Why Would Someone Email Bomb a Person?
There are several possible reasons.
The first is simple disruption.
If I fill someone’s mailbox with thousands of messages, I can make it harder for them to work.
But there is another reason that I find much more concerning.
Distraction can be used to hide another security event.
Imagine someone successfully changes a password on an online account.
The service sends an email saying:
Your password was changed.
At almost the same time, the victim receives hundreds of other notifications.
That legitimate security email can disappear into the noise.
The same concept could apply to:
- Password reset notifications
- New login alerts
- Payment confirmations
- Bank notifications
- Account recovery messages
- Shipping notifications
- Subscription changes
- Security warnings
- New device alerts
- MFA notifications
The attacker doesn’t necessarily need to make the legitimate notification disappear technically.
They only need to make it difficult for the victim to notice.
That is a much more interesting attack model.
Notification Fatigue Is a Security Issue
I’ve seen the idea of notification fatigue discussed in different areas of cybersecurity, and I think it deserves more attention.
We usually talk about alert fatigue from the perspective of security analysts.
A SOC analyst might receive hundreds of alerts and eventually start ignoring them because too many are false positives.
But regular users can experience something similar.
If my phone starts producing notification after notification after notification, eventually I stop treating every notification as important.
That creates a dangerous psychological effect.
The first notification might get my attention.
The hundredth one probably won’t.
This is why communication flooding can become a form of social engineering.
The attacker is not necessarily manipulating the software.
They are manipulating the user’s attention.
Email Bombing and Account Takeover
This is one area where I think defenders should be especially careful.
An email flood does not automatically mean that an account has been compromised.
But it can be a reason to investigate.
If I suddenly receive:
- Dozens of password-reset emails
- Multiple MFA notifications
- Login alerts
- New-device notifications
- Account-change messages
- Hundreds of unrelated emails
I would not simply start deleting everything.
I would first ask what else is happening.
Did someone try to log into my account?
Was my password reset?
Was a recovery email changed?
Did a new device appear?
Were there unexpected purchases?
Did a financial account send a security notification?
Did I receive authentication messages that I never requested?
The flood itself may be the distraction while another event is taking place.
That is why I think the right mindset is:
Don’t treat the flood as the entire incident until you know it is.
SMS Bombing Can Be Even More Disruptive
Email is not the only communication channel that can be abused.
SMS bombing can create a similar problem with text messages.
In some ways, SMS can be even more disruptive because people tend to treat text messages as more immediate than email.
A phone might display every incoming message as a notification.
And SMS is also commonly used for authentication.
That creates an interesting attack surface.
For example, imagine receiving a large number of unexpected one-time passwords.
The messages might look like:
Your verification code is 482913
Then another:
Your verification code is 731204
Then another.
And another.
The important thing here is that receiving an OTP does not automatically mean someone successfully accessed the account.
It could mean that someone is repeatedly triggering an authentication or recovery process.
But it should still get my attention.
If I didn’t request those codes, I want to know why they are being generated.
OTP Flooding and MFA Fatigue
This also connects to a broader security concept: MFA fatigue.
MFA is designed to make account compromise harder.
But if an authentication system repeatedly sends prompts or codes, users can eventually become frustrated.
The attacker may try to take advantage of that frustration.
The lesson for me is that authentication security cannot be evaluated only by asking:
“Do we have MFA?”
We should also ask:
“How does the system behave when someone repeatedly abuses the authentication workflow?”
That’s a much better security question.
A strong authentication system should consider things such as:
- Rate limits
- Number of authentication attempts
- Device reputation
- Session information
- IP reputation
- Account behavior
- Geographic anomalies
- Recovery attempts
- Repeated OTP requests
- Failed authentication patterns
The goal should be to make abuse difficult without accidentally creating an easy denial-of-service mechanism.
Don’t Accidentally Turn Protection Into a DoS Attack
This is one of the technical points I think developers sometimes overlook.
Imagine an authentication system that automatically locks an account after five OTP requests.
That sounds secure.
But what happens if someone else can trigger those five requests?
An attacker might be able to repeatedly lock legitimate users out of their accounts.
Now the defensive control itself becomes an attack mechanism.
This is why security controls need to be designed around abuse cases.
Instead of simply thinking:
More blocking equals more security.
I think a better approach is:
How can I reduce abuse while preserving legitimate access?
Possible controls include:
- Progressive rate limiting
- Temporary throttling
- Risk-based authentication
- Alternate verification methods
- Duplicate notification suppression
- Device-based controls
- Account-level monitoring
- Additional verification for suspicious activity
- Human support escalation
Security is usually about tradeoffs.
Too little protection creates risk.
Too much friction creates usability problems and can sometimes create new denial-of-service opportunities.
What About Call Bombing?
The same concept can affect phone systems.
Call bombing involves an unusually high number of calls or call attempts directed at an individual, phone number, support queue, or organization.
For a normal user, this can be extremely annoying.
For a business, it can become an availability problem.
Imagine a customer-support center with 20 agents.
If an automated source generates a massive number of calls, the phone queue can become saturated.
Legitimate customers now have to wait.
Some abandon their calls.
Agents become overloaded.
Important calls can be missed.
And the business may spend money processing the unwanted traffic.
At that point, this is no longer simply a spam problem.
It is an availability problem.
And availability is one of the three classic parts of the CIA triad:
- Confidentiality
- Integrity
- Availability
Cybersecurity discussions sometimes focus heavily on confidentiality.
We talk about stolen passwords, leaked databases, and exposed files.
But availability matters too.
If legitimate users cannot access a communication service when they need it, security and business operations can both suffer.
Communication Flooding Can Become a Multi-Channel Attack
This is probably the part of the subject I find most interesting.
Email, SMS, and phone calls are usually managed as separate systems.
Email might belong to IT.
SMS might be managed by an application or identity team.
Telephony might be handled by customer support.
Security monitoring might live somewhere else entirely.
The problem is that an attacker doesn’t care how an organization’s departments are structured.
They can move across communication channels.
For example:
Email flood
|
v
SMS authentication requests
|
v
Phone calls
|
v
Social engineering attempt
Individually, each event might look relatively harmless.
Together, they can tell a completely different story.
That is why I think cross-channel correlation is becoming increasingly important.
Why SIEM-Style Thinking Matters Here
If I were designing a security monitoring system for this type of problem, I would not want three completely isolated dashboards.
I would want to correlate events.
For example:
User: [email protected]
10:02 5 password reset requests
10:04 200 unusual emails
10:06 12 SMS authentication codes
10:09 7 inbound calls
10:11 New login attempt
10:12 Password recovery attempt
Now we have a timeline.
The individual events are useful.
The timeline is much more useful.
This is the same basic thinking used in SIEM platforms and other security analytics systems.
One event rarely tells the whole story.
A sequence of events can.
Useful Signals for Detecting Email Bombing
If I were building detection logic, I would start with relatively simple signals before reaching for complicated machine-learning models.
Some useful signals include:
Message volume
How many messages is the recipient receiving?
Message velocity
How quickly is the volume increasing?
Baseline deviation
How different is the current activity from the user’s normal behavior?
Sender diversity
Are the messages coming from one source or hundreds of different sources?
Repetition
Are the subjects, templates, or message structures repeated?
Timing
Are messages arriving at machine-like intervals?
Recipient concentration
Is one particular employee being targeted?
Authentication correlation
Did password-reset or MFA activity happen around the same time?
Business impact
Is the flood affecting a support queue, ticketing system, or critical mailbox?
Cross-channel activity
Are email, SMS, and phone events occurring together?
None of these signals is perfect by itself.
That’s the point.
Security detection is often about combining weak signals into a stronger conclusion.
A Simple Detection Model
A basic conceptual scoring system could look something like this:
Risk Score =
Volume anomaly
+ Velocity anomaly
+ Sender diversity
+ Authentication activity
+ Cross-channel activity
+ Target sensitivity
+ Business impact
This doesn’t have to be an advanced AI system.
Even a rules-based system can be useful.
For example:
IF
email_volume > baseline_threshold
AND
rapid_increase = true
AND
authentication_events > normal
THEN
increase_risk_score
Then:
IF
email_flood = true
AND
sms_anomaly = true
AND
call_anomaly = true
THEN
escalate_as_multi_channel_incident
Of course, production systems need much more careful logic.
But I like starting with simple models because they are easier to understand, test, monitor, and explain.
Why Baselines Matter
One thing I would avoid is relying entirely on a fixed threshold.
For example:
More than 500 emails = attack
That sounds easy.
But it is not very intelligent.
A marketing mailbox might legitimately receive thousands of emails.
A CEO might normally receive 100 emails per hour.
A rarely used employee mailbox might normally receive 10.
So 500 means completely different things depending on the target.
This is where baselines become useful.
Instead of asking:
“Is 500 emails a lot?”
Ask:
“Is 500 emails unusual for this particular recipient?”
That is a much better question.
Protecting Against Email Bombing Without Destroying Evidence
Another point I think deserves attention is evidence preservation.
If a mailbox is being flooded, the easiest reaction might be to delete everything.
I understand the temptation.
But from an incident-response perspective, that can be a mistake.
Those messages may contain useful evidence.
The security team may want to understand:
- When did the flood begin?
- Which sources were involved?
- How many messages arrived?
- Were there patterns?
- Did the sources change?
- Were legitimate security messages mixed in?
- Did the attack move between channels?
A better approach can be to use quarantine, filtering, tagging, or controlled isolation where possible.
The goal is to restore usability while preserving enough information to investigate.
In cybersecurity, deleting the problem is not always the same thing as solving the problem.
What Should a Person Do During an Email Flood?
If this happens to me, I would try not to panic.
The first thing I would do is avoid assuming that everything is harmless spam.
I would check my important accounts directly through trusted applications or websites rather than following links inside the flood of messages.
I would look for:
- Password changes
- New login alerts
- Recovery email changes
- MFA activity
- Financial transactions
- New devices
- Unexpected purchases
- Account recovery attempts
I would also report the incident through another trusted communication channel if possible.
That’s important.
If email is being flooded, email may not be the best way to communicate with the security team.
Don’t Click “Unsubscribe” on Everything
This is another practical point.
When someone receives a huge number of unwanted emails, the natural reaction is:
“I’ll just unsubscribe from everything.”
I would be careful with that.
If I don’t recognize the sender, clicking links inside suspicious emails is not something I want to do automatically.
It is safer to use trusted account settings or established provider controls where possible.
The same principle applies to unexpected password-reset messages.
I don’t want to click a link just because the message says my account needs attention.
I want to open the service through a trusted route and check the account directly.
Email Bombing Can Be a Social Engineering Opportunity
This is where the technical and human sides of cybersecurity overlap.
Imagine that someone receives hundreds of messages and then gets a phone call:
“Hi, I’m from your account security team. We noticed something unusual. I can help you fix it.”
Under normal circumstances, that call might seem suspicious.
After receiving hundreds of notifications, the victim might actually be relieved that someone is offering help.
That changes the psychology.
The attacker doesn’t necessarily need to create trust from scratch.
They can take advantage of confusion that they helped create.
This is why communication flooding should sometimes be considered part of a larger social-engineering scenario.
The Help Desk Can Become a Target Too
Security teams aren’t the only people who need to understand this.
Help-desk employees and customer-support agents can be affected as well.
A flooded ticketing system can create the same problem as a flooded inbox.
If every email automatically creates a ticket, then an email flood can become a ticket flood.
Now the attack is consuming operational resources.
And there is another risk.
When support staff are overwhelmed, they may be more likely to make mistakes.
That could mean:
- Skipping verification
- Approving a request too quickly
- Missing an important warning
- Sharing information with the wrong person
- Accepting a fake escalation
- Processing fraudulent requests
So communication flooding can potentially increase the effectiveness of a separate social-engineering attack.
Email Bombing Protection Should Be Layered
I don’t think there is one magic product that solves this problem.
A good defensive architecture should have multiple layers.
For example:
Internet
|
v
Email / SMS / Voice
|
v
Filtering + Rate Controls
|
v
Behavioral Detection Layer
|
v
SIEM / Security Monitoring
|
v
Incident Correlation
|
v
Security + IT + Fraud Teams
|
v
Response Actions
Each layer has a different job.
Filtering can reduce obvious unwanted traffic.
Rate limiting can slow abuse.
Behavioral detection can identify unusual patterns.
SIEM or security analytics can correlate events.
Incident response can investigate what is actually happening.
And trained employees provide another layer of defense.
What I Would Monitor
If I were responsible for monitoring an organization against communication flooding, I would want visibility into several metrics.
For email:
- Messages per recipient
- Messages per minute
- Messages per sender
- Messages per domain
- Sender diversity
- Repeated subjects
- Delivery failures
- Quarantine volume
- User reports
- Authentication events
For SMS:
- OTP requests
- Messages per phone number
- Requests per account
- Requests per IP or network source
- Requests per device
- Failed authentication attempts
- Geographic anomalies
- Message delivery patterns
For phone calls:
- Calls per number
- Calls per queue
- Call duration
- Abandoned calls
- Repeated callers
- Calls per time period
- Queue wait times
- Agent transfers
- Call patterns across different numbers
Then I would try to connect these events.
The Real Goal Is Not Just Blocking
This is where I slightly disagree with the simplistic version of “protection.”
The goal shouldn’t just be:
Block bad messages.
The bigger goal should be:
Maintain visibility and availability while reducing malicious activity.
Those are not exactly the same thing.
If I block everything, I might stop the attack.
But I might also block legitimate communication.
If I filter too little, the user gets overwhelmed.
If I delete everything, I lose evidence.
If I lock accounts too aggressively, I may create a denial-of-service condition.
If I disable notifications, I might hide an important security alert.
Cybersecurity is full of these tradeoffs.
What About Tools Designed for Communication-Flood Protection?
The article I reviewed discusses FloodCRM as a security-focused concept for detecting and managing communication flooding across email, SMS, and phone channels. I think the general problem it is trying to address is legitimate and interesting.
However, I would not automatically assume that any security product solves the problem simply because it has “AI,” “cybersecurity,” or “automated protection” in its marketing.
If I were evaluating a platform in this space, I would want to know exactly what it can see and what it can actually do.
I would ask:
- Which email systems does it integrate with?
- Which SMS providers are supported?
- Can it monitor telephony?
- Does it provide real-time detection?
- How does it establish a baseline?
- Can it correlate events across channels?
- What happens after an incident is detected?
- Can analysts investigate historical activity?
- Does it preserve evidence?
- Can it integrate with a SIEM?
- Can it integrate with identity systems?
- Can response actions be automated?
- How are false positives handled?
- What data is stored?
- How long is it retained?
- How is personal data protected?
Those questions matter much more to me than a product’s feature list.
A security tool is only useful if it fits the environment where it is deployed.
Email Bombing Protection for Small Organizations
You don’t need a huge enterprise security stack to start defending against this problem.
A small organization can still implement basic controls.
First, make sure strong authentication is enabled.
Second, use MFA wherever appropriate.
Third, configure sensible email filtering.
Fourth, monitor unusual login and password-reset activity.
Fifth, establish a simple process for employees to report unusual communication activity.
Sixth, make sure there is an alternate communication channel for security incidents.
That last one is easy to overlook.
If the primary communication channel is under attack, I need another way to contact the security team.
What I Would Recommend for Individuals
For an individual user, the strategy is simpler.
I would recommend:
- Use unique passwords for important accounts.
- Enable MFA.
- Prefer stronger MFA methods when available.
- Don’t trust unexpected password-reset messages.
- Check important accounts directly through trusted applications.
- Pay attention to unexpected authentication codes.
- Monitor financial accounts for suspicious activity.
- Avoid clicking links in suspicious notification floods.
- Report unusual communication activity to the relevant provider.
- Don’t assume an email flood is harmless until important accounts have been checked.
Most importantly, don’t let the sheer amount of noise force you into making a rushed decision.
That’s exactly what an attacker may want.
How Security Teams Could Improve Detection
If I were building a detection strategy from scratch, I would start with visibility.
You can’t respond to a pattern you can’t see.
I would collect normalized metadata from relevant communication systems and build a timeline around users, accounts, phone numbers, and business systems.
Something like:
User
|
+-- Email events
|
+-- SMS events
|
+-- Authentication events
|
+-- Account changes
|
+-- Financial events
|
+-- Phone calls
|
+-- Help-desk tickets
|
+-- Endpoint alerts
Then I would use correlation rules to identify suspicious combinations.
For example:
Email anomaly
+
MFA anomaly
+
Account change
=
High-priority investigation
Or:
Email flood
+
SMS flood
+
Phone activity
=
Potential coordinated communication attack
Again, this doesn’t prove that an attack happened.
Correlation creates a reason to investigate.
That distinction matters.
Don’t Overtrust Automation
I like automation.
As someone interested in cybersecurity, I think automation is one of the most useful ways to deal with large amounts of security data.
But I don’t think everything should be automated blindly.
A detection system might see a huge increase in emails and decide something is malicious.
Then it blocks an important business communication system during a legitimate event.
That could be a serious incident of its own.
So I would prefer automated systems to have different response levels.
For example:
Low risk
|
+-- Monitor
Medium risk
|
+-- Alert analyst
+-- Increase logging
High risk
|
+-- Quarantine suspicious traffic
+-- Notify security team
+-- Protect priority communications
Critical
|
+-- Activate incident response
+-- Correlate identity and financial activity
+-- Apply approved containment
This is much more flexible than a simple “block or allow” model.
Why This Is Also a Network Security Problem
At first, email bombing might not sound like network security.
But the more I think about it, the more connections I see.
Network security is about protecting the availability, integrity, and confidentiality of systems and communications.
Communication flooding directly affects availability.
It can also be used as a component of attacks against identity systems, customer applications, APIs, messaging infrastructure, and support systems.
For example, an organization may have an API that sends authentication codes.
If an attacker repeatedly triggers that workflow, the problem isn’t really “SMS spam.”
The underlying issue is abuse of an application workflow.
That means developers, security engineers, network engineers, fraud teams, and support teams may all have a role in defending it.
Developers Have a Role Too
From a developer perspective, rate limiting is one of the most obvious controls.
If an API allows unlimited password-reset requests, that’s a problem.
If an endpoint allows unlimited OTP generation, that’s a problem.
If a notification system can be triggered repeatedly without controls, that’s a problem.
A basic application architecture might include limits at several levels:
IP address
|
v
Account
|
v
Phone number
|
v
Device
|
v
Session
|
v
Application workflow
The exact implementation depends on the application.
But the principle is important:
Don’t rely on one identifier to stop abuse.
Attackers can distribute activity across different sources.
Rate Limiting Is More Complicated Than It Looks
A basic rate limiter might look conceptually like:
10 requests / minute
But real applications need more context.
Maybe a legitimate customer forgets their password several times.
Maybe a corporate NAT makes hundreds of users appear behind one IP address.
Maybe mobile users change networks frequently.
Maybe attackers distribute requests across many addresses.
That’s why modern abuse prevention often combines several signals.
For example:
Rate
+ Account
+ Device
+ IP reputation
+ Session behavior
+ Historical activity
+ Risk score
There is no single perfect signal.
That’s normal in cybersecurity.
The Human Element Is Still the Biggest Wildcard
This entire topic reminds me why I became interested in cybersecurity in the first place.
Technology is complicated, but people are complicated too.
A perfectly configured security system can still be undermined by a tired employee who receives 500 notifications and then answers a phone call from someone claiming to be IT.
That means security awareness should include communication flooding scenarios.
Employees should know that:
- Unexpected MFA requests can matter.
- A flood of notifications may be intentional.
- Security alerts can be buried in noise.
- Attackers may call after creating confusion.
- Urgent requests should be independently verified.
- Security incidents should be reported even if they initially look like spam.
These aren’t complicated rules.
But they can make a real difference.
My Biggest Takeaway
The biggest thing I took from this topic is that security events should not always be analyzed one message at a time.
A single email may be harmless.
A single SMS may be harmless.
A single phone call may be harmless.
But when hundreds of events target the same person around the same time, the pattern becomes meaningful.
That’s a fundamental idea in security monitoring.
Context matters.
Timing matters.
Behavior matters.
Relationships between events matter.
And the business impact matters.
Final Thoughts
Before researching this topic, I probably would have described email bombing as an annoying form of spam.
Now I see it differently.
Email bombing, SMS bombing, and call bombing can become availability attacks, social-engineering enablers, sources of notification fatigue, and potentially useful distractions during account compromise or fraud.
That doesn’t mean every flood is a sophisticated cyberattack.
Sometimes systems break.
Sometimes legitimate events generate huge traffic.
Sometimes an application has a bug.
Sometimes a customer simply gets caught in an automated workflow.
That’s why context is so important.
A good security system should be able to tell the difference between normal high volume and suspicious high volume.
For me, the most interesting technical direction is cross-channel correlation.
Instead of having one system watching email, another watching SMS, and another watching phone calls, security teams should increasingly think about the person, account, device, or business process being targeted.
If the same user suddenly experiences abnormal email traffic, repeated authentication requests, suspicious account activity, and unusual phone calls, I don’t want three separate alerts.
I want one incident that tells me there is a pattern worth investigating.
And that’s the bigger lesson here.
Cybersecurity isn’t always about stopping one malicious packet, one phishing email, or one suspicious login.
Sometimes the real challenge is separating the signal from the noise.
When an attacker creates the noise on purpose, that becomes a security problem.
For anyone learning cybersecurity, I think communication flooding is a great example of why defensive security requires more than knowing how attacks work. We also need to understand human behavior, application design, authentication systems, monitoring, incident response, and the operational side of keeping systems available.
I’m still learning all of this myself, and topics like this are exactly why I enjoy cybersecurity.
The deeper I get into it, the more I realize that security is rarely about one tool or one rule.
It is about connecting the pieces.
And sometimes the first clue that something is wrong is simply an inbox that suddenly becomes way too busy.