Re: [dmarc-ietf] Header munging, not ARC, can solve the mailing list problem
On Sun, Jun 14, 2020 at 7:09 AM wrote: > 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. Both have been around for a long time now and I've seen no evidence that the Internet public at large is keen to make such a wholesale migration. We apparently really, really like our mailing lists. -MSK, hatless ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Seeking volunteers to edit DMARCbis
On Fri, Jun 12, 2020 at 5:02 PM Jim Fenton wrote: > About a year ago, I had suggested [1] that the reporting and policy > mechanisms of DMARC be split, and was, I think, the only one supporting > that idea. There were quite a few comments along the line of, "it's not > broken, so why should we go to the trouble?" If I was not on the record before as believing such a split is a good idea, I am now. -MSK, just participating ___ 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
Other uses of indirect mail: My university offered an alumni account implemented as a relay to whatever hosting service I was using at the moment. Never took them up on it, and glad that I did not. Perhaps RFC 7960 talked about that scenario, because I think I have seen it mentioned in an IETF document. Header munging vs Alternatives: Header munging vs. Perfect author attribution I have been considering an alternative world where header munging is eliminated because author content is not modified and therefore author identified is fully verifiable using DKIM and DMARC. Several concerns come to mind: We do a fair amount of geographic filtering, so some of the postings to this list would be blocked, because of coming from countries where we do not do business. Header munging provides a single point of origin; if one message is allowed through the geographic filters, then all messages will be allowed through. If an exception is needed, the list member and system manager can be confident that only a single exception is necessary. One of the reasons that IETF breaks DKIM is because it converts everything to a plain text. This is a significant security benefit, by lowering the threat potential of the message. It makes the IETF messages more trustworthy than if they came to me directly from the author. Other mailing lists may use other criteria, but they should all use some sort of filtering to protect their reputation and their members. Header munging allows me to distinguish between IETF-filtered traffic and other traffic. As an extension of that point, successful sender authentication establishes identity, but it does not establish trust. Trust is assigned by the recipient, largely based on experience, so message from unrecognized senders is given a low trust level by default.I know how to trust IETF. I do not know whether to trust the next random person who contributes to this mailing list. ARC assumes that after a user subscribes to a mailing list, he negotiates with his I.T. staff to have the mailing list operator authorized. I expect this to be problematic for many users. To mitigate these concerns, the non-munging solution would presume that recipient systems have the ability to filter differently between ( unknown sender + known mailing list ) and ( unknown sender without mailing list ). To prevent spoofing of the mailing list, list identity would need to be verified as well as author identity. As we add complexity to the inbound mail process design, some extra processing logic is applied to all messages, not just the mailing list messages. How many filtering solutions will be unable or unwilling to add this complexity? Others have already noted that the mailing list operator must choose a configuration without knowledge of what capabilities will exist in the receiving system message filter. This seems to limit the range of possible solutions. Given all of that, I think a non-munging solution would be more problematic for me than what IETF is already doing. DF ___ 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 <5608000.6bWcHqoX70@localhost> you write: >> That's what RFC 7960 (the first work product from this group) was all about. >> >So problem solved? No need to revisit? The only indirect flows it talks about in any detail is mailing lists. It's worth a look to see if there are others we understand well enough to describe. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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] Header munging, not ARC, can solve the mailing list problem
On Monday, June 15, 2020 4:56:55 PM EDT Kurt Andersen (b) wrote: > On Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski wrote: > > On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman > > > > wrote: > >> To follow-up on Brandon's note about Google's use of ARC, it's bigger > >> than > >> mailing lists and so is this problem. It's any intermediary that > >> modifies a > >> message in such a manner that DKIM fails (SPF is only useful for direct > >> source > >> ADMD to destination ADMD tranmissions). > >> > >> I suspect that by hyper focusing on mailing lists, we're missing part of > >> the > >> problem. > >> > >> Scott K > > > > I think the mailing list issue looms so large as to block out everything > > else. We (probably the chairs) should make sure we don't miss the the > > non-mailing list part of this problem. > > That's what RFC 7960 (the first work product from this group) was all about. > So problem solved? No need to revisit? Scott K ___ 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 Mon, Jun 15, 2020 at 11:30 AM Tim Wicinski wrote: > > On Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman > wrote: > >> >> To follow-up on Brandon's note about Google's use of ARC, it's bigger >> than >> mailing lists and so is this problem. It's any intermediary that >> modifies a >> message in such a manner that DKIM fails (SPF is only useful for direct >> source >> ADMD to destination ADMD tranmissions). >> >> I suspect that by hyper focusing on mailing lists, we're missing part of >> the >> problem. >> >> Scott K >> >> > I think the mailing list issue looms so large as to block out everything > else. We (probably the chairs) should make sure we don't miss the the > non-mailing list part of this problem. > That's what RFC 7960 (the first work product from this group) was all about. --Kurt ___ 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 Mon, Jun 15, 2020 at 2:27 PM Scott Kitterman wrote: > > To follow-up on Brandon's note about Google's use of ARC, it's bigger than > mailing lists and so is this problem. It's any intermediary that modifies > a > message in such a manner that DKIM fails (SPF is only useful for direct > source > ADMD to destination ADMD tranmissions). > > I suspect that by hyper focusing on mailing lists, we're missing part of > the > problem. > > Scott K > > I think the mailing list issue looms so large as to block out everything else. We (probably the chairs) should make sure we don't miss the the non-mailing list part of this problem. 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
On Monday, June 15, 2020 2:19:22 PM EDT Jesse Thompson wrote: > On 6/15/20 12:44 PM, John Levine wrote: > > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: > > They both claim they're working on ARC. > > > >> So, solution 1.3 has been naturally selected. Does it need to be > >> standardized, or is a BCP good enough? I'd still like to see a solution > >> for receivers to "un-munge" trustworthy messages in a safe and > >> consistent way. Is that where ARC comes in? > > > > No. ARC lets mail systems accept list mail without munging. > > How will a random intermediary know if random destination has implemented > ARC and will trust their claim? Even domains hosted by SaaS providers will > have their own ARC reputation to manage, and might have to do things like > configure munging on a per-recipient/domain basis, assuming the SaaS > provider grants that level of control. It's safer and easier to munge > everything. They won't. Bypassing DMARC based on ARC requires some level of trust in the source of the message. > Even if you ignore my line of reasoning, I think that Ale made in the OP a > compelling case that the practice of From rewriting is here to stay. As a practical matter, that's certainly true for the short to medium term, but it doesn't follow that the IETF should standardize the practice. To follow-up on Brandon's note about Google's use of ARC, it's bigger than mailing lists and so is this problem. It's any intermediary that modifies a message in such a manner that DKIM fails (SPF is only useful for direct source ADMD to destination ADMD tranmissions). I suspect that by hyper focusing on mailing lists, we're missing part of the problem. Scott K ___ 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
(no hats) On Mon, Jun 15, 2020 at 2:18 PM Brandon Long wrote: > > We sometimes use a different solution that isn't listed, which is > basically where internal groups have access to the > domain DKIM key, so they just re-sign. Those aren't really an interesting > case, though. > > I used to encourage creating CNAMEs to DKIM keys that internal groups managed themselves. (DNS things like that are like nice BCP for DMARC deployment.) Large corporations with legacy domains and multiple business units operating semi-independently are the same problem space as Jesse's University case. 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
On 6/15/20 12:44 PM, John Levine wrote: > In article <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: > They both claim they're working on ARC. > >> So, solution 1.3 has been naturally selected. Does it need to be >> standardized, or is a BCP good enough? >> I'd still like to see a solution for receivers to "un-munge" trustworthy >> messages in a safe and >> consistent way. Is that where ARC comes in? > > No. ARC lets mail systems accept list mail without munging. How will a random intermediary know if random destination has implemented ARC and will trust their claim? Even domains hosted by SaaS providers will have their own ARC reputation to manage, and might have to do things like configure munging on a per-recipient/domain basis, assuming the SaaS provider grants that level of control. It's safer and easier to munge everything. Even if you ignore my line of reasoning, I think that Ale made in the OP a compelling case that the practice of From rewriting is here to stay. Jesse ___ 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 <1ef0572d-a83c-ad97-9c0d-5f5615ab1...@wisc.edu> you write: >On 6/15/20 2:33 AM, Alessandro Vesely wrote: >> Let me quote a list of nineteen usable solutions: >> 1.2 Turn off all message modifications >> 1.3 Replace address with a generic one >> 1.5 Rewrite addresses to forwarding addresses >> That page hasn't been updated since 2016. I don't think we can devise any >> new solution now. There's >been a natural selection. Solution 1.3 prevailed, with a minority of lists >opting for 1.2. Let's face >facts. Here in the IETF we use 1.5 but, yes. >Microsoft's solution: 1.2 (conditionally, based on some logic, it seems) >Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject) They both claim they're working on ARC. >So, solution 1.3 has been naturally selected. Does it need to be >standardized, or is a BCP good enough? >I'd still like to see a solution for receivers to "un-munge" trustworthy >messages in a safe and >consistent way. Is that where ARC comes in? No. ARC lets mail systems accept list mail without munging. 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
On 6/15/20 2:33 AM, Alessandro Vesely wrote: > Let me quote a list of nineteen usable solutions: > > 1 Sending side workarounds > 1.1 Exclude domains that require alignment > 1.2 Turn off all message modifications > 1.3 Replace address with a generic one > 1.4 Add fixed string such as .invalid to addresses > 1.5 Rewrite addresses to forwarding addresses > 1.6 Message wrapping > 1.7 Mandatory digests > 1.8 Ignore DMARC bounces > 1.9 Third Party Authorization > 2 Recipient workarounds > 2.1 Forwarder whitelist > 3 Cooperative solutions > 3.1 Shared whitelist > 3.2 Per sender whitelist > 3.3 Original-Authentication-Results header > 3.4 Forwarding token > 4 Authorization approaches > 4.1 Authenticated Received Chain (ARC) > 4.2 Signing key delegation > 4.3 Relay through author domain server > 4.4 Relay one copy through author domain server > 4.5 Have author domains sign camera-ready posts > [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail] > > That page hasn't been updated since 2016. I don't think we can devise any > new solution now. There's been a natural selection. Solution 1.3 prevailed, > with a minority of lists opting for 1.2. Let's face facts. Precisely. Let's work from a basis of reality. I'm representing an EDU here. Mailing lists are still heavily used in EDU for cross-institution and cross-sector collaboration. They aren't going to be replaced by web forums or Yammer (or whatever corporate enterprise aspire to do) because faculty are open and collaborative by their nature. We have over $1bn in research expenditures, most of which are funded by federal grants, and so we need to receive mail (sometimes indirectly) from federal agencies who are adhering to BOD 18-01. A growing number of universities are publishing DMARC policies, and an unknown but presumably growing number of universities and agencies are enforcing DMARC policies for other domains. It's becoming increasingly difficult to ignore DMARC. Given that Microsoft and Google have essentially soaked up the entire EDU email market (hey, the price is right), let's say for sake of argument[*] that most EDUs are faced with 2 choices for their MLM: Google Groups and Microsoft 365 Groups. Microsoft's solution: 1.2 (conditionally, based on some logic, it seems) Google's solution: 1.3 (conditionally, based on DMARC p=quarantine or p=reject) We can delve into *why*, but the reality is that we have failed with using Microsoft 365 Groups with external collaborators from domains that have adopted DMARC *even though* we use Microsoft 365 for mailbox hosting, and we heavily use Microsoft 365 Groups for internal collaboration. Given that choice in this context, I believe that Google Groups will be chosen as their MLM by anyone taking DMARC into consideration. I would not be surprised if Microsoft falls in line with solution 1.3. So, solution 1.3 has been naturally selected. Does it need to be standardized, or is a BCP good enough? I'd still like to see a solution for receivers to "un-munge" trustworthy messages in a safe and consistent way. Is that where ARC comes in? Thanks, Jesse [*] Glossing over the fact that a university is not a single entity. There are hundreds of entities within a university that all may individually choose their own solution. ___ 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: >Let me quote a list of nineteen usable solutions: I wouldn't call them all usable. Proposed, perhaps. > [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail] > >That page hasn't been updated since 2016. If anyone has any new bright ideas, let me know and I'll send you a password so you can update the wiki. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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] Header munging, not ARC, can solve the mailing list problem
On 6/14/2020 10:29 PM, Jim Fenton wrote: On 6/13/20 8:17 PM, Dave Crocker wrote: 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. The WG needs to consider the operational impact of DMARC deployment if it is going to publish DMARC as a WG document. 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? That is a false dilemma. We can (and should) consider possible use/abuse of specifications we publish, but that does not imply worrying less about technical quality. Some people send spam. We'd better deprecate all the email specifications. Some agencies make silly or terrible rules. And there are so many agencies. We'd better shut down the IETF because any specification can be abused and probably will be. Perhaps you can offer a rather more focused, specific and deterministic concern? 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 Sun 14/Jun/2020 19:18:43 +0200 Scott Kitterman wrote: On Sunday, June 14, 2020 5:24:42 AM EDT devel2...@baptiste-carvello.net wrote: 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 don't think that's the question at all. +1, we're not going to reinvent DMARC, just elucidate it. Whether user's knowledge of the from address has any bearing on anti-abuse methods or not, it has plenty of value for other purposes. DMARC is not all of email. From rewriting is a gross hack that exists only due to dire necessity. If this working group can't move the space towards a more usable solution, I'm not at all sure DMARCbis is worth the trouble. Let me quote a list of nineteen usable solutions: 1 Sending side workarounds 1.1 Exclude domains that require alignment 1.2 Turn off all message modifications 1.3 Replace address with a generic one 1.4 Add fixed string such as .invalid to addresses 1.5 Rewrite addresses to forwarding addresses 1.6 Message wrapping 1.7 Mandatory digests 1.8 Ignore DMARC bounces 1.9 Third Party Authorization 2 Recipient workarounds 2.1 Forwarder whitelist 3 Cooperative solutions 3.1 Shared whitelist 3.2 Per sender whitelist 3.3 Original-Authentication-Results header 3.4 Forwarding token 4 Authorization approaches 4.1 Authenticated Received Chain (ARC) 4.2 Signing key delegation 4.3 Relay through author domain server 4.4 Relay one copy through author domain server 4.5 Have author domains sign camera-ready posts [https://wiki.asrg.sp.am/wiki/Mitigating_DMARC_damage_to_third_party_mail] That page hasn't been updated since 2016. I don't think we can devise any new solution now. There's been a natural selection. Solution 1.3 prevailed, with a minority of lists opting for 1.2. Let's face facts. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
