On Thu, Aug 3, 2023 at 1:39 PM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> wrote:
> On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote: > > On Mon, Jul 31, 2023 at 9:47 AM Hector Santos > > <hsantos=40isdg....@dmarc.ietf.org > > <mailto:40isdg....@dmarc.ietf.org>> wrote: > > > > - I mentioned using the deprecated SUBMITTER/PRA > > (RFC4405/RFC4407) > > protocols as an implementation detail to access the author's DMARC > > policy at the SMTP "MAIL FROM" stage. Wei expressed interest in > > this > > idea. This could also enhance the "auth=" idea to help manage local > > policy SPF -ALL handling. Should SMTP immediately reject? The > > PRA at > > SMTP could aid this decision for SPF -ALL policies. Based on many > > years of implementation, it's evident that many mailers are either > > identical or are using the same software that supports > > SUBMITTER/PRA, > > possibly due to ongoing support for the deprecated SenderID > > (RFC4406) > > protocol. [...] > > > > > > Can you or Wei spell this out a little more? What could a list > > subscriber do with this algorithm that we don't have today? > > > > The issue we're facing in a DMARC world isn't determining who the > > original sender is, but rather that with broken signatures, we can't > > prove it to DMARC's satisfaction. I'm not clear on how your idea > > fixes that. > > > > The utilization of SUBMITTER/PRA protocols possibly can help manage > situations where SPF fails before any DKIM information is accessible. > This strategy provides SPF processors with preliminary DMARC policy > data, potentially mitigating the impact of SPF hard-fail situations. > The advantages of this approach are especially clear when SPF fails, > but DMARC can help to temper the initial rejection. > Nope. A real big NOPE! There is a reason that SUBMITTER/PRA and SENDER-ID are deprecated. > > Through the SUBMITTER/PRA, it's possible to ascertain the presence of > a DMARC p=none or an auth=dkim, giving operators the choice to delay > immediate rejection and verify DKIM instead. > This is absolutely false. There is no way to validate a relationship between the From email address which DMARC is based on and the SUBMITTER/PRA, which can be any arbitrary email address. Back in the day when Harry Katz and Craig Spiezle from Microsoft were pushing Sender-ID, I used to drive them a bit crazy by sending them emails with their email addresses in the From and my email address as the SUBMITTER/PRA. Guaranteed to get a neutral every time rather than a fail. Please stop pushing this. To the chairs, I ask that pushing a deprecated approach which has previously been shown to be hopelessly broken (even Microoft stopped pushing it) be ruled off topic and out of scope. > > In the context of a mailing list, using a SUBMITTER in the > distribution can prove useful. For instance, a list might not need to > rewrite if it identifies an auth=spf for the domain, allowing it to > function as a resigner although the original domain integrity was > broken. There might be a auth=arc which ARC is needed for pass > broken 1st party signature. > How does one differentiate between a random mail list and other possibly malicious intermediaries? Is there a list of "acceptable" mailing lists? If a list isn't implementing email authentication practices itself, how does one trust any given list to be acting "on behalf" of a sending domain that has published p=reject? Why is your proposal better than rewriting or lists deciding not to accept mail from domains publishing p=reject? > > I know this is out of scope, but legacy scenarios may included > checking for the 'atps=y' tag and check for an ATPS DNS authorization > record for the resigner domain. There still many domains who don't use > DMARC but instead still have ADSP dkim=all to expose a mail policy - > "Expect all my mail to be signed." > You acknowledge that your proposals are out of scope but insist on wasting the working group participants time by repeatedly bringing them up. I again call on the Chairs to shut down out of scope discussions. Michael Hammer > 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. > > -- > Hector Santos, > https://santronics.com > https://winserver.com > > > > _______________________________________________ > 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
