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

For indirect mail, the aligned signature selector tells you where to look for the message origin. The last hop information tells you where it ended up. For direct messages, the last hop tells you whether it came from a third party or internal server, and the aligned signature selector confirms the

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

On Tuesday, January 26, 2021 11:47:51 AM EST Alessandro Vesely wrote: > On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote: > > On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote: > >> On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote: > >>> On Monday, January 25, 2021 4

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 > 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 to do is send a mail cannon

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 4:19 PM Michael Thomas 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 to do > is send a mail cannon to mimic Marsha in Marketing every once in a while > and the entire

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 their authorize

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 > 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 a outsourced email b

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 > 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 of using DMARC aggre

Re: [dmarc-ietf] attack on reports

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 their authorized sending sources. If that were common, t

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 3:17 PM Michael Thomas 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 a outsourced email blaster? > This is solved with conversation with the relevant stake

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 3:16 PM Michael Thomas wrote: > > On 1/26/21 12:01 PM, Todd Herr wrote: > > On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas 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

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 > 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 with the reporting domain

Re: [dmarc-ietf] attack on reports

On Tue, Jan 26, 2021 at 2:24 PM Michael Thomas 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 with the reporting domain or the reported source IP. >> > That is to say, I won't be able to deduce if the

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 Tue, Jan 26, 2021 at 1:01 PM Michael Thomas wrote: > > 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

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 to it. W

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

Doing it now might overload the WG. If DKIM for binary has its own merit, we can just hypothesize we'll do. Meanwhile we can mention it and suggest to use it for https: when it comes, if ever. After all, that's what RFC 2045 does with "binary". Since client certificates exist and http DKIM

Re: [dmarc-ietf] attack on reports

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 to it. With a record for each message it wouldn't be an

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

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

On Tue 26/Jan/2021 18:23:35 +0100 Murray S. Kucherawy wrote: On Tue, Jan 26, 2021 at 9:16 AM John R Levine wrote: Sheesh. That isn't mission creep, it's mission gallop. The spec can be commissioned to a narrowly focused WG (like dcrup). Really, no. It's something we might think about on i

[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] Ticket #42 - Expand DMARC reporting URI functionality

On Tue, Jan 26, 2021 at 9:16 AM John R Levine wrote: > >> Sheesh. That isn't mission creep, it's mission gallop. > > The spec can be commissioned to a narrowly focused WG (like dcrup). > > Really, no. It's something we might think about on its own merits some > other time, but its absurd to try

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

On Tue, 26 Jan 2021, Alessandro Vesely wrote: Won't we put a DKIM-Signature: in the http: header? Sheesh. That isn't mission creep, it's mission gallop. The spec can be commissioned to a narrowly focused WG (like dcrup). Really, no. It's something we might think about on its own merits so

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

On Tue 26/Jan/2021 15:12:57 +0100 Douglas Foster wrote: At some point, an investigator will ask, "which of our systems sent these messages?" Possibly none. In that case this is either an abuse or a forward. Or maybe the report generator lies. I know how to search my logs for messages to

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

On Tue 26/Jan/2021 14:14:45 +0100 Scott Kitterman wrote: On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote: On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote: On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote: May I propose that the section labeled "SPF-Authent

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

At some point, an investigator will ask, "which of our systems sent these messages?" I know how to search my logs for messages to domain example.com. I do not know how to search my logs for messages to domains hosted by hostingservice.tld. That is why I would expect SMTP To domain to be useful.

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

On Tuesday, January 26, 2021 6:54:56 AM EST Alessandro Vesely wrote: > On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote: > > On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote: > >> May I propose that the section labeled "SPF-Authenticated Identifiers" be > >> rewritten as follows: >

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

On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote: DKIM Scopes I have not heard a compelling argument to require information about authentication tests that are unrelated to alignment testing.    For DKIM specifically, I think one scope should be sufficient, on this hierarchy: - The best

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

This topic becomes much more than "which signature". It is really about "what is needed to identify and correct alignment problems". Based on the authentication discussion, we have several inter-related issues: - I started with a concern about putting excessive data collection requirements on th

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

On Mon 25/Jan/2021 22:35:09 +0100 Scott Kitterman wrote: On Monday, January 25, 2021 4:04:33 PM EST Todd Herr wrote: May I propose that the section labeled "SPF-Authenticated Identifiers" be rewritten as follows: [...] The reader should note that SPF alignment checks in DMARC rely solely

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

On Mon 25/Jan/2021 22:22:25 +0100 John Levine wrote: 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 ne