> -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Yoav Nir > Sent: Thursday, April 17, 2014 9:27 AM > To: mrex@xxxxxxx > Cc: ietf@xxxxxxxx > Subject: Re: (DMARC) Why mailing lists are only sort of special > > > On Apr 17, 2014, at 4:11 PM, Martin Rex <mrex@xxxxxxx> wrote: > > > Yoav Nir wrote: > >> > >> On Apr 17, 2014, at 9:35 AM, Dave Cridland <dave@xxxxxxxxxxxx> wrote: > >>> > >>> Right now, my MUA treats this as a message "From John R Levine > >>> <johnl@xxxxxxxxx>". This means that any policy on the message > >>> origination comes from looking solely at the taugh.com domain. We'll > >>> pretend it has a DMARC policy. Herein lies the Yahoo/DMARC issue, > >>> because unless your policy essentially stipulates that the IETF is > >>> allowed to spoof you, we're stuck. > >> > >> Then perhaps this is what needs to change. John R Levine did not send > >> you a message. He sent a message to the list. It is the list software > >> that sent you a message. So perhaps the From field should have been > >> ?From: IETF Mailing list on behalf of John R Levine <ietf@xxxxxxxx>?. > > > > But that is EXACTLY what the IETF mailing list exploder *IS* doing > > exactly as it has been specified for ages: > > > > https://tools.ietf.org/html/rfc822#section-4.4.2 > > https://tools.ietf.org/html/rfc822#appendix-A.2 > > > > https://tools.ietf.org/html/rfc5322#section-3.6.2 > > > > The "From:" field specifies the author(s) of the message, > > that is, the mailbox(es) of the person(s) or system(s) responsible > > for the writing of the message. The "Sender:" field specifies the > > mailbox of the agent responsible for the actual transmission of the > > message. > > > > From: Yoav Nir <ynir.ietf@xxxxxxxxx> > > Subject: Re: (DMARC) Why mailing lists are only sort of special > > Errors-To: ietf-bounces@xxxxxxxx > > Sender: ietf <ietf-bounces@xxxxxxxx> > > Date: Thu, 17 Apr 2014 13:50:30 +0300 > > Message-ID: <B3467912-BDCA-4AE8-9939-60013DA99267@xxxxxxxxx> > > To: Dave Cridland <dave@xxxxxxxxxxxx> > > CC: "ietf@xxxxxxxx" <ietf@xxxxxxxx> > > > > > > Something as old as Outlook 2003 will properly display a message that > > is received with a "Sender:" as "<Sender> on behalf of <From>" > > A client as new as Mail.app on Mac OS X 10.9 does not. > > Obviously the Sender: field is not where the DMARC implementations use > for checking policy. > Yoav, this is by design. There is no reliable way to determine the relationship between the Sender:field and the From: field from an authentication and authorization perspective at the domain level unless both are within the same domain space. Other than "I say so", how do we know that the Sender IS truly acting on behalf of the author in the From field where they are not both in the same domain space? This is the crux of the debate that has been going on for quite a few years. As a receiver, on what basis can I trust the sender is authorized in this circumstance? John says, "trust the mail (is on behalf of the author because you trust me". This actually has worked in the real world for some time but has been under increasing pressure due to abuse. While mailing lists have not been a significant vector in the past (John says never, I say I have seen abusive mail passed through lists so never is not true), that is not to say they will not be a significant vector. Some people are unhappy that DMARC ties identity to the From:field. Identity could just as easily have been tied to the Mail From:field but there still would have been a need for alignment ( going the other way) and ultimately there still would have been an issue with the Sender:field if the goal is to provide a model for authentication/authorization that does not have significant defects allowing abuse (and again we are only talking about the problem space of direct domain abuse, not phishing or spam in general). The only reason for alignment is because of the use of both IP based (transport layer) and message based (requiring examination of the message body) authentication. The problem with an approach of trying to identify trust relationships between domains (let alone authors and domains acting on behalf of individual authors at other domains) is that it is not a linear relationship. That is, the complexity of potential trust relationships does not increase in a linear fashion as we add more users and domains to the equation. There are other/easier ways of approaching the stated goal of authentication/authorization. In going back and re reading RFC 822 (1982), RFC 2822 (2001) and RFC 5322 (2008), I notice a small but important change between RFC 822 and RFC 2822. RFC 822 actually specified "This field contains the authenticated identity..." for both the From:field and Sender:field among others. I followed the discussion for RFC2822 but was not an active participant. I don't remember significant discussion on this change but there may have been some. If this requirement had been maintained AND had been implemented, it is quite possible we would be having a different discussion today. In the examples given in RFC822 for use of Sender:Field, where a domain name is used, all of the Sender:field email address Domains (someone please validate this as I went through the "A." examples once and somewhat quickly) were the same as the From:field email address domains although there were examples where the Sender:Field display name domain was different. On a side note, for the next update it might be appropriate to drop the word "secretary" and substitute "assistant" in the example given - a nit but appropriate nonetheless. So it's clear that contrary to some assertions that we have today's issues with email because authentication/security was not thought of, there was in fact some consideration given to authentication/security in the original specification. Just a few thoughts. Mike