My experience is that any authentication is better than no authentication, so I am happy to use both SPF and DKIM as evidence of authentication. Both SPF and DKIM are subject to the possibility of false Pass based on credential upgrade, so their is no reason to prefer one to the exclusion of the other.,
SPF, DKIM, and DMARC are relatively easy to implement because they only examine a few values from the final message state. An evaluator who wants to detect credential upgrade will have to develop his own custom logic, as that effort is outside the scope of this effort. Outlook.com is the most common source of false Pass based on credential upgrade. Fortunately, it is also careful to use ARC to tell us when it has accepted and signed an unauthenticated message. After giving Outlook.com the special handling that it needs, I don't see much evidence of other credential upgrade threats in my incoming mail stream. Doug Foster On Mon, Dec 23, 2024 at 4:40 AM Tero Kivinen <[email protected]> wrote: > 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] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
