Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Fri, Aug 4, 2023 at 2:28 AM Alessandro Vesely wrote: > > 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. > Huh? I didn't say anything

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

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 wrote: >Overall, DMARCbis has a “SPF comes before DMARC” conflict where SPF can >“preempt” DMARC. > >The

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Thu 03/Aug/2023 21:15:57 + Murray S. Kucherawy wrote: On Thu, Aug 3, 2023 at 10:39 AM Hector Santos 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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Thu, Aug 3, 2023 at 1:39 PM Hector Santos wrote: > On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote: > > On Mon, Jul 31, 2023 at 9:47 AM Hector Santos > > > > wrote: > > > >- I mentioned using the deprecated SUBMITTER/PRA > > (RFC4405/RFC4407) > >

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Thu, Aug 3, 2023 at 10:39 AM Hector Santos 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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

I don't agree. An allow list bypasses something -- whatever processing the list allows something past -- but not everything. In this case, we might be talking about a list that means "If we are sufficiently certain that a message same from the entity on the list, we will not reject it even if

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

The IETF's policy is to consider replacing these obsolete terms; there is no mandate. That said, I will push us strongly to do so: there is no harm in using "block list" and "allow list" instead, and we should. Barry On Thu, Aug 3, 2023 at 1:53 PM Steven M Jones wrote: > > On 8/3/23 12:50 AM,

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On 8/3/23 12:50 AM, Alessandro Vesely wrote: There is a push to avoid names that might recall racial prejudice, so blacklists are sometimes called blocklists...  The mentioned Appendix D talks about "whitelists of generally recognized forwarding services".  I support sticking to classic

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote: On Mon, Jul 31, 2023 at 9:47 AM Hector Santos > wrote: - I mentioned using the deprecated SUBMITTER/PRA (RFC4405/RFC4407) protocols as an implementation detail to access the author's DMARC

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Thu 03/Aug/2023 01:45:44 + Douglas Foster wrote: A nit on whitelisting. I suggest that we use the term "Alternate Authentication" rather than "Whitelisting". In my experience, whitelisting often implies exemption from both authentication checks and content checks. IME, whitelist

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Mon, Jul 31, 2023 at 9:47 AM Hector Santos 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

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

A nit on whitelisting. I suggest that we use the term "Alternate Authentication" rather than "Whitelisting". In my experience, whitelisting often implies exemption from both authentication checks and content checks.When an administrator simultaneous disables both types of defenses, his

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

On Mon 31/Jul/2023 16:47:15 + Hector Santos wrote: - I highlighted that "SPF Comes First" before DMARC or DKIM is known. It is entirely possible that an SPF restrictive policy (-ALL, Hard Fail) can preempt the payload transfer, causing a rejection before the DATA is reached. DMARCbis does

[dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

Hector Santos writes: > o Concerning p=reject: > >- Our focus on p=reject should be expanded to include p=quarantine > as they're both challenging. We should perhaps categorize these under > 'Restrictive Policies'. I will repeat the point I made in the mic in IETF: I think DMARC should