Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08
On Fri, Jan 22, 2021 at 5:01 PM Tim Wicinski wrote: > Since this is an experiment, Appendix A discusses the updates that > happen. we don't actually say explicitly "if the experiment is a success, > the following changes will be made" and perhaps I should add some wording > like that. > Something like this, perhaps? "A standards track update to [RFC7489] will take into account the results of this experiment." ... somewhere in Section 1. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] report floods, not Forensic report loops are a problem
OK, let's hop into your example. I care enough about DMARC to send reports about it, and I want to send all of my mail aligned. I send a test message that ends up unaligned somehow, perhaps through a broken relay I don't own, and I would ideally like to get one message back that tells me that. If I happen to send my test to a place that unintentionally sends an unaligned report back to me, perhaps because of the same relay, I'm going to get flooded, even though my local setup is verifiably correct. And, probably, so are they. Report floods could be a problem, but they're a general problem that don't have a lot to do with failure loops. I used to get buckets of failure reports about random chinese spam that forged my domains on the From line. It's reasonable to say that reporters should rate limit failure reports to avoid flooding recipients, but that's true no matter who sent the mail being reported. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On Thu, Jan 28, 2021 at 1:42 PM John R Levine wrote: > > This to me is almost exactly the same thing as saying "Don't generate a > > bounce about a bounce", > > Because these are not bounces. They are not even a little bit like > bounces. Bounces are about invalid recipient addresses, but these have no > relation to anything about the recipient address. > Yes, I realize the difference. I was making an analogy. They are fresh new messages sent from a system that presumably cares > enough about DMARC to send reports about it, and presumably wants to send > all of its mail with DMARC alignment. If they are unaligned, that is > because the sending system is broken, and if that systems publishes an > ruf= tag, it is specifically asking to be inforned about exactly that > breakage. > OK, let's hop into your example. I care enough about DMARC to send reports about it, and I want to send all of my mail aligned. I send a test message that ends up unaligned somehow, perhaps through a broken relay I don't own, and I would ideally like to get one message back that tells me that. If I happen to send my test to a place that unintentionally sends an unaligned report back to me, perhaps because of the same relay, I'm going to get flooded, even though my local setup is verifiably correct. And, probably, so are they. You're saying the only real answer here is that the two end operators in this example need to fix their evidently-crappy setups, or change their DNS records to remove the "ruf" value until they can get the guy in the middle to fix whatever's broken? Maybe I'm the dim one, but I can't see why it's manifestly absurd to think we might somehow augment either the report or the message containing it by adding just enough metadata someplace to signal one end or the other, or both, to avert the flood. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
C) Stipulate somehow that generated reports should not contain data about received reports. (If you do that, then you likely obviate the need to generate a new report back to that operator in the first place.) I can't even tell what might be a failure report without deep parsing and heuristics. And, of course, I am not inclined to add extra code to program around other people's bugs. This to me is almost exactly the same thing as saying "Don't generate a bounce about a bounce", Because these are not bounces. They are not even a little bit like bounces. Bounces are about invalid recipient addresses, but these have no relation to anything about the recipient address. They are fresh new messages sent from a system that presumably cares enough about DMARC to send reports about it, and presumably wants to send all of its mail with DMARC alignment. If they are unaligned, that is because the sending system is broken, and if that systems publishes an ruf= tag, it is specifically asking to be inforned about exactly that breakage. Maybe I'm dim, but I am having no success understanding the apparent interpretion of ruf as "tell me about the unaligned messages I'm sending, except for some that should be really easy for me to fix." Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On Wed, Jan 27, 2021 at 7:08 PM John R Levine wrote: > Which of these should we do: > > A) Everyone in the world who produces failure reports adds special cases > to look for incoming failure reports, and heuristics to try and recognize > failure reports in the wrong format, and when it finds one of them, it > makes a note not to send a failure report about it. > > B) Someone slaps me upside the head and I fix my SPF record so my reports > are sent correctly. > I'm suggesting: C) Stipulate somehow that generated reports should not contain data about received reports. (If you do that, then you likely obviate the need to generate a new report back to that operator in the first place.) This to me is almost exactly the same thing as saying "Don't generate a bounce about a bounce", which has been part of SMTP for decades (it's a SHOULD NOT in 2821). I don't understand why you're saying it's appropriate in one but a non-issue in the other. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On Thu, Jan 28, 2021 at 4:13 AM Alessandro Vesely wrote: > > DKIM (in its simplest form) returns N tuples of the form (d= domain, > > pass/fail). All of them were run through exactly the same check; all of > > them were attached to the message in exactly the same way; all of them > have > > essentially identical semantics. Giving them equal footing makes sense > to > > me. > > > > The two identifiers in SPF hold different places in the SMTP session, and > > have different semantics. I think treating them differently is also just > > fine. > > It is relevant that both identifier come from /the same/ SMTP session. > That's > not true for many DKIM signatures. > I guess if report consumers really want this information, we can include it. I just don't see the value in the HELO parameter if it's effectively random junk in the session. At least a passing DKIM signature is associated with a domain that existed at some point in time and whose DNS contained apparently-valid public keys. I can mostly type anything I want to HELO or EHLO. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Forensic report loops are a problem
On Thu 28/Jan/2021 04:17:06 +0100 Steven M Jones wrote: On 1/27/21 12:47, Murray S. Kucherawy wrote: On Wed, Jan 27, 2021 at 12:37 PM John Levine wrote: I still don't understand why failure reports about messages that happen to be failure reports are in any way special. >> Loop detection in RFC 5321 is a normative MUST because of the obvious operational problems it creates. Maybe I'm being thick, but right now I don't see how this is different, apart from the fact that each message is distinct; you're still causing a problem by turning this on without a care in the world about whether two verifiers start spamming each other. > There's coverage in 7489 Section 7.2 that a domain owner can inadvertently DDoS themselves via failure reports. And that still surprised many implementers, even though it seemed obvious to them in retrospect. > This case is even less obvious, and we still have questions coming in about it from new implementers. > I don't think it's a security consideration because it doesn't scale up the way "ruf" can, so it deserves a brief mention here. But I would rephrase Ale's last sentence: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken for authentication, as failure to authenticate failure reports may result in mail loops. These loops can be mitigated by sending reports from a domain or subdomain that doesn't request reports, or by performing rate limiting for report receiving mailboxes. I rephrased it further: 3.3. Transport Email streams carrying DMARC failure reports MUST conform to the DMARC mechanism, thereby resulting in an aligned "pass". Special care must be taken of authentication, as failure to authenticate failure reports may result in mail loops. These loops can be mitigated by sending reports from a domain or subdomain that doesn't request reports, or by performing rate limiting especially for failures related to messages received at addresses published in a ruf= tag. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] understanding section 7.2
On Wed 27/Jan/2021 21:18:50 +0100 Michael Thomas wrote: On 1/27/21 12:14 PM, Murray S. Kucherawy wrote: The schema's already pretty large, and probably has to be, but maybe a trivial example report would be reasonable to craft and include? Yeah, that might do too. +1. It can be produced starting from a real report and replacing IPs and domain names with exemplifying ones. I think it's important that it be in section 7.2 though because you should be able to read that section and understand what the report is and isn't. The full report should go in an appendix, because it is too long to make sense in the middle of text. Section 7.2 may show the corresponding tabular form[*], which provides for a visual summary of fields, and reference the appendix. Best Ale -- [*] A tabular form is showed here: https://en.wikipedia.org/wiki/DMARC#Aggregate_reports ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On Wed 27/Jan/2021 21:10:37 +0100 Murray S. Kucherawy wrote: On Wed, Jan 27, 2021 at 9:26 AM Alessandro Vesely wrote: AFAIUI, there's no reason why SPF would work with a logic substantially different than DKIM's. DKIM can provide n identifiers, if one of them is aligned and "pass", then DMARC is "pass". SPF can provide 2 identifiers but one of them is of class B. WTF? DKIM (in its simplest form) returns N tuples of the form (d= domain, pass/fail). All of them were run through exactly the same check; all of them were attached to the message in exactly the same way; all of them have essentially identical semantics. Giving them equal footing makes sense to me. The two identifiers in SPF hold different places in the SMTP session, and have different semantics. I think treating them differently is also just fine. It is relevant that both identifier come from /the same/ SMTP session. That's not true for many DKIM signatures. In addition, as I said, SPF filters are likely to report HELO as helo and MAIL FROM as mailfrom. If we want to carry over this quirk, the spec must say that a DMARC filter which gathers SPF authentication status from an upstream filter MUST make sure that mailfrom is empty before validating based on an aligned helo. > ...or it doesn't evaluate against SPF at all in such a situation. Dropping SPF altogether is too much. I'm querying about dropping just the idiosyncrasy... Dropping that absurd discrimination between SPF identifiers would make for a smoother spec. Since non-null mailfroms are in most cases aligned with either From: or helo, the differences between existing compliant implementations and the smoother spec would be limited to a hardly noticeable set of test messages. > I don't think we should ignore what those two identifiers mean, how likely they are to contain junk, how they are applied, outside of DMARC, etc. How is that different from d= identifiers? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Ticket #1 - SPF alignment
On Wed 27/Jan/2021 20:24:05 +0100 Scott Kitterman wrote: On Wednesday, January 27, 2021 12:25:59 PM EST Alessandro Vesely wrote: Can we fix this aberration? The spec needs a fix anyway, because from the text I quoted above I understood that the example message passes DMARC. Am I the only one? In addition, as I said, SPF filters are likely to report HELO as helo and MAIL FROM as mailfrom. If we want to carry over this quirk, the spec must say that a DMARC filter which gathers SPF authentication status from an upstream filter MUST make sure that mailfrom is empty before validating based on an aligned helo. Dropping that absurd discrimination between SPF identifiers would make for a smoother spec. Since non-null mailfroms are in most cases aligned with either From: or helo, the differences between existing compliant implementations and the smoother spec would be limited to a hardly noticeable set of test messages. Your absurd is my eminently reasonable. I can't explain why it was added, but it makes sense, IMO, to have it there to aid in reconstructing the exact situation for trouble shooting purposes. Can you expand on how ignoring helo aids trouble shooting? DMARC has always (for the SPF related portion) been about alignment of mail from and from. I don't think adding HELO has appreciable value and is certainly not worth the added complexity to implement DMARC to include. From an implementer POV, the complication stays in the idiosyncratic identifier processing. I wonder how many do follow it strictly. IMHO, a reasonable DMARC spec should either smooth out the discrimination or provide a clear explanation of why such peculiar processing is needed and what would happen if all identifiers were treated equal. There are lots of ways that DMARC could have addressed SPF. Personally I thought it might make sense to skip using the mail from SPF result and just check if the from address would pass if it were subjected to an SPF check, but that's not the existing design. I don't think it should be changed now. Yeah, after you insisted, I vaguely recollected about an SPF argument that I had erased from memory. I can't recall its merit. DKIM'S d= are domains, and DKIM scope is exactly to identify a domain. That's more akin to helo than mail from. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
