A frustration with SM, as well as several purpose-built email filters, is the failure to provide adequate features for whitelisting.
If I want to block mail from example.com, blacklisting is easy: I only have to match on one unwanted attribute, such as the MailFrom sender domain, the HELO domain name, the ReverseDNS domain name, or the message From address domain.
But if I want to give preferred treatment (whitelist) to example.com, things are much trickier. First I detect that
example.com is an asserted identity. But before I can safely grant special treatment to the message, I need to verify that identity by some other means, to protect against whitelisting a spoofing attack. In the email world, there are only 2 things that we really trust: Source IP and DNS. Other trusts are derived from these two sources:
- We can trust Helo name or ReverseDNS name if they can be forward-confirmed to the Source IP.
- We can trust the Mail From address if it can be matched to the Source IP using SPF.
- We can trust the message From address if it can be verified using DMARC-equivalent logic (SPF with domain alignment or DKIM verified with domain alignment.) Note that I use DMARC-equivalent, because the From address can be validated using that approach whether or not the originator domain has published a DMARC policy.
- We could extend this concept. For instance, we could apply SPF logic to the LIST-ID address to see if the list address can be validated to the Source IP.
- We can also trust based on a local policy. For example, if I know a correspondent has an error in his SPF record, I may want to create a local policy to define a domain-sourceIP pair (or domain-helo domain pair) which is treated as equivalent to SPF PASS.
Additionally, I need granularity when granting "preferred treatment". For some sources, I may be willing to bypass all filtering rules, but for others, I just want to bypass one specific filter.
SmarterMail does not provide a way to test for an attribute value and a verification condition at the same time, because it does not provide for multi-attribute conditions, It also does not evaluate some of the trust options in the list above.
But every block rule will need an exception eventually. A tool which knows how to block on SPF and DMARC loses its value if it does not provide a safe and effective way to define exceptions to SPF and DMARC. Whitelisting always needs to be a multi-attribute condition.