Postmaster and abuse aliases

Questions
1

Your question

I’m not able to find a clear explanation in the documentation or in other discussion posts for the handling of [email protected] and [email protected] e-mail aliases.

I see the settings in the configuration to designate [email protected] as the designated e-mail to handle inbound report capture and review as well as the checkbox to enable passing the reports to the “final destination address” upon report review completion. However, what I don’t find in the documentation is any details on the existence of these aliases. My guess is Stalwart expects the administrator to manually create these addresses or to create aliases for postmaster and abuse on an existing account in the domain.

If my assertion is correct, I believe it would be helpful to clearly state this in the documentation. It’s not a far leap to think with the auto-creation of the DNS records as well as the automated-publishing and maintenance of these records, that the postmaster and abuse aliases would be auto-generated or otherwise built into the MTA processing. I believe a short blurb in the Installation or Configuration sections of the documentation could alleviate this misunderstanding.

2

Your assertion is correct. Stalwart does not auto-create postmaster@ or abuse@ addresses. They are treated as ordinary local recipients, which means they must be manually created – either as real accounts or as aliases pointing to an existing account, just like any other address on the domain.

Here is what the docs tell us about how these addresses intersect with Stalwart’s built-in report analysis:

  • The inboundReportAddresses setting (under Settings > MTA > Reports > General) defaults to ["postmaster@*"]. Any address listed there is intercepted by Stalwart’s report analysis engine when a DMARC/DKIM/SPF/TLS report arrives addressed to it.
  • The key word in the docs is that “these addresses must be routable” – meaning the address has to actually exist as a deliverable local address. If [email protected] doesn’t exist in the directory, the SMTP session will reject the incoming message before report analysis ever has a chance to act on it.
  • If inboundReportForwarding is true (the default), after analysis the message is forwarded to the actual account behind that address – so the account or alias must exist for delivery to succeed.

What you need to do: Manually create a postmaster account (or an alias [email protected] pointing to an admin account) for each domain. The same applies to abuse@ if you add it to inboundReportAddresses. A domain’s catchAllAddress field can also serve as a fallback if you’d rather not create individual aliases per domain.

Your feedback that the docs should spell this out explicitly is well taken – the report analysis doc at /docs/mta/reports/analysis notes “these addresses must be routable” but doesn’t explain that this requires manual account/alias creation. Worth filing as a documentation improvement.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.