Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/7/2020 8:04 PM, Murray S. Kucherawy wrote:  If I wanted an organization policy that controlled when Friendly Name was displayed or DMARC status was displayed, I would have to find and distribute plug-ins to all of these products.   As best as I have been able to tell, no suc

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sun, Jun 7, 2020 at 6:58 AM Douglas E. Foster < fost...@bayviewphysicians.com> wrote: > 1) The original assertion, that DMARC creates a conflict with prior > specifications, appears to be undefended and incorrect. For From > Addressing, It merely establishes some boundaries that the sender an

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/7/2020 2:40 PM, John Levine wrote: I believe the real question is*whether* to show trust data to users and the consensus seems to be don't bother, it only confuses them. It's not that it 'seems to be'. It isn't nearly that soft. It is that there have been multiple efforts over the years

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sunday, June 7, 2020 5:53:08 PM EDT Dave Crocker wrote: > On 6/7/2020 10:53 AM, Stan Kalisch wrote: > > Assuming this can be practically done, I would rephrase this, > > "...[E]stablish how MUAs should display trust data to users." > > Since there has been a demonstrated lack of efficacy in thi

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sun, Jun 7, 2020, at 5:40 PM, John Levine wrote: > I believe the real question is *whether* to show trust data to users > and the consensus seems to be don't bother, it only confuses them. I mean, I can't dispute that that's a fair question. Confusion obviously works against the goals behind

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/7/2020 10:53 AM, Stan Kalisch wrote: Assuming this can be practically done, I would rephrase this, "...[E]stablish how MUAs should display trust data to users." Since there has been a demonstrated lack of efficacy in this sort of display, there needs to be an objective basis for knowing t

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

In article <71cddc80-008c-4f33-bdac-71ebc029b...@www.fastmail.com> you write: >I didn't know the history of the IETF's approach to UI, in particular, but I'm >aware of the research on the nastiness of >solving the UI problem. I mostly wanted to clarify that the problem is, >indeed, *how* to show

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/7/20 6:16 AM, Douglas E. Foster wrote: > 2) Some of the discussion appeared to resolve around the assertion > that DMARC can have no value.   Since that view is not universal, I > think the project can continue with those who do believe that it adds > value. > That's not how it works; this wor

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sun, Jun 7, 2020, at 3:52 PM, John Levine wrote: > In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write: > >-=-=-=-=-=- > > > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > >> 3) Some of the discussion has been about how to prevent soclal engineering > >> o

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

In article <46e045ae-9691-4f5b-86bf-142c06645...@www.fastmail.com> you write: >-=-=-=-=-=- > >On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: >> 3) Some of the discussion has been about how to prevent soclal engineering >> of the recipient user. This is an important >topic, but not direc

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sun, Jun 7, 2020, at 9:16 AM, Douglas E. Foster wrote: > 3) Some of the discussion has been about how to prevent soclal engineering of > the recipient user. This is an important topic, but not directly related to > the project. IETF would do well to establish some recommendations about how >

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

In article <14fe18acad53467a8027e680dfc10...@bayviewphysicians.com> you write: >-=-=-=-=-=- >1) The original assertion, that DMARC creates a conflict with prior >specifications, appears to be undefended and incorrect. It should not be controversial that DMARC can only describe a subset of valid I

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

standardization. From: Alessandro Vesely Sent: 6/7/20 6:19 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Sun 07/Jun/2020 00:03:28 +0200 Jim Fenton wrote: > On 6/6/20 2:42 PM, Scott Kitterman wrote: >> On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >>> On 6/6/2020 2:23 PM, Scott Kitterman wrote: If things like DMARC, SPF, and DKIM do nothing more than get abusers to use diffe

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/6/20 2:42 PM, Scott Kitterman wrote: > On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: >> On 6/6/2020 2:23 PM, Scott Kitterman wrote: >>> If things like DMARC, SPF, and DKIM do nothing more than get abusers to >>> use >>> different domains than they would otherwise, I think that's

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Saturday, June 6, 2020 5:26:08 PM EDT Dave Crocker wrote: > On 6/6/2020 2:23 PM, Scott Kitterman wrote: > > If things like DMARC, SPF, and DKIM do nothing more than get abusers to > > use > > different domains than they would otherwise, I think that's a win. > > The issue here is DMARC, not SPF

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Fri, Jun 5, 2020 at 5:26 PM Jim Fenton wrote: > On 6/4/20 10:39 PM, Dotzero wrote: > > > The goal of DMARC was (and is) to mitigate direct domain abuse. Nothing > more and nothing less. It helps receiving systems identify a (correctly) > participating domain's mail. That is why a DMARC policy

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/6/2020 2:23 PM, Scott Kitterman wrote: If things like DMARC, SPF, and DKIM do nothing more than get abusers to use different domains than they would otherwise, I think that's a win. The issue here is DMARC, not SPF or DKIM, since DMARC is the only one of the 3 that restricts the choice of

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Saturday, June 6, 2020 4:45:11 PM EDT John Levine wrote: > In article , > > Scott Kitterman wrote: > >I think the market has spoken on the utility of DMARC. > > There's no question that it was highly successful at Yahoo and AOL > after they let crooks steal their address books at reducing th

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

In article , Scott Kitterman wrote: >I think the market has spoken on the utility of DMARC. There's no question that it was highly successful at Yahoo and AOL after they let crooks steal their address books at reducing the amount of spam their users received that forged addresses in those stolen

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On June 6, 2020 7:25:56 PM UTC, Jim Fenton wrote: >On 6/5/20 3:37 PM, Scott Kitterman wrote: >> On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: >>> >>> So maybe the core question here is, does the identity in the domain >name >>> matter or not? It does to me personally because I look a

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/5/20 3:37 PM, Scott Kitterman wrote: > On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: >> >> So maybe the core question here is, does the identity in the domain name >> matter or not? It does to me personally because I look at it (whenever I >> can -- my iPhone doesn't make it easy to

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Friday, June 5, 2020 5:26:19 PM EDT Jim Fenton wrote: > On 6/4/20 10:39 PM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. > > Nothing more and nothing less. It helps receiving systems identify a > > (correctly) participating domain's mail. That is why a DMARC

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/4/20 10:39 PM, Dotzero wrote: > > The goal of DMARC was (and is) to mitigate direct domain abuse. > Nothing more and nothing less. It helps receiving systems identify a > (correctly) participating domain's mail. That is why a DMARC policy is > often described as a sending domain's request and

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On Fri 05/Jun/2020 13:45:18 +0200 Hector Santos wrote: > On 6/5/2020 6:34 AM, Alessandro Vesely wrote: >> > >> For completeness, I'd also mention conditional signatures, as a fifth point. >> They were specified, implemented and then abandoned in lieu of ARC. > > h, interesting. Where was the

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/5/2020 1:39 AM, Dotzero wrote: The goal of DMARC was (and is) to mitigate direct domain abuse. +1, it was the goal of: [1] The original proof of concept with DomainKeys' built-in o= policy tag for 1st party support, and [2] The original DKIM draft augmented with the original SSP dra

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/5/2020 6:34 AM, Alessandro Vesely wrote: 4) Require all recipient systems to make special policy accommodations to grant trust to messages from List B, simply because it comes from List B. This is feasible, but specific to each participants incoming email filter. This is a hindrance t

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/4/2020 6:31 AM, Douglas E. Foster wrote: MAILING LISTS. The mailing list problem can be stated as follows: * Domain B wants to operate a mailing list. * The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C. * List owner B

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On Thu 04/Jun/2020 12:31:51 +0200 Douglas E. Foster wrote: > MAILING LISTS. > > The mailing list problem can be stated as follows: > > * Domain B wants to operate a mailing list. > * The list owner will accept messages from domain A, alter them, then > re-transmit the altered message to m

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Fri, Jun 5, 2020 at 12:40 AM Jim Fenton wrote: > On 6/2/20 10:35 AM, Dotzero wrote: > > > As part of the original DMARC team, the goal was to make clear whether the > email was authorized by the domain being used, hence the reliance on SPF > and DKIM. These are clearly under the domain owner/a

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/20 10:35 AM, Dotzero wrote: > > As part of the original DMARC team, the goal was to make clear whether > the email was authorized by the domain being used, hence the reliance > on SPF and DKIM. These are clearly under the domain > owner/administrator's control to the extent they choose to ex

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

In article <652580c1-5f8b-4d11-af25-d968b277c...@www.fastmail.com>, Stan Kalisch wrote: >> That depends on who creates the Author: field. I'd imagine it can be created >> on rewriting From:. If it exists already at that time, one can still check >> (by >> ARC?) if it was signed, and, in case,

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Wed, Jun 3, 2020, at 2:30 PM, Alessandro Vesely wrote: > On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: > >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: > >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: > MUAs should be d

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

MAILING LISTS. The mailing list problem can be stated as follows: Domain B wants to operate a mailing list.The list owner will accept messages from domain A, alter them, then re-transmit the altered message to member C.List owner B wants the mail filter for member C to guarantee that his list m

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

On 6/2/2020 8:45 PM, Douglas E. Foster wrote: Someone said that the Sender Address is all we can trust. Nonsense. +1 As to identifiers: The RFC 5321 MAILFROM sender is intended, at least in my understanding, to represent the login account used to create the message, while the RFC 5322 From H

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Wed 03/Jun/2020 19:27:52 +0200 Dave Crocker wrote: > On 6/3/2020 10:20 AM, Alessandro Vesely wrote: >> On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: >>> On 6/3/2020 9:38 AM, Alessandro Vesely wrote: MUAs should be discouraged from displaying or using Author:, unless (verifiably

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/3/2020 10:20 AM, Alessandro Vesely wrote: On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: On 6/3/2020 9:38 AM, Alessandro Vesely wrote: MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. Wh

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Wed 03/Jun/2020 18:43:16 +0200 Dave Crocker wrote: > On 6/3/2020 9:38 AM, Alessandro Vesely wrote: >> MUAs should be discouraged from displaying or using Author:, unless >> (verifiably) signed by a trusted domain or otherwise configured by the user. > > Why? That avoids the dreaded back-to-sq

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/3/2020 9:38 AM, Alessandro Vesely wrote: MUAs should be discouraged from displaying or using Author:, unless (verifiably) signed by a trusted domain or otherwise configured by the user. Why? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue 02/Jun/2020 19:00:55 +0200 Dave Crocker wrote: > On 6/2/2020 9:44 AM, Jesse Thompson wrote: >> I'm relaying these DMARC questions/concerns on behalf of an email admin at >> another university.  [...] >> >> " >> I don't see on the list of issues the most fundamental problem of DMARC, >> namel

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 5:45 PM, Seth Blank wrote: There's a lot of clear and generally consistent data that shows From: header field spoofing leads to outsized impact on end users. Odd that I've never seen it.  Odd that it didn't surface during the literature search that was done when BIMI was started.

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields D

I don't understand why this topic is debatable. We are faced with a constant stream of mail which we do not want. We need to block the nuisance stuff as well as the dangerous stuff, so that the important stuff gets processed in a timely manner, and so that our labor efforts can be spent on thin

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

Thanks for bearing with me, Dave. On Tue, Jun 2, 2020 at 5:26 PM Dave Crocker wrote: > When this match fails, a message can be rejected before it's ever in front > of a user and capable of causing confusion or fraud. > > Exactly. What matters is that unalignment is presumed to demonstrate bad >

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 5:13 PM, Seth Blank wrote: On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker > wrote: On 6/2/2020 3:53 PM, Seth Blank wrote: > The point I was trying to make is that consumers are susceptible to > fraud, Of course they are.  Unfortunately, that p

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue, Jun 2, 2020 at 4:02 PM Dave Crocker wrote: > On 6/2/2020 3:53 PM, Seth Blank wrote: > > The point I was trying to make is that consumers are susceptible to > > fraud, > > Of course they are. Unfortunately, that point is irrelevant, because it > isn't the question at hand. > Dave, this i

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 3:53 PM, Seth Blank wrote: The point I was trying to make is that consumers are susceptible to fraud, Of course they are.  Unfortunately, that point is irrelevant, because it isn't the question at hand. and the system needs to stop these messages before they ever get in front o

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue, Jun 2, 2020 at 3:42 PM Dotzero wrote: > Actually Seth, you are flat out wrong. I was there and part of it. It was > not about signaling. It was implemented at the MTA level and was about > preventing the "badness" from reaching the end user rather than signaling > to the end user. > Mic

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue, Jun 2, 2020 at 5:31 PM Seth Blank wrote: > As an individual: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > >> However there appears to be no actual evidence that lying in the From >> field affects end user behaviors, and certainly none that lying in the From >> field about the

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 2:42 PM, Seth Blank wrote: Also, from literally today: https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more Oh my. Is it really that difficult to understand the difference between choosing to take an action, versus being affected by your taking that a

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

I'm sorry to pile on but could not restrain myself: https://www.bmj.com/content/327/7429/1459?ijkey=c3677213eca83ff6599127794fc58c4e0f6de55a&keytype2=tf_ipsecsha I get Dave's point, but at the same time, it is well known that copy tweaks can have significant effects on conversion rates. Whether th

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

Wow. I'll ask folk to reread my text, here, carefully, since it specified something quite narrow and concrete, but is somehow being taken to have meant something broad and general: On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker > wrote: However there appears to be no act

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

Also, from literally today: https://www.justice.gov/usao-sdtx/pr/man-admits-spoof-email-fraud-scheme-and-more On Tue, Jun 2, 2020 at 2:30 PM Seth Blank wrote: > As an individual: > > On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > >> However there appears to be no actual evidence that lyin

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

As an individual: On Tue, Jun 2, 2020 at 1:46 PM Dave Crocker wrote: > However there appears to be no actual evidence that lying in the From > field affects end user behaviors, and certainly none that lying in the From > field about the domain name does. > There are decades of data that prove j

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 1:36 PM, Murray S. Kucherawy wrote: On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker > wrote: Your comment implies that what is displayed to the user is important in anti-abuse efforts, but there is no data to support that view, and some sig

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue, Jun 2, 2020 at 11:01 AM Dave Crocker wrote: > Your comment implies that what is displayed to the user is important in > anti-abuse efforts, but there is no data to support that view, and some > significant data to support the view that that's wrong. (cf, the > extensive literature review

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 12:32 PM, Pete Resnick wrote: On 2 Jun 2020, at 13:29, Dave Crocker wrote: On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but t

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 2 Jun 2020, at 13:29, Dave Crocker wrote: On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: fiel

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 11:12 AM, Pete Resnick wrote: On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 2 Jun 2020, at 13:01, Dave Crocker wrote: There's no reason that DMARC couldn't have included the sender or tried to have some kind of PRA like spf v2... but that's not the goal. But the Sender: field is not reliably present and, of course, DMARC needs an identifier that is reliably pres

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 10:11 AM, Brandon Long wrote: And if the mail client displays the Author, then we're kind of back to square one with displaying unvalidated data to the user. No we aren't. Your comment implies that what is displayed to the user is important in anti-abuse efforts, but there is no

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On Tue, Jun 2, 2020 at 12:44 PM Jesse Thompson wrote: > I'm relaying these DMARC questions/concerns on behalf of an email admin at > another university. I quickly searched this list's archives for the Sender > header vs DMARC alignment issue and don't see much aside from a > conversation in May

Re: [dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

On 6/2/2020 9:44 AM, Jesse Thompson wrote: I'm relaying these DMARC questions/concerns on behalf of an email admin at another university.  I quickly searched this list's archives for the Sender header vs DMARC alignment issue and don't see much aside from a conversation in May 2015.  Is it wor

[dmarc-ietf] DMARC alignment conflicts with RFC 5322 on the use of the From and Sender header fields

I'm relaying these DMARC questions/concerns on behalf of an email admin at another university.  I quickly searched this list's archives for the Sender header vs DMARC alignment issue and don't see much aside from a conversation in May 2015.  Is it worth further discussion and/or an issue in Trac