[dmarc-ietf] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-19.txt

[Brotman, Alex]

The changes in this new version should all be from:

https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/18

Daniel did a good job of keeping the changes small, and explicitly stating what 
each change was for.

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

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, August 30, 2024 1:26 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-19.txt
> 
> Internet-Draft draft-ietf-dmarc-aggregate-reporting-19.txt is now available.
> It is a work item of the Domain-based Message Authentication, Reporting &
> Conformance (DMARC) WG of the IETF.
> 
>Title:   Domain-based Message Authentication, Reporting, and Conformance
> (DMARC) Aggregate Reporting
>Author:  Alex Brotman
>Name:draft-ietf-dmarc-aggregate-reporting-19.txt
>Pages:   29
>Dates:   2024-08-30
> 
> Abstract:
> 
>Domain-based Message Authentication, Reporting, and Conformance
>(DMARC) allows for Domain Owners to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the Domain Owner's
>specified destination as supported by the receiver.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!EPz3Zg7JNaXHk391QSEniYispF2u9PLth1rKSdSkS2Wt
> Zgm9OQ8tWFFiKOoZZKjtlOC7iPEIvZSUk_2EwfwEspSHxEnjyCrgGLU$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-
> 19.html__;!!CQl3mcHX2A!EPz3Zg7JNaXHk391QSEniYispF2u9PLth1rKSdSkS2WtZg
> m9OQ8tWFFiKOoZZKjtlOC7iPEIvZSUk_2EwfwEspSHxEnjrmr_xB0$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-
> dmarc-aggregate-reporting-
> 19__;!!CQl3mcHX2A!EPz3Zg7JNaXHk391QSEniYispF2u9PLth1rKSdSkS2WtZgm9O
> Q8tWFFiKOoZZKjtlOC7iPEIvZSUk_2EwfwEspSHxEnj3l-_mPM$
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: Review of the dmarc draft documents

[Brotman, Alex]

Okay, Daniel had maybe 20-25 alterations.  Shortly, I'm going to merge them 
all, and the rev the document. 

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

> -Original Message-
> From: John R. Levine 
> Sent: Friday, August 30, 2024 1:01 PM
> To: Brotman, Alex ; Daniel K.
> ; dmarc@ietf.org
> Subject: [dmarc-ietf] Re: Review of the dmarc draft documents
> 
> On Fri, 30 Aug 2024, Brotman, Alex wrote:
> > Any comments on the alteration for the "ridtxt" that Daniel has included?  
> > There
> was a fair bit of back and forth when we altered that previously.
> >
> > Specifically:
> > https://urldefense.com/v3/__https://github.com/ietf-wg-dmarc/draft-iet
> > f-dmarc-aggregate-reporting/pull/18/commits/21aa5a8303b65e3725d3dc10e0
> > 7c4b05c02282a7__;!!CQl3mcHX2A!ADK-
> LzjuvJMAMGch79UbuS1pADObQ2yPz4WY9Pzi
> > 57KHZAYhnDo60h6cpx37aTlQZJPEJU6T6gUDK-4kDb0qRQ$
> 
> I think he's right.  I see a lot of junk in the report names and in this case 
> I think it's
> better to adjust the spec to match reality.  I don't see much downside to 
> doing so.
> 
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies", Please consider the environment before reading this e-mail.
> https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!ADK-
> LzjuvJMAMGch79UbuS1pADObQ2yPz4WY9Pzi57KHZAYhnDo60h6cpx37aTlQZJPEJ
> U6T6gUDK-6dJ0Vy5w$
> 
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: Review of the dmarc draft documents

[Brotman, Alex]

Any comments on the alteration for the "ridtxt" that Daniel has included?  
There was a fair bit of back and forth when we altered that previously.

Specifically: 
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/18/commits/21aa5a8303b65e3725d3dc10e07c4b05c02282a7



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

> -Original Message-
> From: Alessandro Vesely 
> Sent: Friday, August 30, 2024 7:22 AM
> To: Daniel K. ; John R. Levine ;
> dmarc@ietf.org
> Subject: [dmarc-ietf] Re: Review of the dmarc draft documents
> 
> On Fri 30/Aug/2024 12:58:55 +0200 Daniel K. wrote:
> > On 8/30/24 10:12, Alessandro Vesely wrote:
> >> I agree on most changes, possibly except that 05.06.07.08 seems to me
> >> an acceptable IPv4 expression,
> >
> > Yeah, but if we allow leading zeroes, 005.006.007.008 should also be
> > allowed, but the current regex does not allow it.
> >
> > We should at least go one way or the other.
> >
> > If double leading zeroes should be allowed, then substitute "1?\d?\d"
> > with "[01]?\d?\d" instead.
> 
> 
> That looks better.
> 
> 
> >> and perhaps the obsolescence note is required (?)
> >
> > There is a similar note in the abstract of the dmarcbis draft, but not
> > in the failure-reporting draft.
> 
> 
> Should I add one?  The I-D expires next September...
> 
> 
> Best
> Ale
> --
> 
> 
> 
> 
> 
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: New Version Notification for draft-ietf-dmarc-aggregate-reporting-17.txt

[Brotman, Alex]

I believe this also means I need to alter:

There MAY be an optional "envelope_from" element, which contains the 
RFC5321.MailFrom domain or the RFC5321.Helo domain that the SPF check has been 
applied to. This element MAY be existing but empty if the message had a null 
reverse-path 
([RFC5321<https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-17.html#RFC5321>],
 Section 4.5.5).

The main document says that only the 5321.From will be used in SPF evaluations 
as it relates to DMARC.

I believe to match the “may use SPF” portion, I need to change:

The "dkim" sub-element is optional as not all messages are signed, while there 
MUST be at least one "spf" sub-element.

To be: The "dkim" sub-element is optional as not all messages are signed, while 
there MAY be at least one "spf" sub-element.

And also alter the XSL:

  

To be:   


Does that sound reasonable?

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

From: Barry Leiba 
Sent: Monday, August 19, 2024 11:08 PM
To: Brotman, Alex 
Cc: dmarc@ietf.org
Subject: Re: New Version Notification for 
draft-ietf-dmarc-aggregate-reporting-17.txt

Thanks, Alex!  This does address all but one comment/question/discussion from 
my review, and thanks for dealing with all that.  The one that’s left might 
need a brief discussion before we decide on a change (and whether to change).  
It’s this one:

   The “dkim” sub-element is
   optional as not all messages are signed, while there MUST be at least
   one “spf” sub-element.

As I read DMARCbis, I think it requires the use of SPF *or* DKIM, but does not 
*require* SPF. A sender doesn’t have to supply an SPF record, and a receiver 
doesn’t have to check SPF if there is aligned DKIM. What do I put in the spf 
sub-element if your domain doesn’t use SPF or if I didn’t check it?

(And I agree that removing “forwarded” in 2.1.5 seems right.)

Barry

On Mon, Aug 19, 2024 at 9:20 AM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Hey folks

I believe I have mostly addressed Barry's concerns that he sent to the list 
last week.

There was a note about two of the policy override options (section 2.1.5), 
"forwarded", and "trusted_forwarder".  They are currently next to each other in 
the draft, though, I don't believe we need both.  If someone else believes 
there is some difference that can be more properly illustrated, I'm happy to 
take that language.  Otherwise, I'd likely remove "forwarded", and just leave 
the other with its current description.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!HQEOX2UUPmgPJWhCzH9htMiPMJcpypEknHAVsTpBQG7VIqyZfqqSe4R5BmQJYKbX9zxsaNfMvGjYksW_tfE0BPGfQg$>

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


> -Original Message-
> From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> 
> mailto:internet-dra...@ietf.org>>
> Sent: Monday, August 19, 2024 9:13 AM
> To: Brotman, Alex mailto:alex_brot...@comcast.com>>
> Subject: New Version Notification for draft-ietf-dmarc-aggregate-reporting-
> 17.txt
>
> A new version of Internet-Draft draft-ietf-dmarc-aggregate-reporting-17.txt
> has been successfully submitted by Alex Brotman and posted to the IETF
> repository.
>
> Name: draft-ietf-dmarc-aggregate-reporting
> Revision: 17
> Title:DMARC Aggregate Reporting
> Date: 2024-08-19
> Group:dmarc
> Pages:29
> URL:  
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft->
> ietf-dmarc-aggregate-reporting-
> 17.txt__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaECKDuPWQ$
> Status:   
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft->
> ietf-dmarc-aggregate-
> reporting/__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaGlx0_4vg$
> HTML: 
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft->
> ietf-dmarc-aggregate-reporting-
> 17.html__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaFZ4LWFXw$
> HTMLized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf->
> dmarc-aggregate-reporting__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1

[dmarc-ietf] Re: [EXTERNAL] Re: Re: New Version Notification for draft-ietf-dmarc-aggregate-reporting-17.txt

[Brotman, Alex]

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

> -Original Message-
> From: John Levine 
> Sent: Monday, August 19, 2024 2:05 PM
> To: dmarc@ietf.org
> Cc: Brotman, Alex 
> Subject: [EXTERNAL] Re: [dmarc-ietf] Re: New Version Notification for 
> draft-ietf-
> dmarc-aggregate-reporting-17.txt
> 
> It appears that Brotman, Alex  said:
> >Hey folks
> >
> >I believe I have mostly addressed Barry's concerns that he sent to the list 
> >last
> week.
> >
> >There was a note about two of the policy override options (section
> >2.1.5), "forwarded", and "trusted_forwarder".  They are currently next to 
> >each
> other in the draft, though, I don't believe we need both.  If someone else 
> believes
> there is some difference that can be more properly illustrated, I'm happy to 
> take
> that language.
> >Otherwise, I'd likely remove "forwarded", and just leave the other with its
> current description.
> >
> >https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf
> >-dmarc-aggregate-
> reporting/__;!!CQl3mcHX2A!FcMIaqE8cIJxQVp3heiHedrQKnBt
> >ENk3MHc3a6DdTNyDgyt770lVqvh3Qyh-5_uKxa7aUUOZAE_gJ6nU$
> 
> I agree that forwarded and trusted_forwarder are redundant
> 
> In the subject line exxample in 2.6.2, the Report-ID is not a ridtxt.
> That example was wrong in 7489.

Removed one of the forward options, and updated the ridtxt on the Subject 
example.

> 
> In 6.2 it says there is no PII in aggregate reports. If a domain has few 
> enough
> users, there can in practice be PII but I wouldn't worry about it, since 
> that's an
> issue for every use of the domain, not just in DMARC.
> 

I feel like this was discussed on the list, and we decided that there wasn't a 
practical issue.   I can rework it to note the above if you believe the 
document benefits.


> I think the XML schema is OK, but as always more people lo
oking at it would be
> better.
> 
> R's,
> John
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: New Version Notification for draft-ietf-dmarc-aggregate-reporting-17.txt

[Brotman, Alex]

Hey folks

I believe I have mostly addressed Barry's concerns that he sent to the list 
last week.

There was a note about two of the policy override options (section 2.1.5), 
"forwarded", and "trusted_forwarder".  They are currently next to each other in 
the draft, though, I don't believe we need both.  If someone else believes 
there is some difference that can be more properly illustrated, I'm happy to 
take that language.  Otherwise, I'd likely remove "forwarded", and just leave 
the other with its current description.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

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

> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Monday, August 19, 2024 9:13 AM
> To: Brotman, Alex 
> Subject: New Version Notification for draft-ietf-dmarc-aggregate-reporting-
> 17.txt
> 
> A new version of Internet-Draft draft-ietf-dmarc-aggregate-reporting-17.txt
> has been successfully submitted by Alex Brotman and posted to the IETF
> repository.
> 
> Name: draft-ietf-dmarc-aggregate-reporting
> Revision: 17
> Title:DMARC Aggregate Reporting
> Date: 2024-08-19
> Group:dmarc
> Pages:29
> URL:  https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> ietf-dmarc-aggregate-reporting-
> 17.txt__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaECKDuPWQ$
> Status:   https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-
> ietf-dmarc-aggregate-
> reporting/__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaGlx0_4vg$
> HTML: https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-
> ietf-dmarc-aggregate-reporting-
> 17.html__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaFZ4LWFXw$
> HTMLized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> dmarc-aggregate-reporting__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-
> AqsBks7RxmB8PBP1KBLaGcSXfKkQ$
> Diff: https://urldefense.com/v3/__https://author-
> tools.ietf.org/iddiff?url2=draft-ietf-dmarc-aggregate-reporting-
> 17__;!!CQl3mcHX2A!C0_7jax4Yi5445A1dcIGVHWlw-b-
> TWY_nk2gLVaBwR4IZzEFiw7o-haU_1R0d0TXf-AqsBks7RxmB8PBP1KBLaH_u-
> OAFw$
> 
> Abstract:
> 
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes RFC7489.
> 
> 
> 
> The IETF Secretariat
> 

___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

[dmarc-ietf] Re: Aggregate reporting loops

[Brotman, Alex]

We send reports from a platform that doesn't contribute to DMARC reports, as 
option 4.

1) What if they fix it?
3) I don’t think this is a valid option.  You could have millions of messages 
from a single IP.  Perhaps you mean omit reports for a single message (or below 
some other threshold)?

However, if it's a bounce (I take that to mean a permanent failure), it won't 
always result in a DMARC report.

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

> -Original Message-
> From: Alessandro Vesely 
> Sent: Monday, July 22, 2024 1:31 PM
> To: dmarc-ietf 
> Subject: [dmarc-ietf] Aggregate reporting loops
> 
> Hi,
> 
> non-existing rua= addresses generate loops, because the target domain sends
> a bounce, and on the next day the generator sends them a report for that one
> message.  The report bounces, and so forth...
> 
> Three ways to prevent that:
> 
> 1, accurately store all bouncing addresses so as to avoid sending again,
> 
> 2, omit aggregating data for DSNs, or
> 
> 3, omit sending reports that have only one row.
> 
> 
> I'd opt for 2.  However, the ID says "The report may include [...] The counts 
> of
> messages based on all messages received".  Would it make sense to change
> that so as to exclude DSNs?
> 
> 
> Best
> Ale
> --
> 
> 
> 
> 
> ___
> dmarc mailing list -- dmarc@ietf.org
> To unsubscribe send an email to dmarc-le...@ietf.org
___
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Brotman, Alex]

To Tim’s note below, should the group create an operational guidance document 
for DMARCbis? This could allow for more lengthy discussions around policy 
decisions, and move that discussion out of the technical document.

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

From: dmarc  On Behalf Of Tim Wicinski
Sent: Monday, April 1, 2024 12:17 PM
To: Dotzero 
Cc: Brotman, Alex ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] SPF follies, WGLC editorial review of 
draft-ietf-dmarc-dmarcbis-30

I have to agree with Seth's comments that "security teams believe an SPF hard 
fail is more secure".
I've been on the receiving end of that discussion more than once.

Also, can we reference those two M3AAWG documents ?  That seems like 
operational guidance.

tim


On Mon, Apr 1, 2024 at 8:55 AM Dotzero 
mailto:dotz...@gmail.com>> wrote:


On Mon, Apr 1, 2024 at 8:18 AM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
One item left out of Seth’s text is that due to MBPs who act in this fashion, 
these SPF evaluation failures will (understandably) not show up in DMARC 
reports, and the domain owner may not have visibility for these failures.  
However, the text also puts the onus on the domain owner instead of the MBP.  
The text could be altered to instead suggest that MBPs who deploy DMARC should 
not utilize the outcome of SPF in this fashion.  If the domain owner wants to 
protect their domain, and has no idea if the MBP supports DMARC properly 
(presuming they also have an enforcing policy), is it more or less advisable to 
use “-all” with your SPF record?

I’d be curious to see the Venn diagram of MBPs who implement SPF in this 
fashion, and also fully support DMARC.  I feel like the MBPs who I’ve 
encountered deploying an SPF check in this way had not at the time supported 
DMARC.

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

I was just thinking along these lines and was going to post but you beat me to 
the punch.

+1

Michael Hammer
___
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Fb-J3cXtCi-g9GrtAS4dOqVZX7mqGuHPpsx_WiInM3oaf51dbfoNWfZ8G67ACgtN7VjFXXC2eIvT794GNh4R$>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

[Brotman, Alex]

One item left out of Seth’s text is that due to MBPs who act in this fashion, 
these SPF evaluation failures will (understandably) not show up in DMARC 
reports, and the domain owner may not have visibility for these failures.  
However, the text also puts the onus on the domain owner instead of the MBP.  
The text could be altered to instead suggest that MBPs who deploy DMARC should 
not utilize the outcome of SPF in this fashion.  If the domain owner wants to 
protect their domain, and has no idea if the MBP supports DMARC properly 
(presuming they also have an enforcing policy), is it more or less advisable to 
use “-all” with your SPF record?

I’d be curious to see the Venn diagram of MBPs who implement SPF in this 
fashion, and also fully support DMARC.  I feel like the MBPs who I’ve 
encountered deploying an SPF check in this way had not at the time supported 
DMARC.

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

From: dmarc  On Behalf Of Seth Blank
Sent: Sunday, March 31, 2024 7:38 PM
To: Murray S. Kucherawy 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] SPF follies, WGLC editorial review of 
draft-ietf-dmarc-dmarcbis-30

It is a very common issue that companies want DMARC, but their security teams 
believe an SPF hard fail is more secure, and then all sorts of actual 
operational issues slam in. It ends up being lots of work to convince those 
security teams otherwise.

I think it is desirable to state that this issue is known, and with respect to 
DMARC a hard fail can have unintended consequences. Operationally for DMARC, 
anything that is not an SPF pass is treated the same, so a hard fail is not a 
stronger signal if you wish to implement DMARC with a policy that is not none.

There are two M3AAWG documents that do call out explicit issues and best 
practice, so I won’t push strongly that this should be in the document. But 
since there’s already text that’s so close, why not update it to cover this 
more explicitly?

S, participating, after just having this conversation the other week


Seth Blank | Chief Technology Officer
Email: s...@valimail.com

[https://hosted-packages.s3.us-west-1.amazonaws.com/Valimail+Logo.png]
This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.


On Sun, Mar 31, 2024 at 18:47 Murray S. Kucherawy 
mailto:superu...@gmail.com>> wrote:
On Sun, Mar 31, 2024 at 3:28 PM Richard Clayton 
mailto:rich...@highwayman.com>> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message mailto:7...@mail.gmail.com>>, Seth Blank 
mailto:40valimail@dmarc.ietf.org>>
writes

>Some Mail Receiver architectures implement SPF in advance of any
>DMARC operations. This means that an SPF hard fail ("-") prefix on
>a sender's SPF mechanism, such as "-all", could cause that
>rejection to go into effect early in handling, causing message
>rejection before any DMARC processing takes place, and DKIM has a
>chance to validate the message instead of SPF. Operators choosing
>to use "-all" to terminate SPF records should be aware of this.

I understood what this said thus far ... but I wonder what it is doing
in a document about DMARC.   Some architectures may reject email from
IPs listed in the PBL ... again nothing to do with DMARC. This isn't a
document on how to improve deliverability is it ?

I don't understand the link being made here between operational details and 
deliverability.  I understand this to be pointing out that if you do any short 
circuiting, DMARC can't be evaluated.  That includes any early rejection, be 
that based on SPF results, DKIM signature failures, domain reputation 
rejections, or anything of the sort.

Mind you, I'm a little worried about anyone that plans to rely seriously on 
DMARC yet to whom this isn't relatively obvious.  You need those results before 
DMARC can even begin, and the DKIM result comes only after the body arrives.

-MSK, p11g
___
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] Fwd: [Technical Errata Reported] RFC7489 (7865)

[Brotman, Alex]

Apologies, which format should be used.  I'm not sure if I should revert to the 
one from 7489, or some other prior version.

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

> -Original Message-
> From: dmarc  On Behalf Of John R Levine
> Sent: Monday, March 25, 2024 1:54 PM
> To: Alessandro Vesely ; dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (7865)
> 
> On Mon, 25 Mar 2024, Alessandro Vesely wrote:
> >> How about:
> >> "(:::)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d|2
> >> 5[0-5])"/>
> >
> >
> > Testing yielded a correct fix:
> >
> >
> > "(::[Ff]{4}:)?(([01]?\d?\d|2[0-4]\d|25[0-5])\.){3}([01]?\d?\d|2[0-4]\d
> > |25[0-5])"/>
> 
> There are lots of other ways to write it, e.g.
> 
>   ::00::12.34.56.78
>   0:0:0:0:0:0::012.034.056.078
> 
> and they're actually IPv6 addresses.  Just take it out, if nobody has tried 
> to use
> this form in the past decade, they won't use it now.
> 
> > Please take my pull request.
> 
> Please take out the grammar change.
> 
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please
> consider the environment before reading this e-mail.
> https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!GrQN5Qa27kbjTdAl8T
> v9N3x0TKJwgntlZNJu0MEv_JDN0Gg6YDL6eEv4lISkNj27tfirjRuQ0seUN9tU$
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!GrQN5Qa27kbjTdAl8Tv9N3x0TKJwgntlZNJu0MEv_JDN0Gg6YDL6eEv
> 4lISkNj27tfirjRuQ0vfo69EU$

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

[dmarc-ietf] Errata for Aggregate Reporting

[Brotman, Alex]

There were a few errata for the aggregate reporting.  I wanted to confirm with 
the list that these are still valid.

https://www.rfc-editor.org/errata/eid5440 :: I thought it had been determined 
the ";" was not necessary.

https://www.rfc-editor.org/errata/eid6485 :: We've since replaced this, so I 
don't believe this is relevant.

https://www.rfc-editor.org/errata/eid5774 :: There were a number of edits for 
clarification to this portion of the document.  The "otherwise specified" 
language is no longer there, and I believe all concerns have been addressed for 
this portion. 


Thanks folks.

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

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

Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-aggregate-reporting-14

[Brotman, Alex]

Thanks for the feedback.  I believe I've corrected all except

- 2.1: "(...) while there MUST be one spf sub-element". At least one according 
to the XML Schema Definition (might be two, each with a different scope "helo" 
and "mfrom").

Can we talk about how this looks in a sample report? 

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Thursday, March 21, 2024 6:23 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Working Group Last Call on 
> draft-ietf-dmarc-aggregate-
> reporting-14
> 
> Barry Leiba wrote on 2024-02-29 16:03:
> > This document is also ready for our final look, so this message starts
> > a working group last call for the aggregate reporting document, with
> > the same timing as for the DMARC spec.
> >
> > Please post to the DMARC mailing list by 31 March, giving your last
> > call comments (which should include “I read it and I think it’s ready”
> > as well).  If you have significant issues to raise that have not
> > already been discussed and closed, please post each of those as a
> > separate thread.  Minor issues and editorial comments can just be
> > posted here, to this thread, and we can split them off if necessary.
> 
> Editorial and nits:
> 
> - Would it be useful to add a reference to dmarc-bis?
> - 2.1: Bullet point "A separate report should be generated (...)"
> appears to be a requirement, not an enumeration of data included in the 
> report.
> - 2.1: Bullet point "The DMARC policy discovered and applied, if any" is 
> redundant
> with "The policy requested by the Domain Owner and the policy actually applied
> (if different)".
> - 2.1: Write out "IP" as "IP address".
> - 2.1: The terminology of having two sections and two subsections may be
> misleading, as this is not reflected in the XML structure. Suggestion:
> replace "subsection" with "element", which is a term used in XML.
> - 2.1: "In most cases, this will be a header_from element, which will contain 
> the
> 5322.From domain from the message." Add: "There may be an envelope_from
> element, which contains the RFC5321.MailFrom domain."
> - Multiple instances: Replace "5322.From" with "RFC5322.From".
> - 2.1: "the 'record' element". Only instance where the element name is 
> enclosed
> in quotes.
> - 2.1: "(...) while there MUST be one spf sub-element". At least one 
> according to
> the XML Schema Definition (might be two, each with a different scope "helo" 
> and
> "mfrom").
> - 2.1: "(...) the value is one of
> none/neutral/pass/fail/softfail/temperror/permerror." Would it make sense to
> add a reference to RFC 8601?
> - 2.1.3: "Specified below, the reader will see a msg-id, Report-ID, 
> unique-id." msg-
> id is not specified below. "5322.Message-Id" is briefly mentioned in 2.6.2.
> - 2.3: "(...) regardless of any requested report interval." The report 
> interval (ri tag)
> has been removed from dmarc-bis.
> - 2.6: "Any reporting URI that includes a size limitation exceeded by the 
> generated
> report (...) MUST NOT be used." The size limitation has been removed from
> dmarc-bis. However, leaving the text as-is offers the option to re-introduce 
> a size
> limitation in future URI schemes.
> - 2.6: "(...) the Mail Receiver MAY send a short report (see Section 7.2.2)"
> Dangling reference: error reports have been removed.
> - 2.6.2: "This transport mechanism potentially encounters a problem when
> feedback data size exceeds maximum allowable attachment sizes for either the
> generator or the consumer. See Section 7.2.2 for further discussion." Dangling
> reference.
> - 3: "(...) after conversion to an A-label if needed." Add reference to 
> definition of
> an A-label. Dmarc-bis references Section 2.3 of [RFC5890].
> - 3: "the same overall format as the policy record (see Section 5.3)."
> Section 5.3 (or 5.4) of dmarc-bis.
> - 8: "report_id: UUID, specified elsewhere". Change to: "report_id:
> Unique Report-ID".
> - 8: "error: ?". Change to: "error: Optional error messages when processing
> DMARC policy".
> - 8: "The percent declared in the DMARC record". Change to: "Whether testing
> mode was declared in the DMARC record."
> - 9: The policy_evaluated in the sample report evaluates to pass,
> but still results in quarantine. Is that an 
> adequate
> example?
> Suggestion: change to pass.
> 
> Regards,
> Matt
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!Bnuiz20ACdarSauiLSk8IQ3CRyWbItwpq20m0AgtFVIA2mRNyWeQMb
> -h_WUJsrvmtSbtJROBvnxFUdm0-HW0MvTSHXxGxoFC-BA$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Security Considerations in aggregate-reporting

[Brotman, Alex]

Thanks, added as a list

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Friday, March 22, 2024 7:15 PM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] Security Considerations in aggregate-reporting
> 
> The Security Considerations section of aggregate-reporting-14 currently 
> consists
> of a placeholder. Suggested text follows.
> 
> 7. Security Considerations
> 
> Aggregate reports are supposed to be processed automatically. An attacker 
> might
> attempt to compromise the integrity or availability of the report processor by
> sending ill-formed reports. In particular, the archive decompressor and XML
> parser are at risk to resource exhaustion attacks (zip bomb or XML bomb).
> 
> The data contained within aggregate reports may be forged. An attacker might
> attempt to interfere by submitting false reports in masses.
> 
> See also the security considerations of [dmarc-bis] (Section 11).
> 
> Regards,
> Matt
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!DFefgrWpAI8yZl-vaXTMNo-
> w25DyauJ5lIv7PgXtLK8GuOehfQXU0cRr94m41JRipIHn7C-
> myd1B9T5zxeCUhXOszRZMN0b3Z6SfZIb4$

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-14.txt

[Brotman, Alex]

Hey folks,

Mostly some typos being corrected.  Changed the URL in the XSD per Ale's 
suggestion. Added a paragraph about the Error field.  

Thanks

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, February 28, 2024 8:32 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-14.txt
> 
> Internet-Draft draft-ietf-dmarc-aggregate-reporting-14.txt is now available.
> It is a work item of the Domain-based Message Authentication, Reporting &
> Conformance (DMARC) WG of the IETF.
> 
>Title:   DMARC Aggregate Reporting
>Author:  Alex Brotman
>Name:draft-ietf-dmarc-aggregate-reporting-14.txt
>Pages:   28
>Dates:   2024-02-28
> 
> Abstract:
> 
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes [RFC7489].
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!Eh7CcgDsmdyuvKl0gabUhtWziumH7vcUO6CZ19hik
> uQYNDz_7FzKwlKvtIIqEtN3ZmQrfBi4e03gW_l8umC0DN3JAA1hJA$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-
> 14.html__;!!CQl3mcHX2A!Eh7CcgDsmdyuvKl0gabUhtWziumH7vcUO6CZ19hikuQ
> YNDz_7FzKwlKvtIIqEtN3ZmQrfBi4e03gW_l8umC0DN2WEA_XEg$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-
> dmarc-aggregate-reporting-
> 14__;!!CQl3mcHX2A!Eh7CcgDsmdyuvKl0gabUhtWziumH7vcUO6CZ19hikuQYNDz
> _7FzKwlKvtIIqEtN3ZmQrfBi4e03gW_l8umC0DN3_aIbO4w$
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!Eh7CcgDsmdyuvKl0gabUhtWziumH7vcUO6CZ19hikuQYNDz_7FzKwl
> KvtIIqEtN3ZmQrfBi4e03gW_l8umC0DN0f5XjmCQ$

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

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

[Brotman, Alex]

Apologies, I went back to read this while I was looking for other updates.  

That URL was the only update that was required for DMARCbis for Aggregate 
Reports?  If so, it'll be updated in the next draft.

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

> -Original Message-
> From: Alessandro Vesely 
> Sent: Friday, November 17, 2023 4:22 AM
> To: dmarc@ietf.org; Brotman, Alex 
> Subject: Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML
> Schema
> 
> On Thu 16/Nov/2023 16:47:48 +0100 Olivier Hureau wrote:
> > On 15/11/2023 14:22, Alessandro Vesely wrote:
> >>
> >> We've had quite some discussion on that scheme, which resulted in
> >> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting
> >> /blob/main/dmarc-xml-0.2.xsd
> >> included in the current draft.
> >
> > Indeed, I was referring to this one.
> > However, I think you should have a fixed value for the /version
> > variable in order to clearly differentiate the XSD version, Even
> > thought it is clearly specified in RFC 7489 :
> > ``` The "version" for reports generated per this specification MUST
> > bethe value 1.0. ``` It is not yet specified in Dmarcbis.
> 
> 
> That's right.  The only mention is in Appendix B. Sample Report, saying
> 1.0.
> 
> That sample record is wrong, as it identifies itself as  xmlns="http://dmarc.org/dmarc-xml/0.2";>.  It should have used
> xmlns="urn:ietf:params:xml:ns:dmarc-2.0".  My fault proposing it.  Alex,
> would you pleas fix that?
> 
> The IETF XML Registry is defined by RFC 3688.[*]  IANA is supposed to insert
> our "dmarc-2.0" per IANA Considerations section.  Referencing that schema in
> the feedback element identifies the format more clearly than a version
> number.
> However, Matt suggested to keep  for compliance with RFC 7489[†].
> In that case, is it correct to stick to 1,0?
> 
> I note that while the report metadata provides for producer identifiers and
> contacts, the software name and version are missing.  Or should version refer
> to the software?  (In that case only its name is missing...)
> 
> 
> Best
> Ale
> --
> [*] https://www.iana.org/assignments/xml-registry/xml-registry.xhtml
> [†]
> https://mailarchive.ietf.org/arch/msg/dmarc/JdRxmT9Aw3HkWM7rr3Av9B3
> EwRc
> 
> 
> 
> 
> 
> 

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

Re: [dmarc-ietf] Dmarcbis way forward

[Brotman, Alex]

+1 SHOULD NOT

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

From: dmarc  On Behalf Of Mark Alley
Sent: Tuesday, October 24, 2023 1:26 PM
To: Matt V 
Cc: dmarc-cha...@ietf.org; Francesca Palombini 
; IETF DMARC WG 
; art-...@ietf.org
Subject: Re: [dmarc-ietf] Dmarcbis way forward

+1 for SHOULD NOT.
On Tue, Oct 24, 2023, 12:14 PM Matt V 
mailto:40emailkarma@dmarc.ietf.org>>
 wrote:
I also agree that "SHOULD NOT" would be my vote as the preferred language going 
forward.

~
Matt

On Tue, Oct 24, 2023 at 12:41 PM Dotzero 
mailto:dotz...@gmail.com>> wrote:
I'd like to first thank Francesca for taking the time to review where the 
working group is as far as consensus.

I fall into the "SHOULD NOT" consensus group with additional non-normative 
language.

The short version of the non-normative language should be in the document 
itself but I believe the issues resulting from deviating from the normative 
"SHOULD NOT" deserve a fuller discussion in a separate document.

Much of the discussion has been focused on the impact to mailing lists but the 
impacts can involve a wider range of issues depending on the nature of the 
domain/organization and users involved. A discussion of those wider impacts in 
the context of a "SHOULD NOT" would be useful in educating domain owners, 
administrators and (even) users. There are differences in control and impacts 
between a corporate/organizational domain, government domains, domains which 
offer free or paid accounts to the public and personal domains for example. 
Advice to one of these groupings may not reasonably address the concerns and 
impacts for domains or constituencies in other groupings.
Michael Hammer


On Mon, Oct 23, 2023 at 4:04 AM Francesca Palombini 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
I have been asked by Murray to assist with a consensus evaluation on the 
discussion that has been going on for a while about the dmarcbis document and 
how to move forward.

I have made an attempt to evaluate consensus on the topic, trying to look at it 
from a complete outsider’s point of view and trying not to let my personal 
opinion bias my assessment. This is a summary of that evaluation. It is based 
on several threads in the mailing list: [1], [2], [3] and recordings of the 
IETF 117 wg meeting [4]. I also tried to pay attention to chronology of 
comments, because some people have expressed different support for different 
proposals, in which case I consider the latest email I can find as the person’s 
latest opinion.
Although that was mentioned, I believe there is no consensus to move the 
document status to Informational. I believe there is a rough consensus that a 
change needs to be made in the text to include stronger requirements 
admonishing operators against deploying DMARC in a way that causes disruption. 
The mails go in many directions, but the most contentious point I could 
identify is if there ought to be some normative MUST NOT or SHOULD NOT text. 
Many people have suggested text (thank you!). I believe the ones with more 
tractions are Scott’s MUST NOT proposal [2] and Barry’s SHOULD NOT proposal 
[3]. I believe most people who’d prefer just descriptive text have stated that 
they can live with the SHOULD NOT text, but they have stronger objections 
towards the MUST NOT text. There also a number of people who strongly believe 
MUST NOT is the way to go, but these people have not objected strongly to 
Barry’s latest proposed text in the mailing list (although they have made their 
preference clear during the meeting [4]). As a consequence, I believe there is 
a stronger (very rough) consensus for going with Barry’s SHOULD NOT text. I 
also believe there is consensus to add some non-normative explanatory text (be 
it in the interoperability or security consideration sections, or both) around 
it.
I suggest the authors and the working group start with Berry’s text and 
fine-tune the details around it.
In particular, as another AD that might have to ballot on this document, I 
suggest that you pay particular attention to the text around the SHOULD NOT, as 
also Murray suggested in [5]. I have often blocked documents with the following 
text: “If SHOULD is used, then it must be accompanied by at least one of: (1) A 
general description of the character of the exceptions and/or in what areas 
exceptions are likely to arise.  Examples are fine but, except in plausible and 
rare cases, not enumerated lists. (2) A statement about what should be done, or 
what the considerations are, if the "SHOULD" requirement is not met. (3) A 
statement about why it is not a MUST.”.
I appreciate everybody’s patience and constructive discussion.
Francesca, ART AD
[1]: 
https://mailarchive.ietf.org/arch/msg/dmarc/Z2hoBQLfacWdxALzx4urhKv-Z-Y/

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Brotman, Alex]

Not that I’m aware of.  But even if we leave it unstructured, including 
examples about what may be useful could be of assistance.

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

From: Murray S. Kucherawy 
Sent: Monday, October 23, 2023 3:12 PM
To: Brotman, Alex 
Cc: Matthäus Wander ; dmarc@ietf.org
Subject: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Mon, Oct 23, 2023 at 12:04 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
I should note that generally, while there's an "error" field available, there's 
no guidance about what should go in there. (not in 7489 either that I could 
find in a brief search)

Has there ever been any push for structured content there?  I think if there 
has been, that might be valuable input.  If not, then although structured is 
probably better than unstructured, unstructured is almost certainly better than 
none.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

[Brotman, Alex]

I can add this.

I should note that generally, while there's an "error" field available, there's 
no guidance about what should go in there. (not in 7489 either that I could 
find in a brief search)

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Monday, October 23, 2023 2:51 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.
> 
> Murray S. Kucherawy wrote on 2023-10-20 21:35:
> > (2) Mapping a misspelled "reject" or "quarantine" to "none" even only
> > in the report will be confusing; the domain owner will be told there's
> > a "none" out there when there isn't.  A non-thorough domain owner
> > might conclude that the receiver is broken and not debug their
> > problem.  The guidance here ought to result in the report indicating
> > somehow that the receiver assumed "none" because what it extracted
> > from the DNS appeared to be junk.  Should the report include a mechanism
> making this explicit?
> 
> I'm a strong proponent of including human-understandable error messages in
> DMARC reports. More than once, I puzzled over whether the outgoing message
> stream or the report sender is broken.
> 
> In the above case, the already existing (but not prominently known) optional
>  field in the  section can be used to include an error
> message, e.g., "syntax error in sp tag".
> 
> Text suggestion:
> The Mail Receiver MAY utilize the optional "error" field in aggregate reports 
> to
> announce syntax errors identified in the DMARC policy record.
> 
> Regards,
> Matt
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!GcbuMEjhafXK7OEhrWB70xSYAvSFVGT776G7Rd9JLN_8FJuuyBCEfJJ
> wkqzM64HD4KC46q0fl4NgesMsfXj22Jxg6gI7MWpfWutCZrad$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-13

[Brotman, Alex]

Thanks, I've updated the docs to note to refer to the section below for 
guidance on a reasonable limit.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Monday, October 2, 2023 11:44 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-13
> 
> On 02/10/2023 15:12, Brotman, Alex wrote:
> > Please let me know if you have any additional issues or concerns.
> 
> 
> One is the sentence " If validation is attempted for any DKIM signature, the 
> results
> MUST be included in the report." toward the end of Section 2.1.  It 
> contradicts
> Section 2.1.2, which accounts for soft and hard limits of the number of 
> signatures
> included in a report.
> 
> 
> Best
> Ale
> --
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!BE33G7Czlzci_YKIJmchWsCSoKJ_oRMEx-
> 0Eob11qTnOGdQBcxmtn5bL2vDL0cwgUQj75IE7NJ1BwEEVIyHr4aCn$

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

[dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-13

[Brotman, Alex]

Hey folks,

I've tried to address the items brought forward by Andreas and Todd.  Note that 
based on some feedback, some paragraphs were removed. Please let me know if you 
have any additional issues or concerns.

One that I don't see as resolved is the "Re ports" broken over two lines, and 
this appears to be an artifact of the xml2rfc process.  It looks fine in the 
XML and HTML, but broken in TXT.

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

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

Re: [dmarc-ietf] [EXTERNAL] Re: Aggregate Report Draft

[Brotman, Alex]

Thanks Barry.  I’ll do my best to address these and get a new version in the 
next week or so.

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

From: Barry Leiba 
Sent: Wednesday, September 27, 2023 4:20 PM
To: Brotman, Alex 
Cc: dmarc@ietf.org; Todd Herr 
Subject: [EXTERNAL] Re: [dmarc-ietf] Aggregate Report Draft

Thanks for that, Todd!

Alex, if you want to post a new revision before I start a WGLC, I'll wait for 
that.

Barry


On Wed, Sep 27, 2023 at 3:07 PM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
On Wed, Sep 20, 2023 at 3:56 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Hey folks,

It feels like we're sort of getting near the end of work on the core document 
(maybe that's the optimist speaking), so I thought I'd see if there are any 
known issues with the aggregate reporting draft [1].  I believe I had 
previously addressed or closed all tickets and addressed known concerns.  It's 
possible that some change to the main document has affected the reporting 
drafts in a way that hasn't yet been addressed.  If you believe that document 
has yet to address some concern you've noted, please let us know.  Thanks for 
your time

1: 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!H7ysDk7jfjDwMiQfRc4D1P6IYmg2u7NH4SW-ylA1VeuBfkqXRvRNkmxgwoZEvKLbH5Y-Me4KxSeuDOXbEH1-dxFdJA$>

My comments...

Section 2.1, Aggregate Reports, contains a bulleted list headed with "The 
report may include the following data:". The sixth bullet ("A separate report 
should be generated...") seems more narrative text than a description of a data 
item and is to me inconsistent with the rest of the items in this list. I would 
move the text from this bullet to a separate paragraph, either just after the 
list or to the "Handling Domains in Reports" section.

Section 2.1, Aggregate Reports, has a paragraph beginning with this text:

"DMARC Aggregate Reports MUST contain three primary sections; one

   consisting of descriptive information (with two subsections), and the

   other a set of IP-focused row-based data."


That reads to me as a description of two primary sections (descriptive 
information and IP-focused row-based data) not three, unless the two 
subsections are two of the three primary sections, but then if they are, they 
wouldn't be subsections.

Same section, next sentence, "Each report MUST contain data for only one Author 
Domain". This contradicts the "A separate report should be generated..." text 
from the bulleted list above, because that text allows for the possibility of 
multiple 5322.From domains to be included in a report. DMARC and DMARCbis 
define Author Domain as the 5322.From domain.

Pick one: subsections or sub-sections.

This sentence is clunky: "The date_range section which will note begin and end 
values as epoch timestamps." The phrasing is a little awkward, and it reads 
like it is one of the two sub-sections that the paragraph is describing. 
However, the next sentence starts with "The other sub-section..." so I guess 
that date_range isn't one of the two sub-sections?

Same section, in the auth_results discussion:

"The dkim sub-element is optional as

   not all messages are signed, while there MUST be one spf sub-element.

   These elements MUST have a domain that was used during validation, as

   well as result.  The dkim element MUST include a selector element

   that was observed during validation."


I would really like that second sentence to be strengthened to require that 
reports contain results of attempts to validate any DKIM signature that used a 
domain that aligned with the 5322.From, if any such signature(s) existed. As 
written now, a message could be double-signed, once with the From domain and 
once with a 3rd party domain (e.g., an ESP) and the report might only include 
the 3rd signature, at least as the text reads to me.

Section 2.1.1 Handling Domains in Reports - The first paragraph allows for 
multiple 5322.From domains in a report, but this contradicts the "Each report 
MUST contain data for only one Author Domain" mentioned above.

Section 2.1.2 DKIM Signatures in Aggregate Report seems to address the concern 
I raised earlier about the text in the auth_results section, so perhaps 
clarifying things in that section would be the best approach.

Section 2.1.3 contains a paragraph starting with NOTE that seems to be one that 
should be removed prior to publishing, and perhaps even prior to WGLC?

Section 2.6.1 - "a commonly observed receiver limit is ten megabytes" - Is this 
still true?

Section 2.6.1 - "ridtxt" is used twice (three times counting the "NOTE" 
paragraph above) before it

[dmarc-ietf] Aggregate Report Draft

[Brotman, Alex]

Hey folks,

It feels like we're sort of getting near the end of work on the core document 
(maybe that's the optimist speaking), so I thought I'd see if there are any 
known issues with the aggregate reporting draft [1].  I believe I had 
previously addressed or closed all tickets and addressed known concerns.  It's 
possible that some change to the main document has affected the reporting 
drafts in a way that hasn't yet been addressed.  If you believe that document 
has yet to address some concern you've noted, please let us know.  Thanks for 
your time

1: https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

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

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-12.txt

[Brotman, Alex]

I believe the only update from the prior revision are the ABNF alterations that 
Ale had noted after -11.

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Sunday, August 27, 2023 8:18 AM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-12.txt
> 
> Internet-Draft draft-ietf-dmarc-aggregate-reporting-12.txt is now available.
> It is a work item of the Domain-based Message Authentication, Reporting &
> Conformance (DMARC) WG of the IETF.
> 
>Title:   DMARC Aggregate Reporting
>Author:  Alex Brotman
>Name:draft-ietf-dmarc-aggregate-reporting-12.txt
>Pages:   28
>Dates:   2023-08-27
> 
> Abstract:
> 
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes RFC7489.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-reporting/__;!!CQl3mcHX2A!BQun3Eb2k07Y0QfZPc0Qfs7djf-
> e1FPqeaQ4GDpflCC3G2KZ-kaDitq3gcP_pf-XJWaszchgunQ1mqAOskK01aSxnP-
> FhrcYGtM$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-12.html__;!!CQl3mcHX2A!BQun3Eb2k07Y0QfZPc0Qfs7djf-
> e1FPqeaQ4GDpflCC3G2KZ-kaDitq3gcP_pf-XJWaszchgunQ1mqAOskK01aSxnP-
> FpS25apg$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-
> dmarc-aggregate-reporting-12__;!!CQl3mcHX2A!BQun3Eb2k07Y0QfZPc0Qfs7djf-
> e1FPqeaQ4GDpflCC3G2KZ-kaDitq3gcP_pf-XJWaszchgunQ1mqAOskK01aSxnP-
> FQvPd5tc$
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C
> Ql3mcHX2A!BQun3Eb2k07Y0QfZPc0Qfs7djf-e1FPqeaQ4GDpflCC3G2KZ-
> kaDitq3gcP_pf-XJWaszchgunQ1mqAOskK01aSxnP-FBhQSB7g$

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

Re: [dmarc-ietf] Another p=reject text proposal

[Brotman, Alex]

I suspect the portion that instructs receivers to not act solely on p=reject 
may be ignored by a fair set of receivers.  I'm not necessarily opposed to the 
language below, just that it seems odd to create language that we know will be 
ignored.  Additionally, I find it odd that we won't tell forwarders how to 
munge messages to avoid this situation, but we will tell receivers how to avoid 
this situation.

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

> -Original Message-
> From: dmarc  On Behalf Of Barry Leiba
> Sent: Thursday, July 6, 2023 10:55 AM
> To: IETF DMARC WG 
> Subject: [dmarc-ietf] Another p=reject text proposal
> 
> I had some off-list discussions with Seth, who was very much against my 
> original
> proposed text, and he suggested an alternative organization that would be more
> palatable to him.  I've attempted to set that out below.  The idea is to 
> remove the
> normative requirements about using p=reject from Sections 5.5.6 and 5.8, and
> instead put a broader discussion of the issues, along with the normative
> requirements, into a new "Interoperability Considerations" section.
> This makes it explicitly clear that any MUST/SHOULD stuff with regard to using
> and honoring p=reject is an issue of interoperating with existing Internet 
> email
> features.  I can accept that mechanism also, and so, below is my attempt at
> writing that proposal up.
> 
> Barry
> 
> -
> 
> — Section 5.5.6 —
> 
> ADD
>In making this decision it is important to understand the
>interoperability issues involved and problems that can result for
>mailing lists and for deliverability of legitimate mail. Those
>issues are discussed in detail in the Interoperability
>Considerations section [see Section x.x].
> END
> 
> — Section 5.8 —
> 
> OLD
>Mail Receivers MAY choose to accept email that fails the DMARC
>mechanism check even if the published Domain Owner Assessment Policy
>is "reject".  In particular, because of the considerations discussed
>in [RFC7960], it is important that Mail Receivers SHOULD NOT reject
>messages solely because of a published policy of "reject", but that
>they apply other knowledge and analysis to avoid situations such as
>rejection of legitimate messages sent in ways that DMARC cannot
>describe, harm to the operation of mailing lists, and similar.
> NEW
>Mail Receivers MAY choose to accept email that fails the DMARC
>mechanism check even if the published Domain Owner Assessment Policy
>is "reject".  In particular, because of the considerations discussed
>in [RFC7960] and in the Interoperability Considerations section of
>this document [see Section x.x], it is important that Mail Receivers
>not reject messages solely because of a published policy of "reject",
>but that they apply other knowledge and analysis to avoid situations
>such as rejection of legitimate messages sent in ways that DMARC
>cannot describe, harm to the operation of mailing lists, and similar.
> END
> 
> — New section —
> 
> ADD
> x.x Interoperability Considerations
> 
>As discussed in “Interoperability Issues between DMARC and Indirect
>Email Flows [RFC7960], use of p=reject can be incompatible with and
>cause interoperability problems to indirect message flows such as
>“alumni forwarders”, role-based email aliases, and mailing lists
>across the Internet.
> 
>Even a domain that expects to send only targeted messages to
>account holders — a bank, for example — could have account
>holders using addresses such as jo...@alumni.example.edu (an
>address that relays the messages to another address with a real
>mailbox) or finance@association.example (a role-based address that
>does similar relaying for the current head of finance at the
>association).  When such mail is delivered to the actual recipient
>mailbox, it will necessarily fail SPF checks, as the incoming
>IP address will be that of example.edu or association.example, and
>not an address authorized for the sending domain.  DKIM signatures
>will generally remain valid in these relay situations.
> 
>   It is therefore critical that domains that publish p=reject
>   MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures
>   to their messages.
> 
>Domains that have general users who send routine email are
>particularly likely to create interoperability issues if they
>publish p=reject.  For example, domains that serve as mailbox hosts
>and give out email addresses to the general public are best advised
>to delay adoption of p=reject until the authentication ecosystem
>becomes more mature and deliverability issues are better resolved.
> 
>In particular, if users in p=reject domains post messages to
>mailing lists on the Internet, those messages can cause operat

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-11.txt

[Brotman, Alex]

One other thing I forgot to note is that there are no longer any open "issues" 
attached to this document (in Github at least). 

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

> -Original Message-
> From: dmarc  On Behalf Of Brotman, Alex
> Sent: Tuesday, May 2, 2023 9:17 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: 
> draft-ietf-dmarc-aggregate-reporting-11.txt
> 
> That was the core of the change.  Also no longer malicious Domain Owner.
> Otherwise, whitespace changes.
> 
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> 
> > -Original Message-
> > From: dmarc  On Behalf Of Scott Kitterman
> > Sent: Tuesday, May 2, 2023 9:13 AM
> > To: dmarc@ietf.org
> > Subject: Re: [dmarc-ietf] I-D Action:
> > draft-ietf-dmarc-aggregate-reporting-11.txt
> >
> > On Tuesday, May 2, 2023 9:00:54 AM EDT internet-dra...@ietf.org wrote:
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories. This Internet-Draft is a work item of the Domain-based
> > > Message Authentication, Reporting & Conformance (DMARC) WG of the
> IETF.
> > >
> > >Title   : DMARC Aggregate Reporting
> > >Author  : Alex Brotman
> > >Filename: draft-ietf-dmarc-aggregate-reporting-11.txt
> > >Pages   : 28
> > >Date: 2023-05-02
> >
> > Thanks.  That addresses my concern on secure transport.
> >
> > Scott K
> >
> >
> > ___
> > dmarc mailing list
> > dmarc@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> > !CQl3mcHX2A!EVHempAvJBk_QAlcebKNXkKR3TxBTXjPbqp5v1WryuN-
> > UpiIuadje3GfqH6rXvaqxQuTm_FiUgjoei_bW3q7$
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!F6LeonWWL2W0J8Pk2Uv4-
> pWZjQRY1OplHu4qBbgSG8_zFwJKa8jVvsw0IkxFjeYpqSIc6iLgOlHiULZB_QdbtVW9
> nGjmQdITSSsblwBd$

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-11.txt

[Brotman, Alex]

That was the core of the change.  Also no longer malicious Domain Owner.  
Otherwise, whitespace changes.

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, May 2, 2023 9:13 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: 
> draft-ietf-dmarc-aggregate-reporting-11.txt
> 
> On Tuesday, May 2, 2023 9:00:54 AM EDT internet-dra...@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This Internet-Draft is a work item of the Domain-based
> > Message Authentication, Reporting & Conformance (DMARC) WG of the IETF.
> >
> >Title   : DMARC Aggregate Reporting
> >Author  : Alex Brotman
> >Filename: draft-ietf-dmarc-aggregate-reporting-11.txt
> >Pages   : 28
> >Date: 2023-05-02
> 
> Thanks.  That addresses my concern on secure transport.
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!EVHempAvJBk_QAlcebKNXkKR3TxBTXjPbqp5v1WryuN-
> UpiIuadje3GfqH6rXvaqxQuTm_FiUgjoei_bW3q7$

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

Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to DMARCbis

[Brotman, Alex]

This sounds like a separate document to me. (yes, I see Ale's draft below) And 
IMO, I don't think we should hold up DMARCbis for that work.

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

> -Original Message-
> From: dmarc  On Behalf Of Hector Santos
> Sent: Monday, May 1, 2023 9:26 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Add MLS/MLM subscription/submissions controls to
> DMARCbis
> 
> On 5/1/2023 6:51 AM, Alessandro Vesely wrote:
> >
> > Been there, done that.  For the message I'm replying to, I have:
> >
> > Authentication-Results: wmail.tana.it;
> >   spf=pass smtp.mailfrom=ietf.org;
> >   dkim=pass reason="Original-From: transformed" header.d=google.com;
> >   dkim=pass (whitelisted) header.d=ietf.org
> > header.b=jAsjjtsp (ietf1);
> >   dkim=fail (signature verification failed, whitelisted)
> > header.d=ietf.org
> > header.b=QuwLQGvz (ietf1)
> >
> > However, not all signatures can be verified.  Mailman tries and
> > preserve most header fields, but not all.  For example, they rewrite
> > MIME-Version: from scratch and don't save the old one.  So if a poster
> > signs that field and writes it differently (e.g. with a
> > comment) MLM transformation cannot be undone.
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draf
> > t-vesely-dmarc-mlm-transform__;!!CQl3mcHX2A!DfPhD9QIFk5QZaU-
> JPkz748sZC
> >
> QtLXqL1FIxGonW_xDwc9pXdioEnY546GZUnzjzSNW1BdDF27VjLabqZaB5XtMgrS
> WZ9HPP
> > m2s$
> >
> 
> And this was my result for your message, separating lines for easier
> reading:
> 
> Authentication-Results: dkim.winserver.com;
>   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
>   adsp=none author.d=tana.it signer.d=ietf.org;
>   dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
> signer);
> 
>   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
>   adsp=none author.d=tana.it signer.d=ietf.org;
>   dmarc=fail policy=none author.d=tana.it signer.d=ietf.org (unauthorized
> signer);
> 
>   dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
>   adsp=dkim-fail author.d=tana.it signer.d=;
>   dmarc=dkim-fail policy=none author.d=tana.it signer.d= (unauthorized 
> signer);
> 
>   dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=tana.it header.s=delta
> header.i=tana.it;
>adsp=dkim-fail author.d=tana.it signer.d=tana.it;
>dmarc=dkim-fail policy=none author.d=tana.it signer.d=tana.it
> (originating signer);
> 
> Four signatures were added to your submission and the only one that counts is
> the top one, the last one added.
> 
> It failed DMARC because tana.it did not authorized ietf.org.   You can
> easily resolve this by adding atps=y to your DMARC record:
> 
>  v=DMARC1; p=none; atps=y; rua=mailto:dmarca...@tana.it;
> ruf=mailto:dmarcf...@tana.it;
> 
> and add an ATPS sub-domain record authorizing ietf.org in your dana.it
> zone:
> 
>  pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;")
> 
> Do that and all ATPS compliant verifiers should show a DMARC=pass:
> 
> Authentication-Results: dkim.winserver.com;
>   dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
>   adsp=none author.d=tana.it signer.d=ietf.org;
>   dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ATPS signer);
> 
> 
> For a short list of signers, I updated my DMARC evaluator to also support ASL
> "Authorized Signer List" to avoid the extra ATPS record.
> So doing this will work across my evaluator for smaller scale mail senders
> 
>  v=DMARC1; p=none; atps=y; asl=ietf.org; rua=mailto:dmarca...@tana.it;
> ruf=mailto:dmarcf...@tana.it;
> 
> 
> This will skip atps=y because asl=ietf.org was satisfied. It was show
> how it was authorized:
> 
>   dmarc=pass policy=none author.d=tana.it signer.d=ietf.org (ASL signer);
> 
> 
> Any ATPS or ASL idea will give us the author-defined trust of ietf.org
> as a 3rd party signer.
> 
> That said,  keeping with the suggestion DMARCBis should add MLS/MLM
> semantics, I believe when the Receiver is receiving mail for a
> MLS/MLM,  it should have the following updated modern consideration
> for a MLS/MLM:
> 
> 1) It should honor policy first, by check for restrictive domains
> 
> 2) It should honor the domain restrictive policy to avoid creating new
> security problems and avoid delivery problems.  This means to
> implement subscription and submission controls.  DMARCbis should pass
> the buck back to the restrictive domain who must deal with user's
> needs or not.
> 
> 3) It should check if the submission's author domain authorizes the
> MLM signing domain by finding a ATPS record, if so
> 
> 3.1) it can continue as the 3rd party signer and also keep the From as
> is, unchanged, or
> 
> 3.2) it can also consider to rewrite.  If rewrite is performed, the
> signing domain should have a security that does not allow any Display
> Attack Replays with the now altered 5322.From identity.
> 
> 
> --
> Hector Santos,
> https://u

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Brotman, Alex]

You just want:

   Where the URI specified in a "rua" tag does not specify otherwise, a
   Mail Receiver generating a feedback report SHOULD employ a secure
   transport mechanism.

Restored in some useful place?

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Thursday, April 27, 2023 10:26 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: 
> draft-ietf-dmarc-aggregate-reporting-10.txt
> 
> I think that the original wording, which is technology agnostic, is better.  
> As you
> suggest, there are multiple ways to address the requirement and being overly
> specific will not age well.
> 
> Scott K
> 
> On April 27, 2023 2:11:17 PM UTC, "Brotman, Alex"
>  wrote:
> >In summary:
> >
> >“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all
> receivers.  Transmitting these reports via a secured session is preferrable.”
> >
> >I don’t think we should add this in, but receivers could deploy DANE/MTA-STS 
> >if
> they wanted to ensure senders who honor those will use TLS.
> >
> >
> >--
> >Alex Brotman
> >Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> >
> >From: dmarc  On Behalf Of Hector Santos
> >Sent: Wednesday, April 26, 2023 4:29 PM
> >To: Scott Kitterman 
> >Cc: IETF DMARC WG 
> >Subject: Re: [dmarc-ietf] I-D Action:
> >draft-ietf-dmarc-aggregate-reporting-10.txt
> >
> >
> >
> >
> >On Apr 26, 2023, at 3:50 PM, Scott Kitterman
> mailto:skl...@kitterman.com>> wrote:
> >
> >I think it would be crazy in 2023 not to use STARTTLS is offered.
> >
> >+1
> >
> >
> >Personally I interpreted it more as employ a secure transport and think 
> >through
> if you really want to be sending the report if you can't.
> >
> >I think there's some room for interpretation and I think that's fine.
> >
> >I believe connectivity is independent of the application.
> >
> >All connections SHOULD assume the highest possible security available today.
> >
> >For unsolicited email, the presumption would be:
> >
> >Port 25
> >STARTTLS
> >
> >If I was start performing reports (and I think I will), that is how I would 
> >begin,
> naturally, with outbound SMTP clients with optional TLS if offered.
> >
> >Sorry if I was not focused with the main question,
> >
> >—
> >HLS
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!AVsdi1d3H3sasZaM8-wu8vjzqXURKE-7ScPmC46NRIUY1Bm-
> BCM87bHXhlrobfn5hRcqTP-Q-joOqGmXiPi-$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

Attempt to make it a tad more concise (I think), altering some of the language:

-
There can be inherent damage to the ability to use certain SMTP-based systems 
in conjunction with a policy of quarantine or reject.  These could include, 
though are not limited to, mailing lists, forwarding services, and other types 
of indirect mail flows.  Especially in situations where the sending domain is 
SPF-only, or the intermediary is known to alter messages.  If the users of the 
domain may utilize these types of systems, the domain administrator MUST NOT 
deploy a policy of quarantine or reject without serious considerations to the 
impact to interoperability.  These considerations will be informed by careful 
analysis of DMARC aggregate reports prior to deploying such a policy.  Some 
third-party systems may be willing to create a workaround for these situations, 
though it cannot be guaranteed.  Domain owners MAY choose to create a 
sub-domain (listmail.example.org) or cousin domain (listmail-example.org) which 
uses a different policy for users wishing to utilize those services.
-

If you're looking for me, I'm standing behind the firewall. 

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Thursday, April 27, 2023 1:07 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Search for some consensus, was: Proposed text for
> p=reject and indirect mail flows
> 
> 
> 
> On April 27, 2023 2:32:49 AM UTC, Jim Fenton 
> wrote:
> >On 26 Apr 2023, at 9:06, John Levine wrote:
> >
> >> It seems to me there are two somewhat different kinds of DMARC
> >> damange that we might separate. One is what happens on discussion
> >> lists, where messages get lost and in the process unrelated
> >> recipients get unsubscribed. The other is simple forwarding and
> >> send-to-a-friend which gets lost but is less likely to cause problems
> >> for the recipients beyond not getting the mail they want.
> >
> >Isn’t (in the latter case) the recipients not getting the mail they want 
> >exactly an
> interoperability problem?
> 
> It absolutely is.  The difference, my view, is that if the domain owner has a 
> policy
> that leads to you not getting your mail, it's a different level of severity 
> than you
> both don't get your mail and end up unsubscribed from the mailing list.
> 
> One might make a case that the former is "works as designed" since the sending
> domain owner has published policy indicating he doesn't want you to get your
> mail and your mail host has decided to honor that request (I think that's 
> wrong,
> but I can see the logic).  I don't think there's any way to claim third 
> party's
> getting bounced from a mailing list is OK.
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!HIiPwxlibmp0jYdSD3ap2XsLrLB28EJJ-xUe-
> XVECMs6n5re7eRqcuXfev2ioFKD8ouqGUsAw9o76AycuD29$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Brotman, Alex]

In summary:

“Report senders SHOULD attempt delivery via SMTP using STARTTLS to all 
receivers.  Transmitting these reports via a secured session is preferrable.”

I don’t think we should add this in, but receivers could deploy DANE/MTA-STS if 
they wanted to ensure senders who honor those will use TLS.


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

From: dmarc  On Behalf Of Hector Santos
Sent: Wednesday, April 26, 2023 4:29 PM
To: Scott Kitterman 
Cc: IETF DMARC WG 
Subject: Re: [dmarc-ietf] I-D Action: 
draft-ietf-dmarc-aggregate-reporting-10.txt




On Apr 26, 2023, at 3:50 PM, Scott Kitterman 
mailto:skl...@kitterman.com>> wrote:

I think it would be crazy in 2023 not to use STARTTLS is offered.

+1


Personally I interpreted it more as employ a secure transport and think through 
if you really want to be sending the report if you can't.

I think there's some room for interpretation and I think that's fine.

I believe connectivity is independent of the application.

All connections SHOULD assume the highest possible security available today.

For unsolicited email, the presumption would be:

Port 25
STARTTLS

If I was start performing reports (and I think I will), that is how I would 
begin, naturally, with outbound SMTP clients with optional TLS if offered.

Sorry if I was not focused with the main question,

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

[Brotman, Alex]

These should be the updates from the last two days or so. (except John's 
s/malicious//, already altered for next run)

I found a few more places where the mmark/xml2rfc process was creating some 
improper output, I believe all for the "_report._dmarc" bits.

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Tuesday, April 25, 2023 9:41 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This Internet-Draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance (DMARC) WG of the IETF.
> 
>Title   : DMARC Aggregate Reporting
>Author  : Alex Brotman
>Filename: draft-ietf-dmarc-aggregate-reporting-10.txt
>Pages   : 28
>Date: 2023-04-25
> 
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes RFC7489.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!AUTgUGRe7di45Svh_jN7XZhnryGPgrFQpP4mdx6tD
> wFMl2YKIR4sjQUTIMW2ewQJblqMf3vix5bJDc8e936Uj9eizefnNIbRg3g$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-
> 10.html__;!!CQl3mcHX2A!AUTgUGRe7di45Svh_jN7XZhnryGPgrFQpP4mdx6tDwF
> Ml2YKIR4sjQUTIMW2ewQJblqMf3vix5bJDc8e936Uj9eizefn87iG1vQ$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-
> ietf-dmarc-aggregate-reporting-
> 10__;!!CQl3mcHX2A!AUTgUGRe7di45Svh_jN7XZhnryGPgrFQpP4mdx6tDwFMl2Y
> KIR4sjQUTIMW2ewQJblqMf3vix5bJDc8e936Uj9eizefn_4PgulM$
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!AUTgUGRe7di45Svh_jN7XZhnryGPgrFQpP4mdx6tDwFMl2YKIR4sj
> QUTIMW2ewQJblqMf3vix5bJDc8e936Uj9eizefnZV79dXg$

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

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Brotman, Alex]

I'm not disagreeing with the idea below, just that by omitting this in the 
draft, we could leave it open to interpretation that it *always* will be a 
privacy violation.  This could justify decisions by some receivers to decline 
to send reports.

Otherwise, I'll remove 6.3.

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, April 25, 2023 1:14 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-
> aggregate-reporting-09.txt
> 
> Assuming for a moment that single user domains can't have a privacy violation
> (I'm not sure I agree), how about a two person domain?  Three?  Unless it's
> impossible to have a report that contains personal information, mail receivers
> (report senders) absolutely can't rely on the assertion in question since 
> they have
> no way of knowing.
> 
> This is a pointless rabbit hole.  Let's not go down it.
> 
> Scott K
> 
> On April 25, 2023 4:58:26 PM UTC, Alessandro Vesely  wrote:
> >John is not alone, I too can recognize single posts.  However, I'd argue 
> >that in
> such cases there is no privacy violation.  You violate privacy when you 
> collect
> personal data of (several) people *different from yourself*.
> >
> >Best
> >Ale
> >
> >
> >On Tue 25/Apr/2023 18:36:34 +0200 Scott Kitterman wrote:
> >> My suggestion is delete all of it.  It's accurate for some cases, not for 
> >> others.
> If you want to keep any of it, I think it needs to be properly caveated.  I 
> expect
> that would be a Sisyphean task that's not worth the effort.
> >>
> >> Scott K
> >>
> >> On April 25, 2023 2:54:46 PM UTC, "Brotman, Alex"
>  wrote:
> >>>> As explained in 6.1, that's not actually true if the domains are small
> enuogh.
> >>>> In some of my tiny domains I can often recognize individual
> >>>> messages I've sent.  I'd just delete these sentences.
> >>>
> >>> I'd argue that you're in a (mostly) unique situation where you're the 
> >>> sender
> and the report reviewer.  That being said, would you prefer I remove all of 
> 6.3?
> Does the remaining sentence have enough value to keep? Or sweep it up to 6.1?
> >>>
> >>> --
> >>> Alex Brotman
> >>> Sr. Engineer, Anti-Abuse & Messaging Policy Comcast
> >>>
> >>>> -Original Message-
> >>>> From: John R. Levine 
> >>>> Sent: Monday, April 24, 2023 10:18 PM
> >>>> To: Brotman, Alex ; dmarc@ietf.org
> >>>> Subject: [EXTERNAL] Re: [dmarc-ietf] I-D Action:
> >>>> draft-ietf-dmarc-aggregate- reporting-09.txt
> >>>>
> >>>> > I removed the small section that faced objections.
> >>>> >
> >>>> > I updated the ridtxt definition and discovered that mmark was
> >>>> > making a
> >>>> mess of those asterisks.  When there are more than one/some on a
> >>>> single line, it believes you would like some subset to be defined as 
> >>>> ""
> things.
> >>>>
> >>>> Looks pretty good.  Minor points:
> >>>>
> >>>> The first paragraph in 2.6 says:
> >>>>
> >>>>  Where the URI specified in a "rua" tag does not specify otherwise, a
> >>>>  Mail Receiver generating a feedback report SHOULD employ a secure
> >>>>  transport mechanism.
> >>>>
> >>>> Since the only mechanism is mail and nobody's going to S/MIME
> >>>> encrypt their reports, I suggest just deleting it.
> >>>>
> >>>> 6.3:
> >>>>
> >>>>  Mail Receivers should have no concerns in sending reports as they do
> >>>>  not contain personal information.  ...
> >>>>
> >>>>  Domain Owners should have no concerns in receiving reports as they 
> >>>> do
> >>>>  not contain personal information.
> >>>>
> >>>> As explained in 6.1, that's not actually true if the domains are small
> enuogh.
> >>>> In some of my tiny domains I can often recognize individual
> >>>> messages I've sent.  I'd just delete these sentences.
> >>>>
> >>>> R's,
> >>>> John
> >

Re: [dmarc-ietf] [EXTERNAL] Re: I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Brotman, Alex]

> As explained in 6.1, that's not actually true if the domains are small enuogh.
> In some of my tiny domains I can often recognize individual messages I've
> sent.  I'd just delete these sentences.

I'd argue that you're in a (mostly) unique situation where you're the sender 
and the report reviewer.  That being said, would you prefer I remove all of 
6.3?  Does the remaining sentence have enough value to keep? Or sweep it up to 
6.1?

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

> -Original Message-
> From: John R. Levine 
> Sent: Monday, April 24, 2023 10:18 PM
> To: Brotman, Alex ; dmarc@ietf.org
> Subject: [EXTERNAL] Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-
> reporting-09.txt
> 
> > I removed the small section that faced objections.
> >
> > I updated the ridtxt definition and discovered that mmark was making a
> mess of those asterisks.  When there are more than one/some on a single
> line, it believes you would like some subset to be defined as "" things.
> 
> Looks pretty good.  Minor points:
> 
> The first paragraph in 2.6 says:
> 
>  Where the URI specified in a "rua" tag does not specify otherwise, a
>  Mail Receiver generating a feedback report SHOULD employ a secure
>  transport mechanism.
> 
> Since the only mechanism is mail and nobody's going to S/MIME encrypt their
> reports, I suggest just deleting it.
> 
> 6.3:
> 
>  Mail Receivers should have no concerns in sending reports as they do
>  not contain personal information.  ...
> 
>  Domain Owners should have no concerns in receiving reports as they do
>  not contain personal information.
> 
> As explained in 6.1, that's not actually true if the domains are small enuogh.
> In some of my tiny domains I can often recognize individual messages I've
> sent.  I'd just delete these sentences.
> 
> R's,
> John
> 
> 
> >> -Original Message-
> >> From: dmarc  On Behalf Of
> >> internet-dra...@ietf.org
> >> Sent: Monday, April 24, 2023 7:39 PM
> >> To: i-d-annou...@ietf.org
> >> Cc: dmarc@ietf.org
> >> Subject: [dmarc-ietf] I-D Action:
> >> draft-ietf-dmarc-aggregate-reporting-09.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >> This Internet-Draft is a work item of the Domain-based Message
> >> Authentication, Reporting & Conformance (DMARC) WG of the IETF.
> >>
> >>Title   : DMARC Aggregate Reporting
> >>Author  : Alex Brotman
> >>Filename: draft-ietf-dmarc-aggregate-reporting-09.txt
> >>Pages   : 28
> >>Date: 2023-04-24
> >>
> >> Abstract:
> >>DMARC allows for domain holders to request aggregate reports from
> >>receivers.  This report is an XML document, and contains extensible
> >>elements that allow for other types of data to be specified later.
> >>The aggregate reports can be submitted to the domain holder's
> >>specified destination as supported by the receiver.
> >>
> >>This document (along with others) obsoletes RFC7489.
> >>
> >> The IETF datatracker status page for this Internet-Draft is:
> >> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ie
> >> tf-dmarc-
> >> aggregate-
> >>
> reporting/__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVy
> qsr7
> >> nLWuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqF46TKSvg$
> >>
> >> There is also an HTML version available at:
> >> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-iet
> >> f-dmarc-
> >> aggregate-reporting-
> >>
> 09.html__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr
> 7nL
> >> WuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEqNRr1SA$
> >>
> >> A diff from the previous version is available at:
> >> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2
> >> =draft-
> >> ietf-dmarc-aggregate-reporting-
> >>
> 09__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLW
> uC
> >> bVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqFdWqTU2g$
> >>
> >> Internet-Drafts are also available by rsync at
> >> rsync.ietf.org::internet-drafts
> >>
> >>
> >> ___
> >> dmarc mailing list
> >> dmarc@ietf.org
> >>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!
> >>
> !CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuCbV
> wCD
> >> o_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEDBiM7_A$
> >
> >
> 
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for
> Dummies", Please consider the environment before reading this e-mail.  href="https://urldefense.com/v3/__https://jl.ly__;!!CQl3mcHX2A!Fpku2qYC
> TuZKAA4K08a9mXXHN3ECaWvI28GCiy40HeEi8kyMh5bKjQWeT7UFbqsfeN5N
> v88e0Nj1WqU$">https://jl.ly

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

[Brotman, Alex]

I removed the small section that faced objections.

I updated the ridtxt definition and discovered that mmark was making a mess of 
those asterisks.  When there are more than one/some on a single line, it 
believes you would like some subset to be defined as "" things.  

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Monday, April 24, 2023 7:39 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This Internet-Draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance (DMARC) WG of the IETF.
> 
>Title   : DMARC Aggregate Reporting
>Author  : Alex Brotman
>Filename: draft-ietf-dmarc-aggregate-reporting-09.txt
>Pages   : 28
>Date: 2023-04-24
> 
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes RFC7489.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7
> nLWuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqF46TKSvg$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-
> 09.html__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nL
> WuCbVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEqNRr1SA$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-
> ietf-dmarc-aggregate-reporting-
> 09__;!!CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuC
> bVwCDo_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqFdWqTU2g$
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!HBzOZHijNkg7AyDQnUKsIyEGZaJcT2dIFMGNVyqsr7nLWuCbVwCD
> o_mqKdBpLG2eSmAWmSaOYcZxRLwpzMl1GqEDBiM7_A$

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

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

[Brotman, Alex]

I’ve talked about this before.  I ran into a utility company that I conversed 
with that explicitly didn’t want to use DKIM because they felt their messages 
should not be forwarded to another provider.  I didn’t quite understand the 
logic, but it was their decision.

I definitely favor some language that endorses using both and perhaps even 
outlines the pitfalls of using only one (can’t forward, both gives you a better 
chance of success, etc)

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

From: dmarc  On Behalf Of Barry Leiba
Sent: Thursday, April 13, 2023 12:44 PM
To: Dotzero 
Cc: Todd Herr ; John Levine ; 
dmarc@ietf.org; superu...@gmail.com
Subject: Re: [dmarc-ietf] Signaling forwarders, not just MLMs

We can say that as well, but I want to specifically say "don't use SPF without 
DKIM and expect it to work right;"

b


On Thu, Apr 13, 2023 at 12:41 PM Dotzero 
mailto:dotz...@gmail.com>> wrote:


On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
Maybe just add a sentence to the end of the second paragraph:

   The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED.

Barry

I think the opposite. Something along the lines of "Sending domains SHOULD 
implement both SPF and DKIM to minimize breakage and non-delivery of mail.

Michael Hammer



On Thu, Apr 13, 2023 at 12:04 PM Todd Herr 
mailto:todd.h...@valimail.com>> wrote:
On Thu, Apr 13, 2023 at 11:21 AM Barry Leiba 
mailto:barryle...@computer.org>> wrote:
> Anyone who does forwarding is damaged by DMARC because there are a lot of
> people who do DMARC on the cheap with SPF only.

This brings up another issue, I think: that there should also be
stronger advice that using DKIM is critical to DMARC reliability, and
using SPF only, without DKIM, is strongly NOT RECOMMENDED.
I don't disagree.

How do we make the following text stronger?
5.5.2. 

 Configure Sending System for DKIM Signing Using an Aligned 
Domain

While it is possible to secure a DMARC pass verdict based on only one of SPF or 
DKIM, it is commonly accepted best practice to ensure that both authentication 
mechanisms are in place to guard against failure of just one of them.

This is particularly important because SPF will always fail in situations where 
mail is sent to a forwarding address offered by a professional society, school 
or other institution, where the address simply relays the message to the 
recipient's current "real" address. Many recipients use such addresses and with 
SPF alone and not DKIM, messages sent to such users will always produce DMARC 
fail.

The Domain Owner SHOULD choose a DKIM-Signing domain (i.e., the d= domain in 
the DKIM-Signature header) that aligns with the Author Domain.


--
Todd Herr | Technical Director, Standards and Ecosystem
e: todd.h...@valimail.com
m: 703.220.4153

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
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] Example of Indirect Mail Flow Breakage with p=reject?

[Brotman, Alex]

> That's the sort of thing I proposed, and which some participants here are
> objecting to.  I continue not to understand the objection to clear language 
> that
> says that if you do  under  conditions, it will cause problems, 
> so
> don't do .  I don't buy the idea that saying "don't do " when we 
> know
> that some deployers will ignore that makes us look out of touch with reality, 
> but
> that *not* saying that is better (when that already *has* given DMARC a bad
> name in the wider Internet community).

I don’t think folks are objecting to cautionary language.  I think folks are 
objecting to a blanket MUST NOT.  If we're going to qualify the MUST NOT with a 
bunch of language, that's a bit different.   The original proposal was: "To be 
explicitly clear: domains used for general-purpose email MUST NOT deploy a 
DMARC policy of p=reject."  I'm still fuzzy on what constitutes general 
purpose, or perhaps more accurately when p=reject is acceptable?  Is it 
acceptable to use p=quarantine in those cases?  If a domain (such as 
comcast.com) decides p=reject is what they really want .. then what? (I know, 
we're not the protocol police..)

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

> -----Original Message-
> From: Barry Leiba 
> Sent: Thursday, April 13, 2023 12:34 PM
> To: Brotman, Alex 
> Cc: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
> p=reject?
> 
> > I think we all understand the inconvenience that DMARC can cause to a
> > subset of domains, or more accurately its users.
> 
> The problem here that we're describing as an interoperability issue is not 
> that
> DMARC causes problems for the users of domains that choose to use p=reject --
> that would be the domain's problem -- but that it causes cascading problems 
> for
> the users of *other* domains.  That makes it more than an inconvenience.
> 
> > 8996 has a section
> > about operational considerations, and discusses the impact of
> > systems/users that do not support TLSv1.2 and how it will break
> > interoperability.  Can we not do similar in DMARCbis with a more
> > lengthy section about the implications of "reject"?  Perhaps even
> > expand it to cover the use cases of each policy type, and the
> > implications of each?
> 
> That's the sort of thing I proposed, and which some participants here are
> objecting to.  I continue not to understand the objection to clear language 
> that
> says that if you do  under  conditions, it will cause problems, 
> so
> don't do .  I don't buy the idea that saying "don't do " when we 
> know
> that some deployers will ignore that makes us look out of touch with reality, 
> but
> that *not* saying that is better (when that already *has* given DMARC a bad
> name in the wider Internet community).
> 
> Barry
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Brotman, Alex]

In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and the 
website signs records via DNSSEC.  The website I want to go to breaks their 
DNSSEC.  My ISP cannot retrieve a record to return to my browser that can be 
used.  A is the browser, B is the website, C is the ISP DNS platform.

I understand your point, though I think mine still has reasonable merit.  I 
understand the charter is to resolve the interoperability between indirect mail 
and p=reject.  I’m just not sure I see an intersection of “fix indirect email” 
and “p=reject”.

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

From: Murray S. Kucherawy 
Sent: Wednesday, April 12, 2023 9:51 AM
To: Brotman, Alex 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 6:31 AM Murray S. Kucherawy 
mailto:superu...@gmail.com>> wrote:
To my mind, there's a substantial difference between something like TLSv1 or 
HTTP whose deprecation excludes you from participating in something until you 
upgrade, versus the DMARC situation where because of an unfortunate interaction 
between A (e.g., me) and B (e.g., you) through intermediary C (e.g., this 
list), D (e.g., someone else) is negatively impacted.

Sorry, that's not quite right: You don't need "D"; if "A" sets a policy and "B" 
generally enforces anyone's policies, "B" will be impacted by messages from "A" 
transiting "C".

I think your analogy would be more apt of "C" simply refused to accept anything 
from "A", or refused to let "B" subscribe.  But that doesn't seem to be the 
kind of mitigation on which we've settled.  And there's no way for "C" to know 
that "B" is enforcing until it's seen a bounce.  And "C" would need to be sure 
about the reason for the bounce.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

[Brotman, Alex]

There is a non-zero set of cases where the IETF prefers security over 
interoperability.   A document like RFC8997/8996 where we've deprecated TLSv1 
in because it was no longer secure. I assure you there are still systems/users 
who have devices incapable of TLSv1.2.  DNSSEC (and things that depend on it) 
can break in "mysterious" ways (specific to DNSSEC) that impact 
interoperability, but sites do so in the in the name of security.

I think we all understand the inconvenience that DMARC can cause to a subset of 
domains, or more accurately its users.  8996 has a section about operational 
considerations, and discusses the impact of systems/users that do not support 
TLSv1.2 and how it will break interoperability.  Can we not do similar in 
DMARCbis with a more lengthy section about the implications of "reject"?  
Perhaps even expand it to cover the use cases of each policy type, and the 
implications of each?  

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, April 11, 2023 11:50 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with 
> p=reject?
> 
> 
> 
> On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz  tech@dmarc.ietf.org> wrote:
> >
> >
> >> On Apr 8, 2023, at 6:56 AM, John Levine  wrote:
> >>
> >> We're never going to persuade DMARC absolutists that the damage is
> >> real, nor the rest of us that we can wave our hands and ignore the damage.
> >
> >John, the damage is real. There’s no doubt about that. Trade offs, painful 
> >trade
> offs, have to be made and I’m sure this isn’t the first WG to face trade offs 
> and
> have to make hard decisions or not.
> >
> >If DMARC can protect domains from spoofing which I believe ends up costing
> over $14 billion per year. Forget about the $14 billion and think how this 
> crime
> spree affects people’s view of one of the last remnants of the free internet. 
> It’s
> a fiasco on so many levels. If you have the tools to make a real difference 
> and I
> can say from first hand experience DMARC has helped people’s financial and
> mental health.
> >
> >The standard and the document should reflect that it’s already making a
> massive difference and could do even more. I don’t think it’s unreasonable to
> expect ml managers to adapt. If cyber crime was street crime people would be
> panicking in the streets.
> >
> You can leave the marketing text aside.  We know.
> 
> The purpose of IETF specifications is to promote interoperability.  For good
> reason, they tend to mostly document reality, not drive it.
> 
> The implication of your approach is we punt to experimental because it's
> currently impossible to document an interoperable protocol that works for
> normal email use cases until the indirect mail flow questions are sorted 
> (they are
> not fully understood yet - ARC is experimental for a reason).  Or maybe the
> working group just shuts down.
> 
> Alternately we keep this on the standards track with a statement along the 
> lines
> of [some appropriate description] domains MUST NOT publish restrictive
> DMARC policies due to interoperability issues.  Then the community works on
> making it easier for domains not to fit [some appropriate description] so it's
> reasonable for them to move to a restrictive policy.
> 
> I believe there's a way to get there on the specifics of the language, if we 
> work
> on it.  I have yet to hear any kind of interest in trying to work something 
> out
> from the anti-interoperability crowd.  More people showing up to opine about
> cyber isn't going to get us there.
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!GooL5z7r6yyYuhFHHRpgovAgUdqy_1ApVEhmyKC1MGY-
> i_qh2X2DY-sNSspGx-Toul9a1rsnu7xwgdQ_V-ZOejFhscE$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

I’m just not sure how we determine what is high-value.

comcast.com: p=reject
comcast.net: p=none
xfinity.com: p=quarantine

The top one is corporate, middle is consumer, bottom is consumer (but not 
actually used) & customer comms (sub-domains).  They’re all used in various 
ways for internal messaging.  Should I tell our corporate admins that they need 
to no longer publish p=reject?  They’re violating the RFC by doing so?  There 
are very few consumer-oriented messages that originate from comcast.com.  Are 
we doing it right?  It makes things a little harder when one of our employees 
wants to use a mailing list.  But that still feels like the right thing to do.

If it’s not obvious, I’m having a hard time with “MUST NOT”, and dictating to 
domain owners what is in their best interests, regardless of our perceived 
value of their domain.

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

From: dmarc  On Behalf Of Barry Leiba
Sent: Wednesday, March 29, 2023 10:15 AM
To: Todd Herr 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

I'm very much against text such as this, as I think it encourages deployments 
that are contrary to interoperability and to the intent of p=reject.

I contend that p=reject (as with the similar construct in the older ADSP) was 
intended for high-value domains and transactional mail, and that it was never 
intended for use in domains where general users send general email.

I stand by the MUST NOT that I proposed.

Barry


On Wed, Mar 29, 2023 at 10:33 PM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
On Tue, Mar 28, 2023 at 9:06 PM Pete Resnick 
mailto:resn...@episteme.net>> wrote:

If you agree that interoperability is increased, then I'd suggest that you 
actually do agree that the proposed text is appropriate.


I don't know that I agree that interoperability is increased...

I'm having trouble squaring proposed language that says "Domain owners MUST NOT 
publish p=reject because it breaks interoperability" with the following 
language from section 5.8:


Mail Receivers **MAY** choose to accept email that fails the DMARC

mechanism check even if the published Domain Owner Assessment Policy

is "reject". In particular, because of the considerations discussed

in [@!RFC7960], it is important that Mail Receivers **SHOULD NOT** reject

messages solely because of a published policy of "reject", but that

they apply other knowledge and analysis to avoid situations such as

rejection of legitimate messages sent in ways that DMARC cannot
describe, harm to the operation of mailing lists, and similar.

It seems inconsistent to state with certainty that authorized mail will be 
rejected due to authentication breakage when there is no requirement that a 
reject policy be honored (and we have plenty of evidence that Mail Receivers 
are following the 'SHOULD NOT reject messages' guidance).

Language that would be more consistent in guidance to the domain owners might 
look something like this:

After careful analysis of the aggregate report data as described in section 
5.5.5
(Collect and Analyze Reports), Domain Owners **MAY** choose to change their
policy from 'none' to 'quarantine' or 'reject'. If, in the Domain Owner's 
judgement,
unauthorized and deceptive use of its domain name in the RFC5322.From field puts
at risk the trust it has built with its recipients, then it is **RECOMMENDED** 
that
the Domain Owner make use of the p and/or sp tags to set policy to 'quarantine' 
or
'reject' for those streams most at risk of loss of trust.

If going that route, probably want to consider expanding on 5.5.5, too; I need 
to think about it some more.

--
Todd Herr | Technical Director, Standards and Ecosystem
e: todd.h...@valimail.com
m: 703.220.4153

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
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] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

There may need to be a bit more clarification around the use of sp= in these 
cases.  "We are telling you that p=reject is harmful, but sp=q/r is acceptable 
in many cases, where these conditions are satisfied".



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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 4:01 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> On Tuesday, March 28, 2023 3:14:38 PM EDT Todd Herr wrote:
> > On Tue, Mar 28, 2023 at 1:41 PM Scott Kitterman 
> >
> > wrote:
> > > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote:
> > > > NEW
> > > >
> > > >5.5.6.  Decide If and When to Update DMARC Policy
> > > >
> > > >Once the Domain Owner is satisfied that it is properly authenticating
> > > >all of its mail, then it is time to decide if it is appropriate to
> > > >change the p= value in its DMARC record to p=quarantine or p=reject.
> > > >Depending on its cadence for sending mail, it may take many months of
> > > >consuming DMARC aggregate reports before a Domain Owner reaches
> the
> > > >point where it is sure that it is properly authenticating all of its
> > > >mail, and the decision on which p= value to use will depend on its
> > > >needs.
> > > >
> > > >It is important to understand that many domains may never use
> > > >policies of “quarantine” or “reject”, and that these policies are
> > > >intended not as goals, but as policies available for use when they
> > > >are appropriate.  In particular, “reject” is not intended for
> > > >deployment in domains with users who send routine email, and its
> > > >deployment in such domains can disrupt indirect mail flows and cause
> > > >damage to operation of mailing lists and other forwarding services.
> > > >This is discussed in [RFC7960] and in Section 5.8, below.  The
> > > >“reject” policy is best reserved for domains that send only
> > > >transactional email that is not intended to be posted to mailing
> > > >lists.
> > > >
> > > >To be explicitly clear: domains used for general-purpose email MUST
> > > >NOT deploy a DMARC policy of p=reject.
> > > >
> > > > END
> > >
> > > [snip]
> > >
> > > How about, "... MUST NOT deploy a DMARC policy other than p=none
> > > because improper used of p=reject or (to a slightly lesser exent)
> > > p=quarantine is extremely harmful to email interoperability."
> >
> > Or, "...MUST NOT deploy a DMARC policy other than p=none because
> > improper use of p=reject or (to a slightly lesser extent) p=quarantine
> > is extremely harmful to email interoperability. Such improper use
> > includes, but is not limited to, cases where the mitigation strategies
> > discussed in RFCs 7960 and 8617 and elsewhere are not deployed for the
> > mail flows in question and cases where the domain owner deems the
> > collateral damage as acceptable loss in service of protecting its
> > domain from unauthorized usage."
> >
> > I suspect that my text above won't go over well, but the use of the
> > term "improper use" smacks, to me, of the IETF being the protocol
> > police, and I've been led to believe that's not what we do here.
> >
> > There are many things I believe, and two of them are these:
> >
> >1. Any domain is a target to be spoofed
> >2. The custodian of a thing has the autonomy to do with that thing what
> >they please, so long as it's within the limits of the law. "My
> > network, my rules" as it were (or "Your network, your rules")
> >
> > DMARC is a tool in the fight against exact-domain spoofing, but some
> > methods of its deployment can cause interoperability issues. I believe
> > that as long as the risks are well understood and fully documented (to
> > include references to mitigation strategies) then a domain owner will
> > have all the information they need to make their choice as to what
> > policy to deploy. To mandate that certain classes of domains not do
> > something (and just how do we define "general-purpose" email anyway?)
> seems a bridge too far for me.
> 
> I agree with your items 1 and 2.  I'm not a particular fan of improper use 
> either.
> Maybe instead of improper use.  Maybe just "use with such domains".
> 
> Your characterization reads more like SHOULD NOT unless   I don't think 
> that
> unless [list of things that are only true in very limited circumstances and 
> can't
> really be verified reliably] is very useful.  How about this instead (I am
> attempting to split the difference between assuming p=reject is okay is normal
> or exceptional):
> 
> "...MUST NOT deploy a DMARC policy other than p=none because use of
> p=reject or (to a slightly lesser extent) p=quarantine for such domains is
> extremely harmful to email interoperability.  Mitigation strategies are 
> discussed
> in [RFC 7960] and [RFC 8617]."
> 
> I don't think we need to re

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

[Brotman, Alex]

Should it reference consumer-oriented domains instead? 

Users of comcast.net can't get an email account with out first being an ISP 
customer.  I don't believe the intent was to exclude them from the proposed 
language.  Similarly for a few other providers, and then there are explicit 
pay-for services like Fastmail, Tutanova, etc.  I would think they're in the 
same category?

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, March 28, 2023 12:18 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows
> 
> On Tuesday, March 28, 2023 11:58:40 AM EDT Todd Herr wrote:
> > Upon further reflection, I find myself liking Barry's proposed text
> > less, and instead propose the following:
> >
> > On Tue, Mar 28, 2023 at 9:42 AM Todd Herr  wrote:
> > > On 28 Mar 2023, at 17:15, Barry Leiba wrote:
> > >> > NEW
> > >> >
> > >> >5.5.6.  Decide If and When to Update DMARC Policy
> > >> >
> > >> >Once the Domain Owner is satisfied that it is properly
> > >> >authenticating
> > >> >all of its mail, then it is time to decide if it is appropriate to
> > >> >change the p= value in its DMARC record to p=quarantine or p=reject.
> > >> >Depending on its cadence for sending mail, it may take many months
> > >> >of
> > >> >consuming DMARC aggregate reports before a Domain Owner reaches
> the
> > >> >point where it is sure that it is properly authenticating all of its
> > >> >mail, and the decision on which p= value to use will depend on its
> > >> >needs.
> > >> >
> > >> >It is important to understand that many domains may never use
> > >> >policies of “quarantine” or “reject”, and that these policies are
> > >> >intended not as goals, but as policies available for use when they
> > >> >are appropriate.  In particular, “reject” is not intended for
> > >> >deployment in domains with users who send routine email, and its
> > >> >deployment in such domains can disrupt indirect mail flows and cause
> > >> >damage to operation of mailing lists and other forwarding services.
> > >> >This is discussed in [RFC7960] and in Section 5.8, below.  The
> > >> >“reject” policy is best reserved for domains that send only
> > >> >transactional email that is not intended to be posted to mailing
> > >> >lists.
> > > >
> > > >To be explicitly clear: domains used for general-purpose email
> > > > MUST
> > > >
> > >> >NOT deploy a DMARC policy of p=reject.
> >
> > NEW
> >
> > 5.5.6 Decide Whether to Update DMARC Policy
> >
> > Once the Domain Owner is satisfied that it is properly authenticating
> >
> > all of its mail, then it is time to decide if it is appropriate to
> >
> > change the p= value in its DMARC record to p=quarantine or p=reject.
> >
> > Depending on its cadence for sending mail, it may take many months
> >
> > of consuming DMARC aggregate reports before a Domain Owner reaches
> >
> > the point where it is sure that it is properly authenticating all
> >
> > of its mail, and the decision on which p= value to use will depend on
> > its needs.
> >
> > The policies "reject" and "quarantine" are more effective than "none"
> > for accomplishing the chief goal of DMARC, namely to stop the
> > exact-domain spoofing of the domain in the RFC5322.From header.
> > However, experience has shown that a policy of "reject" can result in
> > the disruption of indirect mail flows and cause damage to the
> > operation of mailing lists and other forwarding services; [@!RFC7960]
> > and [@!RFC8617] and Section 5.8, below, all discuss this topic and/or
> > possible strategies for addressing it.
> >
> > Because of these challenges, some domains, particularly those with
> > open signup capabilities, may prefer to remain at a policy of p=none.
> > This topic is discussed further in section 11.4 below.
> >
> > 11.4 Open Signup Domains and DMARC Policies
> >
> >
> > Certain domains with open signup capabilities, where anyone can
> > register an
> >
> > account and send mail, may not want to implement p=reject. An example
> > of such
> >
> > domains would be consumer mailbox providers that used to be known as
> > "freemail
> >
> > providers". Domains with no DMARC policy or a policy of p=none are
> > vulnerable
> >
> > to spoofing, but their users can send mail using these registered
> > email addresses
> >
> > from unrelated third party systems (such as "forward to a friend"
> > services) or participate
> >
> > in mailing lists without impediment. The security challenges that this
> > presents to the
> >
> > domain owner are left up to those systems that allow open registration
> > of users.
> 
> I don't understand the connection between DMARC policies and open signup
> domains?  What makes them in any way special relative to DMARC?
> 
> Scott K
> 
> 
> 
> ___
> dmarc ma

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-08.txt

[Brotman, Alex]

Ale,  
Thanks for the notes, I'll try to get those sorted out.  I'll check RE the 
7405/5234 to see what I can find.  I only made one minor modification there 
based on a ticket JohnL had submitted.

Scott,

There were two version fields in this document at one point.  The second 
originally came about when there was a thought that there might be a "DMARC2' 
in the DNS record.  I'm happy to remove all references to a "version", as I 
agree with you that it doesn't have much utility at this point.  As for who 
would switch to BIS and use PSL, that was a separate discussion perhaps three 
weeks ago 
(https://mailarchive.ietf.org/arch/msg/dmarc/4jyF_FytKZ1tR7bknkMi23cLQYw/).  
Trent's point was that the reporter should not leave the policy domain being 
discovered left to interpretation, and instead cleanly state which method was 
used.

I can change those references.  I agree that it's probably more of a RefNeeded 
sort of thing.  

The Data Consistency section was added based on a fairly old ticket (from a 
conversation between Tomki and Seth IIRC).  Do you believe it completely 
unnecessary, or that it needs to elaborate a bit more?

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Monday, March 27, 2023 3:21 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: 
> draft-ietf-dmarc-aggregate-reporting-08.txt
> 
> On Monday, March 27, 2023 12:29:03 PM EDT internet-dra...@ietf.org wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This Internet-Draft is a work item of the Domain-based
> > Message Authentication, Reporting & Conformance (DMARC) WG of the IETF.
> >
> >Title   : DMARC Aggregate Reporting
> >Author  : Alex Brotman
> >Filename: draft-ietf-dmarc-aggregate-reporting-08.txt
> >Pages   : 29
> >Date: 2023-03-27
> 
> I'm not convinced we entirely made progress on this revision.
> 
> It's likely I missed or have forgotten the list discussion on some of these 
> items,
> sorry for any repetition.
> 
> This revision removes the optional version field, adds a new optional field 
> for
> discovery method, and adds a paragraph on data consistency in reporting.
> There are other changes that look to be editorial.
> 
> I agree with the removal of the version field.  It never made any sense to me.
> 
> I see though that the version element is only removed from the text, not from
> Appendix A and Appendix B.  Is it intended to be removed?  Now I'm confused.
> 
> I don't understand who is expected to implement DMRCbis and report using the
> PSL.  If you want to keep using RFC 7489, nothing stops you, but it would be 
> odd
> to decide not to upgrade your DMARC processing, but still expend engineering
> resources to upgrade your reporting.
> 
> Also, this revision correctly drops the reference to RFC 7489 because it was 
> no
> longer referenced in Section 2.1, but now it's referenced in the schema, so
> doesn't it need to be added back?  Also, this is presumably published with
> DMARCbis, which will obsolete RFC 7489.  Is it good IETF practice to reference
> historic documents?
> 
> I'm not sure this really adds much.  If we do keep it, I think it's in the 
> wrong
> section.  How you found the policy isn't the policy that was published.
> I think this goes in the metadata section.
> 
> Regarding "Data Consistency in Reporting", I don't see the point.  Who is 
> going
> to read this section and do something different?  Are we suggesting that
> recording the results and reporting them is not sufficient?  Do receivers 
> need to
> run a second DMARC check on the data before sending feedback to make sure
> it's consistent?  I reads like a plea not to use buggy software.  Who do we 
> expect
> to read an RFC and then realize they should test before deploying to avoid
> sending inconsistent data?  Seriously, what behavior are we trying to motivate
> here that fits within an RFC's scope?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!H8G5uZT5a1ton4-
> AnqD6LNYhIxe47F4MTcjsmU0XzJyGBFHD3tirxEwynV-
> vaG21KThPjTN7ZDUhabSiLht-$

___
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] 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>" 
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<mailto:dmarc@ietf.org>

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!ORgEfCBsr282Fw!pZ3zknT6evZJHIUrrdNBtZV32p6hgQXznrYrM80i5YsP-PzFnI7TEG6znII6BZlUN43ij3wR65B1HC-LbYgoOeD_6-6G0HzY$<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-ietf] Version in aggregate report

[Brotman, Alex]

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://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Treewalk causing changes

[Brotman, Alex]

While discussing this with someone at the conference yesterday, we thought 
perhaps we could introduce something of a referral.

Currently:
_dmarc.ret.bmcc.cuny.edu NULL
_dmarc.bmcc.cuny.edu "v=DMARC1; p=quarantine; fo=1; 
rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
ruf=mailto:dmarc_...@emaildefense.proofpoint.com";
_dmarc.cuny.edu  
"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";

Proposed:
_dmarc.bmcc.cuny.edu "v=DMARC1;sp=refer:cuny.edu; p=quarantine; fo=1; 
rua=mailto:dmarc_...@emaildefense.proofpoint.com; 
ruf=mailto:dmarc_...@emaildefense.proofpoint.com";

Adding the "sp=refer:cuny.edu" would allow the existing policy to be used for 
undeclared subdomains under the third-level domain.  This could be useful in 
the situation where an OrgDomain would like to still maintain some control over 
policy for the undeclared domains.

We didn't give it a ton of thought, so if others believe it to be problematic, 
that's understandable.  

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Friday, February 24, 2023 6:54 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Treewalk causing changes
> 
> As I recall it, for some...@ret.bmcc.cuny.edu, the policy domain is
> bmcc.cuny.edu, so the policy is p=quarantine.  However, the organizational
> domain is cuny.edu, so a signature having d=anothersub.cuny.edu is aligned.
> 
> Correct?
> 
> Best
> Ale
> 
> 
> On Fri 24/Feb/2023 03:03:08 +0100 Barry Leiba wrote:
> > I don't understand your point here, Doug.  It seems more likely that a
> > subdomain of a subdomain should be following the latter subdomain's
> > policy by default, rather than the higher-level domain's.  That is,
> > for a.b.c.d, "a" would be more likely to expect to follow "b" than
> > "c".  Which means that the tree walk will give the desired result when
> > the PSL would generally not have done so.
> >
> > Are you disagreeing with that, as it seems?  Or am I misunderstanding you?
> >
> > Barry
> >
> > On Thu, Feb 23, 2023 at 5:56 PM Douglas Foster
> >  wrote:
> >>
> >> I seem to have missed this redesign.   I thought the plan had always been 
> >> to
> take the top-most policy not flagged as PSD=Y.Taking the first policy 
> found is
> less work, but it turns subdomain policies into organizational domain 
> policies.  I
> expect that to be an unwanted surprise to many domain owners, since the
> subdomain policies will typically lack an sp clause.
> >>
> >> On Thu, Feb 23, 2023 at 7:46 PM Scott Kitterman 
> wrote:
> >>>
> >>> I don't find this to be a surprise.
> >>>
> >>> I believe we discussed this specific type of case early in the tree walk
> discussion.  An early proposal was to walk up the tree to find the PSD and 
> then
> reverse back down the tree to find the org domain (PSD +1).  This approach
> would have provided an identical result to the PSL design for this case, but 
> we
> concluded the added complexity and potential other issues made it not the best
> approach.
> >>>
> >>> Up to now, I don't think anyone has suggested that DMARCbis needs to
> produce 100% identical results with RFC 7489.  We know it won't, but the
> differences are at the margins and we assessed that they're okay.
> >>>
> >>> Scott K
> >>>
> >>>
> >>> On February 24, 2023 12:36:03 AM UTC, Barry Leiba
>  wrote:
> >>> >The issue here, Tim, is that the current way of checking the PSL
> >>> >would send you to the DMARC record for cuny.edu and p=none, while
> >>> >using the new tree walk would send you to the DMARC record for
> bmcc.cuny.edu and p=quarantine.
> >>> >
> >>> >In this case, it’s showing that the tree walk is the better
> >>> >mechanism, because it’s pretty clear that it matches the
> >>> >publisher’s intent.  But Elizabeth is pointing out that it DOES
> >>> >change the result, which means that the result depends upon which
> >>> >version of the DMARC spec the receiving domain is using.
> >>> >
> >>> >Barry
> >>> >
> >>> >On Thu, Feb 23, 2023 at 3:51 PM Tim Wicinski 
> wrote:
> >>> >
> >>> >>
> >>> >> Elizabeth,
> >>> >>
> >>> >> (speaking as a DNS person).  I think this is "OK" - at my last
> >>> >> job we set up DMARC records which stricter in certain subdomains
> >>> >> than the parent domain. (Now I need to go find the machine where
> >>> >> I left my code which did all this validation).
> >>> >>
> >>> >>
> >>> >> (As a DNS person I want to find the folks who put in the TXT
> >>> >> record for _ dmarc.cuny.edu and ask them to quote their string.
> >>> >> But that's my OCD).
> >>> >>
> >>> >> tim
> >>> >>
> >>> >>
> >>> >> On Thu, Feb 23, 2023 at 5:30 PM Elizabeth Zwicky  >>> >> 40otoh@dmarc.ietf.org> wrote:
> >>> >>
> >>> >>>
> >>> >>> I haven’t done extensive research but here is a live example
> >>> >>> where treewalk will cause a result change.
> >>> >>>
> >>> 

Re: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

[Brotman, Alex]

I believe I read that thread, and don’t believe I saw a consensus that this 
should change.

https://mailarchive.ietf.org/arch/msg/dmarc/uAcbvK49M8qI5o36qnJnyg_hULY/

Reviewing that again still suggests no consensus, perhaps even leaning toward 
“no”.  Scott said “not a forensic document” and “not related to DMARC”.

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

From: dmarc  On Behalf Of Douglas Foster
Sent: Thursday, January 5, 2023 6:36 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

Alex, I was referring to the discussion,which you apparently missed, not the 
prior draft.   HELO and Reverse DNS names should be requested in our report 
format, along with the Source IP.   They can (must) be optional for upward 
compatibility.

The reasons for including HELO and RevDNS are so obvious to me that I am 
surprised it was omitted by RFC 7489.If a report row requires corrective 
action, it needs to be resolved to a responsible organization and a responsible 
server.Source IP alone gives you neither.   ReverseDNS is a starting point, 
but it can either represent the ISP client or the ISP itself, depending on SWIP 
status.   Even if you get an organization from that, it only tells you the 
server when there is one-to-one NAT or no NAT.   That leaves a lot of problems:

1) A machine is sending unauthorized messages, possibly because it is infected. 
  Source IP tells you the firewall NAT address that is allowing the traffic 
out, not the infected machine.HELO will tell you the specific machine(s) 
that are involved.

2) A group of machines are used for sending legitimate messages on a send-only 
basis using a shared IP.   One of the machines has a configuration error and is 
not applying DKIM signatures correctly.   Source IP reporting tells you that 
you have a problem because less than 100% of messages from the IP are signed.  
HELO tells you which machine has the signature problem.

3) You want to know if an unexpected IP address represents a forwarder or an 
unauthorized message originator.   The HELO and ReverseDNS together give you a 
high confidence about which domain represents the sender.   Then you check your 
outbound message history to see if you are sending messages to that domain.   
If not, the server is probably a message originator.   If yes, the server is 
probably a forwarder.The conclusion is tentative and ambiguous, but it gets 
you started.

4) Some HELO and ReverseDNS names provide a clue that the server is malicious.  
 For example, an IP address in brackets is an allowed format for HELO, and it 
is in use on actual mail, but in my experience this always indicates that the 
server is a spam source.

5) Both HELO and ReverseDNS can be checked for validity by checking to see if 
the names can be resolved back to the Source IP address.   In most cases, one 
or both will validate and indicate the server owner.   Validation status can 
provide a clue about whether the server is legitimate or not.

6) Since DNS results can change with time and geography, it seems better to ask 
the reporting system to supply the Reverse DNS name, rather than waiting until 
the report is received by the domain owner.

I am assuming that most report senders will capture HELO and ReverseDNS as part 
of their evaluation process, so I see it as a very reasonable data request with 
very little incremental cost to the evaluator.  But for those who see it as a 
problem, the data is optional.

When HELO is multi-valued because multiple machines are behind a single IP 
address, some disaggregation will occur.   This strikes me as a benefit, not a 
disadvantage.

Doug Foster


On Wed, Jan 4, 2023 at 6:49 PM Brotman, Alex 
mailto:alex_brot...@comcast.com>> wrote:
Which section are you referring to?  Can you show where this has changed from 
-06 (or RFC7489)?

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

From: dmarc mailto:dmarc-boun...@ietf.org>> On Behalf 
Of Douglas Foster
Sent: Wednesday, January 4, 2023 6:35 AM
To: IETF DMARC WG mailto:dmarc@ietf.org>>
Subject: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

The new draft only asks for IP address, not HELO or Reverse DNS name.   HELO is 
valuable forensic information that cannot be obtained any other way.   Server 
identity becomes particularly important when the MailFrom identity fails SPF or 
matches the RFC5322.>From domain.  Why was these fields omitted?

Doug Foster

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

Re: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

[Brotman, Alex]

Which section are you referring to?  Can you show where this has changed from 
-06 (or RFC7489)?

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

From: dmarc  On Behalf Of Douglas Foster
Sent: Wednesday, January 4, 2023 6:35 AM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

The new draft only asks for IP address, not HELO or Reverse DNS name.   HELO is 
valuable forensic information that cannot be obtained any other way.   Server 
identity becomes particularly important when the MailFrom identity fails SPF or 
matches the RFC5322.>From domain.  Why was these fields omitted?

Doug Foster

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-07.txt

[Brotman, Alex]

Hey folks,

The big changes are XML cleanups from Ale, and then Scott's privacy section.  
Thanks to both of them for the contributions.   Ale's changes are throughout 
various portions of the document, and include some changes to whitespace, 
structure, and the way the XML in managed in the document repository.  Thanks 
for your feedback.

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Thursday, December 22, 2022 11:49 AM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-07.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
> 
> Title   : DMARC Aggregate Reporting
> Author  : Alex Brotman
>   Filename: draft-ietf-dmarc-aggregate-reporting-07.txt
>   Pages   : 29
>   Date: 2022-12-22
> 
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
> 
>This document (along with others) obsoletes RFC7489.
> 
> 
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!FLRM2BzDbP46Sp7ZCfDqdCtnibkGw5hTPB01K_b3p
> sQubeEtzRnsxgWTgdK4QiSuiqSZsxueGSnP1u0XhsTrnHOLY_PrsdUZx80$
> 
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-dmarc-
> aggregate-reporting-
> 07.html__;!!CQl3mcHX2A!FLRM2BzDbP46Sp7ZCfDqdCtnibkGw5hTPB01K_b3psQ
> ubeEtzRnsxgWTgdK4QiSuiqSZsxueGSnP1u0XhsTrnHOLY_PrQY7bP3g$
> 
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-
> ietf-dmarc-aggregate-reporting-
> 07__;!!CQl3mcHX2A!FLRM2BzDbP46Sp7ZCfDqdCtnibkGw5hTPB01K_b3psQubeEt
> zRnsxgWTgdK4QiSuiqSZsxueGSnP1u0XhsTrnHOLY_PrD7JksiU$
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!FLRM2BzDbP46Sp7ZCfDqdCtnibkGw5hTPB01K_b3psQubeEtzRnsx
> gWTgdK4QiSuiqSZsxueGSnP1u0XhsTrnHOLY_PrZvEBNoc$

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

Re: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate Reporting Draft

[Brotman, Alex]

Thanks Scott.  I'll try to get this merged in the next few days. I have two 
other merges from Ale that I need to sort out.  I'll get a new rev done after 
they're both merged.



--

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


From: dmarc  on behalf of Scott Kitterman 

Sent: Monday, December 19, 2022 10:43 AM
To: IETF DMARC WG
Subject: [dmarc-ietf] PSD Related Privacy Considerations For Aggregate 
Reporting Draft

The RFC 9091 privacy considerations, with minor updates need to be
incorporated into the DMARCbis effort.  Given the constraints on PSDs
requesting failure reports, they belong in the aggregate draft.  I've opened a
PR to, with some light editing, pull them in:

https://urldefense.com/v3/__https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-aggregate-reporting/pull/15__;!!CQl3mcHX2A!E1ob9b6zOndeoRR8Tg7UMGAjqaq9Oo_z3eoYEByvsS-ttdsgNKpMMLcme9a-O1864chySx8TnYuf_EiF96H_$

I don't think it should be particularly controversial, since it's almost
exactly what the WG already agreed for RFC 9091, but people should review it.

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!E1ob9b6zOndeoRR8Tg7UMGAjqaq9Oo_z3eoYEByvsS-ttdsgNKpMMLcme9a-O1864chySx8TnYuf_IbBOtPw$

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

Re: [dmarc-ietf] XML Schema error in draft-ietf-dmarc-aggregate-reporting-06

[Brotman, Alex]

Thanks Mauro, I'll review and get those in for the next version where 
appropriate.

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

> -Original Message-
> From: dmarc  On Behalf Of Mauro De Gennaro
> Sent: Tuesday, November 29, 2022 4:23 AM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] XML Schema error in draft-ietf-dmarc-aggregate-
> reporting-06
> 
> Hello,
> 
> Section 4 (Extensible Reporting) of draft-ietf-dmarc-aggregate-reporting-06
> specifies that extensions MAY exist in one of two places; within the record
> element, or in a separate extensions element under the feedback element.
> However, in the XML Schema included on Appendix A it is defined within the
> RowType element instead of RecordType:
> 
> 
>   
> 
>  minOccurs="1" maxOccurs="1"/>
> 
>  minOccurs="1" maxOccurs="1"/>
> 
>  type="PolicyEvaluatedType"
> minOccurs="1" maxOccurs="1"/>
>  minOccurs="0" maxOccurs"unbounded"/>
>   
> 
> 
> Instead, it should be defined in RecordType:
> 
> 
>   
> 
>  minOccurs="1" maxOccurs="1"/>
>  minOccurs="1" maxOccurs="1"/>
>  minOccurs="0" maxOccurs"unbounded"/>
>   
> 
> 
> In addition to that, the sample report on Appendix B has two errors:
> 
> - The “version” element is included within “report_metadata” instead of under
> the “feedback” element.
> - The closing tag of “extra_contact_info” is  instead of
> .
> 
> Thank you.
> 
> 
> 
> Kind Regards,
> Mauro De Gennaro
> Stalwart Labs Ltd.
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!AGfGxYORMMmDibOcHQ2c7CSMr8tj0beWZhr5W1lk5MvQ6bGBn
> ssbsVOSf0J1fARxZqXHyrHeb-VcR-lWi2v-IwFE$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Notes on Aggregate Report draft 6

[Brotman, Alex]

Amended language for section 2.1:
"The report may include...
- Sending domain and receiving server organizational domain."

Which organizational domain?  Taking my corporate domain as an example, you 
send the message to “comcast.com”, which is hosted at pphosted.com 
(MX/Proofpoint), but ultimately resides in outlook.com (O365/M365).  Should it 
be the domain that is the addressee, the domain that performs the DMARC (or 
other) evaluation? Or even the one that does the reporting?

There is also the envelope_to as part of the IdentifierType data, which seems 
to contradict the first part of your message.  Perhaps I misunderstand the 
objection.

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

From: dmarc  On Behalf Of Douglas Foster
Sent: Sunday, November 13, 2022 3:22 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Notes on Aggregate Report draft 6

Section 2.1
---
 This section says in part:
"The report may include...
- Sending and receiving domains"

This language is incorrect or misleading because the receiving SMTP domain is 
not part of our standard reporting at all, which is intentional.   (However, 
Yahoo has chosen to use the filename portion of the report name to indicate the 
receiving SMTP domain.   This behavior is probably worth mentioning in a later 
section, since established implementations trump the prior specification.)

Instead, the report design is intended to indicate the receiving MX server's 
organizational domain.  Unfortunately, the current design and practice does not 
communicate this information with any confidence.   We should address this by 
adding a field to indicate the MX server's organizational domain (or a 
subdomain which encompassess all of the MX servers included in the report).   
If MX servers are in different organizational domains, they should use separate 
reports.

Amended language for section 2.1:
"The report may include...
- Sending domain and receiving server organizational domain."

Additional language will be needed elsewhere to clarify these points.

Section 6.1
---
This section says
"Aggregate report may expose sender and recipient identifiers, specifically the 
RFC5322.From addresses."

This seems contradicted by section 6.3, so I think it can be dropped.

XML Definition

Consistent with the above comments, and my previous recommendation to include 
HELO and Reverse DNS names, the following changes are recommended to the XML
Report Metadata Type
-
Current

  






  


Recommended
 
  








  


Row Type
-
Current

  







  


Recommended

  









   

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

Re: [dmarc-ietf] Aggregate report signature requirements

[Brotman, Alex]

Are you aware of any evaluators who selectively escalate signatures?   I'm not, 
and I expect they do so to gather as much domain-based data as possible.  I'm 
not saying they don't exist, but I would imagine there aren't many, and the 
numbers will dwindle.

Are you suggesting the spec should limit the number of signatures evaluated, or 
reported? If it's evaluated, I think that's the core document.  If it's 
reported, the "hard work" of evaluation has already been completed.  Ignoring 
any privacy implications, I would think the domain owner may want to know who 
else is signing messages that is using their domain.

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

From: dmarc  on behalf of Douglas Foster 

Sent: Saturday, November 5, 2022 9:08:45 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Aggregate report signature requirements

(Changed the subject to return to the primary topic.)

Certainly, non-aligned signatures may be important to some evaluators, but that 
falls into the category of local policy, which I am not obligated to disclose.  
An evaluator may choose to reject a message even though it produces DMARC PASS, 
or he may choose to accept a message even though it fails to produce DMARC 
PASS.  DMARC allows a domain owner to influence this decision by ensuring his 
messages produce SPF PASS and DMARC PASS at the first hop.   SPF data (server 
identity, MailFrom identity, and SPF results) indicate whether the message was 
received directly or not, and aligned DKIM scope IDs indicate where a message 
apparently originated.   I am not obligated to give the domain owner 
information that will help him reverse engineer my filtering logic.I send 
him a DMARC report to help him produce DMARC PASS, and that is what he should 
do to influence my disposition in his favor.

If a message loses authentication in transit, this becomes a secondary trust 
and authentication issue between the evaluator and the submitting server.   The 
domain owner cannot know if the authentication loss happened for innocent or 
malicious reasons, cannot know if the original message was desired by the 
recipient, and consequently is not a party to the problem.   He may want to use 
signatures to reverse-engineer the message flow path, but the effort is not 
likely to be productive and more importantly is not a DMARC goal.

Most importantly, this is about respect for evaluators.You would be 
offended if I announced, "Security is really important to me, so I expect you 
to take a weekend job driving for Uber so that you can pay the monthly fee for 
my security service."   You would be even more offended if I said that my 
neighborhood did not have a crime problem but I wanted you to fund my security 
service anyway.In the same way, it is wrong to ask evaluators to do 
unnecessary work on every message, simply because there is a long shot 
possibility that the extra work might be useful to some domain owner, in some 
undefinable way, on some random occasion.   This is waste, and it is as rude to 
the evaluator as it would be for me to ask you to fund my security service.

Doug





On Fri, Nov 4, 2022 at 9:47 PM Murray S. Kucherawy 
mailto:superu...@gmail.com>> wrote:
On Fri, Nov 4, 2022 at 4:18 AM Douglas Foster 
mailto:dougfoster.emailstanda...@gmail.com>>
 wrote:
Maybe the problem is that John has trademarked "weak" to mean "L=0", so I will 
use "poorly constructed".   DKIM "works" because malicious actors have found 
easier ways to attack than using an intermediary MTA to alter a message without 
breaking the signature.   This may not always be the case, and signature 
construction practices lack consistency, making many of them vulnerable if 
mischief occurs.   Nonetheless, well-constructed signatures are a guidance 
issue, so I have no problem with putting it in a guidance document, as long as 
one is actually written.

I'm actually trying to remember what "weak" was supposed to mean.  It could 
refer to a number of different things, anything from not following DKIM's 
signing recommendations to unacceptably small keys to "l=0".  We probably 
should be specific, or stop using it.

But right now, we are not moving toward the goal because the players have left 
the field.   The questions before the group are:

- Do non-aligned signatures provide any benefit to domain owners?

I suggest that the answer is "maybe".  DKIM only really tells you something 
when the signature passes; at that point you can conclude that the message 
definitely either came from or passed through whatever domain generated the 
signature.  A failing signature tells you nothing, given the myriad ways a 
perfectly valid signature on a properly handled message can still be 
invalidated.

A receiver can thus make decisions based on the (possibly empty) set of domains 
for which passing signatures were present on a message.  Imagine for a moment 
the existence of a globally accepted spam f

Re: [dmarc-ietf] Weak signatures

[Brotman, Alex]

How will we handle the ever-changing definition of "weak"?

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Wednesday, October 26, 2022 10:27 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Weak signatures
> 
> 
> 
> On October 26, 2022 11:56:31 PM UTC, Steven M Jones 
> wrote:
> >On 10/26/22 16:45, Neil Anuskiewicz wrote:
> >>> On Oct 26, 2022, at 3:48 AM, Douglas Foster
>  wrote:
> >>>
> >>> 
> >>> Murray first raised the issue of weak signatures.
> >>> ...
> >>>
> >>> Weak results need to be part of the aggregate report so that domain
> owners understand the importance of moving from weak to strong signatures.
> >>> ...
> >>>
> >>> - DAMRC Evaluation does not exit upon finding an aligned and verified weak
> signature.   Instead, the result is noted but the evaluation continues in 
> hopes of
> finding an aligned and verified strong signature.
> >> Strong defined as the strength of the encryption algorithm (i.e., key 
> >> size).
> >
> >
> >And to be clear(er), any language talking about "strength" in terms of key 
> >size
> has to account for algorithm + key size, or you can get some incorrect 
> treatment
> of e.g. elliptical curve signatures.
> 
> If we need to define it, I'd say "weak" is anything that doesn't meet the
> requirements of RFC 8301 (RSA key length < 1024 bits or hash is SHA-1).  Any 
> RSA
> SHA-256 with a large enough key or any ed25519-SHA-256 (RFC 8463) is not
> weak.
> 
> No need to spend a lot of effort on this.
> 
> Scott K
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!BboGMRWEwa30TsEsWdFhy6Kbbj9Mp7QiEC1KaaKRniq7TE4jzqub
> PhnYWVDXZtfpjgArGQeryvtvMUTf_9D9DTtODa4$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Brotman, Alex]

There is a portion of the proposed aggregate document that affords one the 
opportunity to use “extensions”, which could potentially be applied to ARC (or 
any other reporting extension one would like to define).  Mindful, this still 
applies within the framework of DMARC.  So how the report recipient is 
identified is still tied to that same mechanism, though would allow Doug to 
define/create an “ARC Report” that is somewhat independent.

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

From: dmarc  On Behalf Of Dotzero
Sent: Monday, October 24, 2022 12:36 PM
To: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result



On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely 
mailto:ves...@tana.it>> wrote:
On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote:
> On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely 
> mailto:ves...@tana.it>> wrote:
>> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote:
>>> Unaligned signatures are orthogonal/irrelevant to DMARC. They may be useful 
>>> in
>>> other contexts. In the DKIM standard, signatures mean that the signer is
>>> asserting some (unspecified) responsibility for the signed message. That 
>>> may be
>>> useful for some reputation systems.
>>
>> Somewhat skewed w.r.t. orthogonality, actually.  Indirect flows are
>> explicitly mentioned in the I-D as a reason to override DMARC dispositions:
>
> DMARC only gives a pass if either SPF or DKIM passes. Unaligned DKIM
> signatures will NEVER give a DMARC pass.


How about dmarc=redeemed?


>> There MAY be an element for reason, meant to include any notes the
>> reporter might want to include as to why the disposition policy does
>> not match the policy_published, such as a Local Policy override
>> (possible values listed in Appendix A).
>
> Local Policy is just that. When a Receiver invokes Local Policy it is
> saying "I don't care what DMARC says, I'm choosing to ignore DMARC Policy
> and do something else".


It is a local decision to trust an ARC seal or an unaligned signature,
depending on the signing domains.  Yet, the decision can be made by the same
filter which looked up the From: domain policy.

It may or may not be performed by the same filter which looked up the From: 
domain policy. So what? That same filter may also consider reputation while the 
SMTP session is held open. That doesn't make reputation part of DMARC.


>> ARC too is a kind of unaligned signature, albeit with a bunch of
>> additions. The extra information it carries, designed to bestow enough
>> trust in the chain of custody to outweigh the self-referential reliance of
>> aligned From:, doesn't substantially change the semantic of DKIM
>> signatures.  And we should say how to report it, sooner or later.
> > ARC != DMARC. It is a separate RFC that gives participants an alternative
> means of evaluating mail flows when DKIM signatures are broken. Nothing
> more and nothing less.

ARC is a different signature not an "unaligned signature".



Conflicting protocols?  ARC was devised by the DMARC WG, during the phase of
"improving the identification of legitimate sources that do not currently
conform to DMARC requirements."  So, yes, on the one hand, since unaligned
signatures don't conform to DMARC requirements, they're not DMARC.  On the
other hand, as a fusion of deterministic authentication techniques and domain
policies, DMARC is intrinsically extensible.  For aggregate reporting in
particular, we explicitly provide for extensions.

Splitting out reporting is a good thing. Perhaps it should be renamed so that 
it is not DMARC centric. I would suggest the fact that something (ARC) which is 
not DMARC is included in the reporting that was developed as an integral part 
of DMARC is a matter of convenience more than anything else.


>> I'm not proposing to mandate the evaluation of any evaluable item.
>> However, I'd neither discourage it.  Perhaps technology will provide us
>> with ecological sources of energy.
>
> There is nothing wrong with using whatever data points you have available.
> That doesn't necessarily mean that such evaluations and choices are DMARC.


If ARC were a separate thing, it'd make no sense to include its data in DMARC
aggregate reports.

As I wrote above, it is more a matter of convenience than anything else. 
Generating separate ARC reports is duplicative effort from both a report 
generating perspective as well as consumption of those reports.

I think what we could do is to identify some criteria that a report generator
may follow, such as doing everything, reporting up to X signatures, or doing
SPF only.  Such meta data could be useful to report consumers, along with the
generator's software/version.


Best
Ale
--

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

[dmarc-ietf] Various IDs in aggregate -06

[Brotman, Alex]

Folks,

I started adding some text around the "Report-ID" format.  I ran into a bit of 
a hurdle, and thought it best to get group feedback.  We decided a while ago to 
add language that the "Report-ID", "msg-id", and "unique-id" were the same.  In 
the thread a few weeks ago, it was suggested the format should allow for 
optional "<>", and then a mix of alphanum, periods, and dashes.  The draft 
states that the filename should include the same report-id used in the subject, 
however, the "<>" I believe are illegal in Windows filenames.   I left a "NOTE" 
in the text in the area where we suggest they should be the same.  It's quite 
possible I've misinterpreted the intent of the "ridtxt", and there's no reason 
to worry. If we really want them to be the same, I'm on the edge of suggesting 
that we create a format that is friendly across the board, and make it a MUST.  
I say the edge because it's possible I'm missing something, and wanted to get 
feedback.  Thanks folks

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

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

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Brotman, Alex]

I’ve been going back and forth on this a bit.  On one side, I understand that 
we’d like to know when a receiving site does not evaluate both SPF and DKIM.  I 
also am not sure I know of any (sizable?) site which short-circuits evaluation 
after SPF.  Given how much time receivers talk about separation of streams and 
so on, I’d be surprised to see them knowingly discard data which could be used 
for data science-y things.

I receive a report without DKIM data from a specific site.  Today, I can’t know 
if that is a signing problem at the sender, a reporting failure/decision, a 
conscious choice for evaluation, a bug at the receiver, was stripped in 
transit, or something else.  I’m also not sure introducing a new “Not 
Evaluated” state solves/explains why it didn’t show in the reports.

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

From: dmarc  On Behalf Of Douglas Foster
Sent: Thursday, October 20, 2022 7:04 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

My thinking has evolved during this discussion:

We should reject Incomplete Results
If an evaluator has decided to do incomplete evaluation, we have to consider 
the possibility that he may or may not collect enough information to enumerate 
what signatures were not evaluated.   So a signature result of "not evaluated" 
does not solve the whole problem, but does cause disaggregation.A bit field 
indicating "incomplete results" could cover all types of incompleteness, and 
report recipients could decide whether to use the data or not.   But since we 
have aversion to incomplete results, the "must not report" approach both 
encourages complete results and provides upward compatibility for report 
receivers.

Scope
I am skeptical that our request for data about non-aligned signatures can 
justify the cost.   I have seen no defined strategy for integrating non-aligned 
signatures into the message evaluation process, so computing those results are 
pure waste to the evaluator.   Waste has real money costs and real opportunity 
costs.Given that billions or trillions of messages are transmitted every 
day, the global cost of extra signature evaluations is really quite 
significant.I am not freaking out about global warming, but it is on my 
radar.  The environmental impact of our decisions, when played out to Internet 
scale, are not trivial.   I would like some convincing that knowledge about 
non-aligned signatures is worth the non-trivial cost that we are asking 
evaluators, and the planet, to absorb.

Doug Foster

On Wed, Oct 19, 2022 at 8:48 PM Neil Anuskiewicz 
mailto:n...@marmot-tech.com>> wrote:


> On Oct 19, 2022, at 5:42 PM, Neil Anuskiewicz 
> mailto:n...@marmot-tech.com>> wrote:
>
> 
>
>> On Oct 19, 2022, at 6:59 AM, Scott Kitterman 
>> mailto:skl...@kitterman.com>> wrote:
>>
>> 
>>
 On October 19, 2022 12:44:16 PM UTC, Dotzero 
 mailto:dotz...@gmail.com>> wrote:
>>> On Tue, Oct 18, 2022 at 11:18 PM Scott Kitterman 
>>> mailto:skl...@kitterman.com>>
>>> wrote:
>>>


 On October 18, 2022 10:16:44 PM UTC, Neil Anuskiewicz <
 n...@marmot-tech.com> wrote:
>
>
>> On Oct 2, 2022, at 11:01 AM, Douglas Foster <
 dougfoster.emailstanda...@gmail.com>
  wrote:
>>
>> 
>> In many cases, an evaluator can determine a DMARC PASS result without
 evaluating every available identifier.
>> If a message has SPF PASS with acceptable alignment, the evaluator has
 no need to evaluate any DKIM signatures to know that the message produces
 DMARC PASS.
> I think it’s critical to DMARC that receivers do things like evaluate and
 report on DKIM whether or not SPF passes and is alignment. Without this, it
 would make it harder for senders to notice and remediate gaps in their
 authentication. Since there’s not a downside (that I know of), I’d say this
 should be a MUST if at all possible.


 What is the interoperability problem that happens if evaluators don't do
 that?

 Scott K

>>>
>>> Scott, What is the interoperability problem is evaluators didn't provide
>>> reports at all? Reporting isn't a "must" for interoperability but it
>>> certainly helps improve outcomes instead of senders flying blind.
>>
>> I read the email as suggesting a MUST for reporting both SPF and DKIM 
>> results if you report results at all, which would, I think lead to exactly 
>> the situation you're concerned about.  I'm skeptical of any kind of MUST 
>> around reporting since that's generally reserved for things that impact 
>> interoperability.  I do agree it should be encouraged.
>>
>> Mostly, at the moment, I'm trying to understand the proposed change and the 
>> rationale.
>
> I think the reactions were to the tone that that seemed to suggest that the 
> importance of reporting was being downplayed. MUST is too strong and

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

[Brotman, Alex]

So we would likely need a section in the core document with a SHOULD for 
evaluation (if it’s not already there), and then a section in the aggregate 
reporting for a MUST for reporting on evaluated information (if they choose to 
send reports at all), correct?

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

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Monday, October 3, 2022 10:03 AM
To: Todd Herr 
Cc: Douglas Foster ; IETF DMARC WG 

Subject: Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

On Mon, Oct 3, 2022 at 9:03 AM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:
On Sun, Oct 2, 2022 at 10:34 PM Douglas Foster 
mailto:dougfoster.emailstanda...@gmail.com>>
 wrote:
I am starting from the viewpoint that (a) reporting is a courtesy provided by 
the evaluator to the domain owner, and (b) the evaluator will do so in the 
context of his own interest, which includes filtering messages with maximum 
possible efficiency.

It is only a courtesy if the evaluator is not interested in promoting more 
widespread adoption of authentication.

For those evaluators who want to maximize adoption of authentication (because 
authenticated identifiers are ones to which reputation can be reliably attached 
and used in handling decisions) it is beneficial to the evaluator to provide 
reports to all who solicit them, so as to ensure that the report receivers can 
address shortcomings in their authentication processes.

I believe that the evaluators wanting to promote more widespread adoption of 
authentication far outnumber those who don't.

(No hat.)
I think if the consensus concurs with this perspective, then this is something 
the document should say explicitly (if it doesn't already).  Specifically, I 
think the case is being made here that all methods SHOULD be evaluated, with no 
short-circuiting, and the results of all of them need to be included in any 
report that's generated, so that the report recipient doesn't get only a 
partial view of what the world is seeing.

Meanwhile, there's clearly a bar someplace with regard to whether an operator 
chooses to generate reports.  I'm sure they all think operators support the 
idea of email authentication, but it's not clear whether they are prepared to 
make the investment to do so beyond getting the filtering part of DMARC 
working.  As Doug put it, it depends on "the context of his own interest".  I'm 
not sure this document making a normative assertion about that part of the 
question will move the needle at all.

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

Re: [dmarc-ietf] Report-ID in Aggregate Reporting

[Brotman, Alex]

That says it was addressed in 04, let us know if you believe otherwise, or not 
sufficiently.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Saturday, October 1, 2022 4:36 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Report-ID in Aggregate Reporting
> 
> Ticket 120 is about similar issues.
> https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/120__;!!C
> Ql3mcHX2A!FytyLaWXPp1OdJ22f1T5721ONHU__4fUzOBBtU9PS7KwL7-
> dBi5i8t2XKDj09Ih8Xg17JofOvAmRWnts7gY$
> 
> 
> Best
> Ale
> --
> 
> 
> 
> 
> 
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!FytyLaWXPp1OdJ22f1T5721ONHU__4fUzOBBtU9PS7KwL7-
> dBi5i8t2XKDj09Ih8Xg17JofOvAmRs6fRrt0$

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

[dmarc-ietf] Report-ID in Aggregate Reporting

[Brotman, Alex]

Folks,

Ticket was opened to address "Report-ID" in aggregate reporting.  Today, 
RFC7489 (Section 7.2.1.1) refers to a "msg-id" that it uses from RFC5322 as the 
format that is required.  The document then goes on to say that the true 
purpose of the field is to ensure that the receiver can identify duplicate 
reports and handle as necessary.  This has been carried forward into the 
aggregate reporting draft. 

Should we change this to specifically state the report must be a unique 
identifier from the reporter perspective, and stop at that?  No need to attempt 
to create some format to be explicitly follow, etc?

"The Report-ID MUST be a unique identifier for the report generation system and 
the domain (domain-name from 7.2.1.1) to which the report applies.  The string 
should be created using some number of ASCII characters.  Otherwise, no format 
guidance is provided."

Thanks

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

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

Re: [dmarc-ietf] Git Repository For Aggregate Reporting Draft

[Brotman, Alex]

That would be me I should hope.  I'll get that sorted out tonight or tomorrow.

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

> -Original Message-
> From: dmarc  On Behalf Of Scott Kitterman
> Sent: Tuesday, August 30, 2022 12:49 PM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] Git Repository For Aggregate Reporting Draft
> 
> I noticed that https://urldefense.com/v3/__https://github.com/ietf-wg-
> dmarc/draft-ietf-dmarc-aggregate-
> reporting__;!!CQl3mcHX2A!HxP9ZZ4TPoryeQeEI7nAqu89fMsxXqcVgXOv63iv
> cvdzrcgMq2My_0FlUbs1KPrVOw-cgK7vVVLTmxD5KTHf$   is at least one
> revision behind.  Can whoever has the files for the
> current revision update the repository?
> 
> Scott K
> 
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!HxP9ZZ4TPoryeQeEI7nAqu89fMsxXqcVgXOv63ivcvdzrcgM
> q2My_0FlUbs1KPrVOw-cgK7vVVLTmxy4QyAO$

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-05.txt

[Brotman, Alex]

The main gist of the change was resolving a few inconsistencies that were 
reported, as well as a few typos.  Thanks folks.

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

> -Original Message-
> From: dmarc  On Behalf Of internet-
> dra...@ietf.org
> Sent: Wednesday, April 20, 2022 9:42 AM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-05.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
> Title   : DMARC Aggregate Reporting
> Author  : Alex Brotman
>   Filename: draft-ietf-dmarc-aggregate-reporting-05.txt
>   Pages   : 25
>   Date: 2022-04-20
>
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
>
>This document (along with others) obsoletes RFC7489.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> dmarc-aggregate-
> reporting/__;!!CQl3mcHX2A!RMxHz0gysO8AyWVwEfLlwFsAan5uop9LJxUQJ9
> qMJ95xXw5zKP4tVd8JsTzOUYLU9UHLUmDT6w$
>
> There is also an HTML version available at:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-ietf-
> dmarc-aggregate-reporting-
> 05.html__;!!CQl3mcHX2A!RMxHz0gysO8AyWVwEfLlwFsAan5uop9LJxUQJ9q
> MJ95xXw5zKP4tVd8JsTzOUYLU9UEBrM64SQ$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-
> dmarc-aggregate-reporting-
> 05__;!!CQl3mcHX2A!RMxHz0gysO8AyWVwEfLlwFsAan5uop9LJxUQJ9qMJ95x
> Xw5zKP4tVd8JsTzOUYLU9UESBJNucw$
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!RMxHz0gysO8AyWVwEfLlwFsAan5uop9LJxUQJ9qMJ95xX
> w5zKP4tVd8JsTzOUYLU9UEPqfbteg$

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

[dmarc-ietf] Tree Walk + CNAME

[Brotman, Alex]

>From section 4.6:

To illustrate, for a message with the arbitrary RFC5322.From domain
   of "a.b.c.d.e.mail.example.com", a full DNS Tree Walk would require
   the following five queries, in order to locate the policy or
   Organizational Domain:

   *  _dmarc.a.b.c.d.e.mail.example.com

   *  _dmarc.e.mail.example.com

   *  _dmarc.mail.example.com

   *  _dmarc.example.com

   *  _dmarc.com


What should the evaluator do if one of these results in a CNAME that either:

a) points outside of the tree
b) results in a loop pointing at a previously evaluated record


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

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

Re: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback

[Brotman, Alex]

Richard,

Thanks for the notes.  I'll file a few trac issues to get these resolved, and 
try to get a new version released soon-ish.  If you're okay with it, I may send 
you a preview version to ensure it resolves the items noted below.  Thanks again

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

> -Original Message-
> From: dmarc  On Behalf Of Richard Gray
> Sent: Tuesday, January 25, 2022 5:03 AM
> To: dmarc@ietf.org
> Subject: [dmarc-ietf] draft-ietf-dmarc-aggregate-reporting-04 feedback
>
> Hi,
>
> I've been reading over the DMARC Aggregate Reporting draft and have some
> feedback on the schema and sample report.
>
> * The ActionDispositionType type definition in the schema is missing a closing
>  tag
>
> * The schema has the DMARC report version element () specified
> immediately under the  root element and not under
>  as stated in section 2.1
>
> * The draft states that  has mandatory fields domain, p, and
> sp, and optional fields fo, adkim, aspf, and testing.
> The schema for PolicyPublishedType has mandatory fields domain and
> version_published, with all other fields optional. Should version_published be
> mandatory or optional?
>
> * The schema for IdentifierType has header_from and envelope_from as
> mandatory fields, and envelope_to as an optional field. The sample report
> includes only header_from. The draft text in section 2.1 says "In most cases, 
> this
> will be a header_from element, which will contain the 5322.From domain from
> the message". Is it the intention of the draft that envelope_to should be
> mandatory?
>
> * The schema for SPFAuthResultType has scope (mfrom/helo) as a mandatory
> attribute but the sample report does not include a scope section. Should the 
> SPF
> scope be a mandatory field?
>
> * The schema does not currently permit report extensions as described in the
> draft (section 4). I am not sure if it is possible to define a schema 
> allowing an
> arbitrary element name with a required definition attribute (pointing to the
> extension spec).
>
>   As an alternative, would it be better to have a standard element name
> representing an arbitrary extension, with an attribute (even just the 
> definition
> URI) to identify the specific extension in use? E.g.
>
>   
>  definition="https://urldefense.com/v3/__https://www.example.com/dmarc-
> extension/0.1__;!!CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx-
> YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahviZ7N-gj3w$ ">
>   ...
> 
>   
>
> * Lastly, the draft states that reports have two primary sections, one with
> descriptive information and the other with row-data for the report. The
> "informative" section is broken into two sub-sections, which are
> report_metadata and policy_published. Would it perhaps be clearer to say that
> there are three main sections rather than two?
> report_metadata and policy_published are subsections of the main feedback
> element along with the record elements holding the row data.
> The schema is clear in this instance, I just wondered if the wording in the 
> draft
> might be improved.
>
> Regards,
> Richard
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!SZyg4CQrLEXm4I_qOm-N9qEMlEx-
> YkNnYRm5_S0C6L9rYHWuDoTGAMToQF8p5wahvibu5fFB5w$

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

[dmarc-ietf] DMARCbis - Aggregate Reporting 04

[Brotman, Alex]

Folks,

I've uploaded a new revision of the aggregate reporting document.  I've tried 
to incorporate feedback from the list, and some of the more notable items may 
include:

https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-04.txt
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

* Clarification of the domains to be included in the report, with a new 
associated paragraph
* Removing pct from reports, adding the testing flag
* A section about handling of duplicate reports (welcome feedback here as I'm 
not sure how all groups handle these today)

Happy to get more feedback from folks, and thank you for your time.

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

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

[dmarc-ietf] Ticket #120 - Unique IDs

[Brotman, Alex]

Hello folks,

We received a ticket about the unique IDs that are included with reporting:

--
unique-id, msg-id, and report_id are loosely defined.

The spec needs to say that they are semantically the same thing and must have 
the same content.

In addition:

Message-ID should also be based on unique-id if possible (for example, 
msg-id@domain-name),
make optional the final part of the Subject:, [Report-ID: msg-id] (like the 
filename).
--

I agree, the references should be made to the point to the same identifying 
string definition.  Today, the msg-id is required via the Subject, report_id is 
required in the XSD, and the unique-id is optional in the filename of the 
attached report.  Proposed is adding a suggestion to use the same ID attached 
to the Message-Id header.  Thoughts about making all required or optional?


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

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

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

[Brotman, Alex]

I know there has been a fair bit of talk about walk-the-tree.  Taking a 24h set 
of data, and trying to measure the number of times where this situation may be 
warranted.  We can try to make a guess the goal is to look for a DMARC policy 
between the 5322.From which has an unknown number of dotted sections, and the 
second-level/apex/organizational domain.  I extracted the 5322.From and counted 
the number of "." in the field.  So "1" dot, means example.com, "2" means 
third.example.com, and so on.  I included the policy as well, 
abs(ent)/none/quarantine/reject.

In roughly 86% of cases, the domain of record is in the format of 
"example.com".  In about 13%, we have "third.example.com".  The other <1% are 
other variations.  Not exactly sure if this data tells us walking-the-tree is 
going to be advantageous, but thought I would share with others.

Let me know if you have questions, or would like to see different data (that 
I'd be allowed to share)

Note: This is percentage of messages, not percentage of domains
(apologies if the formatting goes sideways)

Num_dotsPolicy  PctOfTraffic
--  -  ---
1   none60.9147275180
1   abs 11.4060937845
1   reject  10.9984823560
2   quarantine  7.3245642177
1   quarantine  3.1460328512
2   abs 2.5626295515
2   reject  2.1029313056
2   none1.1140098795
3   abs 0.1924108697
3   reject  0.1362830691
3   none0.0797639119
3   quarantine  0.0173744076
4   abs 0.0021115047
4   reject  0.0017292496
6   abs 0.0003094447
4   none0.0002730394
4   quarantine  0.0001092158
5   quarantine  0.0001092158
5   abs 0.364053
5   none0.091013
6   none0.091013



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

From: dmarc  On Behalf Of Todd Herr
Sent: Monday, October 25, 2021 3:30 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

Greetings.


There are, by my count, eleven tickets that are primarily focused on or at 
least touch on the issue of policy discovery. A specialized query for them is 
at this URL - 
https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/report/15__;!!CQl3mcHX2A!VGJAEdJ0DpNqMeFma5x4t8ehOeZpPCdYqZs4Dq9_D2Zja366Lx0pcwqK4DFcSskDWHhaFXGCzA$

The question of policy discovery has a few options as its answer:
• Leave things as they are (meaning look up the policy for the RFC5322.From 
domain and the organizational domain of that domain if different)
• Add a third lookup for a public suffix domain
• Walk the DNS tree from the RFC5322.From domain all the way to an agreed-upon 
level in the DNS hierarchy
• Something other than what's listed here
The topic of policy discovery has been proposed for the agenda for the upcoming 
DMARC session at IETF 112, and so this message should serve to kick off a 
discussion of the topic now, so that we can have a most productive discussion 
on the 9th.

Thank you.

--
Todd Herr | Technical Director, Standards and Ecosystem
e: mailto:todd.h...@valimail.com
m: 703.220.4153

This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Experiments

[Brotman, Alex]

Murray,

We’ve started (relatively recently, in volume) logging ARC data so we can try 
to make some informed decisions going forward.  We’re not yet acting on 
anything as a result, nor writing into the message. We’re also not doing 
anything when mail is being forwarded.  We’ll hopefully have more 
information/data available to share in the future (may not be the very near 
future given other projects going on).   This isn’t a guarantee that we’ll 
fully adopt ARC in the future, but enough to say we’re logging/analyzing things.

Random thing while looking at some data just now .. At least one message 
apparently came through with seven ARC sets.

Let me know if there’s anything I can answer at this point.

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

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Wednesday, September 22, 2021 4:30 PM
To: IETF DMARC WG 
Subject: [dmarc-ietf] Experiments

Is anyone in a position to comment on the ARC and PSD experiments and how 
they're progressing?  Deployment status?  Data acquired thus far?

-MSK

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Brotman, Alex]

It feels like folks would prefer that the subject be required to be of a 
specific format to better enable duplicate report processing.  Do I understand 
that correctly?

So that would be:

 If a report generator needs to re-send a report, the system
 MUST use the same filename as the original report.

And:

 The RFC5322.Subject field for individual report submissions
 MUST conform to the following ABNF:

And we need to add some language suggesting how to deal with duplicates report 
transmission, if they happen.  Scott/Matt also pointed toward a few other areas 
that could use with a bit of clarification.

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Friday, August 27, 2021 6:10 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-
> 03.txt
>
> Scott Kitterman wrote on 2021-08-26 17:41:
> > Why would a report be sent more than once?
>
> Happens regularly with Google as reporter. Seems to be a design choice.
>
> > Other than error cases, the only thing I can immediately think of is the 
> > case
> where the report was sent, but the SMTP session doesn't properly terminate
> so it's unknown if they entire report was received.
> >
> > Which leaves me wondering what the receive side processing should be?
>
> > Should partial reports be discarded? (draft is silent on this)
>
> CRC would break with compressed files in this case, i.e. the report would be
> clearly invalid.
>
> If the reporter generates a partial report but with valid syntax, then the
> report consumer will have no way to detect it. Re-sending the full report may
> fix the issue (if the consumer implements an overwrite logic) or make it
> worse (if the consumer doesn't deduplicate).
>
> > If a complete message has been received, then I think deduplicating based
> on the Report-ID makes sense (don't have to open up the MIME parts to do
> it).
>
> Yes.
>
> > It's not clear to me from skimming the draft if one message can have
> multiple XML files or not (I'm less familiar with the details of the feedback
> part of DMARC).  If there can be only one, that's probably sufficient.  If 
> there
> can be more than one, then there may be a case where one file was
> successfully received and stored, but another wasn't.  In this case, you would
> need to examine the MIME parts, so filename consistency would be
> important.
>
> The definition of one Report-ID in the subject line implies that a message
> carries no more than one report. This could be clarified in the RFC, though.
>
> Regards,
> Matt
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!VARGCtFK2D3DtJLxI2cq5iDvCCraX74A2LhFHQst6COZ1K187
> _UjKv583lD5kM8thacb$

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

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Brotman, Alex]

I haven't heard any other support for this.  I'm inclined to leave it as is 
currently written unless others chime in.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Thursday, August 19, 2021 7:19 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-
> 03.txt
>
> On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
> > If you feel as though something is amiss, or I've misinterpreted the
> consensus, please let me know.
>
>
> I'd swap SHOULD and MUST between the following sentences:
>
>  If a report generator needs to re-send a report, the system
>  SHOULD use the same filename as the original report.
>
> and
>
>  The RFC5322.Subject field for individual report submissions
>  MUST conform to the following ABNF:
>
> For the subject, alternatively, "Report-Id" msg-id could be optional, as it is
> with the filename.  It is very noisy and doesn't seem to be much useful if it
> doesn't match the filename, let alone its uniqueness.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!WUcDqYdgg-
> N4xaJrhTrh7yyVJXLl0YFs7Q9H9vY338oILvyM7_trujnFdTtnE_fQ2W9b$

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

Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

[Brotman, Alex]

I tend to agree on that last Receiver bullet being unenforced.  If I had to 
choose between an organization deploying DMARC without reporting, or holding up 
on deploying DMARC because they can’t provide reporting for X,Y,Z reasons .. 
I’m choosing the former.  Does it potentially leave a hole in intelligence?  
Yes, though doesn’t leave a hole in protection.  I suppose there’s the case 
where they just say they’ve only “partially” implemented DMARC, but then what’s 
the point of the MUST.

I want to stew on some of the other bits.  I’m on the fence for the Domain 
Owner requirements.  I also feel like the document needs a better definition of 
Mediator (I didn’t see one in the document).

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

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Thursday, August 19, 2021 3:16 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Ticket #66 (Define What It Means to Have Implemented 
DMARC) and #62 (Reporting a MUST)

On Thu, Aug 19, 2021 at 11:24 AM Todd Herr 
mailto:40valimail@dmarc.ietf.org>> 
wrote:



   Mail Receiver: To implement DMARC, a mail receiver MUST do the

   following:



   *  Perform DMARC validation checks on inbound mail



   *  Perform validation checks on any authentication check results

  recorded by mediators that handled the message prior to its

  reaching the Mail Receiver.



   *  Send aggregate reports to Domain Owners at least every 24 hours

  when a minimum of 100 messages with that domain in the

  RFC5322.From header field have been seen during the reporting

  period

Let's discuss...

I'm of the opinion that this last bullet can't be a MUST.  I understand that 
operators in this space really want this to be mandatory, but we are going to 
run into cases where doing this is difficult or impossible either because of 
operational difficulties (think resource-constrained environments) or policies 
("I am not willing to share any detail about what mail arrives here").  Making 
this a MUST explicitly disqualifies them.

Moreover, I would claim that not generating aggregate reports does not impede 
interoperability at all, which means use of MUST or even SHOULD here is not 
appropriate.

-MSK, participating only
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt

[Brotman, Alex]

Hello folks,

My updates aren't as exciting as they are for the other document.  I wanted to 
get a document out with the feedback provided.  Tried to clean up the 
extensions section, some normative language, and a few other items.  If you 
feel as though something is amiss, or I've misinterpreted the consensus, please 
let me know.

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

> -Original Message-
> From: dmarc  On Behalf Of internet-
> dra...@ietf.org
> Sent: Wednesday, August 18, 2021 4:22 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-03.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
> Title   : DMARC Aggregate Reporting
> Author  : Alex Brotman
>   Filename: draft-ietf-dmarc-aggregate-reporting-03.txt
>   Pages   : 24
>   Date: 2021-08-18
>
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
>
>This document (along with others) obsoletes RFC7489.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-
> dmarc-aggregate-reporting/__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT65dsNWz$
>
> There is also an htmlized version available at:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-
> ietf-dmarc-aggregate-reporting-03__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT8P4Kaj1$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-
> dmarc-aggregate-reporting-03__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT8GeqF4e$
>
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-
> drafts/__;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT3PaCn_l$
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!V4dyBOdtyfUCLKNx-
> DTfL0s53LkzELz3txXwSw3FHpD4FjlCsCR--yZnIFIPT5u086-R$

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

[dmarc-ietf] Trac #117

[Brotman, Alex]

Folks,

A ticket was opened to add a "human_result" to the SPF results in the report.  
As DKIM has similar, I don't necessarily see an issue here.  It seems like this 
could be useful to those attempting to resolve issues relating to failing SPF 
results. The ticket illustrates a few examples:

--
Justification:
A free text string  allows to add a meaningful error message in 
case when the SPF result is permerror or temperror.
This can be used as signaling mechanism, especially when the error is not 
obvious or does not occur with every mail receiver (subject to how strict they 
interpret the SPF spec and how they handle minor errors).

Here are a couple of real-world examples (anonymized) during SPF checks that 
have been all subsumed as permerror:

"example.net: Maximum DNS-interactive terms limit (10) exceeded"
"example.net ... example.com: Maximum DNS-interactive terms limit (10) 
exceeded"
"example.net: Redundant applicable 'v=spf1' sender policies found"
"example.net: Included domain 'example.com' has no applicable sender policy"
"mail.example.net: Junk encountered in record 'v=spf1 a mx ip4:192.0.2.1 
ip4:192.0.2.51 ~all|'"
"example.net: Junk encountered in record 'v=spf1 ip4:192.0.2.1 
ip4:192.0.2.51 include:_spf.example.com <​http://spf.example.com> ~all'"
"example.net: Missing required domain-spec in 'Include:'"

Note that there are different interpretations of how to count the number of DNS 
lookups:
<​https://www.mail-archive.com/dmarc-discuss@dmarc.org/msg03268.html>

Examples for temperror:

"example.net: 'SERVFAIL' error on DNS 'TXT' lookup of 'example.net'"
"email.example.net: 'SERVFAIL' error on DNS 'TXT' lookup of 
'email.example.net'"
"example.net: 'SERVFAIL' error on DNS 'PTR' lookup of 
'1.2.0.192.in-addr.arpa'"

The name  has been chosen, because it already exists for the 
 section.
-




https://trac.ietf.org/trac/dmarc/ticket/117



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

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

[dmarc-ietf] Trac #6 - Normative filename construction

[Brotman, Alex]

https://trac.ietf.org/trac/dmarc/ticket/6

Folks,

I'd like to get a bit of feedback on this one. I realized I'd changed this to a 
SHOULD, which doesn't really address the "fuzzy" complaint.  Seems like the 
proper thing to do is make this a MUST, though I'd be interested in opposing 
thoughts.  Instead of "The filename SHOULD be constructed using the following 
ABNF:", it would be convert to a "MUST be constructed".

Relevant section in the current draft: 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-2.6.1

(there's another nit in the ticket, though I don't think that requires 
discussion)

Thanks

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

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

[dmarc-ietf] Sender-supplied decision matrix for passing DMARC

[Brotman, Alex]

Hello,

I was talking to some folks about DMARC, and a question came as to suggest as 
the domain holder that your messages should always pass DKIM.  Effectively, the 
asker wants to say "I intend to deploy SPF and DKIM, but I will *always* sign 
my messages with DKIM."  So the obvious answer may be "Just only use DKIM", but 
I'm not sure that completely answers the question.  While discussing with 
someone else, "Tell me when DKIM fails, but SPF is fully aligned".  There was 
recently an incident at a provider where they were allowing any sender to send 
as any domain (and I'm aware that's not specifically a DMARC issue).  We all 
know brands that have just dumped in a pile of "include" statements without 
fully understanding the implications.  In this case, other users could send as 
other domains, but perhaps they would not have been DKIM signed.  Should there 
be a method by which a domain holder can say "We want all message to have both, 
or be treated as a failure", or "We'll provide both, but DKI
 M is a must"?

>From a receiver side, it makes evaluation more complex.  From a sender side, 
>it gives them more control over what is considered pass/fail.

How does this look in practice?  Maybe 
"v=DMARC1;p=quarantine;rua=...;pm=dkim:must,spf:should;"
(pm=Policy Matrix)

Does this make everyone cringe, or perhaps worth a larger discussion?

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

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

Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Brotman, Alex]

To summarize,

We'd like to see extensions available both below the "feedback" and "record" 
elements.  The -02 draft only has it below the "feedback" element.  I agree 
that all elements, each time they are utilized, should mention a reference as 
to how they are to be utilized.

We'd also like to have extensions go through an IETF process, however, we also 
understand that we cannot exclude third parties from defining/deploying their 
own extensions.  I suppose we could tell report receivers they "MUST" ignore 
any extensions which are not IETF-approved, though that seems a bit 
heavy-handed.

So, a sample report may look something like:

   
 2.0
 
   2
   Sample Reporter
   report_sen...@example-reporter.com
   ...
   3v98abbp8ya9n3va8yr8oa3ya
   
 161212415
 161221511
   
 
 
   example.com
   quarantine
   none
   100
 
 
   
 192.168.4.4
 123
 
   quarantine
   pass
   fail
 
   
   
 example.com
   
   
 
   example.com
   pass
   abc123
 
 
   example.com>
   fail
 
   

  
 .
  
   
 

   

   

   

The goal being to allow extensions to live either at the reported-IP level, or 
at the domain level.

Does this seem reasonable?

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Saturday, June 5, 2021 7:56 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback
> Requested
>
> Alessandro Vesely wrote on 2021-06-04 11:26:
> > Second, I'm not sure we need an  container.
> > I'd go for an example like, say, so:
> >
> > [...]
> >  > xmlns="http://ietf.org/xml-namesapaces/bimi-xml?/1.0";>
>  > [...]
> > > xmlns="http://ietf.org/xml-namesapaces/bimi-xml??/1.0";>
>
> If we use an attribute for the extension name, then we don't the container
> section.
> As the current schema does not use attributes at all, I'm more inclined to 
> define
> the extension name in a different way for consistent non-use of attributes. 
> But
> that's a minor detail.
>
> >> 1) Extensions in their own section (as it is now) or within each
> >>  element
> >
> >
> > Both, and both optional.  An extension can have some data to add in
> > some , but not necessarily in all of them.
>
> +1
>
> Regards,
> Matt

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

[dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

[Brotman, Alex]

Hello folks,

During our interim call last week the topic of extensions within the DMARC 
aggregate report came up.  There was a discussion about how to best introduce 
these, but also how they might be best used.  I noted three cases that I could 
see today; ARC, PSD, and BIMI.   And indeed we have tickets relating to the 
first two.  The original thought was that the aggregate draft would allow a 
place for extensions, and then additional drafts would define those within the 
IETF.  When -02 was originally being worked on, there was a thread about how we 
might like to see this, though not many responses.  The result is in section 4 
of the -02 draft [1]. and I thought we'd enhance that as we progressed.  At the 
time, I didn't intend to limit the extensions to IETF-approved extensions, 
though wasn't sure how else this might be used by reporting entities (I 
mentioned domain reputation-ish things during the call).  I'd consider that if 
we don't enforce IETF-registered extensions, the receivers could still
  ignore extensions they don't want to handle.  I'm also aware this could bloat 
a report in terms of size, though we've already indicated we don't seem overly 
concerned with the size of the XML body.  A few things I'd like to see the 
group reach consensus on are:

1) Extensions in their own section (as it is now) or within each  element
2) Must extensions be IETF-approved
3) If (2) is true, do we want to define any during the DMARCbis process 
(essentially a demonstration of how it is to be done)

Thank you for your continued feedback

1: 
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-aggregate-reporting-02#section-4

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

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

Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Brotman, Alex]

We "can avoid", but *must* we?  There are a number of tickets this impacts.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Friday, May 14, 2021 2:13 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> On Fri 14/May/2021 15:42:56 +0200 Brotman, Alex wrote:
> > There are a few tickets that may break report ingestion systems due to
> structure and/or value changes.  Should we decide that's an implementation
> issue, or that we truly can't change the format of the reports?  I'm sure most
> ingestion systems are rather flexible given the number of reports that
> appear to not match what 7489 states/suggests.
>
>
> Report consumers use XML libraries to recover the value of named fields.
> We can safely add fields.  Renaming fields or change existing semantics
> would break backward compatibility, which I think we can avoid.
>
>
> > If we are going to allow changes to the structure, and there is some
> concern about which version the receiver supports (or prefers?), should we
> put a flag into the DMARC record?  And of course, that may dependent on
> the receiver, if multiple are listed, so that would have to belong to each
> individual receiving address.
>
>
> Overkill IMHO.
>
>
> >> From: dmarc  On Behalf Of Matthäus Wander
> >>
> >> Regarding the existing top-level  below : Even if
> >> parsers don't require the version to function, it remains useful for
> >> measuring the adoption of the different DMARC specifications (as
> >> requested in #70). In fact, one implementation I looked at
> >> (parsedmarc) uses it for only this purpose. A missing  is logged
> as "draft"
> >> schema version.
>
> In my tiny MX I have a cache of 631 aggregate reports received recently.  121
> reports from 31 unique org_names have a /feedback/version element, 510
> from 37 organizations don't.  The latter group includes google.com, Yahoo!
> Inc., Verizon Media, Mail.Ru, ...
>
> Perhaps, someone with larger mail flows can bring better statistics.
>
>
> >> Regarding the XML namespace declaration:
> >> The XML schema serves not only as specification for developers, but
> >> can be also used for automatic syntax checks of reports -- provided
> >> that the namespace declaration is fixed. XSD validation is an
> >> immensely useful tool for testing the output of report generators. It
> >> helped me to discover two nasty bugs in an implementation, which
> >> appeared in 2 out of ~10k reports and would have gone unnoticed
> otherwise.
>
>
> Very much agreed.  Validating the report before sending is very safe.  Also
> building online aggregate report checking utilities would benefit from this
> possibility.
>
> Does the IETF provide URLs for hosting XSDs?
>
>
> >> A version number within the schema is not necessary for this use case.
>
>
> Or we can stick to a static 1.0, similar to v=DMARC1,
> MIME-Version, and the like, if useful.
>
>
> >> A different matter is whether automatic XSD validation on the report
> >> consumer side is a supported use case. There is some value in it: two lines
> of
> >> code suffice to perform input validation. However, the validation is strict
> and
> >> does not allow for being liberal in what you accept (might be handy for
> >> protocol police, though). Achieving upward compatibility is not trivial,
> >> because there is no general "ignore all unknown elements" statement in
> >> XSD. It is possible to define a  placeholder in the schema, but 
> >> this
> >> element must be inserted explicitly into each place where extensibility is
> >> desired. This would require careful foresight in the schema design.
>
>
> Designing an abstract extension for ARC is going to be particularly 
> challenging.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!Q3kGuVczKJh6EQuYf24QFyvWnwvaeUkyjnyhIGu9DMQQ-
> 6Xb_w-hV7tSxFRmor-OwwfRXbxMrg$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] [EXTERNAL] DMARC XML grammar

[Brotman, Alex]

I'll give it a look, and incorporate what I can (it seems to diverge from -02) 
into the XSD in the repository.

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

> -Original Message-
> From: Alessandro Vesely 
> Sent: Thursday, May 13, 2021 3:02 PM
> To: Brotman, Alex 
> Cc: dmarc-ietf 
> Subject: [EXTERNAL] DMARC XML grammar
>
> Alex,
>
> Matthäus made some interesting addition to the draft grammar at google-
> doc[*].
>
> That file also contains other changes, e.g. IPAddress, which are not yet 
> included
> in the I-D.
>
> Please have a look at it.
>
>
> Best
> Ale
> --
>
> [*]
> https://urldefense.com/v3/__https://docs.google.com/document/d/1Fh18iswR
> u4WJxnN6LBPIpVBncwhfJODOQxoeYH__Z-
> Q__;!!CQl3mcHX2A!UoTPBS6pTwALIT2IZH6YeBkWza-
> 4CJjOGm8X62AMXshWVCaOiQROU7h6_tBzOauQbf72$
>
>
>
>
>
>
>
>
>
>
>
>

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

Re: [dmarc-ietf] Versioning and XML namespaces in aggregate reports (#33, #70)

[Brotman, Alex]

There are a few tickets that may break report ingestion systems due to 
structure and/or value changes.  Should we decide that's an implementation 
issue, or that we truly can't change the format of the reports?  I'm sure most 
ingestion systems are rather flexible given the number of reports that appear 
to not match what 7489 states/suggests.

If we are going to allow changes to the structure, and there is some concern 
about which version the receiver supports (or prefers?), should we put a flag 
into the DMARC record?  And of course, that may dependent on the receiver, if 
multiple are listed, so that would have to belong to each individual receiving 
address.

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

> -Original Message-
> From: dmarc  On Behalf Of Matthäus Wander
> Sent: Thursday, May 13, 2021 5:29 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Versioning and XML namespaces in aggregate
> reports (#33, #70)
>
> Alessandro Vesely wrote on 2021-05-10 18:29:
> > On Mon 10/May/2021 17:28:20 +0200 Dave Crocker wrote:
> >> If an new spec merely /adds/ to a previous spec, then the presence of
> >> the new constructs is self-declaring.  The only requirement is to
> >> have the base specification declare that unrecognized constructs are
> >> to be ignored.  So, versioning adds the illusion of utility, but
> >> really only adds unnecessary complexity.
> >
> >
> > I think the format we'll end up with will be pretty compatible with
> > the existing practice, meaning that existing report consumers that use
> > a proper XML parser and ignore unknown tags can work unchanged.  I
> > don't think any consumer parses reports "by hands".
>
> Alright, introducing incompabilities is off the table and backward compability
> is a must. This brings #51 into question, which may affect backward
> compability.
> https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/51__;!!
> CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3FowsLllQ$
>
>
> Regarding the existing top-level  below :
> Even if parsers don't require the version to function, it remains useful for
> measuring the adoption of the different DMARC specifications (as requested
> in #70). In fact, one implementation I looked at (parsedmarc) uses it for only
> this purpose. A missing  is logged as "draft"
> schema version.
>
>
> Regarding the XML namespace declaration:
> The XML schema serves not only as specification for developers, but can be
> also used for automatic syntax checks of reports -- provided that the
> namespace declaration is fixed. XSD validation is an immensely useful tool for
> testing the output of report generators. It helped me to discover two nasty
> bugs in an implementation, which appeared in 2 out of ~10k reports and
> would have gone unnoticed otherwise.
> A version number within the schema is not necessary for this use case.
>
> A different matter is whether automatic XSD validation on the report
> consumer side is a supported use case. There is some value in it: two lines of
> code suffice to perform input validation. However, the validation is strict 
> and
> does not allow for being liberal in what you accept (might be handy for
> protocol police, though). Achieving upward compatibility is not trivial,
> because there is no general "ignore all unknown elements" statement in
> XSD. It is possible to define a  placeholder in the schema, but this
> element must be inserted explicitly into each place where extensibility is
> desired. This would require careful foresight in the schema design.
>
> Regards,
> Matt
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!RCdb_46_lcqdxdM882JSzD-hjS-
> 66H5H0OL8qTxqEITjJ7dViYTApbhFoP1sF8sc-3GZUejGJQ$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

[Brotman, Alex]

Martin,


  1.  I’ll see if we can get this cleaned up (I’ll create a proper ticket for 
tracking this)
  2.  I’d welcome other inputs here on the original idea for this option.  I 
would imagine modern systems would be able to deal with rather large XML files, 
though MTAs routinely set limits under 50M for accepting messages.
  3.  I don’t think it suggests we should all send at the same time (Unless I’m 
reading a different section). It suggests that the report producer should 
create reports on the same UTC boundaries.  For example, we do abide by the day 
boundary, but our reports are generated a few hours after UTC (and 
delivered upon completion).  If you’d like, I can put a clarifying note into 
the document.

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

From: dmarc  On Behalf Of Martin Kealey
Sent: Friday, May 7, 2021 1:24 AM
To: dmarc@ietf.org
Subject: [dmarc-ietf] nits in draft-ietf-dmarc-aggregate-reporting-02

I'm not quite sure how I'm supposed to submit nitpickery like this, so if 
there's a better forum please let me know.

1. Filename & content-type

Section 2.6.1 among other things says that the name for the mime-part 
containing the report MUST end with ".xml" or ".xml.gz", yet the example given 
ends with neither of those (it ends with just ".gz").

The main use for this is as a unique report identifier; its use as a filename 
is entirely secondary and only relevant to manual processing by a human, so 
MUST seems quite excessive.

It seems like there are separate drivers for each part of the filename suffix, 
and perhaps they should be two independent SHOULD requirements. If we want to 
facilitate its use as a filename, perhaps we should just say that the filename 
SHOULD be universally unique and MUST NOT contain "/" or start with ".".

It seems strange to vary the content-type based solely on what amounts to a 
transport optimization, namely gzip; this smells of working around deficiencies 
in other standards. (From the perspective of an application using email as a 
transport, it would seem to make more sense to allow 
"content-transfer-encoding" to be a chain such as "base64+gzip", or 
alternatively, for "content-type" to accept the addition of a "gzip/" prefix, 
forming "gzip/text/xml". However I digress, as that's a discussion for an 
entirely different standards track.)

According to rfc 7303 
§9.2,
 the "text/xml" content-type is merely an alias for "application/xml". Other 
standards such as related documents by 
w3c
 go further in actively declaring it deprecated.

It seems to me that rfc7303 
§4.2
 and rfc6838 
§4.2.5
 taken together indicate that registration of a content type such as 
application/dmarc-feedback+xml would be appropriate.

2. Size limit

I'm concerned that specifying the maximum report size after compression is 
possibly focussing on the wrong costs, and distorts the conceptual model:

  1.  It implies that the compressed file is the relevant artefact being 
transported, which leads to the weirdness with filenames and content-types 
mentioned above.
  2.  The size of the report is trivial compared with the size of the messages 
it's reporting on, both in terms of storage and bandwidth, and gzip 
decompression is very cheap, so compression makes negligible difference to 
those costs.
  3.  The cost of processing the received report to incorporate it into the 
bulk reporting correlates more closely with its "uncompressed" size. In 
particular, the memory footprint of the receiver process is likely to be 
correlated with this limit, especially if its first step is to build an 
in-memory DOM from the XML. (I would be surprised if any real report-accepting 
system didn't work this way.)

3. Scheduling

Concern about processing load also brings me to section 2.4.2, which 
essentially directs everyone to send their reports simultaneously. Since the 
receiver needs to be able handle reports with any reporting period, it seems 
likely that having most but not all reports arriving at the same time would be 
the worst outcome, needing both (a) complex coding to cope with asynchronous 
reporting, and (b) having to cope with high load spikes (or suffer delays with 
the reports spooled for batch processing).

It also imposes a load spike on the report generators, to ge

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt

[Brotman, Alex]

I sent this over to support the other day, and it was forwarded to operations.

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

From: Murray S. Kucherawy 
Sent: Monday, May 3, 2021 8:03 PM
To: Brotman, Alex 
Cc: Alessandro Vesely ; IETF DMARC WG 
Subject: Re: [dmarc-ietf] I-D Action: 
draft-ietf-dmarc-aggregate-reporting-02.txt

On Mon, May 3, 2021 at 11:49 AM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
I apologize, corporate mail gateway does that (I've asked them to exempt 
ietf.org<https://urldefense.com/v3/__http:/ietf.org__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Y97QeLs$>
 now). The links have an expiration of a few days.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6bqFdLuE$>

One of the URLs that came from the datatracker was:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VV5FMHzQ9IRbWwvLWi6noKzvhvvOVr5GK-OmVlF7Blvv8D0DEjx3PyHIAjwg6Ys_rsaT$>

It appears to return blank for me as well.

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

Re: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group feedback on timing and participation

[Brotman, Alex]

  1.  Just blocked off the time on my calendar to attend

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

From: dmarc  On Behalf Of Seth Blank
Sent: Thursday, May 6, 2021 12:27 AM
To: IETF DMARC WG 
Subject: [dmarc-ietf] DMARC WG Interim meeting Proposal -- request for group 
feedback on timing and participation

WG colleagues,

We committed to holding an interim meeting after the DMARCbis documents were 
delivered, and cancelled our IETF 110 meeting to make space for the design team 
to work.

We now have new documents from the design team, and it's time to schedule the 
Interim.
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/
- 
https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/

Barry and I propose Thursday, May 27th, from 9-11am PT / 12-2pm ET / 4-6pm GMT.

We believe this provides sufficient time for the group to digest the newly 
proposed text and have a productive discussion.

The Chairs ask group participants to explicitly speak up if:
1) they intend to participate in the interim
or 2) they wish to participate in the interim, but the timing does not work

Thanks,

Seth and Barry, as Chairs

--
Seth Blank | VP, Product
e: s...@valimail.com
p: 415.273.8818


This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Brotman, Alex]

Are we divided?  Seems like use cases have been noted.  However, removing these 
completely protects some aspects of privacy.  Could we perhaps err on the side 
of caution, removing these definitions, and leave a note to suggest that if 
domain holders need further assistance to reach out to the report generator. 
The generator can then make decisions about how much information to expose.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Tuesday, May 4, 2021 5:07 AM
> To: dmarc@ietf.org; Douglas Foster
> 
> Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
>
> Doug,
>
>
> On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
> > No.  I can't talk straight.
> >
> > I meant to say that we need N unique (and valid) smtp TO addresses, so
> > that an attacker cannot send a single email address and wait for an
> > rua report to know where it lands.
>
>
> A simple positive DSN can confirm email addresses better than elaborate
> DKIM design.  To confirm delivery is usually not considered a privacy
> violation, given that the sender learned the recipient's address.  Privacy
> violation occurs when senders track the recipient's opening of each message,
> which is typically obtained by inserting unique images in HTML messages.
>
> Avoiding to reveal final email addresses requires various precautions, which,
> if I understood what Laura wrote, can be put into effect on forwarding.  I
> would *add to the Privacy Consideration section* that, due to reporting,
> changing the envelope from is not enough, From: has to be changed as well
> in order to forward without revealing the final address.
>
>
> > Valid addresses are needed to hinder usage of bogus addresses to defeat
> the test.
>
>
> However, the aggregate report counts the number of messages, not the
> number of recipients.
>
>
> > Requiring aggregation on DKIM selector follows the sane logic to hinder
> > tracking an individual.
> >
> > Using DKIM selectors for tracking will also put a huge load on DNS if
> > implemented at scale, so it needs to be obstructed.
>
>
> I think mass mailers have better means to track recipients.  But I agree that
> to generate, publish, retrieve and report million DKIM selectors would be
> somewhat impractical.  Putting a limit on aggregate report size (even if not
> requested by the report consumer) can prevent excessive disaggregation.
>
>
> > It is also not enough to null the DKIM selector; the null aggregate still 
> > needs
> > to meet the N recipient requirement.  If not, then additional selectors need
> to
> > be nulled or the nulled-selector messages need to be completely excluded
> from
> > the report.
>
>
> Most reports I send have 1, given my volumes.  Yet, by
> aggregating many of them one could reach significant sums.
>
>
> > If the To domain is included in the report, the aggregation rules should 
> > still
> > apply.  If they cannot be met, then the To domain must be nulled out or
> the
> > report not sent.
>
>
> This is a recipient's choice.  If I wanted to stay anonymous, I'd use a domain
> like gmail.com rather than tana.it.
>
>
> > I favor making To domain an option which the owner domain requests and
> the
> > sending domain chooses to follow or ignore.  This provides upward
> > compatibility.  The request for this data element keeps coming up.  The
> > protocol can allow flexibility so that the participants make the final 
> > decision.
>
>
> It is already optional in the I-D.  (Not that I find it useful.)
>
>
> > I asked previously whether report senders do any filtering based on
> domain
> > reputation, and the answer was "probably not".  I think the specification
> > should encourage recipients to omit reporting to sources with negative
> > reputations, as their motive for report collection may be unrelated to
> > self-identification.
>
>
> Some receivers cannot report mail discarded during early SMTP phases at all,
> for example because the DMARC filter is run after the end of data.
>
>
> > I want the protocol to address all of Laura's concerns.  I think ensuring
> > aggregation is the best way to do this.
>
>
> DMARC cannot address those concerns directly, IMHO.  However, it can note
> under
> what conditions aggregate reporting doesn't violate privacy.  It is especially
> useful to note that, in most cases, aggregate reports do NOT constitute a
> privacy risk.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!R7ZKTY4HhF1wSMZwpruVsXIE5-
> EtRxdlYaxRVkylrlTKnqYLGf-PSpD4ChOUaRGFE27SBql-1Q$
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt

[Brotman, Alex]

I apologize, corporate mail gateway does that (I've asked them to exempt 
ietf.org now). The links have an expiration of a few days.

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/


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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Monday, May 3, 2021 1:55 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] I-D Action: 
> draft-ietf-dmarc-aggregate-reporting-02.txt
>
> Strange...
>
> On Fri 23/Apr/2021 20:21:00 +0200 internet-drafts wrote:
> >
> > There are also htmlized versions available at:
> > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc-
> aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4n1FbKlO$
>
>
> This arrives empty:
>
> ale@pcale:~/tmp$ curl
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc-
> aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4n1FbKlO$
> | wc
>% Total% Received % Xferd  Average Speed   TimeTime Time  
> Current
>   Dload  Upload   Total   SpentLeft  Speed
>0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- > 0
>0   0   0
>
>
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> dmarc-aggregate-reporting-02__;!!CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4t4SW-BT$
>
>
> This looks like the traditional htmlized I-D that was missing in the previous 
> link.
>
> How come?
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!VLHh-
> dyyGaHUPgaAFaPg3qsb8PlhOPrpMNkFUCu3qtCLqzx2JUZXysgpDqBD4vAtUgBj$

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

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

[Brotman, Alex]

Matt,

While, yes, there is the existing envelope_to, there was a request to add this 
to the report format (which I believe I did as the submitter desired).  I would 
assume we’d hash it out on the list and remove one of them.

However, from an operator side of things, I tend to align with Todd on this.  
Could someone provide a real-world example of where reporting the destination 
domain assisted them in resolving an issue?

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

From: dmarc  On Behalf Of Todd Herr
Sent: Wednesday, April 28, 2021 8:34 AM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Apologies to Matt; I sent this originally only to him when I meant to send it 
to the list...

On Wed, Apr 28, 2021 at 4:27 AM Matthäus Wander 
mailto:40wander.scie...@dmarc.ietf.org>> 
wrote:
Hello everyone,

I'm new to the party. I'd like to bring in some practical experience of
working with DMARC rua reports.

#23 introduces "receiving_domains" in the report metadata, justified by
large infrastructures that host a large number of domains (e.g. Google).

I think, this information would be more useful per-record rather than in
the global metadata. As large infrastructures tend to include many
different records in the report, the analyst needs a correlation between
record and recipient domain.

The  section has an optional "envelope_to" already:
>
>minOccurs="0"/>

Is there a benefit in the global "receiving_domains" over the per-record
"envelope_to"?

Most reporters don't include "envelope_to" (e.g. Google). This field
could be made more prominent in the draft. The main body mentions
"header_from" only, but neither "envelope_to" nor "envelope_from".

There is a hole in my understanding of this topic that I'm hoping someone can 
fill here, and that hole is this: I don't understand the value of reporting out 
receiving domains.

The reason I don't understand it is because my expectation as a sender 
receiving a report about my sending domain would be that my DMARC validation 
results from a given receiving infrastructure would generally not vary across 
the different receiving domains, regardless of if there was one domain, ten 
domains, or ten thousand domains hosted by the reporting infrastructure. To 
extend my expectations further, unless I'm dedicating part of my infrastructure 
to sending solely to one and only one receiving site, I would expect my DMARC 
validation results to generally not vary across different reporting 
infrastructures. I'm declaring here that "DMARC validation results" are 
separate from "applied receiver handling policy" because as a sender I can only 
control the former; "DMARC validation results" means "whether or not SPF and/or 
DKIM passed and was aligned and consequently resulted in a DMARC pass or fail".

If I'm reading draft-ietf-dmarc-aggregate-reporting-02 correctly, 
receiving_domains, defined as the "List of domains which received messages for 
the domain in this report" I guess it could perhaps help me as a report 
consumer in the case where I receive a report from an previously unknown or 
unfamiliar to me reporter that hosts many domains, and if that's the use case, 
then perhaps the field ought to be amended to "List of the top $SMALL_NUMBER 
domains which received messages for the domain in this report" because as a 
report consumer I don't need to see 837 domains listed when realistically one 
or two will suffice.

What is the value that I'm not seeing in reporting out receiving domains?
--
Todd Herr | Sr. Technical Program Manager
e: todd.h...@valimail.com
m: 703.220.4153


This email and all data transmitted with it contains confidential and/or 
proprietary information intended solely for the use of individual(s) authorized 
to receive it. If you are not an intended and authorized recipient you are 
hereby notified of any use, disclosure, copying or distribution of the 
information included in this transmission is prohibited and may be unlawful. 
Please immediately notify the sender by replying to this email and then delete 
it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt

[Brotman, Alex]

Hello folks,

Below you'll see the details relating to the most recent iteration of the 
aggregate reporting document.  I attempted to address as many tickets as I 
thought feasible.  I would probably suggest that the core of changes were 
relating to explaining more about the format, more properly defining the report 
format, and extensions.  There are a few other items that may need resolved, 
depending on feedback from these alterations.  Thank you for your feedback, and 
happy reading!

https://datatracker.ietf.org/doc/draft-ietf-dmarc-aggregate-reporting/
https://www.ietf.org/archive/id/draft-ietf-dmarc-aggregate-reporting-02.txt

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

> -Original Message-
> From: dmarc  On Behalf Of internet-dra...@ietf.org
> Sent: Friday, April 23, 2021 2:21 PM
> To: i-d-annou...@ietf.org
> Cc: dmarc@ietf.org
> Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain-based Message Authentication,
> Reporting & Conformance WG of the IETF.
>
> Title   : DMARC Aggregate Reporting
> Author  : Alex Brotman
> Filename: draft-ietf-dmarc-aggregate-reporting-02.txt
> Pages   : 23
> Date: 2021-04-23
>
> Abstract:
>DMARC allows for domain holders to request aggregate reports from
>receivers.  This report is an XML document, and contains extensible
>elements that allow for other types of data to be specified later.
>The aggregate reports can be submitted to the domain holder's
>specified destination as supported by the receiver.
>
>This document (along with others) obsoletes RFC7489.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-
> aggregate-
> reporting/__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaW
> gQDB55FiuC8137pI2qMKu6L5N_$
>
> There are also htmlized versions available at:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-dmarc-
> aggregate-reporting-
> 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55
> FiuC8137pI2qMGEpytDa$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-
> dmarc-aggregate-reporting-
> 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55
> FiuC8137pI2qMMR-T_gY$
>
> A diff from the previous version is available at:
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-
> dmarc-aggregate-reporting-
> 02__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55
> FiuC8137pI2qMJZqLFqL$
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-
> drafts/__;!!CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQD
> B55FiuC8137pI2qMJhtlMe4$
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!XYGoVpJyLMjJvBfT6HfI7rp_pBZainnzqhXO4GaZaWgQDB55FiuC81
> 37pI2qMMU63FiT$

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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Brotman, Alex]

Aggregated comments:

--
Aggregate feedback reports contain aggregated data relating to messages 
purportedly originating from the Domain Owner. The data does not contain any 
identifying characteristics about individual users. No personal information 
such as individual email addresses, IP addresses of individuals, or the content 
of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not 
contain personal information. In all cases, the data within the reports relates 
to the domain-level authentication information provided by mail servers sending 
messages on behalf of the Domain Owner. This information is necessary to assist 
Domain Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not 
contain personal information. The reports only contain aggregated data related 
to the domain-level authentication details of messages claiming to originate 
from their domain. This information is essential for the proper implementation 
and operation of DMARC. Domain Owners who are unable to receive reports for 
organizational reasons, can choose to exclusively direct the reports to an 
external processor.
--

Agreeable?

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Thursday, February 18, 2021 12:09 PM
> To: Kurt Andersen (b) ; Ken O'Driscoll
> 
> Cc: dmarc@ietf.org; John Levine 
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> On Thu 18/Feb/2021 17:52:55 +0100 Kurt Andersen (b) wrote:
> > On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll  > 40wemonitoremail@dmarc.ietf.org> wrote:
> >
> >>
> >> . . . I'd propose something like the below, which I think gets across
> >> what we all want to say.
> >>
> >> ===
> >> Aggregate feedback reports contain anonymized data relating to
> >> messages purportedly originating from the Domain Owner. The data does
> >> not contain any identifying characteristics about individual senders
> >> or receivers. No personal information such as individual email
> >> addresses, IP addresses of individuals, or the content of any messages, is
> included in reports.
> >>
> >> Mail Receivers should have no concerns in sending reports as they do
> >> not contain personal information. In all cases, the data within the
> >> reports relates to the authentication information provided by mail
> >> servers sending messages on behalf of the Domain Owner. This
> >> information is necessary to assist Domain Owners in implementing and
> maintaining DMARC.
> >>
> >> Domain Owners should have no concerns in receiving reports as they do
> >> not contain personal information. The reports only contain aggregated
> >> anonymized data related to the authentication details of messages
> >> claiming to originate from their domain. This information is
> >> essential for the proper implementation and operation of DMARC.
> >> Domain Owners who are unable to receive reports for organizational
> >> reasons, can choose to exclusively direct the reports to an external
> processor.
> >> ===
> >>
> >
> > With a s/anonymized/aggregated/g change, this seems like reasonable
> > language. In technical terms, there is no anonymization involved. The
> > only other issue might be some ambiguity in the intepretation of the
> > term "individual senders or receivers" because the IP addresses of the
> > MTAs involved in the email interchange are definitely in the report.
> > As someone has pointed out earlier in the thread, a compromised home
> > computer which is able to send out on port 25 would indeed be exposed
> > in such a scenario, though it is a rare case.
>
>
> I'd s/individual senders or receivers/individual users/.
>
> Also s/authentication/domain-level authentication/.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!QnQcMsS_KTWtqiiZuaapRUWc3xT1P55tS453rXWzE_lJElYm2DKE3
> yW2lwFWuJZIJs-sye0H4w$

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

Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Brotman, Alex]

Incorporating some feedback:

---
## Data Contained Within Reports (Tkt64)

Within the reports is contained an aggregated body of anonymized data pertaining
to the sending domain.  The data is meant to aid the report processors
and domain holders in verifying sources of messages pertaining to the
DMARC Identifier.  The data should not contain any identifying
characteristics about individual senders or receivers.  An entity
sending reports should not be concerned with the data contained as
it does not contain personal information, such as email addresses or
usernames. There are typically three situations where data is reported to
the aggregate receivers: messages properly authenticated, messages that fail to
authenticate as the domain, or messages utilizing the DMARC Identifier that
have no authentication at all.  In each of these cases, there exists no 
identifying
information for individuals, and all content within the reports should be 
related
to SMTP servers sending messages posing as that domain.
---


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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Monday, February 15, 2021 8:31 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> > Hello folks,
> >
> > In ticket #64
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64__;!
> !CQl3mcHX2A!W97hZ0-
> iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMRa
> BuxGQg$ ), it was suggested that a Privacy Considerations section may
> alleviate some concerns about the ownership of the data.  I created an initial
> attempt, and thought to get some feedback.  I didn't think we should go too
> far in depth, or raise corner cases.  Felt like doing so could lead down a 
> rabbit
> hole of trying to cover all cases. This would go within a "Privacy
> Considerations" section.
> >
> > * Data Contained Within Reports (#64)
> >
> > Within the reports is contained an aggregated body of anonymized data
> > pertaining to the sending domain.  The data is meant to aid the report
> > processors and domain holders in verifying sources of messages
> > pertaining to the 5322.From Domain.
>
>
> I'd replace all those 5322.From Domain with main DMARC identifier.
>
>
> > The data should not contain any identifying characteristics about
> > individual senders or receivers.
>
>
> The aggregated data refers to names and IP addresses of SMTP servers.  It
> cannot be used to identify individual users.
>
>
> >  An entity
> > sending reports should not be concerned with the data contained as
> > it should not contain PII (NIST reference for PII definition), such as email
> addresses or
> > usernames.
>
>
> I'd substitute /should not/does not/.  Even if a server has a unique user, the
> domain name and the IP address are those of a public entity, not those of a
> private citizen.
>
> The term Personally Identifiable Information (PII) is US-national.  I think
> just personal information is of broader use.  Personal data is also a valid
> alternative.
>
>
> jm2c
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!W97hZ0-
> iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMTF6
> fzPKA$

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

Re: [dmarc-ietf] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns

[Brotman, Alex]

Apologies, this is for aggregate reports.  I'm would imagine the Failure 
reports draft would have its own section as the questions there may be 
different.

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

> -Original Message-
> From: John Levine 
> Sent: Friday, February 12, 2021 3:46 PM
> To: dmarc@ietf.org
> Cc: Brotman, Alex 
> Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> In article
>  11.prod.outlook.com> you write:
> >Hello folks,
> >
> >In ticket #64
> >(https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64
> >__;!!CQl3mcHX2A!TwDVjWOh08AOGCxPZ0IKR8IxgdUb6u3LDW1Po0KbrzIgXW
> wlVm53NUB
> >Q6gqZ8IbIjUjG$ ), it was suggested that a Privacy Considerations section may
> alleviate some concerns about the ownership of the data.  I created an initial
> attempt, and thought to get some feedback.  I didn't think we should go too 
> far
> in depth, or raise corner cases.  Felt like doing so could lead down a rabbit 
> hole
> of trying to cover all cases. This would go within a "Privacy Considerations"
> section.
> >
> >* Data Contained Within Reports (#64)
> >
> >Within the reports is contained an aggregated body of anonymized data
> >pertaining to the sending domain.  The data is meant to aid the report
> >processors and domain holders in verifying sources of messages
> >pertaining to the 5322.From Domain.  The data should not contain any
> >identifying characteristics about individual senders or receivers.  An
> >entity sending reports should not be concerned with the data contained
> >as it should not contain PII (NIST reference for PII definition), such
> >as email addresses or usernames.
> >
> >Does this seem a reasonable start?  Thanks for your time.
>
> It's not clear which kind of report this is talking about.
>
> If it's aggregate reports, they contain IP addresses of mail servers and 
> domain
> names of SPF and DKIM identifiers, but nothing about the e-mail address or IP 
> of
> the original senders.
>
> If it's failure reports, they contain as much or as little as the reporter 
> includes,
> possibly an entire message sent by someome who may or may not be connected
> to the domain that receives the report.
>

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

[dmarc-ietf] Ticket #64 - Contained Data PII Concerns

[Brotman, Alex]

Hello folks,

In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), it was suggested 
that a Privacy Considerations section may alleviate some concerns about the 
ownership of the data.  I created an initial attempt, and thought to get some 
feedback.  I didn't think we should go too far in depth, or raise corner cases. 
 Felt like doing so could lead down a rabbit hole of trying to cover all cases. 
This would go within a "Privacy Considerations" section.

* Data Contained Within Reports (#64)

Within the reports is contained an aggregated body of anonymized data pertaining
to the sending domain.  The data is meant to aid the report processors
and domain holders in verifying sources of messages pertaining to the
5322.From Domain.  The data should not contain any identifying
characteristics about individual senders or receivers.  An entity
sending reports should not be concerned with the data contained as
it should not contain PII (NIST reference for PII definition), such as email 
addresses or
usernames.

Does this seem a reasonable start?  Thanks for your time.

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

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

Re: [dmarc-ietf] Discussion: Removal of validation for external destinations (Ticket #76)

[Brotman, Alex]

This came up in another thread elsewhere, and wanted to see if there was any 
more input before closing this as "wontfix".  The only feedback I got during 
this thread was that this external check should remain as it may prevent abuse 
and it appears that many have already implemented this.

The original thread is here: 
https://mailarchive.ietf.org/arch/msg/dmarc/pL7dsXjXn9BmADxly0yO2cDC_ro/

Thanks

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

From: dmarc  On Behalf Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:25 PM
To: DMARC IETF 
Subject: Re: [dmarc-ietf] Discussion: Removal of validation for external 
destinations (Ticket #76)

Removing this opens up the potential for abuse, I don't see the value in 
removing it.

On Sun, 6 Dec 2020, at 11:06 PM, Alessandro Vesely wrote:
On Sat 05/Dec/2020 14:51:52 +0100 Brotman, Alex wrote:
>
> There's currently a ticket that suggests that the requirement for external 
> validation be removed.  Today, if example.com has an RUA that points at 
> example.net, the latter must create a record as such:
>
> example.com._report._dmarc.example.net TXT "v=DMARC1"


Actually, the record can also be:

example.com._report._dmarc.example.net TXT "v=DMARC1; 
rua=updated-addr...@example.net<mailto:updated-addr...@example.net>"

or even, considering a parallel thread:

example.com._report._dmarc.example.net TXT "v=DMARC1; 
rua=rep...@example.net<mailto:rep...@example.net>, 
/https://www.example.net/report/<https://urldefense.com/v3/__https:/www.example.net/report/__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpAiHzHx$>"


That way, external services have the ability to control or suspend  their 
service.  I think this is an essential requirement.  Let's keep it.


> The original thought was that a bad actor could overwhelm a target with 
> unrequested reports.  It seems in reality, most report generators only send 
> once per day.


Once-per-day has to be amended.  See ticket #71.


> Additionally, there appear to be some generators who ignore the absence of 
> these records.


Aggregate reports are often tagged as spam anyway, but when sent in violation 
of the spec such tagging is certainly deserved.


> https://tools.ietf.org/html/rfc7489#section-7.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7489*section-7.1__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpuaI_16$>


Why don't you refer to either of the drafts we're editing:
https://tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00#section-2.1<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-aggregate-reporting-00*section-2.1__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivpqSIEHa$>
https://tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00#section-3.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-dmarc-failure-reporting-00*section-3.2__;Iw!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivqDi6FH6$>

BTW, this duplication is worth yet another ticket.


Best
Ale
--


















___
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivrqoGdKN$>


--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  Marc Bradshaw
  
marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivmARoKHF$>
 | 
@marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!TJoHWx6S1NRchnwhQ0ijzD46MbakofNi7Vpmyu0BaBaZslL1pTcbvwKcBEHivu6ug4qh$>



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

Re: [dmarc-ietf] understanding section 7.2

[Brotman, Alex]

Murray,

That is on my to-do (though not ticketed).  I’m not quite sure how elaborate 
the example should be, but at least enough to demonstrate a basic report.

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

From: dmarc  On Behalf Of Murray S. Kucherawy
Sent: Wednesday, January 27, 2021 3:14 PM
To: Michael Thomas 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] understanding section 7.2

The schema's already pretty large, and probably has to be, but maybe a trivial 
example report would be reasonable to craft and include?

On Tue, Jan 26, 2021 at 11:05 AM Michael Thomas 
mailto:m...@mtcc.com>> wrote:

So I'm an outsider who has not tried to digest what's going on in the
reports until recently so my eyes are fresh. Basically section 7.2 is
extremely hard to understand what is in the reports. I know that the XML
is what ought to be normative, but a little bit of ascii art could go a
long way to helping people understand what the reports do and don't
have. I've been staring at the XML all morning trying to understand it
and it is very difficult when all you're trying to do is figure out what
the reports supply or not. It would be extremely helpful to layout what
is in each record for human consumption to just understand what the
reports do and don't contain.

Mike

___
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] Discussion - ARC/Extensible Reporting (Ticket #56)

[Brotman, Alex]

This thread tailed off over the holidays.  For the moment, I’ve included a 
small section in the draft that allows for an optional “extensions” element in 
the aggregate draft, being optional for both report creation/ingestion.   I’d 
be happy to work with someone who has an idea of what an ARC report should look 
like if it were to be a self-contained piece of XML within the main DMARC 
report.  That could help drive this section as we move forward.

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

From: dmarc  On Behalf Of Brotman, Alex
Sent: Wednesday, December 30, 2020 4:49 PM
To: Emil Gustafsson 
Cc: Marc Bradshaw ; DMARC IETF 
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)


We’ve already mentioned ARC.  Could it also be extended to allow for Domain 
Reputation reporting back to the sender?  Instead of a central access point, 
the data is sent periodically to the domain holder, and they can then utilize 
the data as they see fit.  I could also see a use case for BIMI reporting.  I’m 
sure others could think of other use cases.

If we prefer it to exist outside of the main body of data, it may result in 
duplication of data, but also allows for more flexibility. This allows the 
original DMARC Aggregate data to remain consistent as well.  On the other hand, 
allowing it to exist within the record elements would allow it to be more 
easily correlated with the existing data.  I think my (slight) preference (as a 
report handler) is to have it outside of the main body of the report, but I 
could be swayed.


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

From: Emil Gustafsson 
mailto:emgu=40google@dmarc.ietf.org>>
Sent: Wednesday, December 23, 2020 2:49 PM
To: Brotman, Alex mailto:alex_brot...@comcast.com>>
Cc: Marc Bradshaw mailto:m...@marcbradshaw.net>>; DMARC 
IETF mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

While the common format would be great as a consumer of reports, I'm wondering 
how many different reports there would be. New auth standards don't pop up that 
often, so what other reports are you thinking about? I can see two obvious 
candidates; the mailserver software and the spam/abuse prevention software. It 
would be interesting to support something like that too but shouldn't those 
just put the results inside the dkim/spf/arc auth_results?
/E

On Tue, Dec 8, 2020 at 12:29 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
I feel (as a receiver of reports) as though another reason to have these as a 
single report is so that the receiver of the report is able to more easily 
correlate the data/times.  I should be able to believe that all reports 
(without a specified ri) will be -2359, though things happen, and systems 
break down.

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

From: dmarc mailto:dmarc-boun...@ietf.org>> On Behalf 
Of Marc Bradshaw
Sent: Monday, December 7, 2020 5:17 PM
To: DMARC IETF mailto:dmarc@ietf.org>>
Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)


There is value in including these in one report, especially where the extended 
property being reported on influences how DMARC is evaluated.

Using ARC as the example, when a p=reject policy was overriden by the receiver 
because of an ARC evaluation, when that data is included in the report the 
indirect mail flow can be clearly seen, which would not be the case if ARC were 
included as a separate report.

This could be included in an  element, or could be included directly 
in the auth_results section of the report, based on an assumption that the 
things being reported SHOULD have an authentication results entry in processed 
mail.


...
...
 (as defined in arc standard) 
 (as defined in foo standard) 


These would be defined in a registry with reference to each standard, and 
parsers would ignore any sections they did not understand.

On Fri, 4 Dec 2020, at 6:43 AM, Alessandro Vesely wrote:
On Thu 03/Dec/2020 19:54:51 +0100 Brotman, Alex wrote:
>
>> -Original Message-
>> From: dmarc mailto:dmarc-boun...@ietf.org>> On 
>> Behalf Of Alessandro Vesely
>> Sent: Thursday, December 3, 2020 6:24 AM
>> To: dmarc@ietf.org<mailto:dmarc@ietf.org>
>> Subject: Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)
>>
>> On Wed 02/Dec/2020 20:46:54 +0100 Brotman, Alex wrote:
>>>
>>> While this ticket/enhancement specifically mentions ARC, I could
>>> perhaps see the usefulness in other places.  It seems like it would be
>>> more beneficial to create a method by which other documents could
>>> provide XML- based "extensions" to the report.  This would allow
>>> mechanisms relying on DMARC to independently define

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

[Brotman, Alex]

Murray,

Personally, as a report reporter & report receiver, I would prefer to not try 
to figure that all out during generation/ingestion.  I’m sure there some use 
case to be stated for storing/reporting unnecessary data elements that have “no 
bearing” on the outcome for DMARC.  Or perhaps it could be perceived as a data 
leak to show where messages have passed on the way to their final destination.  
But point made, and if we go that route, we’ll be sure to include pros/cons.  
Thank you

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

From: Murray S. Kucherawy 
Sent: Monday, January 25, 2021 12:20 PM
To: Brotman, Alex 
Cc: dmarc@ietf.org
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Some time ago, an issue[1] was brought to the list where which DKIM(s) being 
reported is not clear in RFC7489 [2].  There was a short discussion, though no 
clear resolution before conversation trailed off.  It seems like there were 
points that may need to be discussed.  One was whether the reporting SHOULD 
report all signatures, regardless of alignment or validity, or perhaps just the 
one that aligns (if there is one).  There was also another question if there 
should be a limit to the number of signatures reported so that it remains sane.

A warning about use of "SHOULD" (or "RECOMMENDED") with respect to protocols: 
Text saying "implementers SHOULD do foobar" presents the implementer with a 
choice.  If you're going to say that, you need to explain the choice; in 
particular, an implementer should have some idea of the circumstances under 
which she might legitimately not do what it says and what the implications of 
doing so are with respect to interoperability.

A bare SHOULD, meant to be hand-wavy like "you really ought to do this, but you 
don't actually have to if you don't want to" is likely to draw attention.  I've 
been kind of picky about this lately during IESG Evaluation.

In this case, "reporting SHOULD report all signatures" -- why would you not?

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

Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

[Brotman, Alex]

Doug,

And I don’t think what you’re doing is necessarily bad from an operational 
standpoint.  I think the question centers around whether that aligning 
signature is sufficient, or should you report all the signatures the receiver 
attempted to verify?  I’m not suggesting that we add anything that would report 
“Signature validation not attempted”, that sounds horrible.  Will the original 
source potentially care that the message was signed in three other places as 
the message bounced around?  Should we put the onus on the reporting entity to 
do the filter out the non-aligned (what if none aligned) signatures, or just 
realize it’s some automated job and including all logged/validated signatures 
is the better way?

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

From: dmarc  On Behalf Of Douglas Foster
Sent: Sunday, January 24, 2021 10:27 PM
To: IETF DMARC WG 
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

Currently, my filter only evaluates signatures that are relevant to From 
alignment, and stops after the first success.   For that decision process, all 
that I need returned (and stored) is a Pass/Fail result; I don't need the 
details of the algorithm evaluated.  Any additional information collection is 
for the benefit of someone else, not the needs of my own organization.

The burden of data collection is proportionate  to the amount of data 
collected.  DMARC reporting is a courtesy service from the data collector to 
the domain owner.  Each effort to increase the precision of the data may reduce 
the number of domains willing to provide that information.

I suggest that we need report consumers in this group to discuss how they use 
the current data and the proposed additions to that data, so that a 
cost/benefit assessment can be made.   At least some of that justification 
should be included in the final document, since one purpose of that document 
will be to convince non-reporting entities to begin sending reports.

Doug Foster


On Sun, Jan 24, 2021 at 7:25 PM Brotman, Alex 
mailto:40comcast@dmarc.ietf.org>>
 wrote:
Hello folks,

Some time ago, an issue[1] was brought to the list where which DKIM(s) being 
reported is not clear in RFC7489 [2].  There was a short discussion, though no 
clear resolution before conversation trailed off.  It seems like there were 
points that may need to be discussed.  One was whether the reporting SHOULD 
report all signatures, regardless of alignment or validity, or perhaps just the 
one that aligns (if there is one).  There was also another question if there 
should be a limit to the number of signatures reported so that it remains sane.

We'd like to try to get this resolved within about two weeks.  Thank you for 
your feedback.

1: 
https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/__;!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61zozlYiYw$>
2: 
https://tools.ietf.org/html/rfc7489#section-7.2<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7489*section-7.2__;Iw!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61yIx7-bJw$>

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

___
dmarc mailing list
dmarc@ietf.org<mailto:dmarc@ietf.org>
https://www.ietf.org/mailman/listinfo/dmarc<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmarc__;!!CQl3mcHX2A!Qpo-kfJv_5UxDUzgIBRorIdxz7CetdRpFZdJGsbp1-jajBKoHP4UU7Czr0lzsRRs61wMnt5UTQ$>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Reports helping spammers? (#81)

[Brotman, Alex]

Ale,

I didn't incorporate that section as I thought that section about Privacy 
Considerations might be in the main document as it applies to both rua/ruf.  
I'll work to add something similar for the coming revision, thank you for the 
note.

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Saturday, January 23, 2021 6:21 AM
> To: John Levine ; dmarc@ietf.org; e...@google.com
> Subject: Re: [dmarc-ietf] Reports helping spammers? (#81)
>
> On Fri 22/Jan/2021 23:40:18 +0100 John Levine wrote:
> >
> > As someone said, the better the spammers align their stuff, the better
> > we can filter it.
>
>
> 100% agreed.
>
>
> > Close this, please.
>
>
> Please don't.  That such a doubt can cross the minds even of knowledgeable
> people is a real issue.  At a minimum, the paragraph I cited[*] should be
> restored.  A crispy further clarification is welcome.
>
> Best
> Ale
> --
>
> [*]
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmarc/HRA
> R3hSdckw3mU_Gebh8vcYOjm4__;!!CQl3mcHX2A!VZ89uCnai2kVE35KuFXiBNx_0
> VGYmUVnYzQbjqBfthrbcZ3wazcjrZ0hgM9i2T4iF5MP$
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!VZ89uCnai2kVE35KuFXiBNx_0VGYmUVnYzQbjqBfthrbcZ3wazcjrZ0
> hgM9i2d5OX4cb$

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

[dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

[Brotman, Alex]

Hello folks,

Some time ago, an issue[1] was brought to the list where which DKIM(s) being 
reported is not clear in RFC7489 [2].  There was a short discussion, though no 
clear resolution before conversation trailed off.  It seems like there were 
points that may need to be discussed.  One was whether the reporting SHOULD 
report all signatures, regardless of alignment or validity, or perhaps just the 
one that aligns (if there is one).  There was also another question if there 
should be a limit to the number of signatures reported so that it remains sane.

We'd like to try to get this resolved within about two weeks.  Thank you for 
your feedback.

1: https://mailarchive.ietf.org/arch/msg/dmarc/9-V596yl2BBaUzCNaDZB1Tg1s4c/
2: https://tools.ietf.org/html/rfc7489#section-7.2

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

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

[dmarc-ietf] Reports helping spammers? (#81)

[Brotman, Alex]

Hello folks,

Thought I'd see if we could come to a conclusion on this ticket.  The gist is 
that the reporter believes that (aggregate?) reports can help spammers to 
determine some effectiveness of their message attempts.

Full Text:
-
Spammers could use DMARC reports to monitor the effectiveness of their 
campaigns, and we do not want to help them. Do existing implementations send 
reports to any domain that requests them, or only to those domains that are 
considered "acceptable"? If reports are only sent to acceptable domains, what 
sort of criteria have been useful?

System administrators will appreciate such advice. Product developers will need 
guidance about the features they should provide so that a system administrator 
can control which domains do not receive reports.
-

>From an operator side, I don't agree with this assessment.  The reports do not 
>show if/why a MBP may place a message in the Junk folder.  Could it be DMARC 
>quarantine?  Sure.  It could also be any number of things from a large matrix 
>of decisions, none of which are shown in a DMARC report.  Also, the reports 
>are typically sent once per day (seems like most ignore the 'ri'), quite 
>likely some time after the end of the reporting period.  Additionally, they 
>probably have more efficient/immediate methods of evaluating their success 
>rate.

If you believe something has been overlooked, please feel free to share.

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

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

Re: [dmarc-ietf] Clarification about data integrity within Aggregate Reports (Ticket #40)

[Brotman, Alex]

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

> -Original Message-
> From: dmarc  On Behalf Of Alessandro Vesely
> Sent: Thursday, December 31, 2020 10:27 AM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Clarification about data integrity within Aggregate
> Reports (Ticket #40)
>
> On Wed 30/Dec/2020 23:18:35 +0100 Brotman, Alex wrote:
> > Hello folks,
> >
> > There's an open ticket
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/40__;!
> !CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQzeJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKuzHLj6b
> $ ) noting that we should clarify what constitutes valid data in a report. For
> example, the report cannot state that DMARC-DKIM was a "pass" when
> DKIM itself was a failure.  See the original thread here:
> >
> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/dmar
> > c/Ii_dLXFzBNnRP361F922ty789I8/__;!!CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQz
> > eJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKvlFgYhq$
> >
> > It seems like the gist is that within the report it should never happen that
> DKIM or SPF are noted to have passed in the context of DMARC if they have
> not passed on their own.  It should also be properly noted by the reporter if
> they override with local policy.  Not by overriding the SPF/DKIM failures (and
> showing them as incorrectly passing), but instead by noting that local policy
> overrides properly (regardless of whether that override is higher or lower).
> >
> > Does that seem properly summarized?
>
>
> If the aggregate report content, Section 2.2, was well explained, the above
> text would be redundant.  The point is that Section 2.2 looks like a high 
> level
> list of features.  It is completely useless for implementing a report 
> producer,
> let alone a consumer.  We have to rewrite that section, possibly trying to re-
> use the same wording and the same order of appearance of concepts, so as
> to minimize readers' confusion, but strictly matching the content of Appendix
> A (was Appendix C).
>

I don't think I disagree here, but I want to be clear on what you're 
requesting.  You'd like to see a more verbose description of the goal of the 
aggregate report, as well as the contents?

"... Each report MUST contain data for only one 5322 domain.  The values 
reported MUST be as evaluated from the original message, not from the local 
policy overrides ..." and so on?


> The consistency checks above can be useful for building verification tools.
>
> Let me take this occasion to recall that there are XML syntax check tools that
> can be used to automatically verify the syntax based on the schema.  We
> should write a more compliant XML in order to use them.

I've written an RNC (Relax NG Compact) previously.  As we get closer to 
finalizing any format changes, we can create that, and then use jing/pyjing to 
validate XML reports.  You'd want to use this to enforce report contents as 
specified above?  Not that I'm opposed, though, it can't enforce that the 
sender is using the proper values for DKIM pass/fail, only that the value is 
one of "pass"/"fail" (at least for RNC).  I don't believe there's a way to 
create interrelated dependencies where we could say that "DMARC can't possibly 
pass if both SPF and DKIM fail, and the report should be bogus if that's the 
case".

>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!VCWZO-
> 6THaYEt8r1yDE9TgQzeJyuFmGpwSepa3SWwao3ViUQfPaxJ5FrbnTPKvtKzeGr
> $

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