Your issues speaks to the core requirements of a spam filtering system. There are five key identifiers in any email message:
Source IP
HELO name
Reverse DNS host name
SMTP "Mail From" address
Message "From" header address
You will have occasional to apply block or allow rules to any of these.
Effective spam detection should lead to identification of the attack source so that a block can be applied to the attackers identifiers. Lists of bad actors will easily grow into the 1000s -- too many to configure in SmarterMail's user interface. Declude's text filters also become unmanageable with thousands of entries, while creating performance problems because every file is parsed anew for every message.
The viable techniques are large lists are either a SQL datababase, or an RBL implemented in DNS. Even then, an RBL is perhaps best implemented as a DNS lookup that gets converted to a SQL database through integration with BIND9. SQL databases give you indexing for performance, enforcement of unique keys, and instant implementation of data changes.
SmarterMail provides the five key identifiers in the .HDR file that it passes to Declude (or anything else uisng the PROC folder). I created Declude custom scripts which parse the header file for those variables, which they use to make database calls to enforce my filtering rules. This design approach seemed so necessary and obvious that I have been surprised that it seems to be unique.
I also determined that whitelisting always requires authentication. Without authentication, a lucky impersonator that lands on a whitelisting rule would have an express trip to destroy my network. IP addresses are assumed true, be virtue of bidirectional communication. (If you have an external attacker using malicious NAT for redirection, email is the least of your problems.) Authentication rules exist for the other four identifiers: Forward-confirmed DNS for host names, SPF for the SMTP Mail From address, and DMARC for the message From address. But these involve voluntary participation, so you need a way to configure alternate authentication in local policy rules. The alternate authentication techniques are:
- When IP address is <value> and host name is <value>, host name is considered verified even without fcDNS.
- When host name is <valuie>, and is verified by fcDNS, and the MailFrom name is <value>, then the MailFrom domain is considered equivalent to SPF PASS.
- When MailFrom domain is <value>, and is verified by SPF PASS or local equivalent, and the From address is <value>, then the FROM address is considered equivalent to DMARC PASS.
To minimize the number of exceptions, it is very beneficial to apply the DMARC test to every message FROM address, whether the domain has a published DMARC policy or not.
These alternate authentication rules are three part (underlying address, verification state, and target address). These rules will also accumulate in large numbers, so they also work well as indexed database tables.
Storing message metadata in the database also provides an effective way to review message history to decide if current rules are working or a planned rule is feasible.
Collectively, these tools have allowed me to reach 100% authentication of the Mail From address and >99% authentication of From addresses. Exceptions go to Quarantine for review, followed by a block rule for unwanted senders or an alternate authentication rule for acceptable senders.
I have shopped for commercial products to do this and have come up empty after looking at a lot of products. I do use a (relatively inexpensive) commercial spam filtering appliance to perform content filtering on the traffic that gets allowed past Declude. That product also provides a good interface for message review, which I use to disposition quarantine, check for inappropriate blocks, and check for inappropriate allows.