Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 17 Jun 2020, at 13:27, Dave Crocker wrote: On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. The two sentences seem to be in conflict. If there is a degree of practice that creates a different semantic for the field, then its semantics have changed, at least for the portion of email traffic. You'll note the word "generally". Most of my email carries the same semantics it always has in From:. There is a small subset that doesn't. But (and not to get too philosophical here), even when the semantics aren't the same, it is often a surprise: I find that something didn't match my expectations, only to discover that the originator of the email didn't use the same semantics I was expecting as recipient. That doesn't necessarily constitute a change in semantics for the email, but a mismatch: The originator said "sunny" and I thought that meant "without clouds". Even if I figure out the mismatch, I might not agree to "the semantics changed"; I might prefer to go with, "The originator made a mistake." In the present case, some mailing lists are using the same old semantics and some are using a new set; that doesn't convince me that we have an interoperable semantics to which we have "changed". Here's a simple operational test: MUAs typically can aggregate messages 'from' the same author. After all, that's always been the primary role of From, to indicate who created the content. Such aggregation is usually found to be helpful. Historically -- for 40+ odd years -- this has worked for mail going through mailing lists. Now it usually doesn't. I'd appreciate an explanation of how that does not constitute a change in semantics. Of course, I'd be interested in the "usually" part. It's not true of my mailstore, but my mailstore is far from average. I do know that even on the local non-profit board to which I belong (and had no hand in setting up), the Outlook server uses the semantics to which I am accustomed, though maybe having a smaller list where most people using their gmail addresses makes it equally "not average". Have a folder with a variety of messages from correspondents, where some of a person's messages are sent directly to you and some of their messages are sent through mailing lists that adapt the From: field content in order to avoid DMARC rejection. The MUA will handle mail from the same person, but that went through these two different paths, as being from different sources. I'm sure that happens. DMARC relies on From: because it is the only field with an identifier that is always present. Sender is not reliably present, except virtually. The nature of what DMARC is actually doing looks more like relying on the operations-related Sender: field than the author-related From: field. DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine. Were the Sender: field always present, that would be the one that DMARC should have used. It could have chosen the more complicated, "Sender unless not present, in which case From". But yes, this bit I get. That said, there are people who have argued that From: was chosen because Sender: was not displayed. I think that's a silly argument, but it's one that people still believe. So, really, DMARC has altered the semantics of the From: field to be the Sender: field. Wait a minute: I think this point needs some clarification. We know that the pre-DMARC semantics of the From: field are "the entity that authored the message". Originators were expressing that meaning and recipients were interpreting that meaning. My understanding of the meaning that DMARC added was, "The author of this message, as expressed in the From: field, always has their messages properly signed by the domain in the From: address." You seem to be saying that, no, what DMARC did was changed the semantic to be, "The From: field now represents the transmitter of the message (as used to be expressed in the Sender: field when present), not the author, and that transmitter always has their messages properly signed by the domain in the From: address". Do I have that right? (And I presume that either way, these are de facto semantics, not intentional ones that are documented anywhere, right?) The nature of the hack that mailing lists do, when altering the From: field, makes this clear: They alter information about the operator handling the message, destroying the original information about content authorship. Mailing lists that make other choices (throwing away messages from DMARC reject senders, denying subscriptions from them, or simply ignoring them and ending up with bad consequences) have obviously not gone along with the
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/17/2020 9:56 AM, Pete Resnick wrote: No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. The two sentences seem to be in conflict. If there is a degree of practice that creates a different semantic for the field, then its semantics have changed, at least for the portion of email traffic. Here's a simple operational test: MUAs typically can aggregate messages 'from' the same author. After all, that's always been the primary role of From, to indicate who created the content. Such aggregation is usually found to be helpful. Historically -- for 40+ odd years -- this has worked for mail going through mailing lists. Now it usually doesn't. I'd appreciate an explanation of how that does not constitute a change in semantics. Have a folder with a variety of messages from correspondents, where some of a person's messages are sent directly to you and some of their messages are sent through mailing lists that adapt the From: field content in order to avoid DMARC rejection. The MUA will handle mail from the same person, but that went through these two different paths, as being from different sources. DMARC relies on From: because it is the only field with an identifier that is always present. Sender is not reliably present, except virtually. The nature of what DMARC is actually doing looks more like relying on the operations-related Sender: field than the author-related From: field. DMARC has nothing to do with display of author information to a recipient, and everything to do with differential handling by a receiving filtering engine. Were the Sender: field always present, that would be the one that DMARC should have used. So, really, DMARC has altered the semantics of the From: field to be the Sender: field. The nature of the hack that mailing lists do, when altering the From: field, makes this clear: They alter information about the operator handling the message, destroying the original information about content authorship. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
In article <0f22234a-5a43-4473-8e67-b76c01cda...@episteme.net> you write: >No, the semantics of From: have not changed generally. It's that some >mailing lists have to change the semantics of From: in the face of the >inability of DMARC to express the semantics that they want. ... I'm with Pete here. Please leave this bunch of worms in the can. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 17 Jun 2020, at 4:23, Alessandro Vesely wrote: 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 soon as you start down that path, you have eliminated one of the purported values of From: alignment: MUAs will start using those conventions (X-Original-From:, decoding encoded Froms) and display that information to the user instead of what's in the From: field, in which case you're going to need X-Original-From: alignment, and down the spiral we go. (For those who are amused by such things, do a web search for "X-X-Sender".) I am not convinced by many of the arguments for From: alignment, and think the problems lie with the lack of semantics able to be conveyed by a DMARC record in these cases, but I seem to be in the rough on these points. But there is no magic bullet in "suitable conventions". 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. No, the semantics of From: have not changed generally. It's that some mailing lists have to change the semantics of From: in the face of the inability of DMARC to express the semantics that they want. I can get together with a group of my friends and decide that the word "sunny" really means "cloudy", but unless the whole English-speaking world is on board with me, communication is bound to have problems. To say nothing of the Sender: field, which wasn't designed for that role anyway. Sender: has had pretty much the same definition back to RFC 733. It was perfectly designed for "the thing that sent the message, independent of the author." That's how email has evolved after introducing authentication. For most email, the meanings haven't changed at all. For a certain class of mail, authentication of a certain sort has forced arbitrary changes that have made the semantics ambiguous as compared to the past. I'd hope rfc5322bis will recognize those changes. I sure hope not. Meanwhile, if we gather consensus on how to do it better, it'd be fair to write it down, no? Assuming you can gather consensus. I'm not convinced you can. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC Policy Boundary Conditions - making DMARC protocol complete.
On 6/16/2020 2:19 PM, Brandon Long wrote: So you think we should include https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail in the actual spec? In essence, with IETF review to update, clarify, extract parts, simplify, I think there are elements that are candidates as a MUST addition to the spec. They would address the remaining states in the protocol's framework. With a quick review, my direct involvement experience with the WG ATPS vs TPA proposals, I would take exception to the statement "TPA is intended to replace RFC6541." While it may be the wiki author's opinion, it was not what I experienced in the WG. I found the TPA proposal to be complex and a hard to read draft. I believe it also included trust assessment concepts as well. ATPS was 16 pages. TPA is 40 pages. ATPS was a much simpler protocol to implement asking the basic question "Is this 3rd party (re)signer domain authorized?" ATPS was implemented in my product line, not TPA. I don't know where TPA was implemented. With the TPA proposal's author MIA today, how would it work? Someone else take it over? Nonetheless, it should be added to the list of solutions to review. Thanks -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
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? Best Ale -- [*] https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail [†] Hm... except for 1.9 TPA. It should be moved downward, methinks. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
