[dmarc-ietf] DMARC workaround test 1

I understand we now have the DMARC workaround test up in this list. That means that "from" addresses should get rewritten if they identify domains with DMARC p=reject. Let's check that out. This message is from my usual computer.org address, and shouldn't get rewritten. It should say sender:

Re: [dmarc-ietf] inheritance and public suffix list

In article you write: >> I think _dmarc as a TXT record is fairly well known. Is there anything >> that would specifically prohibit this? > >gTLDs are not permitted to place TXT records in their zones. That's mostly right. There is

Re: [dmarc-ietf] Issue #22 - perverse incentives to use p!=none & pct=0

On Tue, Apr 10, 2018 at 12:47 PM, Brandon Long wrote: > > On Fri, Apr 6, 2018 at 9:48 AM Kurt Andersen (b) wrote: > >> *I filed issue 22 after observing a discussion today on another list:* >> >> Pursuant to an email thread on the mailop list, we may want to

Re: [dmarc-ietf] inheritance and public suffix list

On Tue, 10 Apr 2018, Kurt Andersen (b) wrote: Registries make RSEP requests all the time. They're tedious and fairly expensive, but the process is straightforward. Is this something that could be within the remit of the dmarc-wg if we wanted to pave the way with ICANN across the board? I

Re: [dmarc-ietf] inheritance and public suffix list

On Tue, Apr 10, 2018 at 1:44 PM, John Levine wrote: > In article <91efb193-9a81-4626-92ca-bf116826f...@uniregistry.link> you > write: > > This is the relevant text from > >https://newgtlds.icann.org/sites/default/files/ > agreements/agreement-approved-31jul17-en.html > > But