A list of rules by which the node decides which address to send a message from. It looks at the message itself: a header, the envelope return address or the recipient address.
Three matchers, one syntax. A directive, an optional parameter, a regular expression (case does not matter) and a result. The result is usually the name of a sending address, which is why the list turns out to be a routing layer between what the message looks like and where it leaves from. There is also another kind of result — recipient priority.
Lists nest inside each other. Instead of an answer, a rule can hand the parsing over to another list — you get a decision tree right in the configuration: one list splits the stream into groups, the next ones sort things out within each.
The recipient matcher has a caveat. When there are several recipients and they match different rules, a message cannot leave from two addresses at once — the manual describes how this is resolved.
This is not the list that reacts to the receiver. The similarly named <smtp-pattern-list> is about SMTP responses during delivery and backoff mode. This one is about the outbound choice before sending.
That way one submission port serves any number of domains: a platform submits a message with the return address of its domain, and the node itself directs it to the right sending address. Neither the platform nor the port needs to know about addresses.
The reference to the list sits in the submission block, next to the default-virtual-mta default — that is what fires when no rule matched.
What to select the sending address by — three matchers:
| Matcher | What it looks at | When it fits |
|---|---|---|
| by return address | the envelope address | our case: requires nothing from the submitting side |
| by header | any message header | when the submitting system can set them |
| by recipient | the recipient address | rarely: a message often has many recipients |
The return address is the most reliable choice. Every message has one, and it does not depend on whether the platform can set headers.
Write the expression with an end anchor. A rule like /@domain$/ will match the domain, while without the anchor it also matches any address with this domain inside. That is exactly why the Hub escapes the domain and adds an anchor.
The default is mandatory. A message that matched no rule will go out from the default address — and if there is none, you will have to explain why the message did not go out.
# a rule for each “domain → sending address” pair <pattern-list pmta-pattern> mail-from /@example\.com$/ virtual-mta=mta-news-1 mail-from /@shop\.example\.net$/ virtual-mta=mta-shop-1 </pattern-list> <source {pmta-auth}> pattern-list pmta-pattern default-virtual-mta pmta-pool </source>
what people get wrong and how it ends3 mistakes▶
§ 3.3.14
§ 3.3.15
§ 3.3.14
2 relations
header<pattern-list>One of the three kinds of rules: the return address, the recipient or a header is matched. § 3.3.14.1mail-from<pattern-list>One of the three kinds of rules: the return address, the recipient or a header is matched. § 3.3.14.2rcpt-to<pattern-list>One of the three kinds of rules: the return address, the recipient or a header is matched. § 3.3.14.3The stream is chosen by matching the envelope or a headerThe rule list itself: it is declared separately and attached to a source by name. § 9.4.2Two priorities, and which of them winsRecipient priority is assigned by a pattern rule — by recipient address or by sender. § 11.9.1Third-party components of the engineA related mechanism: they work together. § 3.3.14
grep -n -A10 '^<pattern-list' /etc/pmta/config pmta show vmtas
3 articles
◇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.◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇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.