[dmarc-ietf] dmarc - Requested session has been scheduled for IETF 118

["IETF Secretariat"]

Dear Barry Leiba,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


dmarc Session 1 (1:00 requested)
Wednesday, 8 November 2023, Session II 1300-1400 Europe/Prague
Room Name: Berlin 3/4 size: 80
-


iCalendar: https://datatracker.ietf.org/meeting/118/sessions/dmarc.ics

Request Information:


-
Working Group Name: Domain-based Message Authentication, Reporting & 
Conformance
Area Name: Applications and Real-Time Area
Session Requester: Barry Leiba


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 30
Conflicts to Avoid: 

   
 Can't meet: Monday morning, Tuesday morning, Wednesday morning, Thursday 
morning, Friday morning

Participants who must be present:
  Alessandro Vesely
  Alex Brotman
  John R. Levine
  Scott Kitterman
  Todd Herr

Resources Requested:

Special Requests:
  Please avoid ART-area and Sec-area BoFs
-


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

If I read that right it gives you what you think is a desirable outcome. That is, this might be a strong sign that you’re at least considering supporting DMARCbis!Yes, we all need to be prepared for headaches no matter which direction this all goes.On Oct 13, 2023, at 3:59 AM, Douglas Foster  wrote:The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.DougOn Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:

> On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> 
> On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
>>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely  wrote:
>>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
 Both approaches have problems.   Stop-at-last enables the walk to exit the current organization and stop on a private registry, for both alignment evaluation and for aggregate report transmission.   This is not a minor problem, even if it is arguably infrequent.
>>> 
>>> The illustrative example in the draft says:
>>> 
>>> _dmarc.a.b.c.d.e.mail.example.com
>>> _dmarc.e.mail.example.com
>>> _dmarc.mail.example.com
>>> _dmarc.example.com
>>> _dmarc.com
>>> 
>>> That is, no stop at all.  In this respect, a psd=n at example.com would save a lookup.  However, it is not something that we can recommend, after we chose the obscure tag name. >
>> I'm not sure I understand what you're saying...
>> The illustrative example cited is intended to illustrate a full tree walk
>> that follows the steps for a full tree walk that are spelled out in the
>> numbered list just prior to the illustrative example.
> 
> 
> Yup, I'm not criticizing the text (I wouldn't know how to better it).
> 
> Just wondering how to implement it.  It is understood that programs must behave /as if/ they followed the letter of the spec, but don't have to actually do so.

Would it be possible to test these scenarios with a working prototype or some other way to provide proof. Due to other obligations I haven’t been able to lurk here much but upon coming back I think the tree walk issues touched on today are possibly the only things standing in the way of dmarcbis. Though I saw there’s a nascent save our PSL movement that I read about. I’m not sure how serious or influential this movement is and why they’d feel so strongly that they’d step in with somewhat dubious play reviews on the 10 yard line. 

I’m just an observer.

I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect problems will be addressed, there’s going to be stress, but ultimately another hack such as the hosts file for DNS will become largely irrelevant in the big picture, taking the Internet another step out of childhood toward adulthood. That’s a good thing even if some things go wrong along the way that need to be fixed or mitigated. The Internet is a place where the perfect is often more blatantly the enemy of the good.

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

___dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

Thank you, sir. That’s part of the reason to cautiously transition away from the PSL. It has the feel of a throwback to a time when people thought the number of total users would be in the hundreds or thousands. Wouldn’t a cautious transition alleviate your concerns? Not everyone, everywhere will pull the switch at midnight.On Oct 13, 2023, at 6:50 AM, Douglas Foster  wrote:Neil, the list is attached. .I used "Z" in the PSD and NP columns to indicate "not specified".   For the other columns, defaults have been inserted.Since everybody has their own copy of the PSL, others may find minor variants of this data.Doug FosterOn Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz  wrote:

> On Oct 13, 2023, at 3:59 AM, Douglas Foster  wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL domains   About 400 of them have DMARC policies.  A super-majority specify relaxed authentication without specifying a NP policy.   This indicates that the policy was created before the PSD for DMARC spec.   I conclude that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of us could make calls to talk to a representative sample. We’d then greatly improve our knowledge of both the concerns and wants of this set of domain operators. Then you’d be in a better position to understand what they want and that, of course, can’t help but influence your decisions. The low numbers at this stage make getting the basic data much easier. 

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

Neil, the list is attached. .
I used "Z" in the PSD and NP columns to indicate "not specified".   For the
other columns, defaults have been inserted.

Since everybody has their own copy of the PSL, others may find minor
variants of this data.

Doug Foster

On Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz 
wrote:

>
>
> > On Oct 13, 2023, at 3:59 AM, Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
> >
> > 
> > The first step in my research has been to do DMARC policy lookups on the
> PSL domains   About 400 of them have DMARC policies.  A super-majority
> specify relaxed authentication without specifying a NP policy.   This
> indicates that the policy was created before the PSD for DMARC spec.   I
> conclude that these domains want to be treated as organizations, not PSOs,
> and tbe stop-last Tree Walk will enable what they have been wanting.
>
> Doug, you’re saying there’s 400? That means anyone of us or, better,
> several of us could make calls to talk to a representative sample. We’d
> then greatly improve our knowledge of both the concerns and wants of this
> set of domain operators. Then you’d be in a better position to understand
> what they want and that, of course, can’t help but influence your
> decisions. The low numbers at this stage make getting the basic data much
> easier.
>
> Neil


PSL entries with DMARC policies.xlsx
Description: MS-Excel 2007 spreadsheet
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Neil Anuskiewicz]

> On Oct 13, 2023, at 3:59 AM, Douglas Foster 
>  wrote:
> 
> 
> The first step in my research has been to do DMARC policy lookups on the PSL 
> domains   About 400 of them have DMARC policies.  A super-majority specify 
> relaxed authentication without specifying a NP policy.   This indicates that 
> the policy was created before the PSD for DMARC spec.   I conclude that these 
> domains want to be treated as organizations, not PSOs, and tbe stop-last Tree 
> Walk will enable what they have been wanting.

Doug, you’re saying there’s 400? That means anyone of us or, better, several of 
us could make calls to talk to a representative sample. We’d then greatly 
improve our knowledge of both the concerns and wants of this set of domain 
operators. Then you’d be in a better position to understand what they want and 
that, of course, can’t help but influence your decisions. The low numbers at 
this stage make getting the basic data much easier. 

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

[Douglas Foster]

The first step in my research has been to do DMARC policy lookups on the
PSL domains   About 400 of them have DMARC policies.  A super-majority
specify relaxed authentication without specifying a NP policy.   This
indicates that the policy was created before the PSD for DMARC spec.   I
conclude that these domains want to be treated as organizations, not PSOs,
and tbe stop-last Tree Walk will enable what they have been wanting.

Doug

On Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz  wrote:

>
>
> > On Oct 10, 2023, at 11:57 AM, Alessandro Vesely  wrote:
> >
> > On Tue 10/Oct/2023 19:16:10 +0200 Todd Herr wrote:
> >>> On Tue, Oct 10, 2023 at 6:14 AM Alessandro Vesely 
> wrote:
> >>> On Tue 10/Oct/2023 00:19:56 +0200 Douglas Foster wrote:
>  Both approaches have problems.   Stop-at-last enables the walk to
> exit the current organization and stop on a private registry, for both
> alignment evaluation and for aggregate report transmission.   This is not a
> minor problem, even if it is arguably infrequent.
> >>>
> >>> The illustrative example in the draft says:
> >>>
> >>> _dmarc.a.b.c.d.e.mail.example.com
> >>> _dmarc.e.mail.example.com
> >>> _dmarc.mail.example.com
> >>> _dmarc.example.com
> >>> _dmarc.com
> >>>
> >>> That is, no stop at all.  In this respect, a psd=n at example.com
> would save a lookup.  However, it is not something that we can recommend,
> after we chose the obscure tag name. >
> >> I'm not sure I understand what you're saying...
> >> The illustrative example cited is intended to illustrate a full tree
> walk
> >> that follows the steps for a full tree walk that are spelled out in the
> >> numbered list just prior to the illustrative example.
> >
> >
> > Yup, I'm not criticizing the text (I wouldn't know how to better it).
> >
> > Just wondering how to implement it.  It is understood that programs must
> behave /as if/ they followed the letter of the spec, but don't have to
> actually do so.
>
> Would it be possible to test these scenarios with a working prototype or
> some other way to provide proof. Due to other obligations I haven’t been
> able to lurk here much but upon coming back I think the tree walk issues
> touched on today are possibly the only things standing in the way of
> dmarcbis. Though I saw there’s a nascent save our PSL movement that I read
> about. I’m not sure how serious or influential this movement is and why
> they’d feel so strongly that they’d step in with somewhat dubious play
> reviews on the 10 yard line.
>
> I’m just an observer.
>
> I’d be shocked if DMARCbis to emerge perfect and triumphant. I expect
> problems will be addressed, there’s going to be stress, but ultimately
> another hack such as the hosts file for DNS will become largely irrelevant
> in the big picture, taking the Internet another step out of childhood
> toward adulthood. That’s a good thing even if some things go wrong along
> the way that need to be fixed or mitigated. The Internet is a place where
> the perfect is often more blatantly the enemy of the good.
>
> Neil
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc