SpamFoo feature request: Authentication based on existing results
Idea shared by Douglas Foster - 8/5/2026 at 9:18 AM
Declined
SpamFoo appears to do something with SPF/DKIM/DMARC, although the details are unclear.   In many cases, SmarterMail or some other calling program will have already performed this analysis.  The /classify function should allow the calling program to supply already-known authentication results.   This serves two purposes:
- It avoids redundant processing.
- If the calling program has already adjusted authentication results based on local policy, passing those results to SpamFoo will permit it to correctly evaluate the message based on the calling program's data..
Derek Curtis Replied
Employee Post
SpamFoo, when running with SmarterMail, simply takes the headers of SmarterMail's checks and uses those versus running its own checks. So I'm not sure whatever you're seeing relates to SpamFoo particularly. Are you running another check that could possibly do its own checks? 
Derek Curtis
CCO
SmarterTools Inc.
Your approach solves the problem for the supported use case, so the denial is understood.

I use a mix of standard algorithms, algorithm enhancements, and local policy to ensure that every accepted message is authentic.   I am committed to blocking all malicious impersonation, and that only occurs if all accepted messages are authentically identified.   (Authentication failures go to quarantine.)  My policy seems to make me unique on the planet, but I cannot understand why.

From a theoretical viewpoint, accurate identity is essential to every aspect of email filtering, so it should not be optional.  Email filtering has three legs:  
  • identity verification to protect against malicious impersonation, 
  • identity reputation to protect against malicious actors (or identify essential senders), and 
  • content analysis to protect against malicious intent.    
Without accurate identity, it is impossible to apply accurate reputation.   A fraudulent author automatically renders content unacceptable.  Accurate identity is needed for author-specific content filtering.   

A possible fourth leg of filtering is flow path analysis, but it is difficult to know what analysis is useful and how to act on whatever is learned.   When the flow path is complicated, threats can be introduced by the originator or any of the intermediaries.   Authentication becomes more difficult because authentication credentials can be either gained or lost during forwarding.   In my configuration, I generally assess whether the indirect flow path is acceptable, then trust (hope) that I will be protected from malicious impersonation by the intermediary or by my content filtering.  For mailing lists, the most important defense is to determine whether the intended recipient really subscribed to the list.   Phony subscriptions indicate a malicious intermediary or malicious use of an intermediary.  GoogleGroups.Com and Groups.Outlook.Com are a regular source of fake mailing lists used as an open relay, so their lists are blocked by default and allowed by exception.

Reply to Thread

Enter the verification text