Safely Test Postfix rmail for Legacy UUCP Mail

You will finish with a clear answer to a narrow question: what does rmail do on this Postfix installation, and how can you check its interface without accidentally submitting a real message? The command is a compatibility boundary for mail received through UUCP, not a general purpose mail client.

Allow about fifteen minutes. You need a shell and the Postfix package. The checks in this guide are read-only until the final warning section. No elevated privileges are needed to inspect the command or its manual. Do not run a delivery example on a production host unless you have confirmed the recipient, the local mail policy and a way to trace the resulting message.

1. Confirm which rmail is installed

Start with the executable that your shell would find. This avoids debugging a different wrapper or an old binary elsewhere in PATH:

$ command -v rmail
/usr/sbin/rmail
$ dpkg-query -W -f='${Package} ${Version}\n' postfix
postfix 3.8.6-1ubuntu0.1

Your path and version can differ. On this installation, the binary belongs to Postfix. The package version is useful when comparing behaviour across machines, but it is not a promise that every distribution builds the same command with the same options.

Checkpoint: the command you are about to examine should belong to the mail transport package you expect. If command -v returns an unexpected path, stop and inspect that file before sending anything.

2. Read the local contract and notice the version difference

Read the installed manual rather than relying on a remembered sendmail command line:

$ man 8 rmail

The manual describes rmail user .... It says that the program handles mail received through UUCP, collapses the From lines produced by mail.local into a single return-path form, and passes the processed message to sendmail. It also states that the program is explicitly designed for UUCP and sendmail.

The installed binary exposes a little more information than this older manual page:

$ rmail --help
usage: rmail [-T] [-D domain] user ...

That output is a property of the installed Postfix build, not an invitation to invent a new workflow. It identifies -T and -D domain as available options, while the manual remains the primary description of the mail transformation. If you need one of those options, check the exact behaviour on the same package version and test it in a controlled mail environment.

3. Check failure handling without submitting mail

Calling rmail without a recipient is a safe interface check. It should print usage information and return a non-zero status:

$ rmail </dev/null
usage: rmail [-T] [-D domain] user ...
$ printf 'exit status: %s\n' "$?"
exit status: 64

The exact diagnostic and status can vary by build. The useful result is that no recipient was supplied, so the command has no message destination to process. If your installation instead waits for input or behaves differently, press Ctrl-C and investigate its local documentation before continuing.

Do not use a real address as a substitute for this check. A syntactically valid recipient changes the operation from interface inspection to mail submission.

4. Understand what input rmail expects

rmail receives the mail message on standard input and takes one or more recipients as arguments. The input is not a subject line, a file name or a command to execute. UUCP supplies the historical message format that this wrapper is intended to translate before handing it to the local mail transport.

A conceptual invocation therefore looks like this:

$ rmail [email protected] < uucp-message.txt

This example is deliberately not a delivery test. It only shows the data flow, and example.invalid is reserved for documentation. Do not create a file containing real mail and run this command casually: Postfix may accept, queue or forward the message according to the host's configuration.

When diagnosing an existing UUCP integration, find the process or spool that invokes rmail and inspect the hand-off there. Preserve the original message while testing. A failed delivery can still leave a queue entry, a bounce or sensitive content in logs.

5. Treat recipient arguments as a security boundary

Recipient arguments normally come from a trusted UUCP transport, not directly from an interactive user. If a script constructs the command line from remote data, review its quoting and validation before changing it. Keep each recipient as a separate argument and do not build an unquoted shell command from a UUCP path or header.

The -D domain option is also not a harmless display setting. It changes domain-related processing in the installed program. Use it only when the configured UUCP-to-mail mapping requires it, and record the expected address transformation before testing. The -T option is similarly implementation-specific on this installation; consult the local help and observe its effect in a disposable test environment rather than adding it to a production wrapper by guesswork.

These checks do not require sudo. Running a mail wrapper as root can widen the impact of malformed input and make ownership or queue problems harder to diagnose. Use the account and service context that the existing UUCP integration already uses, and change service configuration only during an approved maintenance window.

6. Verify the hand-off without sending to the outside world

For a real integration test, use a local test recipient or an isolated mail transport agreed by the system owner. Confirm the transport's queue and logs before and after the run, and use a message with no sensitive content. The command will have the same shape as the conceptual example, but the recipient and input must belong to your test environment.

Before running it, capture the current queue state with the Postfix tools already used on the host. Afterward, check whether a new queue entry exists and whether the message was delivered, deferred or rejected. Do not infer success from a silent shell: a successful hand-off only means that the next mail component accepted the input, not that the recipient read it.

Recovery depends on what happened. If a test message was queued, follow the site's normal Postfix queue-management procedure and remove only the message you identified. If the wrapper changed a service unit, cron job or UUCP hook, restore the previous file from the backup made before testing, then reload only the affected service. Do not delete an entire mail queue as a shortcut.

7. Diagnose the common wrong turns

• Expecting a normal mail client: rmail is a UUCP compatibility program. Use the site's ordinary submission interface for interactive mail.
• Testing with a real address: use the no-recipient check first, then an isolated recipient. A valid address can create a queue entry or an outbound delivery.
• Trusting the manual alone: this installed binary reports -T and -D domain, while the local manual has an older, shorter synopsis. Record the package version when comparing hosts.
• Running as root to fix a lookup failure: a missing recipient, wrong domain mapping or absent UUCP input is a configuration problem. Extra privilege does not make the data valid.
• Deleting evidence: keep the original input, queue identifier and relevant log lines until the result is understood. They are usually the shortest route to recovery.