<smtp-listener>
The line names the certificate for connections arriving at this listener’s address and port. The form is the same as at the node level: a file or a reference to the secrets store, with the password as the second word, also optional.
It is inherited from smtp-server-tls-certificate — the manual says so directly. If it is not set here, the node certificate is presented.
Why separate them. Different entry points may serve different names: platform submission on one address, report receiving on another. A certificate with a matching name on each entry point spares clients mismatch warnings.
The setting is inherited from the node — it is worth setting here only when this entry point must be different:
| What | When |
|---|---|
| do not set it | one entry point or a shared name — the node certificate is used |
| a file of its own | the entry point has its own name, and clients verify it |
| a reference to the store | the private key must not sit as a file on the node |
# configuring one entry point; the rest take the node value <smtp-listener 127.0.0.1:25> tls-certificate /var/lib/pmta/smtp.pem aaaa</smtp-listener>
what people get wrong and how it ends2 mistakes▶
§ 3.3.17.4
our experience
2 relations
openssl s_client -starttls smtp -connect 127.0.0.1:25 2>/dev/null | openssl x509 -noout -subject
3 articles
◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.◇The load balancer header at the entranceThe node reads the PROXY header at the start of an incoming connection and treats the address from it as the source; this works for both kinds of entry point.