PRA was not donated to anyone. Licensing terms for it was what blew up MARID.
It's not helpful here, let's move on. Scott K On August 4, 2023 2:01:14 PM UTC, Hector Santos <hsantos=40isdg....@dmarc.ietf.org> wrote: >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
