On July 21, 2019 6:01:05 PM UTC, Alessandro Vesely wrote:
>On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote:
>>>
Keep in mind that senders do send from what we call non-existent
>domains for
reasons that seem good and sufficient to them. Let's take that as
>a fact,
whethe
On Sun 21/Jul/2019 18:53:35 +0200 Scott Kitterman wrote:
>>
>>> Keep in mind that senders do send from what we call non-existent domains for
>>> reasons that seem good and sufficient to them. Let's take that as a fact,
>>> whether it makes sense to us or not.
>>
>>
>> Fair enough. Let me quote th
On July 21, 2019 4:40:49 PM UTC, Alessandro Vesely wrote:
>On Wed 17/Jul/2019 08:26:25 +0200 Scott Kitterman wrote:
>
>> Keep in mind that senders do send from what we call non-existent
>domains for
>> reasons that seem good and sufficient to them. Let's take that as a
>fact,
>> whether it mak
On Wed 17/Jul/2019 08:26:25 +0200 Scott Kitterman wrote:
> Keep in mind that senders do send from what we call non-existent domains for
> reasons that seem good and sufficient to them. Let's take that as a fact,
> whether it makes sense to us or not.
Fair enough. Let me quote the current spec:
19 04:15
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last
Call: draft-ietf-dmarc-psd
On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote:
> I've been following the discussion but haven't contributed anything
> until this point. Comme
In article
you write:
>Most MTAs will also follow CNAMEs. Should they be included (along with
>other things like DNAME records) within the scope of existence? I'm a
>little concerned that we are making a special definition of "non-existence"
>which differs from the standard DNS concepts of NODATA
On Wednesday, July 17, 2019 1:07:05 AM EDT Scott Kitterman wrote:
> On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote:
> > On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
> > > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
> > > > On Fri, Jul 12, 2019
On Friday, July 19, 2019 11:33:38 AM EDT Kurt Andersen (b) wrote:
> On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote:
> > On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman
> >
> > wrote:
> >> If we want to take another run at this and put it in more standard DNS
> >> terminology, then mayb
On Wednesday, July 17, 2019 10:01:01 AM EDT Chudow, Eric B CIV NSA DSAW (USA)
wrote:
...
> For the current wording, I think the “if not” is unclear in the “If absent,
> the policy specified by the "sp" (if present) and then the "p" tag, if not,
> MUST be applied for non-existent subdomains.” Does
An experimental draft isn't the best place for a deployment guide.
an operational document that discusses deployment among other things is a
different story
On Fri, Jul 19, 2019 at 11:13 PM Scott Kitterman
wrote:
> On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote:
>
> > > >
On Friday, July 19, 2019 8:04:20 AM EDT Dotzero wrote:
> I've been following the discussion but haven't contributed anything until
> this point. Comment below.
>
> On Fri, Jul 19, 2019 at 3:29 AM Ian Levy
> 40ncsc.gov...@dmarc.ietf.org> wrote:
> > > I think this is one of those "you must be this
On Friday, July 19, 2019 11:30:01 AM EDT Kurt Andersen (b) wrote:
> > > I'm also concerned
> > > that a wildcard null MX record at the org level would end up having all
> > > subdomains "exist", but the policy that should be applied would be the
> >
> > more
> >
> > > restrictive "np" policy
On Fri, Jul 19, 2019 at 8:30 AM Kurt Andersen (b) wrote:
> On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman
> wrote:
>
>>
>> If we want to take another run at this and put it in more standard DNS
>> terminology, then maybe:
>>
>> a domain for which there is an NXDOMAIN or NODATA response fo
On Thu, Jul 18, 2019 at 10:42 PM Scott Kitterman
wrote:
> On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> > On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman
> >
> > Most MTAs will also follow CNAMEs. Should they be included (along with
> > other things like DNAME records) wi
I've been following the discussion but haven't contributed anything until
this point. Comment below.
On Fri, Jul 19, 2019 at 3:29 AM Ian Levy wrote:
> > I think this is one of those "you must be this tall to ride on this ride"
> > situations. DNS comes equipped with multiple footguns and you ha
have to. If this
arrives outside your normal working hours, don’t feel compelled to respond
immediately!)
-Original Message-
From: dmarc On Behalf Of Scott Kitterman
Sent: 19 July 2019 06:41
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last
Cal
On Thursday, July 18, 2019 11:42:36 AM EDT Kurt Andersen (b) wrote:
> On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman
>
> wrote:
> > > 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
> > > >"n
On Wed, Jul 17, 2019 at 7:35 PM Scott Kitterman
wrote:
> > 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 Domai
> 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
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
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
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.
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.
nt)”.
Thanks,
-Eric
_
Eric Chudow
DoD Cybersecurity Mitigations
___
From: Tim Wicinski
Sent: Wednesday, July 17, 2019 8:29 AM
To: Scott Kitterman
Cc: IETF DMARC WG
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy wa
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
On July 17, 2019 5:54:41 AM UTC, Seth Blank wrote:
>On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman
>wrote:
>
>> Yes, the point of 'np' is to allow for a stricter sub-domain policy,
>but
>> that's to support early deployment of strict PSD level policies
>without
>> breaking org domains that a
On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman
wrote:
> Yes, the point of 'np' is to allow for a stricter sub-domain policy, but
> that's to support early deployment of strict PSD level policies without
> breaking org domains that are still deploying/have not deployed DMARC.
>
I absolutely agr
On Wednesday, July 17, 2019 1:18:50 AM EDT Seth Blank wrote:
> As an individual-
>
> On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman
>
> wrote:
> > Although a few people have suggested this, I think it would be a mistake
> > because it would cause a gratuitous incompatibility with RFC 7468.
>
As an individual-
On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman
wrote:
> Although a few people have suggested this, I think it would be a mistake
> because it would cause a gratuitous incompatibility with RFC 7468.
>
The people suggesting this are the people asking for np= in the first place
On Saturday, July 13, 2019 3:34:51 PM EDT Scott Kitterman wrote:
> On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
> > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
> > > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman
> > >
> > > wrote:
> > > > On Wednesday, Ju
On Tuesday, July 16, 2019 12:14:54 PM EDT Chudow, Eric B CIV NSA DSAW (USA)
wrote:
> I recently joined this working group from the United States Department of
> Defense (DoD), which runs the .mil TLD. We appreciate all the work that has
> been done so far on DMARC and are currently investing signi
>
> | -Original Message-
> | From: dmarc On Behalf Of Scott Kitterman
> | Sent: 13 July 2019 20:35
> | To: dmarc@ietf.org
> | Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group
> | Last Call: draft-ietf-dmarc-psd
> |
> | On Friday, July 1
I was slightly more verbose. I'll send the updated diff for 'np' once I get
through my email backlog.
Scott K
On Monday, July 15, 2019 8:30:35 AM EDT Tim Wicinski wrote:
> I totally agree with the logic behind the experiment.
>
> >From a document point of view, should we not document the 'np'
don’t feel compelled to respond
immediately!)
-Original Message-
From: dmarc On Behalf Of Alessandro Vesely
Sent: 16 July 2019 15:53
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last
Call: draft-ietf-dmarc-psd
On Mon 15/Jul/2019 09:08:04 +0200 Ian Le
.
Sincerely,
-Eric
Eric Chudow
DoD Cybersecurity Mitigations
________
From: Alessandro Vesely
Sent: Tue, 16 July 2019 14:53 UTC
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last
Call: draft-ietf-dmar
On Mon 15/Jul/2019 09:08:04 +0200 Ian Levy wrote:
> Sorry for not contributing more to this thread - please don't take it as any
> indication of lack of interest. For UK NCSC specifically, I think we'd prefer
> NXDOMAIN rather than NODATA, given it's more constrained and this is an
> experiment
org
| Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group
| Last Call: draft-ietf-dmarc-psd
|
| On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
| > On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
| > > On Fri, Jul 12
I totally agree with the logic behind the experiment.
>From a document point of view, should we not document the 'np' part of the
experiment?
"The experiment will also evaluate the effectiveness of the 'np' tag for
non-existent subdomains. "
Tim
On Fri, Jul 12, 2019 at 2:28 PM Scott Kitterman
c On Behalf Of Scott Kitterman
Sent: 13 July 2019 07:04
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last
Call: draft-ietf-dmarc-psd
On Saturday, July 13, 2019 12:34:09 AM EDT John Levine wrote:
> In article <2902055.CzhLQO0xIX@l5580> you write
On Friday, July 12, 2019 2:28:39 PM EDT Scott Kitterman wrote:
> On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
> > On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman
> >
> > wrote:
> > > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> > > > 3. If an np= tag is need
On Saturday, July 13, 2019 12:34:09 AM EDT John Levine wrote:
> In article <2902055.CzhLQO0xIX@l5580> you write:
> >Here's the definition we have in the draft now:
> >> 2.6. Non-existent Domains
> >>
> >>For DMARC [RFC7489] purposes, a non-existent domain is a domain name
> >>that publish
In article <2902055.CzhLQO0xIX@l5580> you write:
>Here's the definition we have in the draft now:
>
>> 2.6. Non-existent Domains
>>
>>For DMARC [RFC7489] purposes, a non-existent domain is a domain name
>>that publishes none of A, , or MX records that the receiver is
>>willing to
On Friday, July 12, 2019 3:13:48 PM EDT John Levine wrote:
> In article you write:
> >-=-=-=-=-=-
> >
> >On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b)
wrote:
> >> I am much more concerned with adding another tag that can only be used in
> >> a PSD-DMARC record. I would be much more open to
On Fri, Jul 12, 2019 at 2:16 PM Seth Blank wrote:
> On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b)
> wrote:
>
>> I am much more concerned with adding another tag that can only be used in
>> a PSD-DMARC record. I would be much more open to make a "normative" change
>> to the DMARC tag list (R
In article
you write:
>-=-=-=-=-=-
>
>On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote:
>
>> I am much more concerned with adding another tag that can only be used in
>> a PSD-DMARC record. I would be much more open to make a "normative" change
>> to the DMARC tag list (RFC 7489 section
On Friday, July 12, 2019 1:54:57 PM EDT Kurt Andersen (b) wrote:
> On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman
>
> wrote:
> > On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
> > > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs
> >
> > The limited feedbac
On Fri, Jul 12, 2019 at 10:55 AM Kurt Andersen (b) wrote:
> I am much more concerned with adding another tag that can only be used in
> a PSD-DMARC record. I would be much more open to make a "normative" change
> to the DMARC tag list (RFC 7489 section 11.4) to define np for any DMARC
> record, t
On Fri, Jul 12, 2019 at 10:50 AM Scott Kitterman
wrote:
> On Wednesday, June 26, 2019 5:21:14 PM EDT Seth Blank wrote:
>
> > 3. If an np= tag is needed to allow PSD functioning for only NXDOMAINs
>
> The limited feedback during WGLC has been favorable to this.
>
> This will require a rather large
48 matches
Mail list logo
