VIRTUAL(8)

okay bestie, grab your iced coffee and settle in because we're about to unpack virtual(8) from the System Manager's Manual and honestly? it's giving main character energy πŸ’…βœ¨


πŸŽ€ NAME πŸŽ€

virtual β€” the Postfix virtual domain mail delivery agent, periodt πŸ‘‘


🌸 SYNOPSIS 🌸

virtual [generic Postfix daemon options]

πŸ’œ DESCRIPTION πŸ’œ

okay so the virtual(8) delivery agent is literally built for virtual mail hosting services πŸ πŸ’–. Originally it was based on the Postfix local(8) delivery agent, but here's the glow-up: instead of doing hard-coded unix password file lookups of just the address local part, this agent looks up recipients with map lookups of their full recipient address. way more flexible, no cap.

and listen β€” this delivery agent only delivers mail. that's it. that's the job πŸ€·β€β™€οΈ. other stuff like mail forwarding, out-of-office notifications, etc.? you gotta set those up yourself via virtual_alias maps or via similar lookup mechanisms. it will not do it for you, bestie.


πŸ“¬ MAILBOX LOCATION πŸ“¬

where your mailbox lives is controlled by the virtual_mailbox_base and virtual_mailbox_maps configuration parameters (peep below for those πŸ‘€). the virtual_mailbox_maps table is indexed by the recipient address, as described under TABLE SEARCH ORDER further down.

the mailbox pathname gets built like this:

$virtual_mailbox_base/$virtual_mailbox_maps(recipient)

where recipient is the full recipient address. slay.


πŸ“ UNIX MAILBOX FORMAT πŸ“

when the mailbox location does not end in /, the message is delivered in UNIX mailbox format. this format stores multiple messages in one textfile, old school, kinda iconic honestly.

here's everything the virtual(8) delivery agent prepends/appends, in order:

  • prepends a "From sender time_stamp" envelope header to each message
  • prepends a Delivered-To: message header with the envelope recipient address
  • prepends an X-Original-To: header with the recipient address as given to Postfix
  • prepends a Return-Path: message header with the envelope sender address
  • prepends a > character to lines beginning with "From "
  • appends an empty line

the mailbox is locked for exclusive access while delivery is in progress πŸ”’. and if things go sideways, an attempt is made to truncate the mailbox back to its original length. damage control queen.


πŸ—‚οΈ QMAIL MAILDIR FORMAT πŸ—‚οΈ

when the mailbox location ends in /, the message is delivered in qmail maildir format. this one stores one message per file β€” very "we don't share" of it πŸ’….

here's what the virtual(8) delivery agent prepends:

  • a Delivered-To: message header with the final envelope recipient address
  • an X-Original-To: header with the recipient address as given to Postfix
  • a Return-Path: message header with the envelope sender address

and by definition, maildir format does not require application-level file locking during mail delivery or retrieval. no lock needed, she's independent like that πŸ¦‹.


πŸ‘‘ MAILBOX OWNERSHIP πŸ‘‘

mailbox ownership is controlled by the virtual_uid_maps and virtual_gid_maps lookup tables, which are indexed with the full recipient address. each table provides a string with the numerical user and group ID, respectively.

the virtual_minimum_uid parameter imposes a lower bound on numerical user ID values that may be specified in any virtual_uid_maps. so don't try to sneak a tiny uid in there, bestie, it's not gonna fly πŸ™…β€β™€οΈ.


πŸ”€ CASE FOLDING πŸ”€

all delivery decisions are made using the full recipient address, folded to lower case. see also the next section for a few exceptions with optional address extensions πŸ‘€.


πŸ”Ž TABLE SEARCH ORDER πŸ”Ž

normally, a lookup table is specified as a text file that serves as input to the postmap(1) command. the result β€” an indexed file in dbm or db format β€” is used for fast searching by the mail system. fast = good.

the search order is as follows, and the search stops upon the first successful lookup:

  • when the recipient has an optional address extension, the user+extension@domain.tld address is looked up first.

with Postfix versions before 2.1, the optional address extension is always ignored. (old behavior, we don't stan.)

  • the user@domain.tld address, without address extension, is looked up next.
  • finally, the recipient @domain is looked up.

when the table is provided via other means such as NIS, LDAP or SQL, the same lookups are done as for ordinary indexed files.

alternatively, a table can be provided as a regular-expression map where patterns are given as regular expressions. in that case, only the full recipient address is given to the regular-expression map. just the full one, that's it 🎯.


πŸ” SECURITY πŸ”

the virtual(8) delivery agent is not security sensitive β€” provided that the lookup tables with recipient user/group ID information are adequately protected πŸ›‘οΈ. also: this program is not designed to run chrooted.

🚨 the virtual(8) delivery agent disallows regular expression substitution of $1 etc. in regular expression lookup tables, because that would open a security hole. do not come for her, she's protecting you.
⚠️ the virtual(8) delivery agent will silently ignore requests to use the proxymap(8) server. instead it will open the table directly. before Postfix version 2.2, the virtual delivery agent will terminate with a fatal error. dramatic? yes. accurate? also yes.

πŸ“œ STANDARDS πŸ“œ

  • RFC 822 (ARPA Internet Text Messages)

🩺 DIAGNOSTICS 🩺

mail bounces when the recipient has no mailbox or when the recipient is over disk quota. in all other problem cases, mail for an existing recipient is deferred and a warning is logged. different problems, different consequences, iykyk.

problems and transactions are logged to syslogd(8) or postlogd(8). corrupted message files are marked so that the queue manager can move them to the corrupt queue afterwards. bye, messy file πŸ’€.

depending on the setting of the notify_classes parameter, the postmaster is notified of bounces and of other trouble πŸ“£.


πŸ› BUGS πŸ›

so, this delivery agent supports address extensions in email addresses and in lookup table keys, but it does not propagate address extension information to the result of table lookup. sigh 😭.

also, Postfix should have lookup tables that can return multiple result attributes. in order to avoid the inconvenience of maintaining three tables, use an LDAP or MYSQL database. three tables is a lot of work, bestie, we get it.


βš™οΈ CONFIGURATION PARAMETERS βš™οΈ

changes to main.cf are picked up automatically, as virtual(8) processes run for only a limited amount of time. use the command "postfix reload" to speed up a change. lazy but efficient, we love.

the text below provides only a parameter summary. see postconf(5) for more details including examples.


πŸ“¦ MAILBOX DELIVERY CONTROLS πŸ“¦

  • virtual_mailbox_base (empty) β€” a prefix that the virtual(8) delivery agent prepends to all pathname results from $virtual_mailbox_maps table lookups.
  • virtual_mailbox_maps (empty) β€” optional lookup tables with all valid addresses in the domains that match $virtual_mailbox_domains.
  • virtual_minimum_uid (100) β€” the minimum user ID value that the virtual(8) delivery agent accepts as a result from $virtual_uid_maps table lookup.
  • virtual_uid_maps (empty) β€” lookup tables with the per-recipient user ID that the virtual(8) delivery agent uses while writing to the recipient's mailbox.
  • virtual_gid_maps (empty) β€” lookup tables with the per-recipient group ID for virtual(8) mailbox delivery.

available in Postfix version 2.0 and later: ✨

  • virtual_mailbox_domains ($virtual_mailbox_maps) β€” Postfix is the final destination for the specified list of domains; mail is delivered via the $virtual_transport mail delivery transport.
  • virtual_transport (virtual) β€” the default mail delivery transport and next-hop destination for final delivery to domains listed with $virtual_mailbox_domains.

available in Postfix version 2.5.3 and later: ✨

  • strict_mailbox_ownership (yes) β€” defer delivery when a mailbox file is not owned by its recipient.

πŸ”’ LOCKING CONTROLS πŸ”’

  • virtual_mailbox_lock (see postconf -d output) β€” how to lock a UNIX-style virtual(8) mailbox before attempting delivery.
  • deliver_lock_attempts (20) β€” the maximal number of attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.
  • deliver_lock_delay (1s) β€” the time between attempts to acquire an exclusive lock on a mailbox file or bounce(8) logfile.
  • stale_lock_time (500s) β€” the time after which a stale exclusive mailbox lockfile is removed.

🚦 RESOURCE AND RATE CONTROLS 🚦

  • virtual_mailbox_limit (51200000) β€” the maximal size in bytes of an individual virtual(8) mailbox or maildir file, or zero (no limit).

implemented in the qmgr(8) daemon: ✨

  • virtual_destination_concurrency_limit ($default_destination_concurrency_limit) β€” the maximal number of parallel deliveries to the same destination via the virtual message delivery transport.
  • virtual_destination_recipient_limit ($default_destination_recipient_limit) β€” the maximal number of recipients per message for the virtual message delivery transport.

🧩 MISCELLANEOUS CONTROLS 🧩

  • config_directory (see postconf -d output) β€” the default location of the Postfix main.cf and master.cf configuration files.
  • daemon_timeout (18000s) β€” how much time a Postfix daemon process may take to handle a request before it is terminated by a built-in watchdog timer.
  • delay_logging_resolution_limit (2) β€” the maximal number of digits after the decimal point when logging delay values.
  • ipc_timeout (3600s) β€” the time limit for sending or receiving information over an internal communication channel.
  • max_idle (100s) β€” the maximum amount of time that an idle Postfix daemon process waits for an incoming connection before terminating voluntarily.
  • max_use (100) β€” the maximal number of incoming connections that a Postfix daemon process will service before terminating voluntarily.
  • process_id (read-only) β€” the process ID of a Postfix command or daemon process.
  • process_name (read-only) β€” the process name of a Postfix command or daemon process.
  • queue_directory (see postconf -d output) β€” the location of the Postfix top-level queue directory.
  • syslog_facility (mail) β€” the syslog facility of Postfix logging.
  • syslog_name (see postconf -d output) β€” a prefix that is prepended to the process name in syslog records, so that, for example, "smtpd" becomes "prefix/smtpd".

available in Postfix version 3.0 and later: ✨

  • virtual_delivery_status_filter ($default_delivery_status_filter) β€” optional filter for the virtual(8) delivery agent to change the delivery status code or explanatory text of successful or unsuccessful deliveries.

available in Postfix version 3.3 and later: ✨

  • enable_original_recipient (yes) β€” enable support for the original recipient address after an address is rewritten to a different address (for example with aliasing or with canonical mapping).
  • service_name (read-only) β€” the master.cf service name of a Postfix daemon process.

available in Postfix 3.5 and later: ✨

  • info_log_address_format (external) β€” the email address form that will be used in non-debug logging (info, warning, etc.).

✨ SEE ALSO ✨

okay bestie, if you want the whole friend group, here's who shows up:

  • qmgr(8) β€” the queue manager, literally the main character
  • bounce(8) β€” delivery status reports (the "hey your mail bounced" texts)
  • postconf(5) β€” configuration parameters, all the settings you can tweak
  • postlogd(8) β€” Postfix logging
  • syslogd(8) β€” system logging, the OG log vibe

πŸ¦‹ README_FILES πŸ¦‹

want the extra lore? use postconf readme_directory or postconf html_directory to locate this information, no cap.

  • VIRTUAL_README β€” the domain hosting howto, iconic

πŸ“œ LICENSE πŸ“œ

The Secure Mailer license must be distributed with this software. like, it has to come along for the ride, periodt.


πŸ•°οΈ HISTORY πŸ•°οΈ

so this delivery agent was originally based on the Postfix local delivery agent πŸ’–. the modifications? mainly removing code that either was not applicable or that was not safe in this context: aliases, ~user/.forward files, delivery to "|command" or to /file/name. not me cleaning house for safety πŸ”₯.

also, the Delivered-To: message header appears in the qmail system by Daniel Bernstein. and the maildir structure appears in the qmail system by Daniel Bernstein too. we stan Daniel Bernstein for those, fr fr.


πŸ‘‘ AUTHOR(S) πŸ‘‘

the legends who made this happen:

  • Wietse Venema β€” IBM T.J. Watson Research, P.O. Box 704, Yorktown Heights, NY 10598, USA
  • Wietse Venema β€” Google, Inc., 111 8th Avenue, New York, NY 10011, USA
  • Andrew McNamara β€” andrewm@connect.com.au, connect.com.au Pty. Ltd., Level 3, 213 Miller St, North Sydney 2060, NSW, Australia

and that's the footer, bestie: VIRTUAL(8) πŸ’… you just read the whole page, slay. that's the source/version right there. periodt. βœ¨πŸ’–

πŸ“¦ where this page comes from