Do not drop non-report emails to postmaster@, abuse@, … with forwarding disabled

[esclear]

My setup

I'm currently looking at the following setup:

report.analysis.addresses = ["dmarc@*", "abuse@*", "postmaster@*"] # Stalwart default
report.analysis.forward = false

The default address for reporting in Stalwart's DNS records for the domains is postmaster@<domain>.

Forwarding is disabled, since I'm my main mailbox has a catch-all and I don't want my mailbox to be filled with DMARC and TLS reports.

The problem

RFC 5321 mandates that every mailserver accepts mails to the postmaster@… address.
I think it is a reasonable expectation to be able to reach a human when sending mail to the postmaster@ or abuse@ system, if the message is not some sort of automated report.

The documentation states that report.analysis.addresses is the:

List of addresses (which may include wildcards) from which reports will be intercepted and analyzed

And that the report.analysis.forward controls:

Whether reports should be forwarded to their final recipient after analysis

The mention of "report" led me to believe that every email that is not a report would be delivered to the corresponding mailboxes.

This would be the desired behavior (at least for me), as this removes the noise of automated reports, but ensures that all other emails (e.g. manual ones to postmaster@) are still delivered.

However, with report forwarding disabled, no messages to the report addresses (including the postmaster and abuse mailboxes) are delivered, even those, which are not automated emails.

My proposal is to change the behavior so that only automated mails are not forwarded.

Analysis

Looking at the code, the mails are dropped after analyzing, if forwarding is enabled, and it is determined to be a report (is_report is true).

However, is_report only checks whether the mail is for one of the analysis mailboxes.

Possible implementation

Since analyze_report is (attempting to) parse the incoming emails anyways, it might return a bool to indicate whether an analyzed email is an automated report.

The conditions for this could be:

• The mail contains at least one report (attachment)
• All of the reports could be parsed without an error.

This return value could then be used when receiving the email as an additional condition for not forwarding the email.

Consequently, every email where Stalwart isn't sure that it is an automated one, would be forwarded.

Other solutions / available workarounds

Another solution could be to change the DMARC and TLS reporting addresses in the generated DNS records to specialized addresses (e.g. dmarc@, tlsrpt@, …).
In that case, I'd change the defaults used in the DNS records shown for every domain as well.

This can be implemented already today, though the records need to be created by hand.

[dantefromhell]

Thanks for the detailed analysis. I am working on exactly the same setup and have been struggling to get it working, my suspision of might be happening overlaps with your analysis.

Another solution could be to change the DMARC and TLS reporting addresses in the generated DNS records to specialized addresses (e.g. dmarc@, tlsrpt@, …).

This is my preferred solution. I consider the ability to separate "automated reporting" from "human reporting" essential for the proper operation of a mail service without too much toil

[mdecimus]

I agree that this behaviour is not desirable. However, parsing is done on a separate thread to avoid adding latency to email delivery. I suggest that you create a separate email address for reports that is not postmaster, for example reports. Make sure you update your SPF/DKIM/DMARC records to use this new address.

[diogotcorreia]

@mdecimus Perhaps it's the webapp? The response from the backend seems weird:

{
  "data": {
    "report.analysis.addresses.0000": "dmarc-reports@*",
    "lookup.default.domain": "example.com",
    "report.analysis.addresses.0001": "spf-reports@*",
    "report.analysis.forward": "false",
    "report.analysis.addresses": "postmaster@*"
  }
}

This is what my config looks like:

[certificate.default]
cert = "%{file:/run/credentials/stalwart-mail.service/cert.pem}%"
default = true
private-key = "%{file:/run/credentials/stalwart-mail.service/key.pem}%"

[config]
local-keys = ["authentication.fallback-admin.*", "certificate.*", "cluster.node-id", "directory.*", "lookup.default.domain", "lookup.default.hostname", "report.analysis.*", "server.*", "!server.blocked-ip.*", "session.rcpt.catch-all", "storage.blob", "storage.data", "storage.directory", "storage.fts", "storage.lookup", "store.*", "tracer.*"]

[config.resource]
spam-filter = "file:///nix/store/hfadwwi9p08k8f6jk7p1dmsaa3j8965h-stalwart-mail-0.10.5/etc/stalwart/spamfilter.toml"
webadmin = "file:///nix/store/qylihqvrln58x6xig6b8h1q61w2akj3k-webadmin-0.1.17/webadmin.zip"

[directory.internal]
store = "db"
type = "internal"

[lookup.default]
domain = "example.com"
hostname = "mail.example.com"

[report.analysis]
addresses = ["dmarc-reports@*", "spf-reports@*"]
forward = false

[resolver]
public-suffix = ["file:///nix/store/qa1df2rx1m0c0dwf3b67yd0fipgjricm-publicsuffix-list-0-unstable-2024-01-07/share/publicsuffix/public_suffix_list.dat"]
type = "system"

[server.listener]
[server.listener.http]
bind = ["[::]:9988"]
protocol = "http"
url = "https://mail.example.com"
use-x-forwarded = true

[server.listener.imap]
bind = ["[::]:143"]
protocol = "imap"

[server.listener.imaps]
bind = ["[::]:993"]
protocol = "imap"

[server.listener.imaps.tls]
implicit = true

[server.listener.smtp]
bind = ["[::]:25"]
protocol = "smtp"

[server.listener.submission]
bind = ["[::]:587"]
protocol = "smtp"

[server.listener.submmissions]
bind = ["[::]:465"]
protocol = "smtp"

[server.listener.submmissions.tls]
implicit = true

[session.rcpt]
catch-all = true

[storage]
blob = "db"
data = "db"
directory = "internal"
fts = "db"
lookup = "db"

[store]
[store.db]
path = "/var/lib/stalwart-mail/db"
type = "rocksdb"

[store.fs]
path = "/var/lib/stalwart-mail/data/blobs"
type = "fs"

[tracer]
[tracer.log]
enable = true
level = "info"
path = "%{env:LOGS_DIRECTORY}%"
prefix = "stalwart-mail.log"
type = "log"

[tracer.stdout]
ansi = false
enable = true
level = "info"
type = "stdout"

[webadmin]
path = "/var/cache/stalwart-mail"

PS: actual domain changed to example.com

EDIT: Could it be that postmaster@* comes from the database even though report.analysis.* is now in local-keys?

[mdecimus]

Yes, check the documentation section about local vs database settings. The setting you're referring to is a database setting by default. You need to set as local keys every setting that you want to configure from NixOS otherwise they will be stored and read from the DB. Also,remember that you won't be able to modify from the webadmin any of the settings that you are managing from Nix.

[diogotcorreia]

The question here is whether Stalwart is still reading it from the DB even though report.analysis.* is in fact in local-keys. Do I have to go into the DB manually and delete it from there?

EDIT for future reference:
PLEASE BACKUP YOUR DATABASE FIRST
To delete it from RocksDB, run the following command (stalwart must be turned off, since rocksdb only allows a single connection):

sudo -u stalwart-mail ldb --db=./db --column_family=s delete report.analysis.addresses

It is very important that this is ran from the same user as stalwart

[mdecimus]

It might still be in the DB from before you switched the setting to local. If that is the case they yes, you need to delete it from the db.

[esclear]

Not sure if it's a problem on my side, but I'm setting report.analysis.addresses to ["dmarc-reports@*", "spf-reports@*"], but it seems like postmaster@* is always added (presumably due to

mail-server/crates/common/src/manager/boot.rs

Line 276 in c380ec7

("report.analysis.addresses", "postmaster@*"),

)

Is there a way to remove it from the list of report addresses?

There's also another minor inconvenience:
The DNS-records have the postmaster address hardcoded:

• For SPF repords
• For DMARC reports
• For TLS reports

Maybe it's not trivial to decide which report should have which address, since we currently can have multiple addresses that cover all reports, but picking at least one of the configured reporting addresses would be nice.