Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND
Hi, Le 11/11/2020 à 22:33, Seth Blank a écrit : > > To the earlier conversation, this is all simplified dramatically if we > define organizational domain (or whatever it's renamed) discovery in a > separate I-D that DMARC just inherits... Let me point out, though, that sending reports to "organizational domain" or to "ancestor domain" have different privacy implications. Which is an argument for defining at least the semantics (and name) of that domain in the main document. Cheers, BC ___ 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, just answering this one bit, which I believe is at the heart of the disagreement: Le 22/06/2020 à 21:44, Brandon Long a écrit : [...] It's the majority which are routinely subjected to phishing and spam messages... IMHO "phishing and spam messages" is way too broad a concept to permit useful discussion. DMARC nowadays addresses a whole range of problems of varying severity to the end user. When protecting security-sensitive domains like banks, where phishing is a major threat to the end user, a fail-closed policy is a necessity, and incompatibility with some uses is acceptable. However, mailboxes with no special security needs call for a different tradeoff. From the end user's point of view, spam or addressbook-based phishing attempts are small annoyances that they somehow deal with (otherwise, they couldn't be using e-mail today). The goal here is an incremental win over an acceptable statu quo, not a revolution. No legitimate communication should thus be made to ressort to tedious workarounds to send mail (mailing-list users having to send every message twice, really?) or to find out who said what. Cheers, Baptiste ___ 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, Le 21/06/2020 à 21:44, Douglas E. Foster a écrit : > > There is no legal corollary for "largely-unmodified". [...] Then what? An overwhelming majority of users need e-mail for day-to-day communication, not for binding legal contracts. "Largely-unmodified" as mailing-lists have been doing it for 40 years is good enough (we usually don't hear authors complaining that they were impersonated). People who need a high-integrity validation for each and every message before reading it are the minority. The rest of us would rather keep our communication possibilities unimpaired, even if it means dealing with a bit of spam and use cryptography or out-of-band checks for important business. Not to say that DMARC's validation is not valuable per se. But asking mailing-list (or other) users to jump through hoops to simply communicate as they have for 40 years is incredibly arrogant. Cheers, Baptiste P.S.: and no, "then don't use DMARC" cannot be the answer. Some time down the road, it will be forced on us by the large mailhosts, who have a business interest in curbing spam. So it'd better be done right. ___ 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
Le 13/06/2020 à 17:19, Douglas E. Foster a écrit : 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 [...] That's not my point. My point is: this working group needs to make a determination whether From addresses being displayed to the users matters to DMARC or not, and then follow up consistently. If it is, then don't break From addresses with munging. If it is not, then use Sender field as a fallback for alignment, and don't break From either. [...] > 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. Thanks for you honesty. Then the relevant question is whether open and interoperable standards still matter, or if they should be replaced by proprietary web apps one feature at a time. Cheers, Baptiste ___ 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
