On 6/15/20 2:33 AM, Alessandro Vesely wrote: > Let me quote a list of nineteen usable solutions: > > 1 Sending side workarounds > 1.1 Exclude domains that require alignment > 1.2 Turn off all message modifications > 1.3 Replace address with a generic one > 1.4 Add fixed string such as .invalid to addresses > 1.5 Rewrite addresses to forwarding addresses > 1.6 Message wrapping > 1.7 Mandatory digests > 1.8 Ignore DMARC bounces > 1.9 Third Party Authorization > 2 Recipient workarounds > 2.1 Forwarder whitelist > 3 Cooperative solutions > 3.1 Shared whitelist > 3.2 Per sender whitelist > 3.3 Original-Authentication-Results header > 3.4 Forwarding token > 4 Authorization approaches > 4.1 Authenticated Received Chain (ARC) > 4.2 Signing key delegation > 4.3 Relay through author domain server > 4.4 Relay one copy through author domain server > 4.5 Have author domains sign camera-ready posts > [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail] > > That page hasn't been updated since 2016. I don't think we can devise any > new solution now. There's been a natural selection. Solution 1.3 prevailed, > with a minority of lists opting for 1.2. Let's face facts.
Precisely. Let's work from a basis of reality. I'm representing an EDU here. Mailing lists are still heavily used in EDU for cross-institution and cross-sector collaboration. They aren't going to be replaced by web forums or Yammer (or whatever corporate enterprise aspire to do) because faculty are open and collaborative by their nature. We have over $1bn in research expenditures, most of which are funded by federal grants, and so we need to receive mail (sometimes indirectly) from federal agencies who are adhering to BOD 18-01. A growing number of universities are publishing DMARC policies, and an unknown but presumably growing number of universities and agencies are enforcing DMARC policies for other domains. It's becoming increasingly difficult to ignore DMARC. Given that Microsoft and Google have essentially soaked up the entire EDU email market (hey, the price is right), let's say for sake of argument[*] that most EDUs are faced with 2 choices for their MLM: Google Groups and Microsoft 365 Groups. Microsoft's solution: 1.2 (conditionally, based on some logic, it seems) Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject) We can delve into *why*, but the reality is that we have failed with using Microsoft 365 Groups with external collaborators from domains that have adopted DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily use Microsoft 365 Groups for internal collaboration. Given that choice in this context, I believe that Google Groups will be chosen as their MLM by anyone taking DMARC into consideration. I would not be surprised if Microsoft falls in line with solution 1.3. So, solution 1.3 has been naturally selected. Does it need to be standardized, or is a BCP good enough? I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and consistent way. Is that where ARC comes in? Thanks, Jesse [*] Glossing over the fact that a university is not a single entity. There are hundreds of entities within a university that all may individually choose their own solution. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
