On Thu, Aug 3, 2023 at 10:39 AM Hector Santos <[email protected]> wrote:
> [...] > > However, at present, the most plausible use-case appears to be the > addition of delayed SPF rejection scenarios through DMARC evaluation. > Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to > soften the impact of SPF -ALL policies. > > The approach might work as follows: > > - If SPF fails and the Submitter indicates p=reject, then reject > (comes with its acceptable problems) > > - If SPF fails, the Submitter specifies p=reject and auth=dkim, then > proceed to transfer the payload and evaluate DKIM > > - If SPF fails and the Submitter signifies p=none, then continue with > payload transfer > > - If SPF fails and the Submitter designates p=quarantine, then proceed > with payload transfer > > SUBMITTER may help align SPF with its original DMARC purpose—combining > SPF+DKIM results while keeping with some level of optimization. > Ah, interesting. I don't think this should go in the base document, since the research we did for RFC 6686 suggests that deployment of SUBMITTER, at least as of that document's publication, wasn't very broad. However, if the size of the problem is substantial, and this solution turns out to be potentially effective, this might be fodder for the applicability statement or usage guidelines document that this WG has discussed producing in the past as a possible enhancement. Collecting some data and doing some experimentation would be really helpful toward determining the right path here, if any. -MSK, just participating
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
