Whitelist is not the inverse of blacklist
Idea shared by Douglas Foster - 6/28/2020 at 7:18 PM
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.

Reply to Thread