Knowledge base
allowed-sender-lists<source>DirectiveNames address lists that MAIL FROM and the sender address from the message are checked against; a message that fails is rejected at submission.authentication-method<smtp-user>DirectiveFive methods — a password, your own certificate, a certificate from a trusted authority, a Linux system account and LDAP through the vault; the default is a password.dkim-identity<domain>DirectiveLets you sign with your own key messages whose From has someone else’s domain — sending on behalf of a client.domain<virtual-mta-pool>DirectiveRules for a receiver written inside a pool are inherited by each of its members; a member’s own block overrides them.jobid-prefix<source>DirectiveThe value is prepended to the tag that arrived in the header; a reserved value substitutes the login of the submitting user.password<smtp-user>set by the HubDirectiveSets the password for password login; it is stored in the configuration in plain text, because otherwise not all SASL mechanisms can be supported.require-auth<source>set by the HubDirectiveWith true the engine accepts not a single message from the source until the sender logs in — including submission from the machine itself.reserved-smtp-in<source-group>DirectiveReserves the named number of slots from the node’s overall limit for the group: others will not take them, even when the node is loaded.smtp-max-auth-failure-rate<source>set by the HubDirectiveAfter the specified number of failed attempts the engine stops accepting logins from the source until the end of the period; the default limits nothing.source<smtp-user>set by the HubDirectiveBinds the login to a named source block; its settings apply after login and override what the connection’s address would have given.bcc<source>DirectiveEvery message accepted from the source goes as a blind copy to the named address; the manual suggests this for archiving.domain-key<domain-key-list>DirectiveThe list narrows the key search to itself — and is chosen by a message header, not by the configuration.host-idGlobalset by the HubDirectiveA per-server unique number that keeps two engine installations from producing the same Message-Id; the default of zero is the same for everyone.include-headers-fromGlobalDirectiveNames a file with headers in RFC 2822 format; they are inserted right after the Received header the node adds.process-x-sp-subaccount-id<signals>DirectiveAllows the submitting side to assign a subaccount with a message header; the number from the header overrides the one set by the configuration.process-x-sp-subaccount-id<inline-seeding>DirectiveAllows taking the subaccount number from a message header; off by default.queue-filter<acct-file>DirectiveA list of queue names with optional negation; by default records of all queues are written.remove-header<source>set by the HubDirectiveLists, separated by commas, the headers removed at delivery; an empty string erases the inherited list.retain-x-sp-subaccount-id<inline-seeding>DirectiveKeeps the service header in the message after processing; by default it is removed.retain-x-sp-subaccount-id<signals>DirectiveKeeps the service header in the message and makes it possible to write its value to accounting files; the line is shared with the seeding block.sender-or-from<signals-filter>DirectiveEnables or disables export by the domain from the sender header; the subaccount and tracking scope are set there too.bcc-upon-delivery<domain>DirectiveThe blind copy is taken on the recipient side and only from delivered messages; an empty string erases the inherited value.How the node selects a source and combines its settingscriticalMechanismA connection falls under all source blocks whose addresses cover it, and they act merged — the narrow one overrides the wide one; named blocks are attached only by direct reference.Two attachment points — and two different behaviorscriticalMechanismA list attached to a source rejects the recipient at submission or bounces the message later; attached to a sending address or pool, it always accepts and then bounces.Configuration through the API and the file do not reconcilecriticalMechanismObjects created through the configuration interface cannot be edited in the file: two sources of truth about the configuration do not reconcile.How to name a queue in a commandcriticalMechanismHow to name a queue in a command argument: the same “receiving server and sending address” pair with asterisks added.Job headercriticalMechanismThe x-job header tags a message with a job; the node reads it only if the source is allowed process-x-job, and then the job is visible in accounting, the monitor and pause commands.Two tags the sender puts on a messagecriticalMechanismA job groups messages, an envelope identifier identifies one; the submitting side sets both, and only by them can you later select your mail in the node’s queue.Reserved merge variable namescriticalMechanismSome merge variable names are taken by the engine: you cannot give your own variables these names.Six ways to choose a stream and the order among themcriticalMechanismA message’s stream is set by a merge variable, an API call, a header, a pattern rule, a listener and a source default — the manual lists them by precedence.The stream is named by a header, if the source is allowed to do socriticalMechanismA message header names the stream; the source the message was submitted from must have permission to process the header, and the header is stripped before delivery.Address lists — named and unnamedMechanismA list of addresses, domains, patterns or hashes; a named one is attached by directives such as suppression, an unnamed one lives inside an inbound mail processor.The source default is the bottom rung, tied to whoever connectsMechanismA source block matching the sender’s address can name a default stream; it applies when no choice was made higher up the ladder.Submission logins, plain-text passwords and per-user settingsMechanismA sender logs in with one of three methods; each login is a configuration block with a plain-text password, and that login’s named source overrides what its address would have given.The stream is chosen by matching the envelope or a headerMechanismA named rule list matches the return address, the recipient or a header against regular expressions and assigns a stream on the first match.The merge variable is the top rung, and it lives in the contentMechanismA service merge variable names the stream for the message and overrides all other selection methods on its submission path.A license for a fleet, not for a serverMechanismThe license is not bound to a server: it is installed on as many machines as the instance limit allows, and the nodes send volume statistics to the vendor every hour.Restrict who can reach the node at allProcedureFive steps of least privilege: the right to hand over mail only for logins, receiving only from a narrow range, the monitor likewise, and running without system administrator rights.pause jobCommandStops delivery of one job’s messages.resume jobCommandResumes delivery of the job’s messages.show jobsCommandPrints the jobs known to the node and their state.Address lists through the configuration APIcriticalAPI endpointCreates, reads, extends and deletes address and domain lists — for suppression, for example — without editing files.Messages in the queueAPI endpointLists messages in the selected queues, filtered by job, envelope, recipient and sender.JobsAPI endpointReturns jobs that have mail in the queue, as a top; /jobDetail returns one job.ReceivedAccounting recordThe message was successfully submitted to the node — through a mail session or through the submission interface.JobsMonitor screenJobs that have mail in the queue: recipients and volume; each has its own page.