vmailctl/SECURITY.md

Security policy

vmailctl runs as root and modifies authentication and mail-routing data. Treat its executable, configuration, source maps and backups as security-sensitive.

Supported versions

Until the first stable release, only the newest tagged public beta is supported.

Reporting a vulnerability

Do not publish passwords, password hashes, mail configuration, account lists, hostnames, IP addresses or exploit details in a public issue.

Use the private contact mechanism provided by the project's repository host. If none is available, open a minimal issue asking the maintainer for a private reporting channel without including sensitive details.

Reports should identify the affected version, describe the impact, and include the smallest safe reproducer possible.

Use the public issue tracker only for reports that contain no sensitive information: https://git.sdf.org/erici/vmailctl/issues.

Deployment precautions

• Install the executable and configuration as root-owned regular files.
• Do not use symbolic links for the configuration, managed mail files, compiled maps, or configured command executables.
• Keep those files and their containing directories unwritable by untrusted users. vmailctl enforces these metadata checks before operation.
• Keep /var/backups/vmailctl accessible only to root.
• Run only reviewed releases from a trusted source.
• Compare the example configuration with the live Postfix and Dovecot setup.
• Retain independent, tested backups outside the transaction-backup directory.
• Run vmailctl audit before and after upgrades.
• Use --dry-run before each new kind of operation.
• Protect terminals and logs when using --generate-password.

Threat-model limits

The transaction lock coordinates cooperative vmailctl processes; it cannot prevent another administrator or program from editing the same files directly. The utility does not protect a host where root is already compromised.

The parser intentionally supports a narrow file schema. A valid but different Postfix or Dovecot layout may be rejected rather than interpreted loosely.

The rollback mechanism handles ordinary failures and terminal interruption, but cannot recover from power loss, kernel failure, or an uncatchable process termination such as SIGKILL. Independent backups remain necessary.