The sad thing is that there is no need to do a bandage pull if evaluators can learn how to serve the interests of their users properly. I don't throw away any mail based on Sender Authentication failure alone. But I also don't tolerate the idea that I have to accept malicious impersonation in order to accept all of the mail that my users should receive.
In this group, I have been arguing a losing cause that DMARC authentication can wisely be applied whether a DMARC policy exists or not. After discarding blacklisted message sources, here are my results from applying DMARC-like rules to all of my mail:
61% are aligned with both SPF PASS and DKIM PASS
16% are aligned with SPF only
16% are aligned with DKIM only
----
93% aligned with DMARC-like logic
4% are authenticated using local policy that allows non-standard alignment or overrides a non-PASS SPF result.
----
97% of all FROM address are verified to my satisfaction
Clearly, I am within reach of 100% verification of the RFC5322.From domain.
I don't know that I receive any mailing list traffic, but this is how it would fit into my model:
- Failure to verify causes the message to be flagged for review.
- Review indicates that the message is from a mailing list
- Research determines that the MLM provides reliable Sender Authentication and best effort spam filtering, so I do not need to repeat sender authentication
- I create a local policy that accepts any From domain when the SMTP and Server information identify the mailing list.
- Mailing list messages are forwarded to content filtering for normal acceptance processing.
So my "stream info" proposal is trying to solve the "research" entry on the list above.
If the mailing list cannot be trusted to perform Sender Authentication, then I need to implement code which parses the entire set of Received headers, ARC headers, and possibly other headers. I am probably not willing put that processing burden on every message to solve a problem for a poorly-managed list I will be easier to refuse the accommodation and tell the user to join the list with a Google account.
So I think we need a document that tells evaluators how to "not be stupid". I may be the only one present who can write it, and I could do so if the scope is willing to move in that direction.
But as long as there are stupid evaluators, senders have to cope with the reality in front of them.
Doug Foster