When dealing with misconfigured mail servers, you might encounter situations where Postfix accumulates thousands of undelivered messages in its queue. This commonly happens when:

• A script generates excessive notification emails
• SMTP relay credentials get throttled (especially with Office 365)
• DNS or network issues prevent delivery

Many admins first attempt to manually delete files from /var/spool/postfix directories:

sudo rm /var/spool/postfix/active/*
sudo rm /var/spool/postfix/incoming/*

This doesn't work because:

• Postfix maintains an internal database of queued messages
• The queue manager will rebuild missing files
• You risk corrupting the queue structure

Postfix provides built-in tools for queue management:

Viewing the Queue

postqueue -p
# or alternative syntax:
mailq

Flushing All Queued Messages

sudo postsuper -d ALL
# For deferred messages only:
sudo postsuper -d ALL deferred

Alternative Deletion Methods

# Delete by queue ID:
sudo postsuper -d A1B2C3D4E5

# Delete all deferred messages older than 5 days:
find /var/spool/postfix/deferred -type f -mtime +5 -exec rm -f {} \;
postsuper -d ALL deferred

After clearing the queue, implement these safeguards:

# Configure message rate limiting in main.cf:
sudo nano /etc/postfix/main.cf
# Add these lines:
anvil_rate_time_unit = 60s
smtpd_client_message_rate_limit = 100

For Office 365 specifically:

# In master.cf:
smtp.office365.com:587 relay:Password123@=

Set up monitoring with these commands:

# Count messages in queue:
postqueue -p | grep -c '^[0-9A-F]'

# Check queue disk usage:
du -sh /var/spool/postfix

---

When dealing with mail server issues, particularly with Postfix on Ubuntu, one common challenge is managing the mail queue after a malfunction. Recently, I encountered a situation where a misconfigured script flooded our Office 365 relay with thousands of notification emails, causing throttling issues.

Initially, I tried manually deleting files from /var/spool/postfix directories:

sudo rm -rf /var/spool/postfix/active/*
sudo rm -rf /var/spool/postfix/incoming/*

However, postqueue -p still showed messages in the queue because Postfix maintains its own internal tracking of messages.

The correct way to manage Postfix queues involves using dedicated commands rather than direct filesystem manipulation:

# View current queue
sudo postqueue -p

# Flush deferred messages (attempt delivery now)
sudo postqueue -f

# Delete ALL messages in queue (use with caution)
sudo postsuper -d ALL

# Alternative: delete only deferred messages
sudo postsuper -d ALL deferred

For a complete reset when dealing with a flooded queue:

# Stop Postfix service
sudo systemctl stop postfix

# Purge all queued messages
sudo postsuper -d ALL

# Optional: clean up corrupted queue files
sudo postfix -c /etc/postfix check

# Restart Postfix
sudo systemctl start postfix

To avoid similar issues:

# Implement rate limiting in main.cf
sudo nano /etc/postfix/main.cf

Add these configuration lines:

default_process_limit = 100
smtpd_client_connection_rate_limit = 30
anvil_rate_time_unit = 60s

For ongoing monitoring, consider these commands:

# Count messages in queue
sudo mailq | wc -l

# View queue summary
sudo qshape

Setting up a cron job to alert when queue size exceeds thresholds can prevent future incidents.