Skip to content

ns8-mail: bypass sender/domain map has no effect when email is sent via a third-party mailing service #8060

Description

@stephdl

Steps to reproduce

  1. Add a sender domain to the bypass map via the ns8-mail UI or directly in bypass_sender_domain.map (e.g. tikehaucapital.com)
  2. Receive an email where the MIME From header is info@tikehaucapital.com but the SMTP envelope sender (MAIL FROM) is a different address from a mailing/relay service (e.g. fo@constance.fr)
  3. Check rspamd scoring in the history or logs

Expected behavior

The email should be accepted without any spam scoring, since the sender domain tikehaucapital.com is whitelisted in the bypass map. The BYPASS_SENDER_DOMAIN prefilter rule should fire and set action: no action.

Actual behavior

Rspamd still scores the message and applies rules such as DMARC_POLICY_REJECT, R_DKIM_REJECT, FORGED_SENDER, etc. The bypass has no effect. The following rspamd symbols confirm the issue:

FORGED_SENDER       (0.3) [info@tikehaucapital.com, fo@constance.fr]
FROM_NEQ_ENVFROM    (0)   [info@tikehaucapital.com, fo@constance.fr]
DMARC_POLICY_REJECT (2)   [tikehaucapital.com : No valid SPF, reject]
R_DKIM_REJECT       (1)   [tikehaucapital.com:s=200608]

Root cause

The BYPASS_SENDER and BYPASS_SENDER_DOMAIN rules in multimap.conf.j2 use type = "from" without the extract_from attribute:

BYPASS_SENDER_DOMAIN {
    type = "from";
    filter = "email:domain";
    map = ["${DBDIR}/bypass_sender_domain.map"];
    ...
}

According to rspamd documentation, type = "from" matches the SMTP envelope sender (MAIL FROM) by default — not the MIME From header. When an email is sent through a third-party mailing service (newsletters, marketing tools, etc.), the envelope sender belongs to the service's domain, while the From header shows the original sender's domain. The bypass map matches neither.

Proposed fix

Add extract_from = "both" to BYPASS_SENDER and BYPASS_SENDER_DOMAIN in multimap.conf.j2. This instructs rspamd to check both the SMTP envelope sender and the MIME From header against the map:

BYPASS_SENDER_DOMAIN {
    prefilter = true;
    action = "accept";
    type = "from";
    extract_from = "both";
    filter = "email:domain";
    map = ["${DBDIR}/bypass_sender_domain.map"];
}

extract_from has been available since rspamd 2.1 (October 2019).

Why block rules should NOT get the same change

The asymmetry between bypass and block rules is intentional:

  • Bypass + extract_from = "both": acceptable tradeoff. The MIME From header is user-controlled and can be forged, but for whitelisting legitimate newsletters this is the only practical option.
  • Block rules without extract_from: correct by design. Block rules should only match the SMTP envelope sender, which is the only data authenticated by the MTA. Adding extract_from = "both" to block rules would offer no real benefit — a spammer can trivially change the MIME From header to evade a domain block while keeping their actual envelope sender.

The conclusion is: check both sources when trusting, check only the authenticated envelope when blocking.

Security note

Since bypass maps now match the MIME From header, they should be kept small and contain only genuinely trusted domains. A forged From header with a whitelisted domain would bypass all rspamd checks.

On the security tradeoff

The extract_from = "both" change introduces a known tradeoff worth understanding:

A forged From: info@whitelisted-domain.com header would bypass rspamd checks. However, this risk is limited in practice for several reasons:

  • An attacker would need to know in advance which domains are in the bypass map, which is not public information.
  • The rspamd prefilter only skips spam scoring. Other defenses (ClamAV, Postfix restrictions, etc.) remain fully active.
  • This is the standard approach used by virtually all rspamd and SpamAssassin deployments that handle newsletters. SpamAssassin's whitelist_from directive works the same way and carries the same documented tradeoff.
  • The alternative — keeping bypass maps ineffective for newsletters sent via relay services — leads administrators to disable filters entirely, which is a far greater security risk.

The key operational recommendation is to keep bypass maps small and limit entries to domains whose emails are genuinely expected and recognized by users. A bypass map is not a general-purpose whitelist; it should be used sparingly.

Components

  • ns8-mail (current main branch)
  • rspamd multimap module

See also

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No fields configured for Bug.

Projects

Status
ToDo

Relationships

None yet

Development

No branches or pull requests

Issue actions