Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
On Thu, Apr 6, 2023, at 11:43 AM, Murray S. Kucherawy wrote: > > > On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote: >> __ >> I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't >> remember) >> >> I'm struggling to understand how ATPS is significantly better than >> delegation via DKIM CNAME records. I can see that it's simpler for a domain >> owner because they need only set 1 ATPS record vs. sometimes 3 CNAME records >> (for key rotation). But that's not enough to justify adoption. > > ATPS is Experimental. I don't think it's a serious candidate for solving the > DMARC problem. There's also a "conditional signatures" draft floating around > someplace. I'm just spit balling experimental ideas, of course, under the assumption of my prior statement, which was something along the lines of: equipping domain owners with more fine-grained delegation capabilities would reduce the amount of p=reject breakage for perpetual mixed-use domains. > To answer your question, ATPS was among other things a substitute for > delegation via CNAME when the author domain doesn't want to give some other > party the ability to generate its own signatures as the author domain. There > was never, at the time it was written, a demand for doing this at a user > level. Also, DKIM has never been tied to specific individual email addresses > because there's no reliable way for an external entity to verify that the > email address is even real, much less meaningful within the domain. This was > ultimately why use of "i=" in the DKIM signature never really took off. If my understanding is correct, the "i=" in the signature can be arbitrarily set by the signer, which already has delegated authority of the entire domain, so what's the purpose of setting it? That [lack of purpose] seems like a more likely reason it never took off (if I had to make a wild guess) I don't think that particular usage of "i=" is an apt comparison to a domain owner delegating [via some DNS record] signing authority for a single address. The DNS entry could reference any 'non-real' address, of course... until it is seen in the rfc5322.from and the receiver finds the DNS entry, at which point it becomes as real as the domain owner intended it to be used by the signer for that purpose. Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: >On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: >> I don't feel strongly about N=10, but I do feel strongly that N=5 is >> insufficient. My gut feel is that 6 or 7 is likely more than enough to cover >> all real world examples, but it's a gut feel only and not backed by data. > > >IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 >(instead of 4), and then say that N=5 is the value we currently consider good >but recommend to make it configurable. Or we could leave the text as is (if >it's easier to understand it that way) and just recommend to not hardcode "5" >and "4". > I don't think everyone picking their own N is going to promote interoperability. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] THIS IS ABUSE (no it's not)
This is not a significant problem in my experience. To the extent this is a problem I think it's primarily a list owner problem, not an Internet protocol problem. Not kidding that if I ran this list I'd probably kick you off the list for awhile to give you a chance to ponder the error of your ways. Don't do this. Scott K On April 6, 2023 8:53:46 PM UTC, someone wrote: >I hope Alex won't get offended by this innocent DMARC test. > >Are we sure that it is all right for mailing lists to allow spoofs and >impersonation? I don't think Comcast has p=reject to safeguard Alex's >contribution to this list, but what if he can't stand being impersonated? >What else is he supposed to do besides setting p=reject? > >THIS LIST TAKES ALL OF THE BAD OF DMARC, NONE OF THE GOOD. > >Best >Ale > > > >___ >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] Example of Indirect Mail Flow Breakage with p=reject?
Hi, Le 06/04/2023 à 20:05, Dotzero a écrit : > > So Baptiste, what responsibility do you expect these organizations to > undertake? I'm asking this as a serious question, not a rhetorical one. > In all seriousness they are/were focused on addressing their, > potentially existential, problems and not those of others. One might > state that is a very selfish attitude. […] Well, for a start I only expect that everybody recognize who exactly is responsible for the breakage. There seems to not even be a clear agreement inside this list. This group has to make a decision and record it in the standard (and a MUST NOT might well be the way to express it). And yes, selfish organizations might ignore the standard and willingly break interoperability. Then there's nothing we can do. But for those who care about fixing what they break, pointing fingers at the right place is a necessary start. Also, impacted mailing lists can more easily retaliate against the selfish if their bad faith is obvious. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
On Thu, Apr 6, 2023 at 9:19 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hallo, > > Le 06/04/2023 à 01:46, Dotzero a écrit : > > > > Not at all. The discussion (and specific post I was responding to) was > > about mailing lists but it also applies more generally. A number of > > years ago I saw bounces from a Polish domain. Their policy was that if > > the From and the Mail From didn't match they would reject the inbound > > email. I find that absurdly limiting but they can implement whatever > > policy they want. Maybe there are sending domains that do that for all > > their mail. My point is that domain owners/admins, at least on certain > > levels, get to choose how they interact with other networks/servers. > > Yeah, but this is where DMARC comes in, and muddies the responsibilities > that come with those choices. Originating domains (quoting Todd Herr) > just "use p=reject as a signal to declare that they got all outgoing > mail authenticated". Evaluators candidly comply with the originator's > wish to have unauthenticated mail rejected. None of them is taking > responsibility for the breakage they collectively are causing to mailing > list (etc…) operation. > Again, not at all. You are quoting Todd's opinion, which does not equal a fact. A domain publishing a p=reject policy is only a signal that the domain wishes email that fails to validate to be rejected, nothing more and nothing less. When we (Yes, I was part of the original dmarc.org team) created DMARC and published it in 2011, we were focused on a point solution to what we perceived as a point problem. That was direct domain abuse of transactional emails from organizational domains which had few or no end users. We recognized that there was a risk of DMARC being implemented by domains with many individual users but felt that the potential downsides limited the likelihood of that happening. When Yahoo and AOL implemented DMARC with a p=reject policy within weeks of each other in 2014, it was because each organization was enduring major impersonation attacks against their users. My understanding is that in both those cases the decision to publish p=reject was made by the top business leader(s) of each organization as a business decision, not a technical one. Since that time, many other organizations with lots of end users have faced similar attacks. So Baptiste, what responsibility do you expect these organizations to undertake? I'm asking this as a serious question, not a rhetorical one. In all seriousness they are/were focused on addressing their, potentially existential, problems and not those of others. One might state that is a very selfish attitude. I would agree and then suggest such a statement changes nothing. I haven't faced that situation or choice so I'm not in a position to answer what I would personally do if faced with those choices. I will point out that in many cases organizations make the decision as a result of being under attack. Avalanches of bounces inflicted upon uninvolved third parties are a > major interoperability problem caused by DMARC. This should not happen > without either the originator or the evaluator breaking a MUST > requirement. Otherwise, DMARC itself is responsible for the breakage. > I again invoke King Canute. There are other things which can cause avalanches of bounces. It's a shame. The fact that it is happening suggests that mailing list operators and others face choices. Simply wagging a finger and shouting "YOU BROKE A MUST NOT" is hardly an effective response. > > > I also don't think it would be pretty but it's within the realm of > > options they can choose from. > > You talk, but you know they won't really do it. Because they're not > trying to coerce you into changing your way of operating. > I personally don't know what (generic) others will or won't do. If faced with avalanches of bounces and the risk of getting blocked overall by large receivers, some list owners have in fact blocked inbound messages from domains which publish p=reject. This may have been a temporary expediency while they decided on other measures, but it has happened. > > BTW, From munging has not become any "neater" than it was 2 years ago. > Or 2 years before. As long as there is no proven solution (ARC?), > rehashing the same pseudo-moral arguments is not helpful. > I certainly haven't engaged in pseudo-moral arguments. I'm looking at it from a very pragmatic perspective. Do you create or update standards based on the reality of what is happening or do you take an Ivory tower approach in which the standard you promulgate bears little relationship to what is happening in the real world? I think Ale's post to the list impersonating Alex is a perfect example of why playing the "MUST NOT" card is insufficient and should be reconsidered. Michael Hammer ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected
On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: I don't feel strongly about N=10, but I do feel strongly that N=5 is insufficient. My gut feel is that 6 or 7 is likely more than enough to cover all real world examples, but it's a gut feel only and not backed by data. IMHO we could rewrite the algorithm in terms of N (instead of 5) and N-1 (instead of 4), and then say that N=5 is the value we currently consider good but recommend to make it configurable. Or we could leave the text as is (if it's easier to understand it that way) and just recommend to not hardcode "5" and "4". Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
On Sat, Apr 1, 2023 at 3:13 PM Jesse Thompson wrote: > I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I > can't remember) > > I'm struggling to understand how ATPS is significantly better than > delegation via DKIM CNAME records. I can see that it's simpler for a domain > owner because they need only set 1 ATPS record vs. sometimes 3 CNAME > records (for key rotation). But that's not enough to justify adoption. > ATPS is Experimental. I don't think it's a serious candidate for solving the DMARC problem. There's also a "conditional signatures" draft floating around someplace. To answer your question, ATPS was among other things a substitute for delegation via CNAME when the author domain doesn't want to give some other party the ability to generate its own signatures as the author domain. There was never, at the time it was written, a demand for doing this at a user level. Also, DKIM has never been tied to specific individual email addresses because there's no reliable way for an external entity to verify that the email address is even real, much less meaningful within the domain. This was ultimately why use of "i=" in the DKIM signature never really took off. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
Hallo, Le 06/04/2023 à 01:46, Dotzero a écrit : > > Not at all. The discussion (and specific post I was responding to) was > about mailing lists but it also applies more generally. A number of > years ago I saw bounces from a Polish domain. Their policy was that if > the From and the Mail From didn't match they would reject the inbound > email. I find that absurdly limiting but they can implement whatever > policy they want. Maybe there are sending domains that do that for all > their mail. My point is that domain owners/admins, at least on certain > levels, get to choose how they interact with other networks/servers. Yeah, but this is where DMARC comes in, and muddies the responsibilities that come with those choices. Originating domains (quoting Todd Herr) just "use p=reject as a signal to declare that they got all outgoing mail authenticated". Evaluators candidly comply with the originator's wish to have unauthenticated mail rejected. None of them is taking responsibility for the breakage they collectively are causing to mailing list (etc…) operation. Avalanches of bounces inflicted upon uninvolved third parties are a major interoperability problem caused by DMARC. This should not happen without either the originator or the evaluator breaking a MUST requirement. Otherwise, DMARC itself is responsible for the breakage. > I also don't think it would be pretty but it's within the realm of > options they can choose from. You talk, but you know they won't really do it. Because they're not trying to coerce you into changing your way of operating. BTW, From munging has not become any "neater" than it was 2 years ago. Or 2 years before. As long as there is no proven solution (ARC?), rehashing the same pseudo-moral arguments is not helpful. Cheers, B. Carvello ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
