Automatically deleted Postfix emails on Ubuntu usually stem from misconfigured mail delivery agents, aggressive spam filtering, or storage quotas. The most common culprits are Dovecot sieve scripts, amavisd-new quarantine policies, or incorrect permissions in the mail spool directory. Diagnosing the specific layer causing deletion requires inspecting system logs and configuration files for rejection reasons.
Understanding Mail Storage and Delivery
To troubleshoot why emails vanish, you must first understand how Postfix interacts with local delivery agents. Postfix itself is an Mail Transfer Agent (MTA) responsible for routing messages between servers. It does not store emails permanently; it hands them off to a Mail Delivery Agent (MDA) likedovecot-lda or procmail. If emails are disappearing, the issue likely lies in this handoff process or in subsequent processing steps rather than in Postfix's core configuration.
When a message arrives, Postfix checks its destination. For local domains, it invokes the MDA specified in main.cf via the mailbox_command or virtual_mailbox_maps settings. If the MDA fails to write the file to disk due to permission errors, quota limits, or script instructions, the email may be silently discarded or moved to a different location. Understanding this flow helps isolate whether the problem occurs before or after the message leaves Postfix's control.
Checking System Logs for Rejection Reasons
The primary diagnostic tool for any Postfix issue is the mail log. On Ubuntu, these logs are typically stored in/var/log/mail.log or managed by journald. You should look for entries corresponding to the affected user accounts or domain names. Use commands such as grep "[email protected]" /var/log/mail.log to filter relevant events.
Pay close attention to status codes and descriptive messages. A status of sent indicates successful delivery, while deferred suggests temporary issues. However, if you see bounced or rejected, the message was actively refused. Look for phrases like "user unknown," "quota exceeded," or "spam detected." These clues point directly to the component responsible for the deletion. If no logs appear for incoming mail, verify that Postfix is actually receiving connections on port 25.
Investigating Dovecot and Sieve Scripts
Dovecot is often configured as both an IMAP/POP3 server and an LDA. If you use Dovecot, check its configuration for Sieve scripting capabilities. Sieve scripts allow users or administrators to automatically move, delete, or forward emails upon arrival. A common mistake is having a global Sieve script that deletes all untagged messages or moves them to trash without proper notification. Inspect thesieve_default setting in /etc/dovecot/conf.d/90-sieve.conf. Additionally, check user-specific Sieve scripts located in their home directories under .dovecot.sieve. If you find rules that execute fileinto "Trash" followed by automatic emptying, or direct keep failures, this explains the disappearance. Restarting Dovecot after modifying these scripts ensures changes take effect immediately.
Evaluating Spam Filtering and Quarantine Policies
Many Ubuntu setups integrate Amavis or SpamAssassin for content filtering. These tools scan incoming mail and can quarantine suspected spam instead of delivering it to the inbox. If the quarantine policy is set to delete messages after a short retention period, users will perceive them as "auto-deleted." Check the Amavis configuration in/etc/amavis/conf.d/ for settings related to $quarantine_cutoff_size or $sa_quarantine_cutoff_size.
If you suspect spam filtering is the cause, review the quarantine reports or access the quarantine interface if enabled. Temporarily disabling strict spam checks in /etc/spamassassin/local.cf by adjusting required_score can help confirm if filtered messages are being purged. Remember that changing these settings requires restarting the Amavis service using systemctl restart amavis.
Fixing Debian Postfix, Dovecot, and SpamAssassin: External Emails Not Accepted, Outside Addresses Not Sent provides further insights into integrating these components effectively.
Verifying Disk Space and Permissions
Storage exhaustion is a silent killer of email delivery. If the partition hosting/var/mail or virtual mailbox directories is full, new messages cannot be written. Use df -h to check disk usage and du -sh /var/mail to assess mail directory size. Additionally, ensure that the postfix and dovecot users have correct ownership and permissions over the mail spool. Incorrect permissions can cause the MDA to fail silently when attempting to create new mail files.
Troubleshooting Postfix: Local Delivery despite External Agent Configuration offers detailed steps for resolving local delivery permission issues.
Frequently Asked Questions
How do I recover deleted emails?
Recovery depends on where the deletion occurred. If Dovecot deleted them via Sieve, check the Trash folder or enable backup logging. If Amavis quarantined and purged them, recovery is generally impossible unless a separate backup system was active. Always configure regular backups of mail directories to prevent data loss.Can Postfix be configured to keep a copy of every email?
Yes, you can use thebcc feature in main.cf to blind carbon copy all incoming or outgoing mail to a designated archive account. Alternatively, configure your MDA to save copies to a separate directory. This ensures that even if primary delivery fails or is deleted, a record remains intact for auditing purposes.
Why are my emails deferred instead of deleted?
Deferred messages indicate a temporary failure, such as network issues or remote server unavailability. They remain in the queue until they succeed or hit the timeout limit. Deleted messages are actively removed from the system. Checking the mail queue withmailq helps distinguish between pending deliveries and permanent losses.
Does enabling SSL/TLS affect email deletion?
SSL/TLS encryption secures transmission but does not influence storage or deletion logic. However, misconfigured certificates can cause connection drops during submission, leading to timeouts that might mimic delivery failures. Ensure your TLS configurations inmain.cf and master.cf are valid to maintain stable connections.