rspamd working but not adding X-Spamd-Result header

[nairobiny]

Hi there

I have a working email server that sits behind a firewall. It can't receive inbound connections, but collects mail from an email service using fetchmail. rspamd is running but it is not adding a X-Spamd-Result header (or any other headers) to inbound email. If I monitor rspamd.log using tail, it seems to score each incoming email. But it's not adding anything to the headers of those emails.

extended_spam_headers = true in milter_headers.conf.

I'd be grateful for any advice on how to get the spam score added to each incoming email. And I accept this is a bit of a vague question, so if there's any specific information I can provide as to my configuration, please let me know.

[glime-ai[bot]]

Please note that this response was created using generative AI, leveraging previously available information from the repository. This information may be helpful. However, it is our strong recommendation that you carefully consider the information before blindly applying it.

---

To address the issue of rspamd not adding the X-Spamd-Result header (or any other headers) to inbound email despite scoring each incoming email as observed in the rspamd.log, there are several potential areas to investigate:

1. Milter Configuration in Postfix: Ensure that rspamd is correctly configured as a milter in your Postfix configuration. This is crucial because rspamd operates as a milter to inspect and modify emails. The configuration parameter in Postfix's main.cf should include rspamd_milter = inet:localhost:11332 added to smtpd_milters. This setup allows rspamd to inspect incoming and outgoing emails and add headers accordingly.

2. Check extended_spam_headers Setting: You've mentioned that extended_spam_headers = true is set in milter_headers.conf. It's good to double-check this configuration file for any typos or syntax errors that might prevent the setting from being applied correctly. Also, ensure that this configuration file is correctly loaded by rspamd.

3. Rspamd Proxy Worker: If you're using a proxy worker setup in rspamd, ensure that it's correctly configured. The proxy worker operates in self-scan mode by default, which simplifies the setup. However, if there are custom settings or overrides, they need to be correctly configured for rspamd to function as expected.

4. Firewall and Network Configuration: Since your email server sits behind a firewall and cannot receive inbound connections, ensure that the necessary ports are open for rspamd to communicate with Postfix and other services. Specifically, the port used by rspamd milter (default is 11332) should be accessible by Postfix.

5. Rspamd Logging and Debugging: Increase the logging level of rspamd to get more detailed information about what happens when it processes emails. This can provide clues as to why headers are not being added. Check the rspamd documentation for instructions on how to adjust logging levels.

6. Check for Conflicts with Other Services: If you have other milters or filters configured in Postfix, ensure there's no conflict that prevents rspamd from adding headers. Sometimes, the order of milters in the smtpd_milters configuration can affect their operation.

If after checking these areas the issue persists, providing more specific information about your configuration, such as the relevant parts of your Postfix and rspamd configuration files, might help in diagnosing the problem more accurately.

This comment was generated by Glime.

[nairobiny]

1. Yes, rspamd is configured as a milter.

Excerpts from main.cf:

non_smtpd_milters = $rspamd_milter
smtpd_milters = $rspamd_milter

rspamadm configdump | grep extended_spam_headers

shows only

extended_spam_headers = true;

3. I am in rspamd_proxy mode. At least, the spam scoring that shows up in the logs is attributed to rspamd_proxy. It's scoring incoming emails, so I guess it's working properly but I'm not sure what else I should be configuring here? DKIM is properly signing outgoing emails, so I know that rspamd is able to update headers.

4. I think this is working properly, because rspamd_proxy is able to score emails.

5. These are at debug level. There are no obvious errors in the rspamd logs.

6. rspamd is the only milter.

[polarathene]

fetchmail is a community contributed feature and the docs we have for it are a little lacking. However the main projects own docs do say this:

As each message is retrieved, fetchmail normally delivers it via SMTP to port 25 on the machine it is running on (localhost), just as though it were being passed in over a normal TCP/IP link.

fetchmail provides the SMTP server with an envelope recipient derived in the manner described previously.
The mail will then be delivered according to your MTA's rules (the Mail Transfer Agent is usually sendmail(8), exim(8), or postfix(8)).
Invoking your system's MDA (Mail Delivery Agent) is the duty of your MTA

If your fetchmail configuration sets a local MDA (see the --mda option), it will be used directly instead of talking SMTP to port 25.

DMS related source files:

https://github.com/docker-mailserver/docker-mailserver/blob/849293f88c8a5faebbe2c704badae92b923b2ac5/target/fetchmail/fetchmailrc

docker-mailserver/target/supervisor/conf.d/dms-services.conf

Lines 117 to 126 in 849293f

	[program:fetchmail]
	startsecs=0
	stopwaitsecs=55
	autostart=false
	autorestart=true
	stdout_logfile=/var/log/supervisor/%(program_name)s.log
	stderr_logfile=/var/log/supervisor/%(program_name)s.log
	user=fetchmail
	environment=HOME="/var/lib/fetchmail",USER="fetchmail"
	command=/usr/bin/fetchmail -f /etc/fetchmailrc --nodetach --daemon "%(ENV_FETCHMAIL_POLL)s" -i /var/lib/fetchmail/.fetchmail-UIDL-cache --pidfile /var/run/fetchmail/fetchmail.pid

docker-mailserver/target/scripts/startup/setup.d/fetchmail.sh

Line 3 in 849293f

function _setup_fetchmail() {

---

I lack time to investigate this further, but it doesn't look like we configure anything differently there, so it's presumably trying to still deliver the mail to Postfix within the container on localhost port 25.

That should result in the mail going through the rspamd milter like any other mail AFAIK, unless there has been some exception added for internal mail delivery (which might be the case since I think we have exceptions for internal services from system users/services sending mail to delivered locally to the postmaster).

@georglauterbach is more familiar with rspamd so may have some input here.

It may require some configuration on the fetchmail side perhaps (see Delivery Control Options). While I don't think DMS provides an easy way to modify the supervisor config for the fetchmail command options, the fetchmail config seems to support the equivalent options as keywords.

---

You should probably share a minimum config to rule out any other DMS settings that could complicate troubleshooting.

[georglauterbach]

I don't know right out of my head, but there are options that exclude certain IP ranges in Rspamd (like local_addrs).

it seems to score each incoming email

We need certainty on that. Can you provide an anonymized source of an e-mail that you received with all headers?

---

PS: I am very low on time, and might not be able to contribute here as much as I'd like.

[polarathene]

there are options that exclude certain IP ranges in Rspamd (like local_addrs).

I'm wondering if this affects opt-out? Upstream docs seem to imply it affects the milter?

docker-mailserver/target/rspamd/local.d/options.inc

Line 3 in 849293f

local_networks = "127.0.0.1/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16";

https://rspamd.com/doc/migration.html#migrating-to-rspamd-160
The milter_headers module now skips adding headers for local networks and authenticated users by default.
This behavior can be re-enabled by setting skip_local = false and/or skip_authenticated = false in the module configuration.

https://rspamd.com/doc/faq.html#can-i-scan-outgoing-mail-with-rspamd
It’s important to note that this mode is activated by default for both authenticated senders and senders originating from local networks (located in options.inc -> local_networks).
The default settings for local networks encompass connections initiated from both loopback/unix sockets and RFC 1918 private networks, such as 10.0.0.0/8 or 192.168.0.0/16.
For outbound checks, numerous checks are deactivated. Therefore, exercise caution to prevent unintentional activation of this mode, for instance, by neglecting to use XCLIENT on a proxy MTA or when employing a backup MX.

https://rspamd.com/doc/quickstart.html#setting-listening-interface
As Rspamd does not perform certain checks for local networks, it may be necessary to adjust the global local_addrs map accordingly.

Maybe somewhat related to discussions here: #3815 (comment)

[nairobiny]

Thank you! I can confirm that adding

set-option-for-module milter_headers skip_authenticated false
set-option-for-module milter_headers skip_local false

to config/rspamd/custom-commands.conf has fixed the issue for me.