[dmarc-ietf] DMARC agenda for IETF 116 -- and do we need one?

[Barry Leiba]

We do have a session scheduled for IETF 116.

We do not yet have a preliminary agenda for that session.

So:

1. Do we, indeed, still need that session to happen?

2. If so, let's collect an agenda for it.

Document authors definitely NEED TO weigh in.  Others, please also
raise any issues you want to discuss, or make a case for cancelling
the session.

Thanks,
Barry

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

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

Okay. That was my understanding, but wanted to make sure it was crystal
clear. Thanks for the clarification.

On Thu, Mar 9, 2023, 2:53 PM John Levine  wrote:

> It appears that Mark Alley   said:
> >-=-=-=-=-=-
> >
> >This question probably has an obvious answer, but asking for
> >clarification on this - Policy difference aside, in this example
> >provided, does this mean with the Treewalk behavior, cuny.edu's DMARC
> >feedback addresses that differ from the subdomain's would stop getting
> >the sub's DMARC reports?
>
> Yes, that's a feature. If you want your subdomains to send reports to
> some particular place, tell them to do that. If you don't, that's OK
> too.
>
> Any domain can put a "rua" tag into its DMARC record so this isn't
> really anything new.
>
> R's,
> John
>
> >On 2/23/2023 6:13 PM, John R. Levine wrote:
> >>> I haven’t done extensive research but here is a live example where
> >>> treewalk will cause a result change.
> >>> From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
> >>> _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine;
> >>> fo=1;
> >>> rua=mailto:dmarc_...@emaildefense.proofpoint.com;
> >>> ruf=mailto:dmarc_...@emaildefense.proofpoint.com;
> >>>
> >>> _dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;"
> >>> "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:
> post.mas...@cuny.edu;"
> >>>
> >>> "ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:
> post.mas...@cuny.edu;"
> >>> "fo=1"
> >>
> >> Good catch, although in this case I think the most likely result is
> >> that the people at bmcc.cuny.edu will say "who set up
> >> Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use
> >> Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to
> >> O365.  There's some other strangeness; www.cuny.edu is a CNAME for
> >> web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A
> >> records pointing to machines running sendmail.
> >>
> >> It might be interesting to set up a web page where you can put in a
> >> mail domain and it'll tell you whether its treatment will change with
> >> the tree walk.
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Version in aggregate report

[Brotman, Alex]

Thanks folks, I’ll get this cleaned up for the next revision.  I’m also trying 
to address the remaining tickets (most, if not all, have been addressed), and 
make sure they’re closed.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc  On Behalf Of Steven M Jones
Sent: Thursday, March 9, 2023 2:49 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Version in aggregate report

On 3/9/23 11:45, Tomki Camp wrote:
I think that's a good idea. Mike Jones from Fortra (ne Agari) also expressed 
concern during M3AAWG 57 about problems for data analysis to be able to 
determine how a specific receiver's result was achieved, with the discovery 
methodology doubling.
An XML indication specifying the approach that the receiver used should help 
allay that concern.



+1, including John's point about accommodating existing implementations.

--S.


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

Re: [dmarc-ietf] Treewalk causing changes

[John Levine]

It appears that Mark Alley   said:
>-=-=-=-=-=-
>
>This question probably has an obvious answer, but asking for 
>clarification on this - Policy difference aside, in this example 
>provided, does this mean with the Treewalk behavior, cuny.edu's DMARC 
>feedback addresses that differ from the subdomain's would stop getting 
>the sub's DMARC reports?

Yes, that's a feature. If you want your subdomains to send reports to
some particular place, tell them to do that. If you don't, that's OK
too.

Any domain can put a "rua" tag into its DMARC record so this isn't
really anything new.

R's,
John

>On 2/23/2023 6:13 PM, John R. Levine wrote:
>>> I haven’t done extensive research but here is a live example where 
>>> treewalk will cause a result change.
>>> From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
>>> _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; 
>>> fo=1;
>>> rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
>>> ruf=mailto:dmarc_...@emaildefense.proofpoint.com;
>>>
>>> _dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;"
>>> "rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;;
>>>  
>>>
>>> "ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;;
>>>  
>>> "fo=1"
>>
>> Good catch, although in this case I think the most likely result is 
>> that the people at bmcc.cuny.edu will say "who set up 
>> Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use 
>> Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to 
>> O365.  There's some other strangeness; www.cuny.edu is a CNAME for 
>> web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A 
>> records pointing to machines running sendmail.
>>
>> It might be interesting to set up a web page where you can put in a 
>> mail domain and it'll tell you whether its treatment will change with 
>> the tree walk.

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

Re: [dmarc-ietf] Version in aggregate report

[Steven M Jones]

On 3/9/23 11:45, Tomki Camp wrote:
I think that's a good idea. Mike Jones from Fortra (ne Agari) also 
expressed concern during M3AAWG 57 about problems for data analysis to 
be able to determine how a specific receiver's result was achieved, 
with the discovery methodology doubling.
An XML indication specifying the approach that the receiver used 
should help allay that concern.



+1, including John's point about accommodating existing implementations.

--S.

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

Re: [dmarc-ietf] Treewalk causing changes

[Mark Alley]

This question probably has an obvious answer, but asking for 
clarification on this - Policy difference aside, in this example 
provided, does this mean with the Treewalk behavior, cuny.edu's DMARC 
feedback addresses that differ from the subdomain's would stop getting 
the sub's DMARC reports?


- Mark Alley

On 2/23/2023 6:13 PM, John R. Levine wrote:
I haven’t done extensive research but here is a live example where 
treewalk will cause a result change.

From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
_dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; 
fo=1;
rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
ruf=mailto:dmarc_...@emaildefense.proofpoint.com;


_dmarc.cuny.edu.3325INTXT"v=DMARC1;" "p=none;"
"rua=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;; 

"ruf=mailto:dmarc_...@emaildefense.proofpoint.com,mailto:post.mas...@cuny.edu;; 
"fo=1"


Good catch, although in this case I think the most likely result is 
that the people at bmcc.cuny.edu will say "who set up 
Ret.bmcc.cuny.edu?"  I see that bmcc.cuny.edu and cuny.edu both use 
Proofpoint in front of O365, while Ret.bmcc.cuny.edu goes directly to 
O365.  There's some other strangeness; www.cuny.edu is a CNAME for 
web.cuny.edu which has an MX to mail-relay.cuny.edu. which has 7 A 
records pointing to machines running sendmail.


It might be interesting to set up a web page where you can put in a 
mail domain and it'll tell you whether its treatment will change with 
the tree walk.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for 
Dummies",

Please consider the environment before reading this e-mail. https://jl.ly

___
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

Re: [dmarc-ietf] Version in aggregate report

[Tomki Camp]

I think that's a good idea. Mike Jones from Fortra (ne Agari) also
expressed concern during M3AAWG 57 about problems for data analysis to be
able to determine how a specific receiver's result was achieved, with the
discovery methodology doubling.
An XML indication specifying the approach that the receiver used should
help allay that concern.



On Wed, Mar 8, 2023 at 8:44 AM Trent Adams  wrote:

>
>
> Alex -
>
>
>
> Good catch... and yeah, if the DMARC-bis version won't be incremented, I
> agree that the "version" field in the RUA should remain "1" for both
> RFC7489 and DMARC-bis so there's no disconnect in meaning of "version".
>
>
>
> What about adding a field that'd expressly identifies which DMARC record
> discovery mechanism was used?
>
>
>
> That way a report analyst would be able to handle differences in results
> from different evaluators (some using the RFC7489 "hop", and others using
> the -bis "tree walk") for the same set of published policies.
>
>
>
> Perhaps something like:
>
>
>
>   
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> The excepted values being the enumerated discovery mechanisms (e.g.
> something like "hop", "treewalk").
>
>
>
> Thoughts?
>
>
>
> - Trent
>
>
>
>
>
>
>
> *From: *dmarc  on behalf of "Brotman, Alex"
> 
> *Date: *Wednesday, March 8, 2023 at 9:25 AM
> *To: *"dmarc@ietf.org" 
> *Subject: *[dmarc-ietf] Version in aggregate report
>
>
>
> While reviewing something in the aggregate doc, I came across this bit in
> the XML specification. Unless I've missed something, we're not incrementing
> the version in the DMARC DNS record. 
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> So, if we're not changing that DNS record, obviously this "version" string 
> has less meaning.  The prose describing the field says this would be "1" or 
> "2".  If we're going to stick to not incrementing the version string, I need 
> to update this to reflect that.  Not a horrible task, just wanted to be clear 
> before I make work for myself.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> ___
>
> dmarc mailing list
>
> dmarc@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$
>  
> 
>
> ___
> 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

Re: [dmarc-ietf] Version in aggregate report

[John Levine]

It appears that Trent Adams   said:
>-=-=-=-=-=-
>
>
>Alex -
>
>I think that the difference comes down to an inference made by the report 
>analyst (and assuming enough data to make an
>informed guess) vs. the report generator expressly stating the mechanism they 
>used.
>
>IMO, it makes sense to include the signal.  I'd rather not rely on inference 
>when an a priori statement can be transmitted.
>
>But yeah... what do others think?

So long as we make it clear that it's optional, sure, why not.

It has to be optional because existing generators don't add it.

R's,
John

PS: Perhaps we should set up a pool for how long it takes to start
getting reports that claim they didn't use a tree walk, but only go
to domains that a tree walk would find.

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

Re: [dmarc-ietf] Version in aggregate report

[Dotzero]

I favor being explicit in the reporting.

Michael Hammer

On Thu, Mar 9, 2023 at 1:51 PM Trent Adams  wrote:

>
>
> Alex -
>
>
>
> I think that the difference comes down to an inference made by the report
> analyst (and assuming enough data to make an informed guess) vs. the report
> generator expressly stating the mechanism they used.
>
>
>
> IMO, it makes sense to include the signal.  I'd rather not rely on
> inference when an a priori statement can be transmitted.
>
>
>
> But yeah... what do others think?
>
>
>
> - Trent
>
>
>
> PS - I'm reminded of the scene in "Seinfeld" when Kramer is pretending to
> be Movie Phone and asks, "Why don't you just tell me the movie you want to
> see?" https://www.youtube.com/watch?v=XagGEi_n_ok=187s
>
>
>
>
>
>
>
> *From: *"Brotman, Alex" 
> *Date: *Thursday, March 9, 2023 at 11:37 AM
> *To: *Trent Adams , "dmarc@ietf.org" <
> dmarc@ietf.org>
> *Subject: *RE: [dmarc-ietf] Version in aggregate report
>
>
>
> Trent, I’m not entirely opposed to the idea, though I wonder if it’s
> necessary. It seems like if the old method is used vs the tree-walk, and if
> the results are different, then the policy domain in the report would be
> different and easily distinguishable?
>
> Trent,
>
>
>
> I’m not entirely opposed to the idea, though I wonder if it’s necessary.
> It seems like if the old method is used vs the tree-walk, and if the
> results are different, then the policy domain in the report would be
> different and easily distinguishable?  I guess if you want something in the
> report to point at, we can create a field.
>
>
>
> Thoughts from others?
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> *From:* Trent Adams 
> *Sent:* Wednesday, March 8, 2023 11:44 AM
> *To:* Brotman, Alex ; dmarc@ietf.org
> *Subject:* Re: [dmarc-ietf] Version in aggregate report
>
>
>
>
>
> Alex -
>
>
>
> Good catch... and yeah, if the DMARC-bis version won't be incremented, I
> agree that the "version" field in the RUA should remain "1" for both
> RFC7489 and DMARC-bis so there's no disconnect in meaning of "version".
>
>
>
> What about adding a field that'd expressly identifies which DMARC record
> discovery mechanism was used?
>
>
>
> That way a report analyst would be able to handle differences in results
> from different evaluators (some using the RFC7489 "hop", and others using
> the -bis "tree walk") for the same set of published policies.
>
>
>
> Perhaps something like:
>
>
>
>   
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> The excepted values being the enumerated discovery mechanisms (e.g.
> something like "hop", "treewalk").
>
>
>
> Thoughts?
>
>
>
> - Trent
>
>
>
>
>
>
>
> *From: *dmarc  on behalf of "Brotman, Alex" <
> Alex_Brotman=40comcast@dmarc.ietf.org>
> *Date: *Wednesday, March 8, 2023 at 9:25 AM
> *To: *"dmarc@ietf.org" 
> *Subject: *[dmarc-ietf] Version in aggregate report
>
>
>
> While reviewing something in the aggregate doc, I came across this bit in
> the XML specification. Unless I've missed something, we're not incrementing
> the version in the DMARC DNS record. 
>
>   
> minOccurs="0" maxOccurs="1"/>
>
>
>
> So, if we're not changing that DNS record, obviously this "version" string 
> has less meaning.  The prose describing the field says this would be "1" or 
> "2".  If we're going to stick to not incrementing the version string, I need 
> to update this to reflect that.  Not a horrible task, just wanted to be clear 
> before I make work for myself.
>
>
>
> --
>
> Alex Brotman
>
> Sr. Engineer, Anti-Abuse & Messaging Policy
>
> Comcast
>
>
>
> ___
>
> dmarc mailing list
>
> dmarc@ietf.org
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$
>  
> 
>
> ___
> 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

Re: [dmarc-ietf] Version in aggregate report

[Trent Adams]

Alex -

I think that the difference comes down to an inference made by the report 
analyst (and assuming enough data to make an informed guess) vs. the report 
generator expressly stating the mechanism they used.

IMO, it makes sense to include the signal.  I'd rather not rely on inference 
when an a priori statement can be transmitted.

But yeah... what do others think?

- Trent

PS - I'm reminded of the scene in "Seinfeld" when Kramer is pretending to be 
Movie Phone and asks, "Why don't you just tell me the movie you want to see?" 
https://www.youtube.com/watch?v=XagGEi_n_ok=187s



From: "Brotman, Alex" 
Date: Thursday, March 9, 2023 at 11:37 AM
To: Trent Adams , "dmarc@ietf.org" 
Subject: RE: [dmarc-ietf] Version in aggregate report

Trent, I’m not entirely opposed to the idea, though I wonder if it’s necessary. 
It seems like if the old method is used vs the tree-walk, and if the results 
are different, then the policy domain in the report would be different and 
easily distinguishable?

Trent,

I’m not entirely opposed to the idea, though I wonder if it’s necessary.  It 
seems like if the old method is used vs the tree-walk, and if the results are 
different, then the policy domain in the report would be different and easily 
distinguishable?  I guess if you want something in the report to point at, we 
can create a field.

Thoughts from others?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: Trent Adams 
Sent: Wednesday, March 8, 2023 11:44 AM
To: Brotman, Alex ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Version in aggregate report


Alex -

Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree 
that the "version" field in the RUA should remain "1" for both RFC7489 and 
DMARC-bis so there's no disconnect in meaning of "version".

What about adding a field that'd expressly identifies which DMARC record 
discovery mechanism was used?

That way a report analyst would be able to handle differences in results from 
different evaluators (some using the RFC7489 "hop", and others using the -bis 
"tree walk") for the same set of published policies.

Perhaps something like:

  
  

The excepted values being the enumerated discovery mechanisms (e.g. something 
like "hop", "treewalk").

Thoughts?

- Trent



From: dmarc mailto:dmarc-boun...@ietf.org>> on behalf 
of "Brotman, Alex" 
mailto:Alex_Brotman=40comcast@dmarc.ietf.org>>
Date: Wednesday, March 8, 2023 at 9:25 AM
To: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] Version in aggregate report

While reviewing something in the aggregate doc, I came across this bit in the 
XML specification. Unless I've missed something, we're not incrementing the 
version in the DMARC DNS record. 

  



So, if we're not changing that DNS record, obviously this "version" string has 
less meaning.  The prose describing the field says this would be "1" or "2".  
If we're going to stick to not incrementing the version string, I need to 
update this to reflect that.  Not a horrible task, just wanted to be clear 
before I make work for myself.



--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast



___

dmarc mailing list

dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Version in aggregate report

[Brotman, Alex]

Trent,

I’m not entirely opposed to the idea, though I wonder if it’s necessary.  It 
seems like if the old method is used vs the tree-walk, and if the results are 
different, then the policy domain in the report would be different and easily 
distinguishable?  I guess if you want something in the report to point at, we 
can create a field.

Thoughts from others?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: Trent Adams 
Sent: Wednesday, March 8, 2023 11:44 AM
To: Brotman, Alex ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Version in aggregate report


Alex -

Good catch... and yeah, if the DMARC-bis version won't be incremented, I agree 
that the "version" field in the RUA should remain "1" for both RFC7489 and 
DMARC-bis so there's no disconnect in meaning of "version".

What about adding a field that'd expressly identifies which DMARC record 
discovery mechanism was used?

That way a report analyst would be able to handle differences in results from 
different evaluators (some using the RFC7489 "hop", and others using the -bis 
"tree walk") for the same set of published policies.

Perhaps something like:

  
  

The excepted values being the enumerated discovery mechanisms (e.g. something 
like "hop", "treewalk").

Thoughts?

- Trent



From: dmarc mailto:dmarc-boun...@ietf.org>> on behalf 
of "Brotman, Alex" 
mailto:Alex_Brotman=40comcast@dmarc.ietf.org>>
Date: Wednesday, March 8, 2023 at 9:25 AM
To: "dmarc@ietf.org" 
mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] Version in aggregate report

While reviewing something in the aggregate doc, I came across this bit in the 
XML specification. Unless I've missed something, we're not incrementing the 
version in the DMARC DNS record. 

  



So, if we're not changing that DNS record, obviously this "version" string has 
less meaning.  The prose describing the field says this would be "1" or "2".  
If we're going to stick to not incrementing the version string, I need to 
update this to reflect that.  Not a horrible task, just wanted to be clear 
before I make work for myself.



--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast



___

dmarc mailing list

dmarc@ietf.org

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc