Email: Mailbox full — prevent it and recover cleanly when it happens

November 27, 2025 • February 3, 2026 • Read: 22 min • Views: 6

Was this helpful?

“Mailbox full” is the kind of failure that feels petty right up until it blocks a contract signature, loses a password reset,
or quietly bounces invoices for a week. Nobody notices the first bounce. People notice the third “I emailed you twice” message.

The worst part: mailbox-full incidents are usually preventable. The second worst part: when they happen, the wrong “quick fix”
can turn a storage issue into a data-loss incident. Let’s avoid both.

What “mailbox full” actually means (protocol vs storage reality)

“Mailbox full” sounds simple. It isn’t. Depending on the system, it can mean:

User quota exceeded (IMAP quota plugin says “no more”).
Mailbox storage backend full (disk, dataset, LVM volume, inode exhaustion).
Message store internal limit (per-folder limits, per-mailbox size caps, per-message max size policies).
Recipient is at their provider limit (you can’t fix it; you can only communicate).
Temporary failures misreported (some MTAs bounce with “mailbox full” when the real issue is delivery/LMTP failure).

The operational distinction that matters: is this a reject at SMTP time (5xx/4xx during delivery) or a
defer/queue that piles up? Rejection is painful for the sender but clean for your servers.
Deferral is how you end up with a mail queue ballooning until it becomes a storage incident.

Where it shows up in the flow

Typical pipeline: SMTP receive (Postfix/Exim/Exchange) → queue → local delivery (LMTP/LDA) →
mailbox storage (Maildir/mbox/dbox, Exchange database) → IMAP access.

“Mailbox full” can originate from the local delivery agent (quota) or from the filesystem (ENOSPC, EDQUOT, ENFILE, inode exhaustion),
and then bubble back up to the SMTP side as a bounce reason.

If you only learn one thing: treat “mailbox full” as a storage + policy problem, not an email problem.
The email part is just where it becomes visible.

One quote to keep you honest

Werner Vogels (paraphrased idea): You build it, you run it—operational responsibility belongs with the builders.

Interesting facts and short history (because this problem is older than your pager)

Fact 1: The classic mbox format stores an entire mailbox in one file; a single huge file can make “full” failures more catastrophic and slower to repair.
Fact 2: Maildir was designed partly to avoid mbox locking issues by using one file per message; it trades file count/inodes for safer concurrency.
Fact 3: Early SMTP error codes established the pattern: permanent failures (5xx) vs transient (4xx). “Mailbox full” often maps to 552 or 452 depending on policy.
Fact 4: Inode exhaustion is a real “disk full” even when df claims plenty of space—Maildir-heavy servers are particularly good at discovering this the hard way.
Fact 5: Some mail systems implement quotas at the application layer (Dovecot quotas, Exchange mailbox limits), not at the filesystem layer. That’s why storage can be fine while delivery fails.
Fact 6: IMAP QUOTA extensions exist so clients can show users they’re close to the limit. Many organizations never enable it, then wonder why users are surprised.
Fact 7: “Unlimited mailbox” marketing often hides a practical limit: attachment max size, retention, or throttling. The mailbox isn’t infinite; the brochures are.
Fact 8: Backscatter (bounces to forged senders) used to be common when MTAs accepted mail then failed later. Rejecting during SMTP is cleaner and kinder.

Fast diagnosis playbook (first/second/third checks)

You’re on-call. Somebody says: “Email is bouncing; mailbox full.” Don’t wander. Do this.

First: determine scope and whether it’s quota vs storage

Is it one user or many? Check logs for multiple recipients failing or a single mailbox repeatedly.
Is the server actually out of space or inodes? Check filesystem usage and inode usage.
Is the MTA queue growing? If it’s growing fast, you may be turning a mailbox problem into a server outage.

Second: identify where delivery is failing

SMTP reject at RCPT/DATA? Look at Postfix logs and status codes (552/452 vs generic “unknown”).
LMTP/LDA error? Dovecot typically emits clear quota messages, and you can validate with doveadm.
Filesystem error? ENOSPC/EDQUOT in logs means your issue is storage enforcement, not mail policy.

Third: choose the least destructive relief valve

If it’s filesystem full: free space safely (rotate logs, clear spool of deferred mail carefully, expand volume). Do not delete random mail files first.
If it’s user quota: increase quota temporarily or force cleanup/archiving (with user consent/policy), then deliver backlog.
If it’s remote recipient: stop retry storms; tune queue lifetimes and communicate. Your disks should not pay for their quota problem.

Joke #1: Mailboxes are like kitchen drawers—no one knows what’s in there, but somehow there’s never room for one more thing.

Hands-on tasks: commands, outputs, and decisions (12+ real moves)

The commands below assume a Linux mail server with Postfix + Dovecot and Maildir storage.
If you run Exchange or a hosted service, many ideas still map: check the store, check quotas, check queue, then remediate with the least data risk.

Task 1: Confirm the error in mail logs (and whether it’s per-user)

cr0x@server:~$ sudo grep -E "quota|mailbox full|552 |452 |over quota|EDQUOT|ENOSPC" /var/log/mail.log | tail -n 20
Jan 04 10:12:19 mx1 postfix/lmtp[28177]: 3C1A12A0B3: to=<alex@example.com>, relay=imap1[10.0.2.10]:24, delay=2.1, delays=0.2/0.01/0.3/1.6, dsn=5.2.2, status=bounced (host imap1[10.0.2.10] said: 552 5.2.2 <alex@example.com> Quota exceeded (in reply to RCPT TO command))
Jan 04 10:12:20 mx1 postfix/qmgr[1123]: 3C1A12A0B3: removed

What it means: DSN 5.2.2 plus “Quota exceeded” points to an application quota on the delivery side (often Dovecot).

Decision: Don’t expand disk yet. Validate the user quota, determine if it’s one mailbox or a policy affecting many.

Task 2: Check disk usage on mail storage mount

cr0x@server:~$ df -hT /var/mail /var/vmail
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda2      ext4   80G   79G  1.1G  99% /
/dev/sdb1      xfs   2.0T  1.3T  700G  66% /var/vmail

What it means: Root filesystem is nearly full; /var/vmail is fine. If Postfix queue or logs live on /, you can fail deliveries even with plenty of mailbox space.

Decision: Treat as an infrastructure incident: free/expand root FS immediately, then re-check mail flow.

Task 3: Check inode exhaustion (Maildir’s favorite prank)

cr0x@server:~$ df -ih /var/vmail
Filesystem     Inodes  IUsed   IFree IUse% Mounted on
/dev/sdb1        64M    63M   850K   99% /var/vmail

What it means: You’re functionally out of space because you’re out of inodes. Maildir creates lots of tiny files; this is normal… until it isn’t.

Decision: You need inode relief: delete/expire mail per policy, move cold mail to archive, or rebuild with more inodes (often means new filesystem or different backend).

Task 4: Check Postfix queue size (is the system accumulating damage?)

cr0x@server:~$ mailq | tail -n 5
-- 10954 Kbytes in 1423 Requests.

What it means: 1423 queued messages isn’t necessarily fatal, but it’s a smell. If the queue is growing, your “one mailbox” problem is turning into “everyone’s email is delayed.”

Decision: If queue growth is driven by a few recipients, consider temporary transport maps or holds to prevent retry storms while you fix quotas/storage.

Task 5: Identify top recipients in the queue

cr0x@server:~$ sudo postqueue -p | awk '/^[A-F0-9]/{id=$1} /to=

What it means: A few recipients dominate. That’s either a quota issue for those mailboxes or a spam/flood pattern.

Decision: Fix those mailboxes first, or quarantine them to protect the rest of the system.

Task 6: Confirm Dovecot quota status for a user

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=5120M Limit=5120M %
Quota name=User quota Type=MESSAGE Value=98234 Limit=0 %

What it means: Storage quota is exactly at the cap (5120M used of 5120M). Message count quota is unlimited (Limit=0).

Decision: Either increase quota temporarily or enforce cleanup/archiving. Prefer policy-backed cleanup over “just bump it forever.”

Task 7: Locate biggest folders and files in a Maildir (quick triage)

cr0x@server:~$ sudo du -h --max-depth=2 /var/vmail/example.com/alex/Maildir | sort -h | tail -n 10
1.2G    /var/vmail/example.com/alex/Maildir/.Sent
2.6G    /var/vmail/example.com/alex/Maildir/.Archive
5.1G    /var/vmail/example.com/alex/Maildir

What it means: Two folders account for most of the usage. This is great news: you can target cleanup without spelunking the entire account.

Decision: Coordinate with the user (or follow retention policy) to archive/purge old Sent/Archive items first.

Task 8: Find unusually large messages (often attachments)

cr0x@server:~$ sudo find /var/vmail/example.com/alex/Maildir -type f -size +50M -printf "%s %p\n" | sort -nr | head
104857612 /var/vmail/example.com/alex/Maildir/cur/1704361234.M12345P6789.mx1,S=104857612:2,
73400612  /var/vmail/example.com/alex/Maildir/.Sent/cur/1704300044.M22222P1111.mx1,S=73400612:2,

What it means: You have 50MB+ messages sitting in the mailbox. These are prime candidates for user-driven cleanup or automated archiving.

Decision: If policy allows, move large/old mail to an archive system. Don’t delete blindly; people store “important” PDFs in email like it’s a filing cabinet.

Task 9: Recalculate and repair Dovecot quota (after cleanup/moves)

cr0x@server:~$ sudo doveadm quota recalc -u alex@example.com

cr0x@server:~$ sudo doveadm quota get -u alex@example.com
Quota name=User quota Type=STORAGE Value=4032M Limit=5120M %

What it means: Quota accounting now reflects reality. Without this, Dovecot can continue rejecting deliveries even after you freed space.

Decision: If delivery still bounces, you’re dealing with a different limit (filesystem, different quota rule, or a separate storage backend).

Task 10: Check for filesystem quota enforcement (EDQUOT) vs Dovecot quota

cr0x@server:~$ sudo dmesg | tail -n 20
[123456.789012] XFS (sdb1): Quotacheck needed: Please turn quotas off and on again.
[123457.001122] XFS (sdb1): User quota exceeded. UID: 5000

What it means: Filesystem quotas are active and being enforced. Dovecot may be innocent; the kernel is saying “no.”

Decision: Fix the kernel-level quota policy (raise it, change mapping, or repair quota state), not just Dovecot settings.

Task 11: Verify the LMTP/LDA transport path and error codes

cr0x@server:~$ sudo postconf -n | egrep "^(myhostname|mydestination|virtual_transport|mailbox_transport|home_mailbox|virtual_mailbox_domains|virtual_mailbox_base|smtpd_recipient_restrictions)"
myhostname = mx1.example.net
virtual_transport = lmtp:imap1:24
virtual_mailbox_domains = example.com
virtual_mailbox_base = /var/vmail

What it means: Mail is delivered to Dovecot over LMTP. That’s good: Dovecot will produce quota-specific errors, and Postfix will show them.

Decision: Focus on Dovecot quota configuration and mailbox storage health, not local mailbox_command oddities.

Task 12: Inspect Dovecot logs for quota plugin behavior

cr0x@server:~$ sudo grep -E "Quota|quota|overquota|mailbox.*full" /var/log/dovecot.log | tail -n 30
Jan 04 10:12:19 imap1 dovecot: lmtp(alex@example.com)<28177>: Error: quota: Quota exceeded (mailbox for user is full)
Jan 04 10:13:02 imap1 dovecot: imap(alex@example.com)<29001>: Disconnected: Logged out in=512 out=2048

What it means: Dovecot is explicitly rejecting due to quota. That’s definitive.

Decision: Apply quota relief (cleanup or temporary increase), then watch the Postfix queue drain.

Task 13: Drain or requeue mail safely after fixing the constraint

cr0x@server:~$ sudo postqueue -f

cr0x@server:~$ sudo postqueue -p | tail -n 5
-- 842 Kbytes in 97 Requests.

What it means: The queue is flushing and shrinking. If it doesn’t shrink, deliveries are still failing and you should re-check the error reason.

Decision: If you see repeated deferrals for the same user, stop and fix the root cause; don’t just hammer retries.

Task 14: Confirm service health (IMAP/LMTP) after changes

cr0x@server:~$ sudo systemctl status dovecot --no-pager
● dovecot.service - Dovecot IMAP/POP3 email server
     Loaded: loaded (/lib/systemd/system/dovecot.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-04 09:55:22 UTC; 38min ago

What it means: Dovecot is running. This doesn’t prove quotas are correct, but it eliminates “service is down” as your villain.

Decision: If status is flapping or failing, check disk full on logs/runtime dirs, config errors, and TLS files.

Task 15: Check whether the mail store is holding deleted mail (expunge/retention)

cr0x@server:~$ sudo doveadm mailbox status -u alex@example.com messages vsize deleted INBOX
messages=12450 vsize=3120M deleted=840

What it means: There are many deleted messages still taking space (common with some client behaviors or server settings).

Decision: Adjust expunge policy or run an expunge job per retention rules. “User deleted it” doesn’t always mean “disk got it back.”

Recover cleanly (without making a mess)

Recovery is a sequence problem. Do steps in the wrong order and you create new outages:
corrupted indexes, permanent bounces, or an MTA queue that eats your root filesystem.

Case A: The server filesystem is full (or inode-exhausted)

This is the urgent one because it spreads. When the disk is full, everything starts failing: deliveries, logging, TLS handshakes that can’t write state,
even authentication caches. Your goal is stability first, then “mail correctness.”

Stop the bleeding: if the queue is massive and growing, consider throttling incoming mail temporarily (rate limits, greylisting adjustments, or external MX failover if you have it). If you don’t have a plan for that, at least ensure you can write logs.
Free space safely: rotate/compress logs, clean old packages, clear temporary files. Avoid deleting mail store files first; it’s slower, riskier, and politically explosive.
If it’s inodes: identify directories with insane file counts (Maildir cur/new/tmp, spam quarantine) and apply policy-driven cleanup (retention on junk, not on INBOX). Expanding inodes usually means rebuilding the filesystem; treat that as a project, not a hero move at 3 a.m.
Confirm services recover: Postfix, Dovecot, antivirus/milter, and any policy daemons.
Flush queue cautiously: once the constraint is gone, flush and monitor error rates. A queue flush can look like a DDoS against your IMAP nodes if you’re not careful.

Case B: User mailbox quota is full

This is where a lot of teams get sloppy. You can “solve” it by raising quotas forever, which is like fixing a leaking pipe by buying a bigger basement.
Sometimes you do it anyway—temporarily—so business can function. But make it explicitly temporary.

Validate the quota authority: is it Dovecot, filesystem quota, Exchange mailbox limit, or cloud policy?
Confirm actual usage: measure folder sizes and identify top offenders (Sent, Archive, “Projects_2016_FINAL_FINAL”).
Apply relief with traceability: either purge per retention policy (prefer deleting trash/spam first) or increase quota with a ticket and expiration date.
Recalculate quota/indexes: don’t skip this step. Incorrect accounting is how you get “I deleted 2GB, why is it still full?” calls.
Deliver backlog: flush queue and confirm new inbound mail succeeds.

Case C: Remote recipient mailbox is full (not your server)

Your job is to protect your infrastructure and be a good SMTP citizen.

Confirm remote DSN: if you see 552 5.2.2 from the remote MX, accept reality. You can’t ssh into their mailbox.
Avoid infinite retries: configure sane queue lifetimes. Don’t hold mail for weeks unless policy requires it and storage is sized for it.
Communicate: notify the sender that the recipient is over quota. Provide guidance: alternate address, resend later, use a file transfer method.
If it’s a recurring partner: consider limiting retries or implementing a separate queue/transport for that domain so one partner doesn’t fill your disks.

Prevent it like you mean it: quotas, monitoring, retention, and storage design

Prevention is where you decide if mailbox-full is a rare nuisance or a quarterly fire drill.
The best setups make it hard to fail, and easy to recover.

Pick the quota model intentionally (and document it)

You have three common models:

Application quotas (Dovecot, Exchange): flexible per user/group, visible to clients, good UX when QUOTA is enabled.
Filesystem quotas (XFS/ext4 project/user quotas): strong enforcement, works even if the mail app misbehaves, but mapping users to UIDs/projects must be disciplined.
Dataset quotas (ZFS datasets, LVM logical volumes per tenant): great for multi-domain isolation; still pair with per-user quotas for fairness.

Opinion: use app-layer quotas for users and dataset/volume limits for blast-radius control. Relying on one layer is how you get surprised.

Expose quota status to users (or they will expose it to you)

If clients can show “you’re at 95%,” users self-correct. If they can’t, they fill the mailbox until your MTA starts bouncing mail like it’s 1999.

Enable IMAP QUOTA reporting where supported, and ensure your webmail shows it plainly. This isn’t hand-holding; it’s load shedding.

Retention policies: the boring lever that works

Mailboxes fill because organizations don’t decide what email is for. Is it a communication channel, or a record system?
If it’s a record system, build an archive with search and legal hold. If it’s a communication channel, retention should be finite.

Practical take: enforce shorter retention on Trash, Junk, and large attachments first. Nobody sues you for deleting spam.

Storage engineering: size for reality, not for hope

Mail storage grows like mold: slowly, then suddenly, then it’s in places you didn’t know existed.
Design storage with these in mind:

Capacity (obvious) and inodes (less obvious, more painful).
IOPS patterns: many small files, metadata heavy; latency spikes show up as “IMAP is slow” tickets, not storage alerts.
Snapshots/backups: your “deleted mail” may still exist in snapshots. Great for recovery, confusing for capacity planning.
Separation of concerns: keep spool/queue/logs off root if you can; root filling is a multi-service incident.

Monitoring that actually prevents incidents

Alerting on “disk 95%” is the start, not the finish. For mailbox-full prevention, watch:

Filesystem space and inodes for mail store, spool, logs.
Postfix queue size and queue age distribution (old deferred mail is a symptom).
Quota headroom distribution (how many users are >90%).
Top mailbox growth rate (a compromised account sending/receiving floods, or a workflow dumping attachments).
Error code rates (spike in 552/452, LMTP failures, EDQUOT/ENOSPC in logs).

Joke #2: If your monitoring only tells you “disk is full,” congratulations—you built a very loud history book.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

A mid-sized company migrated from an old single-server mail setup to a “proper” split: MX servers running Postfix, IMAP nodes running Dovecot,
and a separate NAS for /var/vmail. They did the migration carefully, tested logins, tested sending, tested receiving. Green checks all around.

Two weeks later, invoices started bouncing. Not all of them—just a few high-volume mailboxes: finance, sales ops, and an executive assistant who lived in email.
The bounces said “Quota exceeded.” Everyone assumed the storage volume was full, because that’s what “mailbox full” sounds like. Storage was at 40%.

The actual culprit was a default Dovecot quota rule left over from a template: 5GB per user. On the old server, quotas were effectively unlimited,
enforced only by disk size. On the new one, quotas were suddenly real. Users had been hoarding mail for a decade, and the new policy landed like a trapdoor.

The recovery was straightforward: raise quotas temporarily for the affected mailboxes, enable quota visibility in webmail,
and roll out retention for Junk/Trash plus a basic archive workflow for finance. The lesson hurt more than the outage:
quotas are product behavior, not just a storage setting. If you change them, you changed the service.

Mini-story 2: The “optimization” that backfired

Another organization decided to “optimize storage” by turning on aggressive compression and deduplication on the mail volume.
The idea wasn’t terrible: attachments repeat, mail is text-heavy, and CFOs love capacity charts that go down.

For a while it looked like a win. Then Monday morning arrived with a familiar chorus: IMAP searches were slow, new mail arrived late,
and the mail queue grew steadily. The alerts triggered on queue size, not disk usage. So the team stared at Postfix settings, because that’s where the pain was.

The backfire was metadata and latency. Maildir workloads do a lot of tiny reads/writes and directory operations. The “optimized” storage layer made those
operations more expensive, especially during compaction. Users didn’t see “storage latency”; they saw “email is broken.”
Meanwhile, the temporary delivery deferrals kept messages in the queue longer, which increased disk churn and made compaction even worse.

The fix wasn’t heroic: scale back the most aggressive settings, schedule heavy maintenance for off-hours, and set guardrails:
maximum queue age alarms, per-volume latency monitoring, and a separate spool disk so queue growth couldn’t starve the whole system.
The moral: if your optimization changes latency tails, it’s not an optimization—it’s a new failure mode.

Mini-story 3: The boring but correct practice that saved the day

A regulated company ran their own mail. Not because they loved it—because compliance did. Their email stack was unglamorous:
Postfix, Dovecot, Maildir, periodic snapshots, and a retention policy enforced by server-side rules.

One afternoon, a mailbox hit quota during a legal discovery window. The executive assistant panicked, because new mail was bouncing and the exec was traveling.
But the team had two boring habits: quotas were visible in webmail, and a daily report listed mailboxes above 85% usage with their top folders.

Instead of guessing, they opened the report, found the top offender folder (.Sent), and applied a pre-approved action:
move mail older than a threshold to the archive mailbox (still searchable, still compliant), then recalc quotas.
Deliveries resumed, the queue drained, and nobody touched the filesystem at all.

Nothing “exciting” happened, which is the highest compliment you can give an operations practice.
Boring saved the day because it was repeatable, authorized, and measurable.

Common mistakes: symptoms → root cause → fix

1) Symptom: Bounces say “mailbox full,” but disk has space

Root cause: Application-level quota (Dovecot/Exchange) is hit; disk isn’t the limiter.
Fix: Check quota status, folder sizes, and quota rules. Cleanup or increase quota temporarily, then recalc quota/indexes.

2) Symptom: Disk usage looks fine, but everything fails with “No space left on device”

Root cause: Inode exhaustion or a different mount (root, spool, logs) is full.
Fix: df -ih and check all relevant mounts. Free inodes (purge spam/quarantine, enforce retention). Move spool/logs off root.

3) Symptom: User deletes mail, still over quota

Root cause: Deleted mail not expunged, or quota accounting stale, or moved to another folder that still counts.
Fix: Recalc quota; check deleted counts; adjust expunge settings; ensure the client actually expunges (especially on IMAP).

4) Symptom: Queue grows rapidly, deliveries keep retrying

Root cause: Transient deferrals (4xx) from delivery backend, often due to storage latency, overloaded IMAP, or policy daemon timeouts.
Fix: Identify dominant recipients/domains; fix backend capacity; throttle; avoid indefinite retries; isolate problem traffic.

5) Symptom: Only large attachments fail; small emails deliver

Root cause: Message size limit on SMTP or mailbox store; sometimes misreported as “full.”
Fix: Confirm size limits in MTA and delivery agent; communicate alternatives; don’t raise limits without considering storage and abuse risk.

6) Symptom: After freeing space, Dovecot still rejects with quota errors

Root cause: Quota plugin uses cached indexes; mismatch between filesystem state and quota database.
Fix: Recalc quota; if needed, repair indexes carefully and during low traffic. Validate permissions and ownership too.

7) Symptom: Only one domain or tenant is “full,” others fine

Root cause: Dataset/project quota at domain level; multi-tenant isolation kicking in.
Fix: Check dataset limits and usage, not just user quotas. Increase domain allocation or enforce tenant retention/archiving.

Checklists / step-by-step plan

Checklist A: When the alert fires (15 minutes to stability)

Confirm whether failures are local or remote (log error codes and relays).
Check df -h and df -ih on root, spool, and mail store.
Check queue size and growth (mailq now, then again in 5 minutes).
Find top recipients in queue; decide whether to isolate them.
If disk/inodes are critical: free safe space first (logs/temp), not mail store deletions.
If quota is the issue: get quota status; identify top folders; apply policy-approved cleanup or temporary increase.
Recalculate quota/indexes.
Flush queue and monitor error rate; confirm new mail deliveries succeed.

Checklist B: Clean recovery without data loss

Before deleting anything: confirm what counts toward quota (Sent/Archive/Junk/Trash).
Prefer moving to archive over deletion when compliance matters.
Document changes: quota adjustments, retention actions, any manual mailbox modifications.
Validate user access after remediation (IMAP login, folder list, new mail arrival).
Confirm that bounces stop and deferred queue drains.
Backfill: if messages were bounced permanently, coordinate resend strategy.

Checklist C: Prevention work that pays rent every month

Define mailbox quotas by role (execs, shared mailboxes, service accounts) and publish the policy.
Enable quota visibility in clients/webmail.
Set retention for Junk/Trash; set a strategy for attachments.
Monitor disk, inodes, and queue age distribution.
Separate spool/logs from root filesystem.
Test recovery quarterly: simulate quota exceed, confirm alerts and runbook accuracy.

FAQ (the questions people ask right after you fix it)

1) Why did the sender get a bounce instead of a delay?

Because the delivery path returned a permanent failure (5xx) like 552/5.2.2. Permanent failures usually generate bounces.
Transient failures (4xx) cause retries and queueing.

2) Should “mailbox full” be a 4xx or 5xx?

If you expect the condition to clear soon (temporary policy window), 4xx can be reasonable. Most quota exceed conditions are treated as 5xx because
the server is explicitly refusing storage. Be careful: 4xx encourages retry storms and queue growth.

3) Users deleted mail but quota didn’t change. Are they lying?

Not necessarily. IMAP deletion often marks messages as deleted until expunge. Also, quota accounting may be stale.
Recalculate quota and verify server-side expunge behavior.

4) Is it safe to delete files directly from Maildir?

It can be safe if you know exactly what you’re doing, but it’s rarely the best first move. Prefer server-side tools (doveadm) or controlled retention jobs.
Manual deletion risks index inconsistencies and user-visible weirdness.

5) Why is inode usage such a big deal on mail servers?

Maildir stores each message as a separate file. Hundreds of thousands of emails translates to hundreds of thousands of inodes.
Run out of inodes and the system can’t create new files—even if gigabytes remain free.

6) Can I just raise quotas and be done?

You can, and sometimes you should (temporarily). But if you do it as the default response, you’re converting a user-level issue into a storage growth problem.
Pair quota increases with retention and archiving, or you’ll repeat the incident with higher numbers.

7) How do I stop one mailbox from filling the Postfix queue?

Identify dominant recipients and consider temporary holds or separate transports for problematic targets.
The goal is blast-radius control: protect the rest of your delivery pipeline while you fix the constraint.

8) What’s the cleanest way to handle large attachments?

Don’t treat email as object storage. Set sane attachment limits and provide an approved file-sharing path.
If compliance requires retention, archive attachments in a system designed for it, with indexing and lifecycle management.

9) Why did freeing space not immediately fix mail delivery?

Because the delivery system might be using cached quota/index state, or the Postfix queue is still retrying slowly.
Recalculate quota, flush the queue, and watch logs for the current failure reason.

10) How do we prove we didn’t lose mail during the incident?

Compare queue state before/after, verify bounces generated, check logs for successful deliveries, and validate mailbox integrity.
If you have journaling or message tracking, use it to confirm end-to-end receipt.

Conclusion: practical next steps

Mailbox-full incidents aren’t glamorous, but they’re predictable. That’s good news: predictable failures are the ones you can engineer out.

Pick a quota strategy (app quotas + dataset limits is a solid combo) and document it like it’s part of the product.
Instrument the right signals: disk, inodes, queue age, quota headroom distribution, and delivery error codes.
Build a safe recovery habit: free safe space first, fix the actual limiter, recalc quota/indexes, then flush queues and verify.
Make retention and archiving real: especially for Junk/Trash and attachments. This is where most of the “mystery growth” lives.

If you do nothing else, implement the fast diagnosis playbook and the checklists above. Next time “mailbox full” shows up, you’ll fix it in minutes—
and you won’t have to explain to finance why the mail server ate itself.