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

On Sat 23/Jan/2021 15:13:53 +0100 Douglas Foster wrote: I can fully endorse Murray's position that alignment reporting is beneficial, even when the sending domain is malicious.   However, it is also off-topic.  My focus is on disposition reporting, not alignment reporting. I see. Bottom

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

This is an interesting issue. Perhaps we need another ticket just to discuss how to handle signature transition. My first thought is that it will be more effective to announce support for ed25519 in the report header, rather than in each message result. Another possibility is for a recipient to

Re: [dmarc-ietf] Ticket #55, closing

On Sun 24/Jan/2021 19:49:00 +0100 John Levine wrote: In article <580831bc-ae5b-de09-e473-39c1a13a8...@tana.it> you write: In sec 3 it says the reports SHOULD include all URIs. That is a privacy problem since it is common for unsubscribe URIs to contain the recipient address in plain text or an

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas wrote: > > On 1/24/21 6:29 PM, John R. Levine wrote: > > I realized why the arguments about whether to require authentication > > on reports are pointless. > > > A blatant assertion. The onus of proof is with people who say we should > accept informa

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 5:25 AM, Todd Herr wrote: On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas > wrote: On 1/24/21 6:29 PM, John R. Levine wrote: > I realized why the arguments about whether to require authentication > on reports are pointless. > A blatant as

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas wrote: > > On 1/25/21 5:25 AM, Todd Herr wrote: > > On Sun, Jan 24, 2021 at 9:53 PM Michael Thomas wrote: > >> >> On 1/24/21 6:29 PM, John R. Levine wrote: >> > I realized why the arguments about whether to require authentication >> > on reports ar

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 8:44 AM, Todd Herr wrote: On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas > wrote: The main thing I've learned over the years of dealing with security is to not underestimate what a motivated attacker can do. Your imagination is not the same as thei

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Since the status quo is unauthenticated, I wonder if adding a signing requirement will help. Will recipients discad unsigned messages, or accept whatever is available to maximize their information capture? I suspect they will conrinye to accept everything. I think we would need an identified thre

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

What operational problem are we solving here? Absent evidence of a problem and strong consensus on the solution, let's close these tickets and move on. On Mon, Jan 25, 2021 at 9:10 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Since the status quo is unauthenticated, I wonder

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

On Sun, Jan 24, 2021 at 4:25 PM Brotman, Alex 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 poin

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Mike, this comment is unproductive and false. It is well known that bad actors are the first and heartiest adopters of authentication. This has been discussed with ample evidence for years. We are not litigating this fact on this list. Please stick to the merits of the discussion and bring operat

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Taking in information from unauthenticated sources and acting on it is an operational problem per se. Have we learned nothing in the last 30 years? Mike On 1/25/21 9:19 AM, Seth Blank wrote: What operational problem are we solving here? Absent evidence of a problem and strong consensus on the

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Mike, how do you believe DMARC reports are consumed and utilized? I think you have a misunderstanding here which is why you're going down this path and everyone else is pushing back. On Mon, Jan 25, 2021 at 9:22 AM Michael Thomas wrote: > Taking in information from unauthenticated sources and ac

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Why is this controversial? Seriously. What is controversial about saying that the a report should authenticate? The onus is on the people who say it does not to lay out the case for why it's not a problem, not me. #98 has a simple piece of text to remedy this. it's 2021. You don't use unauthent

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas wrote: > Why is this controversial? Seriously. What is controversial about saying > that the a report should authenticate? The onus is on the people who say it > does not to lay out the case for why it's not a problem, not me. #98 has a > simple piec

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Michael, as an individual, I don't disagree. What's not clear about the current text? https://tools.ietf.org/html/rfc7489#section-7.2.1.1 Email streams carrying DMARC feedback data MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass" (see Section 3.1

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Realized I think we're going in circles. Just posted text that is status quo that I believe already addresses Michael's concern. On Mon, Jan 25, 2021 at 9:38 AM Murray S. Kucherawy wrote: > On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas wrote: > >> Why is this controversial? Seriously. What is

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

That text is not very clear to say the least. It's written in a very passive voice. What is wrong with the text I provided? It should be made very explicit like I did with what the responsibility of the sender and receiver is. Mike On 1/25/21 9:40 AM, Seth Blank wrote: Michael, as an individu

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

But just as an example, suppose I'm trying to get to a position to use p=reject, but some bad actor doesn't want me to do that so they can keep phishing me. All they have to do is keep sending forged message reports from gmail which makes me think I've got a problem. Seriously, this is not rock

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

In article you write: >lets say a site signs an email with both rsa and ed25519 algorithms. This >site wants to know, whether the recipient can >validate the ed25519 signatures, so that in the future rsa signing for that >receiving site can be skipped (or errors in the >ed25519 implementation f

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

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 tha

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Issue #99 would need to be resolved if you want to use https as well. That's really why I brought up the entire issue. It's an easy fix for email, and not obvious how you fix it for https. Mike On 1/25/21 9:41 AM, Seth Blank wrote: Realized I think we're going in circles. Just posted text that

Re: [dmarc-ietf] Ticket #55, closing

In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write: >OLDER: >These reports SHOULD include the "call-to-action" URI(s) from inside >messages that failed to authenticate. Well, you can guess where that came from. >NEW: >These reports SHOULD include as much of the messag

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

Michael, are you aware of anyone not following the guidance in the document? This thread feels like we're discussing a non-issue. Aggregate reports are already required to be authenticated and I'm unaware of anyone sending failure reports, let along unauthenticated ones. Is the language causing pro

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

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 co

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, Jan 25, 2021 at 12:53 PM Michael Thomas wrote: > But just as an example, suppose I'm trying to get to a position to use > p=reject, but some bad actor doesn't want me to do that so they can keep > phishing me. All they have to do is keep sending forged message reports > from gmail which m

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 10:02 AM, Seth Blank wrote: Michael, are you aware of anyone not following the guidance in the document? This thread feels like we're discussing a non-issue. Aggregate reports are already required to be authenticated and I'm unaware of anyone sending failure reports, let along unau

Re: [dmarc-ietf] Ticket #55, closing

On Mon, Jan 25, 2021 at 10:05 AM John Levine wrote: > In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write: > >OLDER: > >These reports SHOULD include the "call-to-action" URI(s) from inside > >messages that failed to authenticate. > The intent of calling out CTA links was

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

>The list seems to be digging in because no one has raised a use case that >shows a need to revisit the text. This was made worse by asserting that >reports must be authenticated, when the text already makes that clear. I think the use case is my proposed https reporting. If you think it would be

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

On Mon 25/Jan/2021 01:25:13 +0100 Brotman, Alex 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

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 10:23 AM, John Levine wrote: The list seems to be digging in because no one has raised a use case that shows a need to revisit the text. This was made worse by asserting that reports must be authenticated, when the text already makes that clear. I think the use case is my proposed h

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

On Mon 25/Jan/2021 13:21:37 +0100 Douglas Foster wrote: This is an interesting issue.   Perhaps we need another ticket just to discuss how to handle signature transition. Reporting the selector suffices. Ticket #57. Best Ale -- _

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

On Mon 25/Jan/2021 18:59:16 +0100 Brotman, Alex wrote: 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?

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

In article you write: >> I continue to believe that authenticating the domain sending reports >> is of no value, since there is no way to tell what if any connection >> that domain has to the IPs in an aggregate report or the IPs or >> domains in a failure report. If I wanted to send fake gmail fa

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

Can we go slightly off topic to review why the report does not include the destination domain? That data element seems a lot more relevant than a tertiary signature. I can see that domain identification and disaggregation could significantly increase the size of reports from Gsuite and Office365,

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. But that change would require every unique domain to generate a unique report. Gsuite and Office365 would probably consider that unacceptable. On Mon, Jan 25, 2021, 1:29 PM Michael Thomas wr

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 10:55 AM, Douglas Foster wrote: DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported.  But that change would require every unique domain to generate a unique report.   Gsuite and Office365 would probably consider that unacceptable.

Re: [dmarc-ietf] Ticket #55, closing

On Mon 25/Jan/2021 19:01:28 +0100 John Levine wrote: In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write: OLDER: These reports SHOULD include the "call-to-action" URI(s) from inside messages that failed to authenticate. Well, you can guess where that came from. Should

Re: [dmarc-ietf] Ticket #55, closing

On Mon 25/Jan/2021 19:01:28 +0100 John Levine wrote: In article <63451726-124b-c24f-3be1-d6435e12c...@tana.it> you write: OLDER: These reports SHOULD include the "call-to-action" URI(s) from inside messages that failed to authenticate. Well, you can guess where that came from. Should w

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

So if a newsletter goes to 10,000 Gsuite domains, Google sends 10,000 reports instead of just one? I don't think either Google or the newsletter domain would consider that an improvement. But perhaps they will speak for themselves. On Mon, Jan 25, 2021, 2:02 PM Michael Thomas wrote: > > On 1

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Sun 24/Jan/2021 19:46:58 +0100 John Levine wrote: Here's a concrete proposal for https reporting: In draft-ietf-dmarc-aggregate-reporting, in the transport section, between Email and Other Methods add: Https POST The message is an XML file with GZIP compression, sent with an https POST mes

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

In article you write: >-=-=-=-=-=- > >DMARC alignment on the report seems of limited value unless it is aligned >to the domain being reported. ... I'm getting the impression that some of us have not looked at any DMARC reports. Aggregate reports contain the domain of the reporter, and the domai

Re: [dmarc-ietf] Discussion - ARC/Extensible Reporting (Ticket #56)

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 rep

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote: issue #99 needs to be addressed. Won't we put a DKIM-Signature: in the http: header? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmar

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 11:52 AM, John Levine wrote: In article you write: -=-=-=-=-=- DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. ... I'm getting the impression that some of us have not looked at any DMARC reports. Aggregate reports contain

[dmarc-ietf] error report in 7.2.2

Does anyone send the error reports described in section 7.2.2 ? I've never seen one but my reports are all quite small. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On 1/25/21 11:53 AM, Alessandro Vesely wrote: On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote: issue #99 needs to be addressed. Won't we put a DKIM-Signature: in the http: header? I don't know. That would need to be specified. To me it sounds like a good reason to not try to specif

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas wrote: > > On 1/25/21 11:52 AM, John Levine wrote: > > In article < > cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq+...@mail.gmail.com> you > write: > >> -=-=-=-=-=- > >> > >> DMARC alignment on the report seems of limited value unless it is > alig

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote: On 1/25/21 11:53 AM, Alessandro Vesely wrote: On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote: issue #99 needs to be addressed. Won't we put a DKIM-Signature: in the http: header? I don't know. That would need to be specified. T

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: On 1/25/21 11:52 AM, John Levine wrote: > In article mailto:cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq%2b...@mail.gmail.com>> you write: >> -=-=-=-=-=-

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon 25/Jan/2021 14:25:23 +0100 Todd Herr wrote: About that, aggregate reports are meant to be machine-parsed, and in my own experience that's accomplished by running a cron job a couple times a day to process the rua mailbox. (Personally, I favored Mark Overmeer's perl stuff; open the mailbo

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon 25/Jan/2021 19:02:13 +0100 Seth Blank wrote: It is likely in scope to discuss if the current text needs to be moved from 7.2.1.1 to 7.1, but let's please be careful to focus on operational feedback and not personal opinions. I'd leave the MUST in 7.2.1.1. If moved to 7.1 it should bec

Re: [dmarc-ietf] error report in 7.2.2

On Mon, Jan 25, 2021 at 12:06 PM John R Levine wrote: > Does anyone send the error reports described in section 7.2.2 ? I've > never seen one but my reports are all quite small. > I've never seen one. I imagine the logic goes something like "I was able to at least submit the report to the subm

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon 25/Jan/2021 20:52:31 +0100 John Levine wrote: In article you write: DMARC alignment on the report seems of limited value unless it is aligned to the domain being reported. ... [...] For at least the third time, there is no "domain being reported". When I get reports from Google or a

[dmarc-ietf] reporting security requirements

On 1/25/21 10:02 AM, Seth Blank wrote: Michael, are you aware of anyone not following the guidance in the document? This thread feels like we're discussing a non-issue. Aggregate reports are already required to be authenticated and I'm unaware of anyone sending failure reports, let along unau

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

In article you write: >On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote: >> issue #99 needs to be addressed. > >Won't we put a DKIM-Signature: in the http: header? No, there's no spec for signing an http transaction. If you want a client domain identity, It's easy enough to permit a client

Re: [dmarc-ietf] error report in 7.2.2

On Mon 25/Jan/2021 21:38:50 +0100 Murray S. Kucherawy wrote: On Mon, Jan 25, 2021 at 12:06 PM John R Levine wrote: Does anyone send the error reports described in section 7.2.2 ? I've never seen one but my reports are all quite small. I've never seen one. I imagine the logic goes something

Re: [dmarc-ietf] reporting security requirements

Entire sections of the document are devoted to preventing reporting abuse. Of course reviewing the security recommendations are part of the process of going standards track which we’ll be undertaking. If there are seeing specific operational issues that you believe require clarification in the doc

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, 25 Jan 2021, Alessandro Vesely wrote: For at least the third time, there is no "domain being reported". When I get reports from Google or any other multi-tenant mail provider, they do not say to which of their gazillion hosted domains the mail was sent. That is not a bug, and it's been li

Re: [dmarc-ietf] error report in 7.2.2

On Mon, 25 Jan 2021, Alessandro Vesely wrote: Does anyone send the error reports described in section 7.2.2 ? I've never seen one but my reports are all quite small. I've never seen one. I imagine the logic goes something like "I was able to at least submit the report to the submission server

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely wrote > > I agree that the spec needs some text somewhere to counter the passage in > Section 2.3 of RFC 7208. This, methinks, is the intended semantics of the > second paragraph of section 3.1.2 of dmarcbis: > > OLD: > Note that the RFC5321.

Re: [dmarc-ietf] reporting security requirements

On 1/25/21 12:47 PM, Seth Blank wrote: Entire sections of the document are devoted to preventing reporting abuse. Of course reviewing the security recommendations are part of the process of going standards track which we’ll be undertaking. As I said, it doesn't appear that there is a whole lo

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

In article <14fba490-7b6b-39bc-9a88-7a28aad5c...@tana.it> you write: >On Mon 25/Jan/2021 21:07:01 +0100 Michael Thomas wrote: >> >> On 1/25/21 11:53 AM, Alessandro Vesely wrote: >>> On Sun 24/Jan/2021 19:49:34 +0100 Michael Thomas wrote: issue #99 needs to be addressed. >>> >>> Won't we put a

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On Mon, Jan 25, 2021 at 3:18 PM Michael Thomas wrote: > > On 1/25/21 12:08 PM, Todd Herr wrote: > > On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas wrote: > >> >> On 1/25/21 11:52 AM, John Levine wrote: >> > In article < >> cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq+...@mail.gmail.com> you >

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 12:18 PM, Michael Thomas wrote: On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: Sounds like a bug to me and an issue should be opened. Just because it's a 10 year old bug doesn't mean it's not a bug.

Re: [dmarc-ietf] Ticket #1 - SPF alignment

On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote: > On Thu, Jan 21, 2021 at 4:24 AM Alessandro Vesely wrote > > > I agree that the spec needs some text somewhere to counter the passage in > > Section 2.3 of RFC 7208. This, methinks, is the intended semantics of the > > second paragraph

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

On 1/25/21 1:26 PM, Steven M Jones wrote: On 1/25/21 12:18 PM, Michael Thomas wrote: On 1/25/21 12:08 PM, Todd Herr wrote: On Mon, Jan 25, 2021 at 2:56 PM Michael Thomas > wrote: Sounds like a bug to me and an issue should be opened. Just because it's a 10

Re: [dmarc-ietf] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

This thread is now counterproductive and needs to come to a close. Michael, your continued assertion has been that unauthenticated reports are an issue. But so far no evidence has been presented that reports are sent without authentication, or that the text of the document is the cause. This thre

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

-- Forwarded message - From: Douglas Foster Date: Mon, Jan 25, 2021 at 8:32 PM Subject: Re: [dmarc-ietf] Reports helping spammers? (#81) To: Alessandro Vesely Yes, I think you are right, the information loss to bad actors is limited, while the benefits of information release may