Safely Test Postfix Mail Injection with postdrop

postdrop is the low-level helper that writes a message into Postfix's maildrop queue, and it is not the tool you reach for to send a test email. You will learn where it fits in Postfix, how to inspect its installed configuration, and how to feed it a controlled message without confusing queueing with delivery. On this machine the command comes from Postfix package version 3.8.6-1ubuntu0.1. Allow about 15 minutes. You need a shell and a working Postfix installation; use a test recipient and a controlled environment if you decide to enqueue a real message.

This guide is about the low-level queue helper. For ordinary local mail submission, the Postfix documentation recommends the sendmail compatibility command, which prepares the submission before relying on postdrop. Direct use of postdrop is most useful when diagnosing that boundary or when a trusted local program already knows the Postfix posting protocol.

1. Confirm the installed command and package

Start with read-only checks. They do not submit mail or change the queue:

$ command -v postdrop
/usr/sbin/postdrop
$ dpkg-query -W -f='${Version}\n' postfix
3.8.6-1ubuntu0.1
$ postdrop --help
postdrop: invalid option -- '-'
postdrop: fatal: usage: postdrop [-c config_dir] [-v]

The last result is expected here. The installed command documents short options and does not provide a GNU-style --help option. Do not turn a failed help probe into a mail test. Read the installed manual with man 1 postdrop when you need the local reference.

2. Inspect the queue and configuration paths

postdrop reads Postfix configuration and creates a file in the maildrop queue directory. Query the values without editing them:

$ postconf -h config_directory queue_directory authorized_submit_users alternate_config_directories
/etc/postfix
/var/spool/postfix
static:anyone

On this installation, the relevant queue path is therefore /var/spool/postfix/maildrop. The helper is set-group-ID so that an unprivileged Postfix submission process can write the protected queue and communicate with Postfix daemons. That is a privilege boundary, not a reason to run an interactive shell or arbitrary application as root.

3. Understand what the command does

The command reads its standard input and copies that input into a new file in maildrop. It is a posting step, not a delivery command. Postfix's pickup service later takes local submissions from that queue and passes them into the normal cleanup and queue-management path. A successful post therefore means Postfix accepted the input into its local queueing boundary, not that the recipient has received it.

There are no recipient arguments in the installed postdrop synopsis. The message and its envelope information are supplied through the Postfix-internal input protocol. This is why a hand-written RFC-style message is not a reliable generic recipe for direct postdrop use: headers alone do not replace the protocol used by the normal submission command.

For a normal local test, use sendmail instead:

$ printf '%s\n' \
    'From: [email protected]' \
    'To: [email protected]' \
    'Subject: Postfix test' \
    '' \
    'Test message from the local Postfix submission path.' \
  | /usr/sbin/sendmail -v [email protected]

Replace both addresses with values approved for your test system. This command can enqueue or attempt delivery, so it is not a harmless probe. The -v belongs to sendmail, not the message body, and its output is delivery diagnostics rather than proof a remote mailbox accepted the message.

4. Use postdrop options only for their documented purpose

The installed synopsis is:

postdrop [-rv] [-c config_dir]

• -r selects the Postfix-internal protocol for reading standard input and reporting status on standard output. The manual says this is currently the only supported method, so treat it as an explicit compatibility detail rather than an optional alternate format.
• -v enables verbose logging for debugging, repeating it for more verbosity. Since Postfix 2.3, the installed manual says this option is available only to the super-user, so do not add it to a script that may run as an ordinary service account and assume it will work.
• -c /path/to/config selects a directory containing main.cf instead of the default configuration directory. A non-standard directory is restricted: it must be listed by alternate_config_directories in the standard configuration, or the command must be invoked by the super-user. This prevents a caller from using the set-group-ID helper with an arbitrary configuration.

Use elevated privileges only when your Postfix administrator has deliberately authorised the configuration and diagnostic action. Do not solve a permission error by running the whole application as root. First check the path, ownership, configuration allow-list and service logs.

5. Check the queue after a controlled submission

If you used the normal sendmail test in step 3, inspect the queue as the same user first:

$ postqueue -p

The exact listing depends on the queue state. An empty queue is valid if Postfix delivered or rejected the message quickly. A queued message means it has not completed delivery. Do not repeatedly submit the same test while investigating, or you may create duplicate mail.

For a direct postdrop integration, capture standard error, standard output and the exit status in the calling program. Fatal errors include malformed input, I/O failure and insufficient memory. The helper logs problems to the configured system logger, or to postlogd where that logging path is in use, as well as to standard error.

if postdrop -r < trusted-postfix-protocol-input; then
    printf '%s\n' 'postdrop accepted the input'
else
    status=$?
    printf 'postdrop failed with status %s\n' "$status" >&2
    exit "$status"
fi

The placeholder input in that example is deliberate. Do not replace it with an ordinary message unless the calling software implements the Postfix-internal protocol expected by your installed version. For ordinary mail, keep using sendmail and diagnose the resulting queue.

6. Recover from an interrupted post

If input is incomplete, or the process receives HUP, INT, QUIT or TERM, the manual says the queue file is deleted, protecting the queue from a partial message. A timeout or broken pipe can still leave your calling application with a failed submission, so record the non-zero status and retry only when the operation is known to be safe to repeat.