Trace Postfix Local Mail Through pickup and maildrop

You will finish with a safe way to identify what the Postfix pickup daemon does, confirm its installed service configuration, and tell a slow local submission path from a downstream queue problem. On this machine the installed package is Postfix 3.8.6-1ubuntu0.1.

Allow about 15 minutes. You need a shell and access to Postfix configuration and logs. Read-only checks work as an ordinary user where permissions allow. Commands that inspect or reload the live mail service are marked as requiring elevated privileges. This guide does not edit main.cf, delete queue files, or start pickup by hand.

1. Keep the service boundary clear

pickup is a Postfix daemon, not a mail-sending command. Its normal invocation is controlled by master; the manpage exposes only generic Postfix daemon options. It waits for notification that a message has arrived in the maildrop queue, reads the file, and passes the message to cleanup. Cleanup then puts the normalised message into the main Postfix queue.

That means a local submission normally follows this path:

sendmail -> postdrop -> maildrop -> pickup -> cleanup -> incoming

Do not launch /usr/lib/postfix/sbin/pickup yourself. It expects to be started by the Postfix process manager, and a manually launched copy can use the wrong environment, permissions, or queue. Check the package instead:

$ dpkg-query -W postfix
postfix 3.8.6-1ubuntu0.1

There may be no pickup command in an ordinary user's PATH. That is not evidence that the service is absent.

2. Confirm the configured service

Use postconf for read-only inspection. These checks do not reload Postfix and do not need sudo:

$ postconf -M pickup
pickup     unix  n       -       y       60      1       pickup
$ postconf -h queue_directory config_directory pickup_service_name
/var/spool/postfix
/etc/postfix
pickup

The -M result is the master.cf service entry. The service name is normally pickup, and pickup_service_name tells Postfix which service handles local submissions. If that parameter names another service, inspect that service in master.cf rather than assuming the default name.

Checkpoint: the queue directory and configuration directory shown by your host are the values to use in later checks. Do not replace them with a guessed path.

3. Check the controls that affect pickup

The pickup manpage lists a small set of main.cf parameters. Display the effective values and compiled defaults together when a setting looks surprising:

$ postconf line_length_limit max_idle max_use ipc_timeout content_filter receive_override_options
line_length_limit = 2048
max_idle = 100s
max_use = 100
ipc_timeout = 3600s
content_filter =
receive_override_options =
$ postconf -d line_length_limit max_idle max_use ipc_timeout
line_length_limit = 2048
max_idle = 100s
max_use = 100
ipc_timeout = 3600s

An empty content_filter or receive_override_options is a real value, not a missing command result. These controls apply as the message is handed to cleanup: a content filter can receive the queued message, while receive overrides can change recipient validation, built-in content filtering, or address mapping. Treat changes to them as mail-routing changes, not as pickup tuning.

4. Look for a maildrop backlog

Inspect the queue summary before looking at individual files. Listing the queue is an ordinary diagnostic, but it may expose mail addresses in its output:

$ postqueue -p
Mail queue is empty

If local submissions are waiting specifically for pickup, the relevant directory is maildrop below the configured queue directory. A privileged read may be needed:

$ sudo find /var/spool/postfix/maildrop -maxdepth 1 -type f -printf '%f\n' | head

An empty result means there are no regular maildrop files at that instant. It does not prove that the complete Postfix queue is empty. Conversely, files in maildrop are not an invitation to open, edit, move, or delete them: they are live queue data and may contain personal or confidential message content.

For a persistent backlog, compare the count over a short interval and inspect logs rather than repeatedly restarting services:

$ sudo find /var/spool/postfix/maildrop -maxdepth 1 -type f | wc -l
$ sleep 10
$ sudo find /var/spool/postfix/maildrop -maxdepth 1 -type f | wc -l
$ sudo journalctl -u postfix --since '15 minutes ago' --no-pager | tail -n 80

Use the queue path from postconf -h queue_directory if it differs from this example. The daemon reports problems and transactions through syslog or Postfix's logging service, so the exact log command depends on the host.

5. Separate pickup trouble from cleanup trouble

A maildrop count that falls while the message appears in the main queue shows that pickup and cleanup are making progress. It does not prove final delivery. Check the queue again:

$ postqueue -p

Messages can leave maildrop and still wait in incoming, active, or deferred. Investigate recipient routing, filters, delivery agents, and remote connectivity at that point. Do not blame pickup for a message that has already reached the normal queue.

If files remain in maildrop and logs show pickup or cleanup errors, check ownership and permissions with the Postfix tools. This is a read-only check, but it requires the service account's view of the queue:

$ sudo postfix check
postfix/postfix-script: the Postfix mail system is not running

The example output is host-dependent. A successful check may print nothing. A non-zero result is evidence to investigate, not a reason to delete files. Preserve the diagnostic output before making a repair.

6. Apply a configuration change safely

A running pickup process can retain old main.cf values for up to about an hour. After a reviewed configuration change, reload Postfix to shorten that delay:

$ sudo postfix reload
postfix/postfix-script: refreshing the Postfix mail system

This command is service-affecting and needs elevated privileges. It does not repair malformed queue files or force delivery. If the reload fails, keep the previous configuration available and read the reported error and Postfix logs. Recovery is to restore the last known-good configuration and run the reload again; do not remove queue data as a first response.

7. Handle malformed files and sensitive data

The pickup daemon deletes ill-formatted files without notifying the originator. That boundary is why you should not hand-create files in maildrop or test by copying arbitrary text there. Use the supported Postfix submission interface when you need an end-to-end test, and choose a test recipient whose delivery and privacy implications you understand.

For a non-delivery check of address rewriting, use the sendmail compatibility command's verification mode instead of injecting a message:

$ sendmail -bv [email protected]

This exercises recipient verification and routing logic without collecting a message for delivery. It does not exercise the pickup daemon. An actual local submission creates queue state and may send mail, so schedule it deliberately, record the queue ID, and remove or release it only with the normal Postfix queue tools after confirming the message is yours.