The block gathers rules for substituting two different things. mail-from changes the envelope return address — the one the bounce returns to and the one SPF checks. from-domain changes the domain in the From header — the one the recipient sees in the mail program.
These are different addresses, and confusing them is costly. The envelope is invisible to the recipient and serves delivery; the header is visible and serves trust. A rule written in the wrong line changes something other than intended.
The list is attached to a source. The manual says plainly: to use it, you must name it in a <source> block. References from <virtual-mta> and <virtual-mta-pool> also exist, but attaching it to a source is the main path: the message passes through the list at reception, before the sending address is chosen.
# envelope — to your own bounce domain, From header — to the visible domain <rewrite-list abc> mail-from *@shop.example.com bounce@bounce.shop.example.com from-domain *.port25.com bouncedomain.com </rewrite-list> <source 0/0> rewrite-list abc </source>
0 relations
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.