On Sat 08/Apr/2023 16:27:35 +0200 Scott Kitterman wrote:
On Saturday, April 8, 2023 10:24:09 AM EDT John Levine wrote:
It appears that Scott Kitterman said:
I think you have gotten yourself side tracked.
The problem with DMARC and mailing lists is that receivers doing DMARC
checks can't (absent a list of mailing lists) reliably distinguish DMARC
fail due to normal mailing list processing and DMARC fail due to abusive
behavior.
Even a list of mailing lists won't do it. One of the reasons ARC is
useful is that it lets recipients look back through the list manager
and recognize mail that was abusive before it hit the mailing list.
OK. A list is necessary, but not sufficient. ARC still needs some external
mechanism to determine when to apply it. It can't be used to override DMARC
results for all mail flows, only the ones that you have sufficient trust in not
to lie in their ARC header fields (e.g. well behaved mailing list operators).
ARC or non ARC, it is enough to have From: rewriting be a subscription option.
When your MX is able to recognize the mailing list and override DMARC results,
you can switch the option off.
How a receiver becomes aware that some of its users are subscribed to which
lists is out of the scope of dmarcbis. I think we should state this
explicitly, so as to imply that mechanisms of that kind have to be adopted.
ARC is good as it testifies dmarc=pass on entry. Indeed, it'd be embarrassing
to find dmarc=fail in AAR, when it is too late to reject or quarantine. MLs
and forwarders should comply with DMARC policies even more than final
receivers. It has to be some kind of a special case for DMARC, because
spreading failures amplifies their effect. Most importantly, we cannot ask MLs
to comply with DMARC and at the same time forbid subscribers from publishing
strict policies.
Disrupting MLs we have already done. Now let's try and better them.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
