On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote: > In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro > Vesely <ves...@tana.it> writes > > >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: > >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely <ves...@tana.it> wrote: > >>>If we add the feature, we should in any case exemplify how to fix SPF, > >>>saying> > >that doing so is safer, at least until all DMARC software has acquired the > >new feature. As the addition would be understood as a response to the > >known vulnerability, it will likely be spread. > > > >> What do we know now that we didn't know the last time we decided not to > >> go > > > >DKIM only? I'd argue there's nothing and endless relitigation of issues > >like this is making it impossible to actually accomplish what we're > >chartered to accomplish. > > > >You're the only one strongly opposing the idea, AFAICS, and I still don't > >know why. > > The only reason that I think that SPF results are of any value at all > (and hence we should go with a "DKIM pass only" marker for those who > need it, rather than just wiping SPF from the document) is because some > people have argued that a SPF only approach is of value to them -- they > can do a sanity check on the sending IP, and they then use other methods > to decide whether they like the email. Their server their choice... > > ... Scott has been arguing (AIUI) that people who want a DKIM only > situation should add the "?" qualifier to relevant SPF mechanisms. This > will produce a "neutral" result and hence there will not be a SPF pass > for DMARC to consider. > > This is all very well, but I have been reading RFC7208 "Sender Policy > Framework (SPF) for Authorizing Use of Domains in Email, Version 1" > (which we should note is authored by S Kitterman) and in particular > looking at #8.2 which says: > > A "neutral" result MUST be treated exactly like the "none" result; > the distinction exists only for informational purposes. > > that is (and Scott can correct me if I misunderstand), that people using > SPF in an RFC compliant manner (which the libraries they use will > undoubtedly do) are effectively obliged to ignore any mechanism with a > "?" qualifier. BTW the same text appears in RFC4408 #2.5.2. so this has > always been the case. > > That is -- using "?" means that the SPF information will not only be > disregarded for DMARC purposes but also for SPF purposes as well. > > In my view that makes promoting the use of "?" a non-starter. So if we > want to allow the people who value SPF to continue to have records they > can use whilst addressing the reality that such records are often, > necessarily, far too wide to provide real authentication, we must have a > way in DMARC of saying "only consider DKIM".
It's not "ignore the mechanism", it's "stop processing and the result in Neutral". The idea behind this is that if you get a match from a mechanism with the '?' qualifier processing stops, so you never get to the end of the record. As a result messages from that particular source don't reach the final 'all' mechanism. It's not some kind of global thing, it's just for that source. This isn't a novel concept. I've used it in the SPF record for kitterman.com for as long as I can remember for two relays I might, in theory, use, but I have no idea how they handle cross-user forgery risks. What's your plan for when easily getting a DMARC pass due to bad SPF records doesn't work anymore, so the bad guys focus more on DKIM replay? DMARC without DKIM as a solution? Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
