| 🛈 SYSTEM INFORMATION | |
|---|---|
| OS type and version | Debian 10 |
| Webmin version | 1.984 |
| Virtualmin version | 6.17-3 |
| Related packages | SpamAssassin, procmail |
Edit:
The problem is that USER_IN_WHITELIST is just another SpamAssassin test with an associated weight rather than an instruction to bypass spam filtering. This is a good thing, because even whitelisted addresses can be forged, so there should still be a threshold above which they can be flagged as spam.
If a user is receiving non-spam messages that nevertheless score high enough that they are not sufficiently offset by the USER_IN_WHITELIST score, then you can either decrease the overall spam score threshold, which may allow more spam through from all addresses, or change the weight of the USER_IN_WHITELIST test, e.g. by inserting something like score USER_IN_WHITELIST -10.0 in either the system-wide .cf file or an individual user’s .cf file.
Keep in mind when testing with GTUBE that SpamAssassin has a specific test for that (named GTUBE) with a weight of 1000!
Original problem:
When my users whitelist an incoming email address, the whitelisting is ignored and messages from the address continue to be delivered to the spam folder. SpamAssassin does add USER_IN_WHITELIST to X-Spam-Status in the message header.
I’m storing SpamAssassin user prefs in a database, if it makes a difference. Those settings are clearly being successfully read, or SpamAssassin wouldn’t know to add USER_IN_WHITELIST to the header.
I can work around this by adding a recipe to /etc/webmin/virtual-server/procmail/[server id] that delivers to the inbox when the message header contains the header described above, but this is not ideal, because any sender could add such a header to their message to completely bypass spam filtering.