----- Original Message ----- > From: "Murray S. Kucherawy" <[email protected]> > To: [email protected] > Sent: Thursday, January 22, 2015 10:27:40 AM > Subject: Re: [dmarc-ietf] questions on the spec, was ... and two more tiny > nits, while I'm at it
> On Wed, Jan 21, 2015 at 11:12 AM, Murray S. Kucherawy < [email protected] > > wrote: > > I am asking the IESG and the ISE what the process is for making such > > adjustments now. > > > Mainly my resistance to further change comes from the fact that we've done > > last calls of varying kinds on this document more times than I can count. > > It > > really is time to put the non-IETF version to bed and hand it off, even > > with > > its weaknesses, and let the standards process take it from there. There's a > > working group already chartered to do exactly that; in fact, that was one > > of > > the premises of creating that working group. > > I've consulted with the Area Director sponsoring the document's conflict > review, and the ISE. Both of them agree that we will only make changes > approved by the ISE and only during AUTH48 at this point, and those will be > limited to correcting serious problems that would prevent current DMARC > implementations from interacting properly. Anything else can be left to the > DMARC working group on its standards track deliverable. > An argument can be made that this proposed change qualifies under that > definition, so please review it and comment as to whether it satisfies the > defect identified, or whether the change is necessary at all. I will assume > "yes" unless I hear otherwise. Again, the diff is here: > http://www.blackops.org/~msk/dmarc/diff.html So after the whole discussion, I don't think in 4.1 we can say "in contradiction of SPF". DMARC is defining a "local policy" for SPF, which is valid. People implementting DMARC must ensure their SPF implementation follow also this local policy. I would cite Terry's email where his SPF follows what DMARC expects, and where Scott said it is a valid implementation of SPF, and Scott implementation of SPF, which is valid too. I would also cite Tim's conformance tests, that matches operational deployment. So to be pedantic, suggested text: [SPF], which authenticates the HELO identity and the MAIL FROM identity: the domain found in an [SMTP] MAIL command, or the domain found in the HELO/EHLO command if the MAIL command has a null path. Note that in the context of DMARC, this later identity is only used.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
