On Sun 14/Jun/2020 19:18:43 +0200 Scott Kitterman wrote:
On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote:
Le 13/06/2020 à 17:19, Douglas E. Foster a écrit :
About this comment
If you teach users that "Joe User by Random Intermediary" is the same
as "Joe User", this expectation is doomed.>
Based on the response to my previous post, "Trained User" is not a
meaningful concept, for purposes of this discussion [...]
That's not my point. My point is: this working group needs to make a
determination whether From addresses being displayed to the users
matters to DMARC or not, and then follow up consistently.
If it is, then don't break From addresses with munging.
If it is not, then use Sender field as a fallback for alignment, and
don't break From either.
I don't think that's the question at all.
+1, we're not going to reinvent DMARC, just elucidate it.
Whether user's knowledge of the from address has any bearing on anti-abuse
methods or not, it has plenty of value for other purposes. DMARC is not all
of email.
From rewriting is a gross hack that exists only due to dire necessity. If
this working group can't move the space towards a more usable solution, I'm
not at all sure DMARCbis is worth the trouble.
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.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
