Demo
Demo

Knowledge base

PMTA knowledge base›Configuration block§ 3.3.21

<transmissions-api-listener>

The Transmissions API listener
A second submission door, separate from the mail one

The block describes an entry point for submitting messages over HTTP — not SMTP: address, port and encryption settings. Clients connect over HTTPS, so the tls-certificate certificate is mandatory, and there can be several listeners — each with its own.

This is an independent entry point, not a variety of the mail one. There is no inheritance between them: the mail listener’s settings do not carry over here, and vice versa.

⚠️ And directive names are deceptive here. Some of them match the mail listener’s names, but the manual’s section describes each one anew, with its own syntax and its own default. Read them in their own section, not by analogy.

The connection ceiling is set separately — with a node-level directive (total-max-transmissions-api), not here.

Example configuration
# an HTTP entry point — separate from the mail one
<transmissions-api-listener 127.0.0.1:8443>
    tls-certificate /etc/pmta/api.pem</transmissions-api-listener>
The highlighted line is described in its own section of the manual rather than borrowed from the mail listener — even though the name is the same. We do not have this block: the whole fleet submits messages over SMTP.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
Block directives: 15
TLS 12
tls-certificateThe certificate the Transmissions API entry point presents to clientstls-min-versionThe lower bound of the TLS version on the Transmissions API entry pointtls-ca-fileFile of trusted authorities for API input client certificatestls-cipher-server-preferenceWho chooses the cipher on the Transmissions API input — the node or the clienttls-ciphersThe Transmissions API input cipher set for versions up to TLS 1.2tls-max-versionThe upper bound of the TLS version on the Transmissions API inputtls-v1.3-ciphersuitesTransmissions API input cipher suites for TLS 1.3tls-allow-sslv3deprecatedWhether to accept SSLv3 on the Transmissions API input — the directive has no effecttls-allow-tlsv1deprecatedWhether to accept TLS 1.0 on the Transmissions API input — a deprecated switchtls-allow-tlsv1.1deprecatedWhether to accept TLS 1.1 on the Transmissions API input — a deprecated switchtls-allow-tlsv1.2deprecatedWhether to accept TLS 1.2 on the Transmissions API input — a deprecated switchtls-allow-tlsv1.3deprecatedWhether to accept TLS 1.3 on the Transmissions API input — a deprecated switch
Proxies 3
use-inbound-proxyWhether to expect a load balancer header on the HTTP submission entry pointinbound-proxy-timeoutHow long to wait for the load balancer header at the HTTP submission inputlog-inbound-proxyWhether to log the load balancer header at the Transmissions API input
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
⇄

Related entries

0 relations

Referenced from

total-max-transmissions-apiGlobalLimits connections to the listener described in this block. § 3.3.1.1

◇

What else to read

3 articles

◇Accept, route, deliverA message’s path inside the node: accept, decide where, deliver — and all the settings live between these three steps.◇Four value types the whole config is written inBoolean, domain pattern, regular expression and time interval — defined once in § 3.2 and then used by all directives.◇Reloading settings versus restarting the serviceThe configuration is read at startup, and after that edits are picked up by the reload command — except for the directives the manual marks as requiring a restart.

In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Configuration lifecycle