Check a Local Mailbox Quickly with from.mailutils

Cron mail, a bounce, something from the server you forgot about: you just want to see who wrote and what it was about. The from.mailutils command shows senders and subjects, counts the messages in a mailbox and narrows the list to one sender. The examples use a throwaway mailbox file, so your real inbox is never altered. Allow about ten minutes if Mailutils is installed and you know your mailbox path.

This is a read-only inspection command, and you do not need sudo for a mailbox you can already read.

Warning: do not reach for elevated privileges just to silence a permission error. Root access can expose private mail, and it fixes neither a wrong mailbox path nor a malformed mailbox.

1. Check the installed command

The command comes from the Debian or Ubuntu mailutils package. On this machine that is GNU Mailutils 3.17, package version 1:3.17-1.1build3. The manpage was generated in March 2024, so record the version when comparing output between hosts.

$ command -v from.mailutils
/usr/bin/from.mailutils
$ from.mailutils --version
from.mailutils (GNU Mailutils) 3.17

from is an alias for the same utility on this installation:

$ command -v from
/usr/bin/from
$ from --version
from (GNU Mailutils) 3.17

Tip: use the explicit from.mailutils name in scripts and notes, because it shows which package provides the command. Keep from for the interactive shell.

2. List your incoming mailbox

With no --file option, run the command without a username to inspect your incoming mailbox:

$ from.mailutils
There are 0 messages in your incoming mailbox.

With messages present, each line of the normal listing has the sender address and subject. An empty mailbox is still a successful result, so check the exit status when using it in a script:

$ from.mailutils --no-config
$ printf 'exit status: %s\n' "$?"
exit status: 0

The --no-config option gives you a predictable diagnostic. Without it, Mailutils loads its site and user configuration files, and those can change the environment the command runs in. A result from a configured host is not necessarily what a clean test host would show.

3. Inspect a specific mailbox file

Use -f FILE or --file=FILE when the mailbox is not the default incoming one. The file must be readable and in a mailbox format Mailutils recognises. This example uses an existing mailbox path as a placeholder:

$ from.mailutils --no-config --file=/path/to/mailbox
[email protected]    Subject shown here

Replace /path/to/mailbox with the real file. Inspect permissions first, without changing them:

$ ls -l /path/to/mailbox
$ test -r /path/to/mailbox && echo readable
readable

Tip: if the file is unreadable, ask its owner or the mail administrator for access through the normal process. Do not copy private mail into a world-readable temporary directory.

4. Count messages without the subjects

Add -c or --count when a script only needs the total:

$ from.mailutils --no-config --count --file=/path/to/mailbox
There are 12 messages in your incoming mailbox.

The command prints a sentence, not a bare integer. If another program needs a number, parse the output carefully and keep the installed version in your test coverage. The singular reads differently:

$ from.mailutils --no-config --count --file=/path/to/one-message-mailbox
There is 1 message in your incoming mailbox.

5. Filter by part of a sender address

Use -s ADDRESS or --sender=ADDRESS to print only messages whose sender address contains the string you give:

$ from.mailutils --no-config --sender=alice --file=/path/to/mailbox
[email protected]    First message

The value is a substring filter, not a complete-address match. A short value such as admin can catch more addresses than you meant. Prefer a distinctive fragment, and quote it if it comes from a shell variable:

$ sender_fragment='[email protected]'
$ from.mailutils --no-config --sender="$sender_fragment" --file=/path/to/mailbox

Checkpoint: no matching lines is a normal outcome. It does not prove the mailbox is empty. Run the count form separately if that distinction matters.

6. Protect output and configuration

from.mailutils reads mail and prints a summary. It has no delete or move operation, but the shell can still do damage around it. Avoid redirecting output over a useful file with >. Use a new destination, or append deliberately:

$ from.mailutils --no-config --file=/path/to/mailbox > /tmp/mailbox-summary.txt
$ sed -n '1,20p' /tmp/mailbox-summary.txt

This writes a summary, not a copy of the mail. Even so, the file can hold private sender addresses and subjects, so remove it under your local data-handling policy once you are done.

Security warning: do not put mailbox contents or summaries into shell history, bug reports or shared temporary storage.

For a deliberate configuration test, --config-file=FILE loads the named configuration and implies --no-config. --config-lint checks configuration syntax and exits. Both are for diagnosing Mailutils configuration, not for ordinary mailbox listing.

7. Diagnose common failures

If the command reports that it cannot create or open the mailbox, check the path, permissions and mailbox format first. An empty file can be a valid empty mailbox, while a text file that only looks like an mbox may hold nothing Mailutils can parse.

$ test -f /path/to/mailbox && echo file-exists
$ test -r /path/to/mailbox && echo readable
$ from.mailutils --no-config --file=/path/to/mailbox
$ printf 'exit status: %s\n' "$?"

Use --debug only when the normal checks do not explain the problem. Debug output can include paths and implementation details, so keep it out of routine logs. --debug-level=LEVEL and --debug-line-info give further debugging control, as the installed manpage documents.

If a script depends on a particular output shape, test it against the same Mailutils version and use an explicit --file and --no-config. Keep the mailbox itself unchanged while you diagnose it. These read-only checks never need a mail service restart, an edit to a system mailbox or root.

Done means