[dmarc-ietf] so long again

I came here wondering what ARC was which I got answered and for which I wrote a blog post saying that we should just give up on the mailing list problem. https://rip-van-webble.blogspot.com/2020/12/are-mailing-lists-toast.html The same crap that drove me away the last time is still raging o

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

On 2/1/21 6:31 PM, Douglas Foster wrote: Michael, let it go. If someone stops you to say "your zipper is down", you will not ask them for proof of identity, you will excuse yourself and investigate the problem.   By my reckoning, DMARC reports are a lot like that. 1. This is already part o

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

On 2/1/21 6:24 PM, Dave Crocker wrote: On 2/1/2021 6:13 PM, Michael Thomas wrote: Because we all know how well unauthenticated data worked out for email. I fail to see why anybody would be in favor of digesting unauthenticated data when the method of authenticating it is trivial and well

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

On 2/1/21 6:05 PM, Dave Crocker wrote: On 2/1/2021 5:58 PM, Michael Thomas wrote: This, on the other hand, should be measurable. Saying that we should ignore authentication requirements should require extraordinary proof that it is needed for practical as well as security reasons. The burden

Re: [dmarc-ietf] DMARC'ed reports, was Forensic report loops are a problem

On 2/1/21 5:42 PM, Dave Crocker wrote: On 2/1/2021 5:38 PM, John R Levine wrote: So I would say that from my small sample, a lot of people have figured out how to send aligned reports, and, to be thorough, some/alot have not. This, on the other hand, should be measurable. Saying that we sho

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 4:16 PM, Dave Crocker wrote: On 2/1/2021 4:12 PM, Michael Thomas wrote: So we're supposed to ignore security considerations because... some companies are a mess? we're supposed to balance purported security considerations with pragmatic, real-world operational limi

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 4:05 PM, Dotzero wrote: On Mon, Feb 1, 2021 at 6:49 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 2/1/21 3:23 PM, Dave Crocker wrote: > On 2/1/2021 3:21 PM, John Levine wrote: >> I find it hard to believe that if you are going t

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 3:21 PM, John Levine wrote: In article <9aea1615-64a5-a310-b8c7-83ec0c316...@gmail.com> you write: -=-=-=-=-=- On 2/1/2021 10:08 AM, Alessandro Vesely wrote: On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote: Consider the challenges to ensuring a DMARC pass.  That's a pretty hig

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 3:23 PM, Dave Crocker wrote: On 2/1/2021 3:21 PM, John Levine wrote: I find it hard to believe that if you are going to enough effort to maintain the data to create and send reports, you can't figure out how to install an SPF record for your reporting domain. Except that the track

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 10:52 AM, Dave Crocker wrote: On 2/1/2021 10:25 AM, Michael Thomas wrote: On 2/1/21 10:13 AM, Dave Crocker wrote: The model that a receiving site is not allowed to report DMARC traffic unless that site is also generating DMARC authentication is Procrustean.  And as I noted, is

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 10:13 AM, Dave Crocker wrote: On 2/1/2021 10:08 AM, Alessandro Vesely wrote: On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote: Consider the challenges to ensuring a DMARC pass.  That's a pretty high barrier to entry against generating reports. Well, if a mail site is unable to

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 10:08 AM, Alessandro Vesely wrote: On Mon 01/Feb/2021 17:38:07 +0100 Dave Crocker wrote: Consider the challenges to ensuring a DMARC pass.  That's a pretty high barrier to entry against generating reports. Well, if a mail site is unable to get a DMARC pass, they have more urgent

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 9:25 AM, Dave Crocker wrote: On 2/1/2021 9:12 AM, Michael Thomas wrote: On 2/1/21 8:38 AM, Dave Crocker wrote: Mostly this will discourage reporting. Legitimate reporting. Versus illegitimate ones you'd assumedly want to ignore. So, it's probably a good thing I

Re: [dmarc-ietf] Forensic report loops are a problem

On 2/1/21 8:38 AM, Dave Crocker wrote: On 1/27/2021 7:17 PM, Steven M Jones wrote: 3.3. Transport    Email streams carrying DMARC failure reports MUST conform to the    DMARC mechanism, thereby resulting in an aligned "pass". Mostly this will discourage reporting.  Legitimate reporting.

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

On 1/30/21 2:09 PM, John R Levine wrote: On Sat, 30 Jan 2021, Jim Fenton wrote: Part of the problem here is that DMARC generally sits on top of an SPF library which doesn't tell you how it got its result.  My DMARC code just calls the SPF library and uses the result.  I suppose I could put in

Re: [dmarc-ietf] understanding section 7.2

n 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 prob

Re: [dmarc-ietf] understanding section 7.2

ld be able to read that section and understand what the report is and isn't. Mike 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

Re: [dmarc-ietf] attack on reports

On 1/26/21 1:44 PM, Todd Herr wrote: On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: I don't see how time helps anything if I can't differentiate between our legitimate traffic and attacker traffic. All an attacker would need t

Re: [dmarc-ietf] attack on reports

[] Ok, I think I understand this enough now to write a ticket. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] attack on reports

On 1/26/21 1:01 PM, Steven M Jones wrote: On 1/26/21 11:24, Michael Thomas wrote: Here's a very basic question: if I do not know all of the IP addresses that send on my behalf, are DMARC reports of any value? No, an organization is not assumed to have perfect knowledge of all

Re: [dmarc-ietf] attack on reports

On 1/26/21 12:41 PM, Matt V wrote: On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: How do I know when I'm done though if I don't know the IP addresses who send on my behalf? Is it an actual forgery or is it Marsha in marketing using

Re: [dmarc-ietf] attack on reports

On 1/26/21 12:29 PM, Todd Herr wrote: On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: Yes, DMARC reports are of value if you don't know all of the IP addresses that send on your behalf. Some have even written blog posts on the topic

Re: [dmarc-ietf] attack on reports

On 1/26/21 12:01 PM, Todd Herr wrote: On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 1/26/21 10:56 AM, Todd Herr wrote: > In addition, if I recover that message from the log, I might find no > relationship wit

Re: [dmarc-ietf] attack on reports

On 1/26/21 10:56 AM, Todd Herr wrote: > In addition, if I recover that message from the log, I might find no > relationship with the reporting domain or the reported source IP. > That is to say, I won't be able to deduce if the report is fake or real. My main point here is to

[dmarc-ietf] understanding section 7.2

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 wa

[dmarc-ietf] nit in section 7.2

"The report SHOULD include the following data:" Normative SHOULD here since very strange because what follows is informational, and why would it be SHOULD in the first place? It seems to me it ought to be: "The report includes the following data:" If there are normative requirements, it seems

Re: [dmarc-ietf] attack on reports

On 1/26/21 9:37 AM, Alessandro Vesely wrote: On Tue 26/Jan/2021 18:24:53 +0100 Michael Thomas wrote: This is different than yesterday. From what I can tell there is no identifying information of the original message like message-id in the report xml. If i'm wrong, please point me

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

On 1/26/21 9:16 AM, John R Levine wrote: Even if you can deduce a From: email address after the Subject Alt Name, you cannot reliably associate it to an organizational domain. Sorry, that makes no sense at all.  The cert has a domain name, or a bunch of domain names.  You can do exactly as

[dmarc-ietf] attack on reports

This is different than yesterday. From what I can tell there is no identifying information of the original message like message-id in the report xml. If i'm wrong, please point me to it. Since the object of the reports is to have confidence so that I can set a p=reject policy, all an attacke

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 <mailto:m...@mtcc.com>> wrote: Sounds like a bug to me and an issue should be opened. Just because it&#

Re: [dmarc-ietf] reporting security requirements

ckets, please. On Mon, Jan 25, 2021 at 12:41 Michael Thomas <mailto:m...@mtcc.com>> wrote: 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

[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] 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 <mailto:m...@mtcc.com>> wrote: On 1/25/21 11:52 AM, John Levine wrote: > In article mailto:cah48zfwejx1pho7x1bjjtyyehxzwmuq3jrhfjzahwfy1jq%2b...@mail.gmail.com>

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

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

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] 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] 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] Tickets 98 and 99 -- fake reports are not a problem and if they were authentication would not help

ust 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 mailto:superu...@gmail.com>> wrote: On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas mailto:m...@mtcc.com>> wrote: Why is this c

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

y, this is not rocket science. Mike On 1/25/21 9:25 AM, Seth Blank wrote: 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:

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

sulting in an aligned "pass" (seeSection 3.1 <https://tools.ietf.org/html/rfc7489#section-3.1>). This practice minimizes the risk of report consumers processing fraudulent reports. On Mon, Jan 25, 2021 at 9:32 AM Michael Thomas <mailto:m...@mtcc.com>> wrote:

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

n, Jan 25, 2021 at 9:22 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: 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:

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

25, 2021, 11:51 AM Michael Thomas mailto:m...@mtcc.com>> wrote: On 1/25/21 8:44 AM, Todd Herr wrote: On Mon, Jan 25, 2021 at 10:18 AM Michael Thomas mailto:m...@mtcc.com>> wrote: The main thing I've learned over the years of dealing

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 <mailto:m...@mtcc.com>> 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 n

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 <mailto:m...@mtcc.com>> 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.

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

On 1/24/21 6:29 PM, John R. Levine wrote: As we all know, bad guys are at least as good at authentication as good guys, probably better. PS: if this were true, DKIM would be useless too. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ie

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

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 information from unknown sources. Extraordinary claims require extraordinar

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

On 1/24/21 1:36 PM, John Levine wrote: In article you write: any reporting needs to be authenticated. if you're going to use http, you need to show how you're going to do that. DMARC systems have been producing and consuming reports for a decade without authentication, without any problems I

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

any reporting needs to be authenticated. if you're going to use http, you need to show how you're going to do that. Mike On 1/24/21 11:08 AM, John Levine wrote: In article you write: issue #99 needs to be addressed. I don't see any connection between issue 99 and this proposal. This is not

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

issue #99 needs to be addressed. On 1/24/21 10:46 AM, 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 wi

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

On 1/20/21 3:10 PM, Steven M Jones wrote: I think we should specify HTTPS URIs, and following 7489 section 12.6 "Secure Protocols" and current practices, HTTP should not be specified/permitted. However I don't yet see a compelling case for the OR- syntax or a separate "ruap" tag. Duplicate re

Re: [dmarc-ietf] Authentication of reports

On 1/20/21 3:08 PM, Seth Blank wrote: Discussion is in scope, per: https://trac.ietf.org/trac/dmarc/ticket/42 This topic has come up before, and there's always general interest in pursuing it, and absolutely no one who puts their hand up for eith

Re: [dmarc-ietf] Authentication of reports

So from those previous discussions, I don't think it's likely that we'll add reporting beyond mailto:, but it is certainly a conversation that's in scope when either ticket is opened. Seth On Wed, Jan 20, 2021 at 3:02 PM Michael Thomas <mailto:m...@mtcc.com>> wrote

Re: [dmarc-ietf] Authentication of reports

ay S. Kucherawy mailto:superu...@gmail.com>> wrote: On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas mailto:m...@mtcc.com>> wrote: I just scanned through DMARC and I couldn't find any security requirements/mechanisms for the failure reports. I would think

Re: [dmarc-ietf] Authentication of reports

On 1/20/21 2:56 PM, Murray S. Kucherawy wrote: On Wed, Jan 20, 2021 at 1:21 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: I just scanned through DMARC and I couldn't find any security requirements/mechanisms for the failure reports. I would think at the very leas

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

On 1/20/21 1:37 PM, John Levine wrote: In article <78ab729e-7ec5-b154-8e29-b02197933...@mtcc.com> you write: A little off topic, but is there any normative text in DMARC about the authenticity of the reporting? See section 7.2. Sorry, I'm not seeing it. It seems like there ought to be

[dmarc-ietf] Authentication of reports

I just scanned through DMARC and I couldn't find any security requirements/mechanisms for the failure reports. I would think at the very least the receiver consuming the reports ought make certain that the report at the very least have either a valid DKIM signature or a SPF pass. Unauthentic

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

A little off topic, but is there any normative text in DMARC about the authenticity of the reporting? It seems like there ought to be normative text that the report should have a valid DKIM signature from the domain reporting. I'm not sure how you'd go about doing that with HTTPS though since c

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

oh, shit. that was not intended to be public. apologies to all. please disregard. Mike On 1/7/21 6:57 AM, Dave Crocker wrote: On 1/7/2021 6:47 AM, Michael Thomas wrote: PS: what brought this all up was me pointing to a report which contradicted his claim, It didn't. and he na

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

PS: what brought this all up was me pointing to a report which contradicted his claim, and he nastily snarled about whether I had read it. he constantly gets away with that kind of shit and never suffers any consequences. never. yes, i've been told he's been tut-tut'd in private, but it never c

Re: [dmarc-ietf] Decorum on the DMARC WG list and BCP 94

On 1/6/21 4:21 PM, Seth Blank wrote: Working Group colleagues, Discussion on this list is increasingly out of scope and process, unproductive, and antagonistic. This behavior undermines the chartered work of this group and will not be tolerated. We expect and require more civil discourse fr

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

The AD said to stop an hour ago. So stop. On 1/6/21 10:04 AM, Dave Crocker wrote: On 1/6/2021 7:07 AM, Michael Thomas wrote: You are literally telling me what I knew at the time. They are literally doing nothing of the kind.  Since you think otherwise, please provide sufficient analysis

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/6/21 7:17 AM, Dotzero wrote:You are literally telling me what I knew at the time. It was a lot of the reason that we got push back to form the DKIM working group. It wasn't until I read that paper that I got some concrete feel for how it affected things, and that was 16 years later. The

Re: [dmarc-ietf] Header Rewriting

On 1/6/21 7:20 AM, Laura Atkins wrote: On 6 Jan 2021, at 15:14, Michael Thomas <mailto:m...@mtcc.com>> wrote: On 1/6/21 4:52 AM, Laura Atkins wrote: Most users may know who constantcontact are or mailchimp because they advertise widely. Some might have heard of GoDaddy but do

Re: [dmarc-ietf] Header Rewriting

On 1/6/21 4:52 AM, Laura Atkins wrote: Most users may know who constantcontact are or mailchimp because they advertise widely. Some might have heard of GoDaddy but do you know what the company name of the GoDaddy ESP is? I don’t off the top of my head. An extremely dubious assertion. Sourc

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/6/21 6:59 AM, Dotzero wrote: On Wed, Jan 6, 2021 at 9:41 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 1/5/21 10:02 PM, Dotzero wrote: On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas mailto:m...@mtcc.com>> wrote: No it was an unalloyed good t

Re: [dmarc-ietf] Header Rewriting

On 1/6/21 2:10 AM, Laura Atkins wrote: 2. A single study is unlikely to be definitive about much of anything. Absolutely true. Anyone relying on a single piece of evidence to prove their point is wrong. I am absolutely sure there is a bigger body of research out there and more data. In fact

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 10:02 PM, Dotzero wrote: On Tue, Jan 5, 2021 at 8:19 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: No it was an unalloyed good that you brought that up. We can use a much more data-driven approach rather than opinion and conjecture. It would be go

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 5:22 PM, Dave Crocker wrote: On 1/5/2021 5:19 PM, Michael Thomas wrote: and not snarled at as a heresy. Michael, That was yet another ad hominem from you.  As well as being grossly inaccurate. Your issue is with the authors of the study. Leave me out of this. Mike

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 5:11 PM, Douglas Foster wrote: Sorry that my name was dragged into this.   The study in question was one  provided by Laura Atkins several months ago.   I forwarded it to Michael to bring him up to speed.   To date, it is the only study submitted to this group. I was not trying to in

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 3:44 PM, Dave Crocker wrote: On 1/5/2021 2:57 PM, Michael Thomas wrote: Oh?  A trust indicator to a user, flagging a domain name, isn't pretty much the same?  Please explain. Pretty much != same. A trust indicator, to a user, flagging a domain name. Essentially the same

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 2:43 PM, Dave Crocker wrote: Your focus on email, as somehow distinctive, would need some basis for ignoring the web experience.  Feel free to provide it. Your example of web is fraught because web stuff has had visual indicators for decades now, and trying to compare EV certs isn't

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 2:07 PM, Dave Crocker wrote: On 1/5/2021 1:58 PM, Michael Thomas wrote: On 1/5/21 1:49 PM, Dave Crocker wrote: On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 1:49 PM, Dave Crocker wrote: On 1/5/2021 1:20 PM, Michael Thomas wrote: On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn'

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 1:18 PM, Dave Crocker wrote: On 1/5/2021 12:55 PM, Michael Thomas wrote: It also says with actual data that your assertion that users can't be trusted for anything is not correct. I didn't say that.  And it didn't say that. "Also, receiver filtering engines

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 12:48 PM, Dave Crocker wrote: On 1/5/2021 12:11 PM, Michael Thomas wrote: On 1/5/21 12:04 PM, Dave Crocker wrote: 1. I've looked back over his postings to this mailing list and am not finding the link you refer to.  Please post it (again). 2. A single study is unlikely

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 12:04 PM, Dave Crocker wrote: On 1/5/2021 11:34 AM, Michael Thomas wrote: On 1/5/21 11:22 AM, Dave Crocker wrote: From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/5/21 11:22 AM, Dave Crocker wrote: From: header field rewriting demonstrates that DMARC is, indeed, trivial to defeat (or rather, to route around.)  Also, receiver filtering engines are all that matter.  Real-time actions by recipients are demonstrably irrelevant to DMARC (and all other

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 1/4/21 9:46 AM, John Levine wrote: Similarly, DMARC alignment tells you nothing unless you also have a reputation for the domain. I have trouble imagining why anyone would think it's a good idea to get alignment by using third party domains that recipients don't know. You don't need to kno

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 12/31/20 10:22 AM, John R Levine wrote: To what?  The Yahoo address is the only address the scout troop has? Copy that to Reply-To: and write a mangled From: that looks troopy but passes DMARC.  Just like MLMs do. Lists at MLMs have names that the subscribers will recognize, but the sco

Re: [dmarc-ietf] auth-res vs. dmarc

sh on open tickets, stand by. On Wed, Dec 30, 2020 at 10:21 Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/30/20 10:13 AM, Alessandro Vesely wrote: > On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: >> And for the second time, that is not a DMARC problem, i

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 10:13 AM, Alessandro Vesely wrote: On Wed 30/Dec/2020 17:38:29 +0100 Dotzero wrote: And for the second time, that is not a DMARC problem, it is an auth-res problem. Standardizing the result names for dmarc authentication method is an integral part of DMARC specification. Adde

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 9:20 AM, Seth Blank wrote: Please follow the process stated by the chairs, open the tickets, and we’ll tear through the items. It’s disruptive threads that take us off task and make it feel like “five years” worth of tickets. Most in the tracker are simple and close to NOOPs if we

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 8:42 AM, Seth Blank wrote: At this point, this thread is deeply unproductive and preventing work on open tickets. Mike, I hear that you believe better normative accounting for DMARC results in auth-res is needed. If this is correct, please open a ticket, and the working group wi

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 8:22 AM, Dotzero wrote: You just stated the case as to why this discussion should be ruled out of scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan" This is the IETF DMARC working group, not the AUTH-RES working group. You gave the example of someone w

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 8:22 AM, Dotzero wrote: DMARC != Auth-res. Auth-res provides all kinds of useful information than just pass/fail. For DMARC Auth-res should provide what the policy was at a bare minimum. But none of this seems to have any normative language anywhere which is a proble

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 7:40 AM, Todd Herr wrote: I already said there is a thunderbird extension called dkim-verify that does exactly that. It says "DMARC: fail". That is highly misleading to the user. I see. I wrote "MDAs and local clients (web and mobile) at the mailbox provider",  and I was referr

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 7:35 AM, Todd Herr wrote: On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/30/20 5:48 AM, Todd Herr wrote: I propose to add two new result name codes, named after the policy requests:     dmarc=quaran

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 7:31 AM, Todd Herr wrote: On Wed, Dec 30, 2020 at 8:56 AM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/30/20 5:48 AM, Todd Herr wrote: On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely mailto:ves...@tana.it>> wrote: On Tue 29/Dec/2020

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 7:06 AM, Laura Atkins wrote: The auth-res result posted as an example of DMARC failing earlier in this thread: Authentication-Results:mx.google.com ; dkim=passheader.i=@ietf.org header.s=ietf1 header.b=aayvF8Pg; dkim=passheader.i=@ietf.org he

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 5:48 AM, Todd Herr wrote: Third-party MUAs perhaps won't, but MUAs aren't really responsible for message disposition in a way that is relevant to DMARC's primitive disposition choices, except in those cases where they're POP clients that download everything to a local message sto

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 5:48 AM, Todd Herr wrote: I propose to add two new result name codes, named after the policy requests:     dmarc=quarantine, and     dmarc=reject (of course, you only see this if the filter didn't honor the request). I do not support this, because quarantine,

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/30/20 5:48 AM, Todd Herr wrote: On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <mailto:ves...@tana.it>> wrote: On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote: > On 12/29/20 12:47 PM, Todd Herr wrote: >>> Unless those values in parens are a

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 12/29/20 12:59 PM, John Levine wrote: In article <14d833ce-0ae0-f818-fd4f-95769266a...@mtcc.com> you write: On 12/29/20 12:10 PM, John Levine wrote: A lot of tiny non-profits like Girl Scout troops use email addresses at webmail providers and send their announcements through ESPs like Const

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/29/20 12:47 PM, Todd Herr wrote: Unless those values in parens are a MUST requirement, the dmarc=fail is highly misleading. I haven't even seen any specification for the dmarc part of auth res in rfc  7601, which may be part of the problem. I don't see any normative language which would

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 12/29/20 12:10 PM, John Levine wrote: In article <5d0793ae-de65-cd1d-32ef-c909202a0...@mtcc.com> you write: On 12/29/20 10:59 AM, John Levine wrote: Don't forget o Normal forwarding of SPF validated mail o Authorized third party senders with no access to DKIM keys If by "authorize

[dmarc-ietf] pro tip: get a plugin for your MUA for DKIM/DMARC

I started using the dkim-verifier for thunderbird the other day and it's been pretty eye opening. I've been using where it just uses the auth-res rather than verifying the actual signature. I've found a few bugs, but overall it's been very enlightening as I've been seeing some pretty interes

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/29/20 11:35 AM, Todd Herr wrote: None of the validation checks bothered with the p= value in the mrochek.com DMARC policy record, because the p= value is immaterial to the validation check. Whether DMARC passes or fails is based on whether SPF or DKIM passes or fails

Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports

On 12/29/20 10:59 AM, John Levine wrote: Don't forget o Normal forwarding of SPF validated mail o Authorized third party senders with no access to DKIM keys If by "authorized" you mean authorized by the originating domain, I don' t have a lot of sympathy since they can delegate them a s

Re: [dmarc-ietf] auth-res vs. dmarc

On 12/29/20 10:01 AM, Todd Herr wrote: On Tue, Dec 29, 2020 at 12:48 PM Michael Thomas <mailto:m...@mtcc.com>> wrote: On 12/29/20 9:18 AM, Todd Herr wrote: The intent of the p= value is for the domain owner to communicate a request for message handling by the entity e

  1   2   3   >