John Levine writes: > It appears that Tero Kivinen <[email protected]> said: > >Todd Herr writes: > >> No consensus reached for proposed change. Closing. > > > >I do not think we can make standard track document which do not > >properly list mandatory to implement features, and give at least some > >recommendations to the optional features, and which hides the > >protocol feature requirements inside very hard to parse text (where > >different people have different understanding what the text is trying > >to say). > > I think you're in the rough here.
Yes, it seems this working group has very different way of doing things what we for example require in security area, thats why I wanted to point this out to the IESG, just in case they disagree with the WG. > >To make this really interoperable standard, we MUST have at least one > >MUST to implement authentication method, and we need to clearly > >express those requirements. > > That would be a seriously incompatible change to 7489, so definitely no. So you are saying we can't do changes from the informational DMARC when we are moving it to the standard track. Why are we then bothering about this work at all. Note, that both RFC 7489 and version 30 of the DMARCbis did say that: 5.7.2. Determine Handling Policy To arrive at a policy for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. (section number changes between RFC and different dmarcbis versions) and those actions included doing both DKIM signature verification checks (step 3), and SPF checks (step 4). This was changed in version 31, and I did not remember seeing any discussion about this, even when this is very big change. And as you now point out this is incompatible change to the DMARC RFC7489 so we should roll it back... -- [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
