On Apr 11, 2023, at 1:06 PM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
Yes, I am talking about inbound policies. Mailing list damage happens when inbound filters block a harmless message that the user wants. So the best fix is for the inbound filters to acknowledge that they live in an environment with imperfect information.
The Sender can only ensure that all of his mail is signed. He cannot ensure that no other legitimate source will impersonate on behalf of a single user, or that no legitimate intermediary will alter content during forwarding. The recipient evaluator has the job of delivering what its users need and blocking what can harm them or don't want. Senders cannot fix evaluators that do that poorly.
Google says they cannot do conditional processing of p=reject, but they don't block on DMARC fail at all. They make up for that limitation by having other spam filtering logic that is pretty impressive. My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked.
I don't have the same content filtering sophistication, so I have ramped up my sender filtering.
Doug Foster
> On Apr 11, 2023, at 4:29 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote:
>
>
> Neil, I am slowly embracing the position of the Mailing List advocates.
>
> If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject". Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures. Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process. This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options. I am content with language that documents this conundrum.
>
> The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions. Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement. Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous. It is my job to replace guesswork with certainty based on research. As indicated earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From. Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none
It’s perfectly acceptable to create bypasses and whatever else you want. The local is the sacrosanct domain of the admin. I don’t see how this relates the standard. It should be as robust as possible. I’m likely missing something.
I’ve dealt with convoluted mailing lists that couldn’t hold a candle to mailman. There’s always a solution. The reality of workarounds shouldn’t touch the standard. |