Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD

In article <132dd4e4-616a-47f5-a4a3-681067c86...@amazon.com>, Flaim, Bobby wrote: >-=-=-=-=-=- >Amazon supports this draft and effort . > >This current DMARC extension (IETF DMARC PSD) >draft would make it >easier for our direct customers (r

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

> On July 17, 2019 8:14:54 PM UTC, "Kurt Andersen (b)" > wrote: > >Firstly, I'm a little concerned with the sentence which says 'Note that > >"np" will be ignored for DMARC records published on subdomains of > >Organizational Domains and PSDs due to the effect of the DMARC policy > >discovery mech

Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD

On Wed, Jul 17, 2019 at 7:51 PM Scott Kitterman wrote: > > > On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" 40amazon@dmarc.ietf.org> wrote: > >Amazon supports this draft and effort . > > > >This current DMARC extension (IETF DMARC PSD) > >draft

Re: [dmarc-ietf] Amazon Comments to DMARC Extension to PSD

On July 17, 2019 10:23:11 PM UTC, "Flaim, Bobby" wrote: >Amazon supports this draft and effort . > >This current DMARC extension (IETF DMARC PSD) >draft would >make it easier for our direct customers (registrants) to setup a common >DMARC

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On your first point, I'll go double check. I copied that text from the 'sp' definition. I'm not sure why 'np' would be different. On the second, I'm slightly reluctant to present redefine existing terms in an experimental document, but it is clearer and more explicit the way you suggest. I'm

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Wed, Jul 17, 2019 at 2:40 PM John Levine wrote: > In article zsdwzvr...@mail.gmail.com> you write: > >Firstly, I'm a little concerned with the sentence which says 'Note that > >"np" will be ignored for DMARC records published on subdomains of > >Organizational Domains and PSDs due to the effe

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

In article you write: >Firstly, I'm a little concerned with the sentence which says 'Note that >"np" will be ignored for DMARC records published on subdomains of >Organizational Domains and PSDs due to the effect of the DMARC policy >discovery mechanism described in DMARC [RFC7489] Section 6.6.3.

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

On Tue, Jul 16, 2019 at 10:07 PM Scott Kitterman wrote: > > Updated rfcdiff attached. The only change other than typos is to add > mention > of 'np' to Appendix A. > Having reviewed the thread and the diff insofar as it pertains to the "np" tag, I'm in favor of the "np defaults to sp" approach.

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Scott, good point about the interoperability issue for the ‘np’ tag. I hadn’t really thought about that. Since what we do here for PSD DMARC will hopefully be included in regular DMARC for the future as well, I agree that it makes that we should not have the default behavior be different than

Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

Thanks for the update Scott, and your wording on the 'np' tag in the Appendix works. I just want to call out your statement: I think changing existing defined behavior for non-participants in an experiment is not appropriate. It's even more unacceptable in a case like this where we absolutely do

[dmarc-ietf] dmarc Digest, Vol 76, Issue 19

Dear all, Congrats for all the great work done so far. Regarding the topics below, 1. What further context is needed in the introduction? 2. If explicit call outs to ICANN/limited operator capacity to implement are needed 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs

Re: [dmarc-ietf] Working Group Last Call: draft-ietf-dmarc-psd

On Thu, Jul 11, 2019 at 5:54 PM John Levine wrote: > In article <3a6e6f9ac98c4e60af1075760efde...@verisign.com> you write: > >> I don't plan any changes except for those in response to last call > comments. > >> Unless I get direction otherwise, I don't plan any updates until after > last call is