Demo
Demo

Knowledge base

PMTA knowledge base›Block Global›Directive§ 3.3.1.54.3

relay-address

Globalset by the Hub

Recipient addresses for which the node accepts mail from anyone
in the configuration this is a linerelay-addressinside the block Global
Accepting mail for individual addresses rather than a whole domain

The line names a recipient address for which mail is accepted regardless of who submits it. The value can be either a specific address or a regular expression. The directive is repeated — one line per rule.

This is an acceptance mechanism. Like the neighboring relay-domain, it is about the right to deliver a message to you, not the right to send through you. The manual says the same: it is useful mainly where the node handles inbound mail.

This is exactly how bounces, complaints and service mail reach the node, to be parsed by processors later.

The difference from accepting by domain is precision: a domain accepts mail for any address within it, a pattern only for matching ones.

The main trap is that an open address is open to everyone. This line has no restriction by sender and cannot have one: that is the whole point — a message is accepted from anyone. So an address that ends up here gets all the mail sent to it — including mail that arrives by guessing.

The practical conclusion: make service addresses unguessable, and patterns narrow. A rule like /^bounce@/ opens bounce@ in all your domains at once; /^bounce@bounce\./ only in the service subdomain.

What the Hub does. It writes it — three pattern rules in the node’s base configuration:

/^fbl@fbl\./ — accepting ARF complaints at an address in the service subdomain. /^bounce@bounce\./ — accepting asynchronous bounces where return address rewriting directs them. /^(dmarc|postmaster|abuse)@/ — role addresses.

The third rule did not appear right away, and the template has an explanation next to it: without it, anti-relay bounced DMARC aggregate reports with a 550 relaying denied response, and along with them service messages to abuse@ and everything written to postmaster@.

The patterns of the first two rules are narrow: they open the address only in the service subdomain, not in all of the node’s domains.

Recommended values

What to set. The value is an address or a pattern; what you have to choose is the width:

Value When
a specific address there is one address and it will not change
a narrow pattern the same address in the service subdomain of each domain
a broad pattern role addresses that must work in all domains

The third is acceptable only for addresses that must be open by standard: postmaster@, abuse@, the address for DMARC reports. Narrow everything else.

The syntax, repeatability and the caveat “useful mainly for inbound mail” come from the manual, § 3.3.1.54.3. The advice on pattern width is ours, from the base configuration template.
Example configuration
# this is how the Hub writes the base configuration — narrow patterns plus role addresses
relay-address /^fbl@fbl\./
relay-address /^bounce@bounce\./relay-address /^(dmarc|postmaster|abuse)@/
The first two patterns open the address only in the service subdomain. The third is broader on purpose: these addresses must work in all of the node’s domains, otherwise DMARC reports and service messages get bounced by anti-relay.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends3 mistakes▶

Opening role addresses too late

our experience

What it costsUntil the rule exists, anti-relay bounces everything that arrives at postmaster@, abuse@ and the address for DMARC reports — with a 550 relaying denied response. The aggregate reports you requested yourself with a DNS record never reach you.
How to spot itThere are no DMARC reports even though the rua record is published.
How to do it rightAdd a rule for role addresses and check acceptance by submitting from another machine.

Writing a broad pattern where a narrow one would do

our experience

What it costsA rule like /^bounce@/ opens the address in all of the node’s domains. Everything sent to it by guessing, the node will accept and queue.
How to spot itThe queues hold messages to service addresses of domains that do not use them.
How to do it rightNarrow the pattern to the service subdomain — so that both the left and the right part of the address match.

Expecting the line to grant the right to send

§ 3.3.1.54.3

What it costsIt is about acceptance, not sending. Submission through the node keeps getting refused, however many addresses you list.
How to spot itThe addresses are listed, yet submission gets relaying denied.
How to do it rightAllow submission with a line in the source block.
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.
Reference data
Syntax
relay-address { EMAIL-ADDRESS | REGEX }
Values
a recipient address or a regular expression; the line can be repeated
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
Global
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
The directive is written at the root of the configuration file and applies to the whole node: it has no block, and no inheritance either. Acceptance cannot be restricted by source — that is the point: the address is accepted regardless of who submits.
⇄

Related directives

2 relations

Depends on

Four value types the whole config is written inThe value can be a regular expression, and that has its own parsing. § 3.2

Can be replaced by

relay-domainGlobalThe neighboring way to solve the same task: there a whole domain is opened, here an individual address or pattern. § 3.3.1.54.3

How to check on the node
The rules are visible in the configuration, the behavior is checked by submitting from another machine:
grep -n 'relay-address' /etc/pmta/config
printf 'HELO test\r\nMAIL FROM:<a@example.com>\r\nRCPT TO:<postmaster@your.domain>\r\nQUIT\r\n' | nc <node-address> 25
A 250 response means the address is open for acceptance. It is worth checking the opposite too: an address that was not meant to be opened should get a refusal. A 550 relaying denied refusal on a role address is a sign that the third rule is missing.
◇

What else to read

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.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.◇Address lists — named and unnamedA 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.

In the Hub
Managed at
Infrastructure → Sending addresses
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Receiving inbound mail
Neighboring settings of the block Global:always-allow-relayingsmtp-listenerrelay-debugpickuprelay-domainAll 108 directives of the block →