Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/13/2020 11:17 PM, Dave Crocker replied to Jim Fenton wrote: Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and more about possible use/abuse by other agencies? Dave, It didn't look good when the IETF officially abandoned the ADSP protocol citing technical quality issues, yet helped a special interest group reintroduce "Super ADSP" under a different name with the same exact technical quality issues and fast tracked it as an informational RFC proposal. -- Hector Santos, https://secure.santronics.com https://twitter.com/hectorsantos ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/13/2020 7:53 PM, Jim Fenton wrote: Alas, others do, Other groups do all sorts of things. They once mandated OSI, for example. Please explain how that is relevant, here and now. Are you perhaps suggesting that the technical work of the IETF should worry less about technical quality and more about possible use/abuse by other agencies? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 6/13/20 1:13 PM, John Levine wrote: > In particular, there is no chance whatsoever that any DMARC policy > will become mandatory, because the IETF doesn't do mandatory. Alas, others do, apparently because they see that DMARC has an RFC number (even though it's informational). For example, in https://cyber.dhs.gov/bod/18-01/ : "All agencies are required to...enhance email security by...Within one year after issuance of this directive, setting a DMARC policy of “reject” for all second-level domains and mail-sending hosts." ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 2020-06-13 22:13, John Levine wrote: In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write: The "mailing list problem" was introduced into this discussion as an objection to DMARCs progress, by implication suggesting that DMARC must be delayed until a solution is found which creates no inconvenience to mailing list operators. At this point I truly have no idea what your point is. The fact that DMARC screws up mailing lists is enough of a problem that a lot of people have put considerable time and money into inventing and implementing ARC. even if ietf tribble dkim sign mails it still gives X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on localhost.junc.eu X-Spam-Status: No, score=-9.3, required=5.0, Autolearn=unavailable autolearn_force=no, LastExt=4.31.198.44 X-Spam-Rules_score: DKIM_INVALID=0.1,DKIM_SIGNED=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25,LOCAL_WHITELIST_URI=-0.5, MAILING_LIST_MULTI=-10.1,SPF_HELO_NONE=1.1,SPF_PASS=-0.1 hmm ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On 2020-06-13 18:42, John Levine wrote: In article you write: I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.) I can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user login. ... That's OK, the rest of us can. if no one breaked dkim then arc would not even be needed IMHO ietf is gone to far of fixing problems ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
In article <2bf78d7529ba4c5e935315d767783...@bayviewphysicians.com> you write: >The "mailing list problem" was introduced into this discussion as an objection >to DMARCs >progresss, by implication suggesting that DMARC must be delayed until a >solution is found which >creates no inconvenience to mailing list operators. At this point I truly have no idea what your point is. The fact that DMARC screws up mailing lists is enough of a problem that a lot of people have put considerable time and money into inventing and implementing ARC. More than that, DMARC exists, it's deployed, it's not going to change beyond minor tweaks to clarify unclear parts of the spec, perhaps to deprecate minor parts that don't work the way we anticipated, and perhaps minor additions like https reporting. In particular, there is no chance whatsoever that any DMARC policy will become mandatory, because the IETF doesn't do mandatory. The word MUST only means "do this to interoperate with other systems", not do this or else. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
The "mailing list problem" was introduced into this discussion as an objection to DMARCs progresss, by implication suggesting that DMARC must be delayed until a solution is found which creates no inconvenience to mailing list operators. That concerns me, First, a a new solution has not really been proposed; all of the discussed options are already available to mailing list operators. Secondly, articulating a required mailing list operational mechanism is unlikely to produce rapid or uniform adoption. The supposed problem is not big enough to warrant that much control over this initiative. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
In article you write: >I suggest that the "Mailing List Problem" is a problem that does not need to >be solved (and evidence suggests that it cannot be solved.) I >can think of no purpose served by a public mailing list, like this one, which >is not be better solved by a community forum website with user >login. ... That's OK, the rest of us can. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Minutes from Interim uploaded
All The minutes from the Etherpad have been uploaded into the meeting materials. You can review them here: https://datatracker.ietf.org/doc/minutes-interim-2020-dmarc-01-202006111600/ If there are any incorrect statements please let the chairs know. Alternatively, a pull request will also work: https://github.com/ietf-wg-dmarc/wg-materials/blob/master/interim-2020-dmarc-01/interim-2020-dmarc-01-minutes.txt thanks tim ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
About this comment If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed. Based on the response to my previous post, "Trained User" is not a meaningful concept, for purposes of this discussion. However, a user who subscribes to a mailing list should be able to recognize its distinctive message characteristics, so I think training is not a significant issue. I have had fun looking at the different ways that IETF mailing list entries are presented in my different MUAs. More to the point: I suggest that the "Mailing List Problem" is a problem that does not need to be solved (and evidence suggests that it cannot be solved.) I can think of no purpose served by a public mailing list, like this one, which is not be better solved by a community forum website with user login. Even in its heyday, I think mailing list subscribers were a narrow subset of email users, heavily skewed toward Unix-oriented technology people. Solving the mailing list problem seems like saying, "I want a secure and reliable way to order my Walmart groceries using the text feature of my flip-phone." It is time for a different technology. There are other indirect mail scenarios that are problematic, but these seem well understood and I do not see that any improvement is available. These include: DKIM (configured at the sender), SRS Encoding (configured at the forwarder), and Trusted forwarder registration or another exception mechanism (configured at the recipient filter).Incoming email filters have inadequacies when looking backward on a forwarded message, but this mailing list is not concerned with specifying the desired features of incoming mail filters. DF From: devel2...@baptiste-carvello.net Sent: 6/13/20 8:04 AM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem Hi, I'm but a mere user, but I cannot let this be presented as an obvious or consensual solution. Header munging is inadequate because: 1) It makes the wrong tradeoffs. DMARC started as a solution for a very specific problem (phishing targetting high impact domains) and made tradeoffs accordingly. Now that it is deployed as a general anti-spam tool, the appropriate tradeoffs are different: most users are willing to live with some degree of spam rather than have their communication tampered with and their name associated with random intermediaries. "Fait accompli" is not acceptable, even if you call it "de-facto standard". 2) It buys you nothing. As was discussed last week, DMARC by design relies on the expectation that users (or their MUA's adress book) will recognize legitimate From addresses. If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed. Cheers, Baptiste Le 12/06/2020 à 10:02, Alessandro Vesely a écrit : > Hi all, > I'm sorry I didn't queue to talk yesterday. After so many months without > speaking one word of English, I really didn't feel like... > > > *Why ARC cannot solve the mailing list problem* > === > > Assume all mailing lists in the world duly did ARC. Somewhat > science-fictitious, given that some of them are not even able to add valid > DKIM > signatures. Let's hypothesize they all did ARC, anyway. Would the mailing > list problem be solved? No, because recipients cannot blindly accept DMARC > failures just because there is an ARC-chain claiming authenticity. Doing so > would completely defeat DMARC, because ARC chains can be forged. > > In order to safely override a reject or quarantine policy based on ARC, a > receiver needs a complete list of legitimate mailing lists. Conversely, having > such a list, a receiver can override DMARC failures also based on DKIM or SPF > authentication. ARC adds nothing to the mailing list problem. (However, huge > mailbox providers do have a complete list of legitimate MTAs. That's where ARC > is useful, AIUI.) > > > *From rewriting is the real thing* > == > > Rewriting From: is the de-facto standard. In a (science-fictitious) scenario > where all mailing lists rewrite the From: header field, DMARC would just work > smoothly. > > Hence, we have to specify an acceptable way to rewrite From:. > > > I'd have said so. > > 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] Header munging, not ARC, can solve the mailing list problem
Hi, I'm but a mere user, but I cannot let this be presented as an obvious or consensual solution. Header munging is inadequate because: 1) It makes the wrong tradeoffs. DMARC started as a solution for a very specific problem (phishing targetting high impact domains) and made tradeoffs accordingly. Now that it is deployed as a general anti-spam tool, the appropriate tradeoffs are different: most users are willing to live with some degree of spam rather than have their communication tampered with and their name associated with random intermediaries. "Fait accompli" is not acceptable, even if you call it "de-facto standard". 2) It buys you nothing. As was discussed last week, DMARC by design relies on the expectation that users (or their MUA's adress book) will recognize legitimate From addresses. If you teach users that "Joe User by Random Intermediary" is the same as "Joe User", this expectation is doomed. Cheers, Baptiste Le 12/06/2020 à 10:02, Alessandro Vesely a écrit : Hi all, I'm sorry I didn't queue to talk yesterday. After so many months without speaking one word of English, I really didn't feel like... *Why ARC cannot solve the mailing list problem* === Assume all mailing lists in the world duly did ARC. Somewhat science-fictitious, given that some of them are not even able to add valid DKIM signatures. Let's hypothesize they all did ARC, anyway. Would the mailing list problem be solved? No, because recipients cannot blindly accept DMARC failures just because there is an ARC-chain claiming authenticity. Doing so would completely defeat DMARC, because ARC chains can be forged. In order to safely override a reject or quarantine policy based on ARC, a receiver needs a complete list of legitimate mailing lists. Conversely, having such a list, a receiver can override DMARC failures also based on DKIM or SPF authentication. ARC adds nothing to the mailing list problem. (However, huge mailbox providers do have a complete list of legitimate MTAs. That's where ARC is useful, AIUI.) *From rewriting is the real thing* == Rewriting From: is the de-facto standard. In a (science-fictitious) scenario where all mailing lists rewrite the From: header field, DMARC would just work smoothly. Hence, we have to specify an acceptable way to rewrite From:. I'd have said so. Best Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On Sat 13/Jun/2020 07:19:21 +0200 Hector Santos wrote: On 6/12/2020 4:02 AM, Alessandro Vesely wrote: *From rewriting is the real thing* == Rewriting From: is the de-facto standard. I don't support it. In a (science-fictitious) scenario where all mailing lists rewrite the From: header field, DMARC would just work smoothly. Occam's razor. The simplest and most honorable protocol solution is to follow the specs. DMARC will work just fine without tampering with headers if the list server simply honored the restrictive policy. It works greats!! A DKIM Policy compliant list server simply needs to do two things: 1) Prohibit new subscribers using addresses with restrictive domains, just like it is done here: https://secure.winserver.com/public/code/html-subscribe?list=winserver 2) Prohibit submission from existing subscribers using addresses with restrictive domains. The existing subscriber becomes a read-only subscriber. Restricting mailing list usage to domains with no DMARC policy is a hindrance to DMARC effectiveness. Those mailing list cannot filter out unauthenticated spammers. Hence, we have to specify an acceptable way to rewrite From:. This is no acceptable way to tamper the mail in this way. But I did suggest with following. For an example of what it did to my headers: X-Original-From: Hector Santos From: Hector Santos Why is that unacceptable? After all, the message comes from dmarc.ietf.org. They are responsible for filtering. The message comes from them. You just authored it —compare with digest mode. I like to see the author's name displayed in the folder view. However, choosing how to rewrite should be an author's decision. For another effect, if the list broadcasted messages maintaining the original From:, then isdg.net would receive an explosion of rows in the aggregate report, loosing the ability to match it with the mail they actually sent. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] why ARC
On Sat 13/Jun/2020 02:45:36 +0200 John Levine wrote: In article <45af2d9b-a2d9-4d5c-b1fd-aae906d3a...@kitterman.com> you write: Which still leaves the question of what the value proposition is since if you trust the source, what more does ARC really do (I suspect that the answer is more tokens to run through your bayesian or whatever filter)? [...] ARC lets the recipient look back and retroactively do the filtering the list didn't. As a concrete example, I find that it is extremely rare for legit mail coming into a list to be DMARC unaligned (as opposed to mail coming out of the list) so if you can look back at the ARC chain and demote mail which failed DMARC coming in, you will catch a lot of spam without a lot of mistakes. Most of us keep p=none because we'd likely loose deliverability with a strict policy. In particular, lists' functioning is smoother that way. When DMARC takes root, non-aligned messages could be filtered inbound by the list themselves. In this respect, strict policies are more effective, and we should consider strategies to get there. I'd guess ARC has more arrows than just retroactive filtering. Anyway, it remains a tool for very large operators. Mailing lists cannot afford to lose participation by small operators. Therefore they won't give up rewriting From:. ARC doesn't help DMARC adoption. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
