SmarterMail now has multiple features that depend on authentication:
- Inbound filtering: Should unauthenticated messages be blocked?
- Images: Does verified authentication permit the image to be tagged as BIMI verified?
- Trusted sender: Should the message be exempted from spam checks?
- Verified sender: Does authentication allow the “From” address to be tagged as verified?
All of these features have been tied to DMARC, because DMARC is a published method for verifying the “From” address. But DMARC is defined to meet the needs of domain owners, not evaluators. It only produces official results if the domain owner has published a policy, and it only produces an actionable result if the domain owner has published a disposition policy of quarantine or reject.
But DMARC is actually several nearly-independent functions:
- An authentication mechanism, using alignment between the “From” address and a verified SMTP Mail From address or a verified DKIM domain, using the PSL to define the default relaxed alignment boundary.
- A DNS policy entry which can be used to change the default relaxed alignment to strict (exact match).
- A DNS policy which provides a disposition recommendation for messages that fail authentication.
- A DNS policy entry which provides a feedback address, so that the domain owner can perfect his outbound message configuration.
The most important point for evaluators is that a PASS result can be obtained by applying the DMARC authentication mechanism to any message, using the default authentication mechanism when a DMARC policy is not present. DMARC can and should be extended to meet the needs of evaluators:
- “Trusted sender” whitelisting and “Verified sender” tagging can and should be based on the DMARC algorithm applied globally, not limited to domains that publish a DMARC policy.
- BIMI is officially still an RFC draft, current text available here:
https://www.ietf.org/archive/id/draft-brand-indicators-for-message-identification-04.html
It is specified to require both a DMARC policy and a DMARC PASS result; I have no problem with that restriction in this context.
- For Inbound filtering, SmarterMail forces automatic application of DMARC quarantine and reject results. This is a problem in both directions: For FAIL with Policy=none, the message should be given an increased risk weighting. For FAIL with Policy=Reject or Non, the message should be given a higher negative weight, but the actual disposition should be a site decision. RFC 7960 discusses some of the situations where DMARC produces the wrong results:
https://www.rfc-editor.org/rfc/rfc7960.html
Some reasons, not all of which are in the RFC: A message is processed by a mailing list which tags the message subject or body with list-related identification. A sender does not sign his message, relying only on SPF, but then the message is forwarded and SPF authentication is lost. A sender uses a third party service like Constant Contact but does not provide a DKIM scope and private key.
Because I am unwilling to apply SmarterMail’s default rules for inbound filtering, I am unable to optimally use SmarterMail’s features for BIMI, Trusted Sender, or Verified Sender. Because SmarterMail does not extend DMARC authentication to messages without a domain policy, the Trusted Sender and Verified Senders are less accurate and less usable, and therefore less trustworthy.
What we need:
- DMARC PASS is a PASS, whether a DMARC policy exists or not.
- DMARC FAIL is given a weight or an automatic action based on the system administrator’s preference, not the developer’s preference.