Overall, DMARCbis has a “SPF comes before DMARC” conflict where SPF can “preempt” DMARC.
The implementation suggestion is leveraging an existing ESMTP extension capability to obtain the DMARC policy at SMTP for one reason - to help DMARC fit better with SMTP-level SPF processing. Otherwise DMARC has an implementation design presumption that SPF+DMARC will always be processed together and this is not always true. The SUBMITTER/PRA was a patented (donated to the IETF Trust) optimizer for the payload version of SPF called SenderID by passing the extracted PRA “Purported Responsible Address” with the reverse-path. I know this. Enable the ESMTP extension and your receiver will see many transactions come in submitter information. So it is still being used. Does have both data points (Reverse-Path, PRA) available at SMTP MAIL FROM state help? I was not thinking using it for SenderID (SPF is sufficient, long decided) but using it for DMARC purposes. Currently, my mailer has a SPF Reject Before Data out of the box logic. To support DMARC, do I delay SPF rejection? One way for me to support existing operations and DMARCbis would be to get the DMARC policy, if any, to see if there is an overriding “auth=dkim” tag or maybe a “p=none” thus overriding the SPF reject at SMTP and continue with the payload transfer overhead where DKIM can be evaluated. That is basically it. DMARC has an implicit design, "To be compliant with DMARC, Receivers SHOULD NOT reject with SPF before DMARC can be evaluated.” It is predictably ignored by many receivers, in particular by systems long existing with SPF and have not put all their marbles in an DMARC yet. Fortunately, DMARCbis already mentions the possibility for DMARC domains to be aware of - SPF can be processed first and preempt any DMARC processing. I believe it is sufficient and there is no real need to go further with a possible implementation note for adventurous explorers. Thanks — HLS > On Aug 4, 2023, at 5:27 AM, Alessandro Vesely <ves...@tana.it> wrote: > > On Thu 03/Aug/2023 21:15:57 +0000 Murray S. Kucherawy wrote: >> On Thu, Aug 3, 2023 at 10:39 AM Hector Santos <hsan...@isdg.net >> <mailto:hsan...@isdg.net>> 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. > > > I agree with Mike about SUBMITTER/PRA. However, while I disagree with Dave's > proposal to use Sender: instead of From:, some kind of advice could still be > derived therefrom. > > >>> 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 > > > That seems gratuitous (assuming Submitter=Sender:'s domain). If I publish > p=none but SPF -all it still means reject (up to whitelists) unless the > receiver follows DMARC advice of disregarding SPF policy, but then that's > based on From:, not Sender:. > > >>> - 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. > > > Evaluating Sender: doesn't help whitelisting rejection before DATA. > > The message I'm replying to has: > > Return-Path: <dmarc-boun...@ietf.org <mailto:dmarc-boun...@ietf.org>> > Sender: "dmarc" <dmarc-boun...@ietf.org <mailto:dmarc-boun...@ietf.org>> > > To find the added value of Sender:, we'd be looking for a class of > forwarders, not mailing lists, where these identifiers differ. > > > Best > Ale > -- > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org <mailto:dmarc@ietf.org> > https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
