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

2023-08-03 Thread John Levine
It appears that Dotzero said: >Nope. A real big NOPE! There is a reason that SUBMITTER/PRA and SENDER-ID >are deprecated. I agree. They're dead, even Microsoft abandoned them years ago. Even if they were useful, which they are not, there is no chance of getting people to use them again.

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

2023-08-03 Thread Dotzero
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

2023-08-03 Thread Murray S. Kucherawy
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

2023-08-03 Thread Barry Leiba
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

2023-08-03 Thread Barry Leiba
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

2023-08-03 Thread Steven M Jones
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

2023-08-03 Thread Hector Santos
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

2023-08-03 Thread Alessandro Vesely
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

2023-08-03 Thread Murray S. Kucherawy
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