Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
The misconfiguration is changing it after the message was signed. Once the message is signed and in the MTA-to-MTA relay system, no one should be altering the message body any more until final delivery. Barry On Mon, Jun 12, 2023 at 6:02 PM Jim Fenton wrote: > > On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > > > > > You were previously talking about inserting ">" before a line starting > > "From ", which is typically done on delivery when writing to an > > mbox-formatted mailbox file, because in that format, "From " at the front > > of a line has a specific meaning (i.e., "this is a new message"). If that > > insertion is happening in transport, then a local mailbox convention is > > leaking out into the transport environment, which means something is > > misconfigured, and all bets are off. > > > > In any case, it is not a transport conversion anticipated by the section > > you're quoting, so I've no idea why a DKIM signer might opt to handle it > > specially. > > I’m not as definite that this is a misconfiguration, but might be a > historical artifact. When we were editing RFC 4871, I remember discussing > with Eric Allman the problem with “from” at the beginning of a line. At the > time, we recognized that some messages would fail to verify because the > message would be modified in transit to add the >. IIRC this was particularly > a problem because message signing was done in a milter that operated on the > incoming leg of the message path (through sendmail, for example), when > ideally you would want signing to be done on the way out of the MTA. > > Your description of why the > was added is probably correct, but I think > there are circumstances where the > leaks out that aren’t just due to > misconfiguration. I have two messages in my bloated inbox that apparently > have had > added (many of you may have the “Communications of the ACM, May > 2023” message from April 24). They pass dkim verification, probably because > they were signed after modification. > > -Jim > > ___ > 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] DMARC2 & SPF Dependency Removal
> On Jun 12, 2023, at 6:02 PM, Jim Fenton wrote: > > On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > >> >> You were previously talking about inserting ">" before a line starting >> "From ", which is typically done on delivery when writing to an >> mbox-formatted mailbox file, because in that format, "From " at the front >> of a line has a specific meaning (i.e., "this is a new message"). If that >> insertion is happening in transport, then a local mailbox convention is >> leaking out into the transport environment, which means something is >> misconfigured, and all bets are off. >> >> In any case, it is not a transport conversion anticipated by the section >> you're quoting, so I've no idea why a DKIM signer might opt to handle it >> specially. > > I’m not as definite that this is a misconfiguration, but might be a > historical artifact. Very historic - UUCP days and it didn’t come with the “>” prefix. Thats something new to perhaps mask and avoid stripping at the MDA. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal
On 9 Jun 2023, at 22:35, Murray S. Kucherawy wrote: > > You were previously talking about inserting ">" before a line starting > "From ", which is typically done on delivery when writing to an > mbox-formatted mailbox file, because in that format, "From " at the front > of a line has a specific meaning (i.e., "this is a new message"). If that > insertion is happening in transport, then a local mailbox convention is > leaking out into the transport environment, which means something is > misconfigured, and all bets are off. > > In any case, it is not a transport conversion anticipated by the section > you're quoting, so I've no idea why a DKIM signer might opt to handle it > specially. I’m not as definite that this is a misconfiguration, but might be a historical artifact. When we were editing RFC 4871, I remember discussing with Eric Allman the problem with “from” at the beginning of a line. At the time, we recognized that some messages would fail to verify because the message would be modified in transit to add the >. IIRC this was particularly a problem because message signing was done in a milter that operated on the incoming leg of the message path (through sendmail, for example), when ideally you would want signing to be done on the way out of the MTA. Your description of why the > was added is probably correct, but I think there are circumstances where the > leaks out that aren’t just due to misconfiguration. I have two messages in my bloated inbox that apparently have had > added (many of you may have the “Communications of the ACM, May 2023” message from April 24). They pass dkim verification, probably because they were signed after modification. -Jim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] version bump to DMARC2
Barry, sorry if it sounded like I was pushing back. The short version is - no I don't have any big concerns. But if we discover something, we'll let you know ASAP. The longer version: Regarding #1: what I've seen in our data matches your observation. It is a small subset of cases where there would be a change in DMARC policy. Regarding #2: I don't (yet) have an exhaustive evaluation for this on our end. I think we can make assumptions that always makes a more secure assumption and in the rare cases that is not inline with the sender's intentions - we would have to deal with that. I think that sticking with v=DMARC1 vs changing it to v=DMARC2 both have pros and cons. And based on all the discussions I don't think there is an objectively preferred way (when we consider the PSL tree walk only) since it depends on what each of us value. I've always said that I think changing the version is preferred based on what I value - but if the consensus is to not do that - I understand and will support that decision too. If we add the removal of SPF from DMARC I think that is similar to the PSL tree walk discussion. That could be done both with or without a version change I think. Depending on what you value - one is preferred over the other. I got a response from JohnL privately and apparently the VLMP he mentioned is not Google so my clarification was not needed. But I think it is good that we got our standpoint clarified to avoid misunderstandings. /E On Fri, Jun 9, 2023 at 5:41 PM Barry Leiba wrote: > Keep in mind that we have looked at this extensively, and what we've > found is this: > > 1. Almost all [1] of the DMARC senders out there will see the same > results when recipients look them up using the tree walk as they have > using the PSL. In other words, the change will be different an > *extremely* small set of DMARC domains. > > 2. In *all* -- by that I mean 100% -- of the cases that we've actually > *seen* where there's a difference, the difference is *better*: that > is, the difference is a better reflection of the intent of the sending > domain. > > 3. We can find theoretical cases where the tree walk will be *worse*: > that is, where the PSL is a better reflection of the intent than the > tree walk is. But *all* of these are theoretical, and we have not > found *any* such cases that actually exist in the real world. It is, > though, possible that they do exist. > > Emil, given those three points, do you still think you need to be > concerned about the risk of making the change? > > Barry > > [1] In mathematics, we use "almost all" as an actual technical term > that applies to an infinite set and means "all but a finite number", > since removing a finite number of entries from an infinite set still > leaves an infinite set. That's kind of what I mean here. That is, > the vast, vast, VAST majority. > > On Sat, Jun 10, 2023 at 12:26 AM Emil Gustafsson > wrote: > > > > Not sure if I am that someone mentioned. In case I am - I'd like to > clarify what I meant; > > > > Without a version change for the tree-walk, I think we (Google) would > need to support both approaches (the old one plus the tree-walk) and based > on what we see - make a best guess which version we should use. > > Having two explicit versions still means we have two implementations, > but at least we don't have to guess which one to use whenever there would > be ambiguity with a single version. > > > > I'm always concerned about what bad people do to gain an advantage. But > in this case I'm more worried about somebody having an ambiguous DMARC > setup where VLMPs end up guessing the wrong intention. The most likely > outcome there would be rejected emails and an upset sender the VLMP need to > deal with. But atleast they are not spoofed. I think explicit versioning > helps mitigate that risk too (but it wont help companies making bad > configurations - but that we always have to live with). > > > > /E > > > > On Thu, Jun 8, 2023 at 10:21 AM John Levine wrote: > >> > >> It appears that Tobias Herkula said: > >> >However, such a fundamental shift in the protocol's architecture > warrants a clear signifier. I suggest we upgrade > >> >our DMARC version string from the current state to 'DMARC2.' This > upgrade would not only denote the change of SPF > >> >removal, but also the switch from the Public Suffix List (PSL) to the > Tree-Walk algorithm. > >> > >> I was talking with someone from a Very Large Mail Provider who told me > that > >> if we keep the same version number, they won't change what they do now, > so > >> no tree walk even if we keep SPF. > >> > >> They understand that as things stand now, the results of the PSL and > >> the tree walk are in practice the same. Their concern is that if some > >> people do it the old way and some the new, and you can't tell which > >> the domain expects, bad guys will create records with deliberately > >> inconsistent results. > >> > >> I'm not sure how likely that is, but arguing with a
