SpamFoo, DMARC flexibility, and Authentication-Results

Idea shared by Douglas Foster - Today at 7:47 AM

Proposed

I asked how Spamfoo determines authentication status. I was told that it looks for an Authentication-Results header provided by SmarterMail. This introduces several problems for me:

I do not let SmarterMail calculate a DMARC result because I do not want it to block on failure with p=reject. This means that Spamfoo will perceive many messages as less authentic than they really are, simply because the DMARC test has not been attempted. The forum discussion and supporting tickets on this topic remains unaddressed. Here is the primary forum post, started two years ago:
https://portal.smartertools.com/community/a96231/expand-dmarc-options-scoring.aspx
At one time, my inbound gateway created an Authentication-Results record for every message. Now it never creates one. No one seems to know why this changed or how SmarterMail currently decides when to insert one. There is certainly no switch that I can use to control the behavior, but maybe we need one. An open ticket on this issue is not going well. I am using Spamfoo on my incoming gateway, so the absence of an Authentication-Results header is another reason that Spamfoo will view my messages as less authentic than the actually are.

There are unresolved trust issues around Authentication-Results.

The purpose of the header is to permit a trusted upstream server to communicate authentication results to a trusting downstream server, so that the downstream server does not have to repeat the tests, especially since the downstream server may not be able to compute accurate results even if it tries.
A downstream server needs to know which headers it should trust, so that any others can be ignored. SmarterMail has never configured this mechanism, so it cannot use Authentication-Results created by an inbound gateway. Their implementation has never really been finished. The trusted results list may include data created internally by an upstream server or externally if created by a forwarder that is trusted to provide accurate information.
Since SmarterMail does not know which Authentication-Results headers to trust, we can also conclude that Spamfoo does not know which Authentication-Results headers to trust. The consequence of this design flaw will also make many messages appear less authentic than they actually are. On the other hand, if Spamfoo treats every Authentication-Results header as trustworthy, it may treat some messages as more authentic than they actually are.
By extension, both SmarterMail and Spamfoo need to know whether any ARC-Authentication-Results are worthy of being trusted.

Back to Community Threads

Reply to Thread

Enter the verification text