]ARGH! Accidentally hit send. I was going to continue with... It is unlikely that an organization would do so even if all it's users were subscribers because now any mail sent through the list is validated for the organization. We go round and round because of a mismatch in granularity. Ultimately, who gets to decide how an account may be used. It's clearly the organization that controls the domain the user account belongs to. So what is needed is a mechanism that enables a user at a domain (other than subscribing) to show, through the domain owner, that the domain authorizes the use of that account at a particular list. This is a different problem space than DMARC and I don't believe it should be conflated with DMARC. It would function at a more granular level and have a whole different set of issues and opportunities. I don't know if it would be appropriate for this group to take up or another group.
Michael Hammer On Thu, Jun 25, 2020 at 9:53 AM Dotzero <[email protected]> wrote: > > > On Wed, Jun 24, 2020 at 1:18 PM Dave Crocker <[email protected]> wrote: > >> On 6/24/2020 8:09 AM, Dotzero wrote: >> >> Sender: is completely irrelevant to the use of DMARC now. >> >> Actually, I'm claiming it isn't. >> >> Or rather, I'm claiming there is a failure to appreciate that it is >> really Sender information that is important, not author information. >> > > Sender sends on behalf of. It ultimately is still about the From (author). > By your logic, if I walk into your bank and can identify myself as myself I > should be able to withdraw money from your bank account even though I have > shown no relationship between myself and yourself. > >> The fact that DMARC only has to do with a domain name tells us that this >> is about an organizational actor and not a person. My claim is that it is >> sufficient to focus on the operations actor rather than the author actor. >> > Organizations get to decide how individual users may use accounts > belonging to a domain controlled by the organization. This is ultimately > why there is such a pernicious problem with MLMs. IF one user at an > organization subscribes to a list, why would an organization undertake the > risk of allowing that MLM to be listed in it's SPF record or to DKIM sign > with the organizations private key. At the other end of the spectrum, if > all or almost all of the organizations users were subscribers to that MLM, > the organization might consider it. > > >> Again, note that RFC 733 (on up through RFC 5322) permit Sender: and >> From: to be conflated. I'm suggesting making sure they are separated, and >> then adjusting the DMARC focus -- and especially discussion -- from author >> to operator. (Well, not so much adjusting the focus as correcting the error >> of thinking that it's the author that matters.) >> >> >> As you have mentioned many times in the past, the burden is on the person >> making the assertion. You have not provided a compelling case that Sender: >> would be a more useful value to validate on than From:. We have substantial >> enough experience on the value of the use of From: and the only experience >> with Sender: (SenderID) was in essence a failure. >> >> We know that the use of From: causes some serious problems. Using >> Sender: would eliminate them. >> >> I'm not clear why that seems an insufficient justification. (Unless >> there a demonstration that using Sender: rather than From: alters DMARC's >> observable -- rather than supposed -- efficacy.) >> >> >> >>> Again: end-user recipient decision-making is irrelevant to meaningful >>> email abuse handling. >>> >> >> While this may in fact be true now, it may be a function of the >> presentation of the information to the end user rather than the content of >> the information itself. >> >> I think I don't understand what that means. >> >> d/ >> >> -- >> >> Dave Crocker >> Brandenburg InternetWorkingbbiw.net >> >>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
