On 6/17/20 4:23 AM, Alessandro Vesely wrote: > On Mon 15/Jun/2020 20:27:08 +0200 Scott Kitterman wrote: >> On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: >> >>> Even if you ignore my line of reasoning, I think that Ale made in the OP a >>> compelling case that the practice of From rewriting is here to stay. >> >> As a practical matter, that's certainly true for the short to medium term, >> but >> it doesn't follow that the IETF should standardize the practice. > > > There are a few shortcomings of From: rewriting, which could be mitigated > adopting suitable conventions. For example, MUAs' replying to author, or > storing rewritten addresses in address books. > > As evidenced in the page cited[*], methods 1.* are characterized by being MLM > side workarounds[†]. That is, they can be applied unilaterally, without > collaboration nor mutual support. A state of affairs dictated by the lack of > standardization. > > Now, if we make a semantic effort, we must recognize that the address of > From: as a matter of fact refers to the "managing editor" of the > corresponding mail flow, whereas the display name may indicate the actual > author. To say nothing of the Sender: field, which wasn't designed for that > role anyway. That's how email has evolved after introducing authentication. > I'd hope rfc5322bis will recognize those changes. Meanwhile, if we gather > consensus on how to do it better, it'd be fair to write it down, no?
There at least needs to be a consensus and an official-looking place that we can point intermediaries when they're getting hit by the DMARC train; as policy publication and enforcement accelerates. A M3AAWG BCP, perhaps? Some MLM operators think that setting the Sender header is recommended/good enough. Some MUAs display the Sender instead of the From if it's set, which is why I think some people think it's equivalent to changing the From header. That wiki[*] doesn't even mention the Sender header, so it doesn't really serve as a mechanism to dissuade the notion. If there is no consensus on a single recommendation, then perhaps there needs to be more than one recommendation articulated in a preferential, guided, fashion: 1) If 100% of receivers will trust ARC from the intermediary - do X 2) If DKIM signing and intermediary survival is 100% - do Y 3) Else, do Z etc... Along with recommendations for each party regarding what they should do in each situation. Those of us who are opinionated about this topic can focus our arguments on the order/criteria/nuances of the recommendations rather than trying to agree on a single one. The main benefit to making the recommendation(s) more standard is that it will serve to help intermediaries configure things in a "DMARC compatible" fashion and justify any change as necessary to skeptical stakeholders. It will also serve as a way for IT staff to evaluate alternative software/services if they are considering upgrades vs. replacement. > [†] Hm... except for 1.9 TPA. It should be moved downward, methinks. Seems in the Cooperative category. Maybe there needs to be a distinction between Sending (user/MSA vs domain owner?) vs Intermediary solutions? Or a matrix to capture different qualities. I don't know, there's a lot about that doc that makes it hard for an average person even know where to start tackling the problem. Most people don't have years of experience in the email domain to understand all of the nuances. Jesse [*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
