I don't think having this language is saying you can't do SPF. Rather this is about preventing new spoofing attacks on DMARC aligned identity. In particular where previously this attack was not possible on forwarders that honored the p=reject policy, now that they will downgrade to quarantine, it opens a new vector that should be reviewed to prevent this attack. I propose this because I've seen the forwarding attack with SPF on ups.com. The Liu et. al. paper notes that they were able to spoof the From header government e.g. state.gov, financial and legal companies with SPF. You noted that it's feasible with DKIM too. The RFC should ask forwarders to do this review when they p=reject downgrade otherwise it does add systemic risk to the DMARC protected From identity.
-Wei On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman <skl...@kitterman.com> wrote: > On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote: > > > On Aug 5, 2023, at 5:37 PM, Scott Kitterman <skl...@kitterman.com> > wrote: > > > > > > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote: > > >> It appears that Scott Kitterman <skl...@kitterman.com> said: > > >>>> When receivers apply the "MUST NOT reject" in Section 8.6 to accept > > >>>> unauthenticated messages as quarantined messages, receivers SHOULD > > >>>> carefully review how they forward mail traffic to prevent additional > > >>>> security risk. That is, this downgrade can enable spoofed messages > > >>>> that > > >>>> are SPF DMARC authenticated with a fraudulent From identity despite > > >>>> having > > >>>> an associated strong DMARC policy of "p=reject". ... > > >> > > >> We all realize that SPF has problems, but I really do not want to fill > > >> up the DMARC document with text that says "you can authenticate with > > >> SPF, hahaha no just kidding." > > >> > > >> The way to fix Microsoft's forwarding SPF problem is for Microsoft to > put > > >> the forwarding user's bounce address on the message, not for us to > tell > > >> the entire world to use kludgy workarounds. > > > > > > I agree. We need to be careful to solve protocol problems in the > protocol > > > and leave fixing implementation problems to implementers. We aren't > > > going to protocol our way out of bad implementation decisions. > > > > Taken within the good-intention, protocol-compliant implementations, > which > > one do we add as “Implementations Notes?” Which or rather What are > > “Current Practice”behavior can we note? > > I think best current practice goes in a different document. Maybe we do > that > after DMARCbis is buttoned up? > > Scott K > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
