https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8401
Bug ID: 8401
Summary: Redirectors plugin incorrectly promotes arbitrary
query parameter values into hostnames for URIDNSBL
lookups
Product: Spamassassin
Version: 4.0.3
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Plugins
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
Created attachment 6068
--> https://bz.apache.org/SpamAssassin/attachment.cgi?id=6068&action=edit
substack to8ex example
The stock Mail::SpamAssassin::Plugin::Redirectors plugin appears to incorrectly
treat an arbitrary query parameter value as a redirect target and generates a
synthetic hostname which is then subjected to URIDNSBL lookups.
This can result in false positives when URI reputation or domain-age DNSBLs are
used.
The original message contains the following URL:
https://substack.com/signup?r=to8ex
There is no URI in the message that references:
http://to8ex
http://to8ex.com
http://www.to8ex.com
or any variation thereof. However, with the stock Redirectors plugin enabled,
SpamAssassin generates the following debug output:
dbg: uri: canonicalizing parsed uri: https://substack.com/signup?r=to8ex
dbg: uri: cleaned uri: https://substack.com/signup?r=to8ex
dbg: uri: added host: substack.com domain: substack.com
dbg: uri: canonicalizing parsed uri: http://to8ex
dbg: uri: cleaned uri: http://to8ex
dbg: uri: cleaned uri: http://www.to8ex.com
dbg: uri: added host: www.to8ex.com domain: to8ex.com
SpamAssassin then performs URIDNSBL lookups against:
to8ex.com
which can trigger URI reputation rules such as SEM URI reputation and age-based
lists.
Initially I suspected a third-party plugin.
To eliminate local causes I disabled all custom URL decoding plugins. The
behavior remained unchanged. I then disabled the stock Redirectors plugin by
commenting out:
loadplugin Mail::SpamAssassin::Plugin::Redirectors
from v402.pre. After doing so, SpamAssassin no longer generated:
http://to8ex
www.to8ex.com
to8ex.com
and no URIDNSBL lookups occurred for that synthetic domain.
Therefore the behavior appears to originate within the stock Redirectors
plugin.
The only change I made was to comment out the Redirectors plugin in v402.pre.
#loadplugin Mail::SpamAssassin::Plugin::Redirectors
Example attached.
--
You are receiving this mail because:
You are the assignee for the bug.
