OQMGR(8)

✨ NAME ✨

okay so <rainbow>oqmgr</rainbow> is the old Postfix queue manager πŸ’Œ β€” like, the vintage one, and she's still out here doing her thing, bestie.


🌸 SYNOPSIS 🌸

oqmgr [generic Postfix daemon options]

πŸ¦‹ DESCRIPTION πŸ¦‹

So the oqmgr(8) daemon is just chilling, waiting for incoming mail to show up, and then she arranges for all of it to get delivered through the Postfix delivery processes. The actual routing strategy? Not her problem, she delegates that whole thing to the trivial-rewrite(8) daemon. Iconic delegation tbh πŸ’…

This program expects to be run from the master(8) process manager. Like, that's her whole support system, she does not run solo.

Mail that's addressed to the local double-bounce address gets logged and then discarded, periodt. Why? Because it stops potential loops caused by undeliverable bounce notifications. The way that undeliverable bounce notifications can spiral into a whole mess? Not on her watch πŸ’€


πŸ“¬ MAIL QUEUES πŸ“¬

The oqmgr(8) daemon keeps these queues, bestie:

  • incoming β€” Inbound mail from the network, or mail picked up by the local pickup(8) agent from the maildrop directory ✨
  • active β€” Messages that the queue manager has opened for delivery. Only a limited number of messages is allowed to enter the active queue (leaky bucket strategy, for a fixed delivery rate) πŸͺ£
  • deferred β€” Mail that could not be delivered upon the first attempt. The queue manager implements exponential backoff by doubling the time between delivery attempts ⏳
  • corrupt β€” Unreadable or damaged queue files are moved here for inspection πŸ”
  • hold β€” Messages that are kept "on hold" are kept here until someone sets them free πŸ”“

πŸ’– DELIVERY STATUS REPORTS πŸ’–

The oqmgr(8) daemon keeps an eye on per-message delivery status reports in these directories, and every single status report file has the same name as the corresponding message file πŸ“

  • bounce β€” Per-recipient status information about why mail is bounced. These files are maintained by the bounce(8) daemon πŸ“
  • defer β€” Per-recipient status information about why mail is delayed. These files are maintained by the defer(8) daemon βŒ›
  • trace β€” Per-recipient status information as requested with the Postfix "sendmail -v" or "sendmail -bv" command. These files are maintained by the trace(8) daemon πŸ•΅οΈ

And it's the oqmgr(8) daemon's job (her main character moment, honestly) to ask the bounce(8), defer(8) or trace(8) daemons to send delivery reports 🫢


πŸŽ€ STRATEGIES πŸŽ€

The queue manager has a whole arsenal of strategies, for either opening queue files (input) or for message delivery (output):

  • leaky bucket β€” This strategy limits the number of messages in the active queue and prevents the queue manager from running out of memory under heavy load πŸͺ£
  • fairness β€” When the active queue has room, the queue manager takes one message from the incoming queue and one from the deferred queue. This prevents a large mail backlog from blocking the delivery of new mail βš–οΈ
  • slow start β€” This strategy eliminates "thundering herd" problems by slowly adjusting the number of parallel deliveries to the same destination 🐒
  • round robin β€” The queue manager sorts delivery requests by destination. Round-robin selection prevents one destination from dominating deliveries to other destinations 🎑
  • exponential backoff β€” Mail that cannot be delivered upon the first attempt is deferred. The time interval between delivery attempts is doubled after each attempt πŸ“ˆ
  • destination status cache β€” The queue manager avoids unnecessary delivery attempts by maintaining a short-term, in-memory list of unreachable destinations 🧠

⚑ TRIGGERS ⚑

On an idle system, the queue manager just waits for trigger events to arrive, or she waits for a timer to go off. A trigger is a one-byte message. Depending on the message received, the queue manager performs one of the following actions β€” and heads up, the message is followed by the symbolic constant used internally by the software:

  • D (QMGR_REQ_SCAN_DEFERRED) β€” Start a deferred queue scan. If a deferred queue scan is already in progress, that scan will be restarted as soon as it finishes πŸ”
  • I (QMGR_REQ_SCAN_INCOMING) β€” Start an incoming queue scan. If an incoming queue scan is already in progress, that scan will be restarted as soon as it finishes πŸ”‚
  • A (QMGR_REQ_SCAN_ALL) β€” Ignore deferred queue file time stamps. The request affects the next deferred queue scan πŸ•°οΈ
  • F (QMGR_REQ_FLUSH_DEAD) β€” Purge all information about dead transports and destinations πŸ’€
  • W (TRIGGER_REQ_WAKEUP) β€” Wakeup call, This is used by the master server to instantiate servers that should not go away forever. The action is to start an incoming queue scan β˜€οΈ

The oqmgr(8) daemon reads an entire buffer worth of triggers. Multiple identical trigger requests are collapsed into one, and trigger requests are sorted so that A and F precede D and I. So like β€” in order to force a deferred queue run, one would request A F D; and in order to notify the queue manager of the arrival of new mail one would request I. iykyk 😌


πŸ“œ STANDARDS πŸ“œ


πŸ”’ SECURITY πŸ”’

The oqmgr(8) daemon is not security sensitive, ngl. She reads single-character messages from untrusted local users, and thus may be susceptible to denial of service attacks 😬 The oqmgr(8) daemon does not talk to the outside world, and she can be run at fixed low privilege in a chrooted environment 🏰


🩺 DIAGNOSTICS 🩺

Problems and transactions are logged to the syslogd(8) or postlogd(8) daemon. Corrupted message files are saved to the corrupt queue for further inspection πŸ—‚οΈ

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


πŸ› BUGS πŸ›

A single queue manager process has to compete for disk access with multiple front-end processes such as cleanup(8). A sudden burst of inbound mail can negatively impact outbound delivery rates 😭 like, she's fighting for her life on that disk fr fr


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

Heads up bestie: changes to main.cf are not picked up automatically, because oqmgr(8) is a persistent process. Use the command "postfix reload" after a configuration change. Periodt.

The text below provides only a parameter summary. See postconf(5) for more details including examples πŸ‘‘

In the text below, transport is the first field in a master.cf entry.

πŸ’œ COMPATIBILITY CONTROLS πŸ’œ

Available before Postfix version 2.5:

  • allow_min_user (default: no) β€” Allow a sender or recipient address to have - as the first character.

Available with Postfix version 2.7 and later:

  • default_filter_nexthop (default: empty) β€” When a content_filter or FILTER request specifies no explicit next-hop destination, use $default_filter_nexthop instead; when that value is empty, use the domain in the recipient address.

🌈 ACTIVE QUEUE CONTROLS 🌈

  • qmgr_clog_warn_time (default: 300s) β€” The minimal delay between warnings that a specific destination is clogging up the Postfix active queue.
  • qmgr_message_active_limit (default: 20000) β€” The maximal number of messages in the active queue.
  • qmgr_message_recipient_limit (default: 20000) β€” The maximal number of recipients held in memory by the Postfix queue manager, and the maximal size of the short-term, in-memory "dead" destination status cache.

πŸ”₯ DELIVERY CONCURRENCY CONTROLS πŸ”₯

  • qmgr_fudge_factor (default: 100) β€” Obsolete feature: the percentage of delivery resources that a busy mail system will use up for delivery of a large mailing list message.
  • initial_destination_concurrency (default: 5) β€” The initial per-destination concurrency level for parallel delivery to the same destination.
  • default_destination_concurrency_limit (default: 20) β€” The default maximal number of parallel deliveries to the same destination.
  • transport_destination_concurrency_limit (default: $default_destination_concurrency_limit) β€” A transport-specific override for the default_destination_concurrency_limit parameter value, where transport is the master.cf name of the message delivery transport.

Available in Postfix version 2.5 and later:

  • transport_initial_destination_concurrency (default: $initial_destination_concurrency) β€” A transport-specific override for the initial_destination_concurrency parameter value, where transport is the master.cf name of the message delivery transport.
  • default_destination_concurrency_failed_cohort_limit (default: 1) β€” How many pseudo-cohorts must suffer connection or handshake failure before a specific destination is considered unavailable (and further delivery is suspended).
  • transport_destination_concurrency_failed_cohort_limit (default: $default_destination_concurrency_failed_cohort_limit) β€” A transport-specific override for the default_destination_concurrency_failed_cohort_limit parameter value, where transport is the master.cf name of the message delivery transport.
  • default_destination_concurrency_negative_feedback (default: 1) β€” The per-destination amount of delivery concurrency negative feedback, after a delivery completes with a connection or handshake failure.
  • transport_destination_concurrency_negative_feedback (default: $default_destination_concurrency_negative_feedback) β€” A transport-specific override for the default_destination_concurrency_negative_feedback parameter value, where transport is the master.cf name of the message delivery transport.
  • default_destination_concurrency_positive_feedback (default: 1) β€” The per-destination amount of delivery concurrency positive feedback, after a delivery completes without connection or handshake failure.
  • transport_destination_concurrency_positive_feedback (default: $default_destination_concurrency_positive_feedback) β€” A transport-specific override for the default_destination_concurrency_positive_feedback parameter value, where transport is the master.cf name of the message delivery transport.
  • destination_concurrency_feedback_debug (default: no) β€” Make the queue manager's feedback algorithm verbose for performance analysis purposes.

πŸ“ RECIPIENT SCHEDULING CONTROLS πŸ“

  • default_destination_recipient_limit (default: 50) β€” The default maximal number of recipients per message delivery.
  • transport_destination_recipient_limit (default: $default_destination_recipient_limit) β€” A transport-specific override for the default_destination_recipient_limit parameter value, where transport is the master.cf name of the message delivery transport.

(part 2 is loading, don't go anywhere πŸ’«)

✨ OTHER RESOURCE AND RATE CONTROLS ✨

Okay bestie, this is where the queue manager’s timing and rate-limit knobs live. It’s giving β€œpatience is a virtue, but make it configurable.” πŸ’…

  • minimal_backoff_time (300s) β€” the minimal time between attempts to deliver a deferred message; prior to Postfix 2.4 the default value was 1000s.
  • maximal_backoff_time (4000s) β€” the maximal time between attempts to deliver a deferred message.
  • maximal_queue_lifetime (5d) β€” consider a message as undeliverable, when delivery fails with a temporary error, and the time in the queue has reached the maximal_queue_lifetime limit.
  • queue_run_delay (300s) β€” the time between deferred queue scans by the queue manager; prior to Postfix 2.4 the default value was 1000s.
  • transport_retry_time (60s) β€” the time between attempts by the Postfix queue manager to contact a malfunctioning message delivery transport.

Available in Postfix version 2.1 and later:

  • bounce_queue_lifetime (5d) β€” consider a bounce message as undeliverable, when delivery fails with a temporary error, and the time in the queue has reached the bounce_queue_lifetime limit.

Available in Postfix version 2.5 and later:

  • default_destination_rate_delay (0s) β€” the default amount of delay that is inserted between individual message deliveries to the same destination and over the same message delivery transport.
  • transport_destination_rate_delay ($default_destination_rate_delay) β€” a transport-specific override for the default_destination_rate_delay parameter value, where transport is the master.cf name of the message delivery transport.

Available in Postfix version 3.1 and later:

  • default_transport_rate_delay (0s) β€” the default amount of delay that is inserted between individual message deliveries over the same message delivery transport, regardless of destination.
  • transport_transport_rate_delay ($default_transport_rate_delay) β€” a transport-specific override for the default_transport_rate_delay parameter value, where the initial transport in the parameter name is the master.cf name of the message delivery transport.

πŸ›‘οΈ SAFETY CONTROLS πŸ›‘οΈ

These are the seatbelts, bestie. Not the ✨fun✨ part, but you absolutely need them.

  • qmgr_daemon_timeout (1000s) β€” how much time a Postfix queue manager process may take to handle a request before it is terminated by a built-in watchdog timer.
  • qmgr_ipc_timeout (60s) β€” the time limit for the queue manager to send or receive information over an internal communication channel.

Available in Postfix version 3.1 and later:

  • address_verify_pending_request_limit (see 'postconf -d' output) β€” a safety limit that prevents address verification requests from overwhelming the Postfix queue.

🌈 MISCELLANEOUS CONTROLS 🌈

The lil grab-bag of extra settings. Random? Maybe. Iconic? Absolutely.

  • config_directory (see 'postconf -d' output) β€” the default location of the Postfix main.cf and master.cf configuration files.
  • defer_transports (empty) β€” the names of message delivery transports that should not deliver mail unless someone issues "sendmail -q" or equivalent.
  • delay_logging_resolution_limit (2) β€” the maximal number of digits after the decimal point when logging delay values.
  • helpful_warnings (yes) β€” log warnings about problematic configuration settings, and provide helpful suggestions.
  • 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:

  • confirm_delay_cleared (no) β€” after sending a "your message is delayed" notification, inform the sender when the delay clears up.

Available in Postfix 3.3 and later:

  • 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.).

πŸ“‚ FILES πŸ“‚

The places where the queue things live. Don’t touch them unless you know what you’re doing, bestie. πŸ’€

  • /var/spool/postfix/incoming β€” incoming queue
  • /var/spool/postfix/active β€” active queue
  • /var/spool/postfix/deferred β€” deferred queue
  • /var/spool/postfix/bounce β€” non-delivery status
  • /var/spool/postfix/defer β€” non-delivery status
  • /var/spool/postfix/trace β€” delivery status

πŸ‘€ SEE ALSO πŸ‘€

Go read these too, they’re part of the lore.


πŸ“– README FILES πŸ“–

Use "postconf readme_directory" or "postconf html_directory" to locate this information.

  • QSHAPE_README β€” Postfix queue analysis

βš–οΈ LICENSE βš–οΈ

The Secure Mailer license must be distributed with this software.

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

  • 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

That’s the OQMGR(8) footer, bestie β€” source, version, and date all wrapped up in that tiny line, periodt. πŸ’…βœ¨

πŸ“¦ where this page comes from