allow-deny
# vi /etc/mail/spamassassin/local.cf
trusted_networks ip.add.re.ss[/mask] ... (default: none)
trusted_networks 192.168.0.0/16 # all in 192.168.*.*
trusted_networks 192.168. # all in 192.168.*.*
trusted_networks 212.17.35.15 # just that host
trusted_networks !10.0.1.5 10.0.1/24 # all in 10.0.1.* but not 10.0.1.5
trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
# 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64
-----------------------------------------------------------------------------------
e.g.
whitelist_from joe@example.com fred@example.com
whitelist_from *@example.com
whitelist_from 212.17.35.15
---------------------------------------------------------------
e.g.
unwhitelist_from joe@example.com fred@example.com
unwhitelist_from *@example.com
# service spamassassin restart
#############################################################################################################
whitelist_from add@ress.com
Used to specify addresses which send mail that is often tagged (incorrectly) as spam; it also helps if they are addresses of big companies with lots of lawyers. This way, if spammers impersonate them, they'll get into big trouble, so it doesn't provide a shortcut around SpamAssassin.
Whitelist and blacklist addresses are now file-glob-style patterns, so friend@somewhere.com, *@isp.com, or *.domain.net will all work. Specifically, * and ? are allowed, but all other metacharacters are not. Regular expressions are not used for security reasons.
Multiple addresses per line, separated by spaces, is OK. Multiple whitelist_from lines is also OK.
The headers checked for whitelist addresses are as follows: if Resent-From is set, use that; otherwise check all addresses taken from the following set of headers:
Envelope-Sender
Resent-Sender
X-Envelope-From
From
e.g.
whitelist_from joe@example.com fred@example.com
whitelist_from *@example.com
unwhitelist_from add@ress.com
Used to override a default whitelist_from entry, so for example a distribution whitelist_from can be overridden in a local.cf file, or an individual user can override a whitelist_from entry in their own user_prefs file. The specified email address has to match exactly the address previously used in a whitelist_from line.
e.g.
unwhitelist_from joe@example.com fred@example.com
unwhitelist_from *@example.com
whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
Use this to supplement the whitelist_from addresses with a check against the Received headers. The first parameter is the address to whitelist, and the second is a string to match the relay's rDNS.
This string is matched against the reverse DNS lookup used during the handover from the untrusted internet to your trusted network's mail exchangers. It can either be the full hostname, or the domain component of that hostname. In other words, if the host that connected to your MX had an IP address that mapped to 'sendinghost.spamassassin.org', you should specify sendinghost.spamassassin.org or just spamassassin.org here.
Note that this requires that trusted_networks be correct. For simple cases, it will be, but for a complex network, or if you're running with DNS checks off or with -L, you may get better results by setting that parameter.
e.g.
whitelist_from_rcvd joe@example.com example.com
whitelist_from_rcvd *@axkit.org sergeant.org
def_whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
Same as whitelist_from_rcvd, but used for the default whitelist entries in the SpamAssassin distribution. The whitelist score is lower, because these are often targets for spammer spoofing.
unwhitelist_from_rcvd add@ress.com
Used to override a default whitelist_from_rcvd entry, so for example a distribution whitelist_from_rcvd can be overridden in a local.cf file, or an individual user can override a whitelist_from_rcvd entry in their own user_prefs file.
The specified email address has to match exactly the address previously used in a whitelist_from_rcvd line.
e.g.
unwhitelist_from_rcvd joe@example.com fred@example.com
unwhitelist_from_rcvd *@axkit.org
blacklist_from add@ress.com
Used to specify addresses which send mail that is often tagged (incorrectly) as non-spam, but which the user doesn't want. Same format as whitelist_from.
unblacklist_from add@ress.com
Used to override a default blacklist_from entry, so for example a distribution blacklist_from can be overridden in a local.cf file, or an individual user can override a blacklist_from entry in their own user_prefs file.
e.g.
unblacklist_from joe@example.com fred@example.com
unblacklist_from *@spammer.com
whitelist_to add@ress.com
If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be whitelisted. Useful if you're deploying SpamAssassin system-wide, and don't want some users to have their mail filtered. Same format as whitelist_from.
There are three levels of To-whitelisting, whitelist_to, more_spam_to and all_spam_to. Users in the first level may still get some spammish mails blocked, but users in all_spam_to should never get mail blocked.
more_spam_to add@ress.com
See above.
all_spam_to add@ress.com
See above.
blacklist_to add@ress.com
If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will be blacklisted. Same format as blacklist_from.
-----------------