Steps to reproduce
- Add a sender domain to the bypass map via the ns8-mail UI or directly in
bypass_sender_domain.map (e.g. tikehaucapital.com)
- 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)
- 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
Steps to reproduce
bypass_sender_domain.map(e.g.tikehaucapital.com)Fromheader isinfo@tikehaucapital.combut the SMTP envelope sender (MAIL FROM) is a different address from a mailing/relay service (e.g.fo@constance.fr)Expected behavior
The email should be accepted without any spam scoring, since the sender domain
tikehaucapital.comis whitelisted in the bypass map. TheBYPASS_SENDER_DOMAINprefilter rule should fire and setaction: 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:Root cause
The
BYPASS_SENDERandBYPASS_SENDER_DOMAINrules inmultimap.conf.j2usetype = "from"without theextract_fromattribute:According to rspamd documentation,
type = "from"matches the SMTP envelope sender (MAIL FROM) by default — not the MIMEFromheader. 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 theFromheader shows the original sender's domain. The bypass map matches neither.Proposed fix
Add
extract_from = "both"toBYPASS_SENDERandBYPASS_SENDER_DOMAINinmultimap.conf.j2. This instructs rspamd to check both the SMTP envelope sender and the MIMEFromheader against the map:extract_fromhas 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:
extract_from = "both": acceptable tradeoff. The MIMEFromheader is user-controlled and can be forged, but for whitelisting legitimate newsletters this is the only practical option.extract_from: correct by design. Block rules should only match the SMTP envelope sender, which is the only data authenticated by the MTA. Addingextract_from = "both"to block rules would offer no real benefit — a spammer can trivially change the MIMEFromheader 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
Fromheader, they should be kept small and contain only genuinely trusted domains. A forgedFromheader 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.comheader would bypass rspamd checks. However, this risk is limited in practice for several reasons:whitelist_fromdirective works the same way and carries the same documented tradeoff.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
See also
extract_fromdocumentation)type = "from"behavior)