Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: > > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then we > can figure out what to do with the rest of it? > Speaking of Pareto: - DMARC covers only 22% of the full ranges of signature scenarios with no provision to define nor authorize 3rd party (re)signers. - Occam’s Razor, the solution is often more simpler than its often appears, 80% of the time — ATPS. Your Idea. Champion it and it will get supported by your peers. Want to try inline method? Fine. But explain why more complexity is better to reach same conclusion ATPS provides. Best option; support both to cover the different admin methods. - 80% of those who have been involved since MARID with LMAP, SPF, DKIM/, SSP, ADSP and "Super ADSP” DMARC are disillusioned why the IETF has allowed the same key cogs over 17 years to continue to perpetuate a broken protocol and problem when they never believed in SPF, ADSP and DMARC — their focus was Reputation modeling with no standard in place for an assessment lookup (opening a door for business interest). This is not about heuristics. We should first close the deterministic holes by providing domains a method to expose their 1st vs 3rd party expectations. DMARC is not a protocol complete when it comes to domain policies. Too many closes. 80%??? — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
> On Apr 10, 2023, at 12:55 PM, Murray S. Kucherawy wrote: >> > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then we > can figure out what to do with the rest of it? > > -MSK, participating Please consider the overall goal and the various methods to get to the same conclusion: - Inline ADID::SDID authorization (2nd signatures, new tags, complexity) - DNS lookup ADID::SDID authorization (plug and plug) The later is the more optimized method for plug and play implementation. I would rather not have to change SPF, DKIM to support a protocol incomplete ADSP/DMARC proposal. We can begin to fix this with the proper add-ons or replacement of DMARC (which is not a good idea. We want to piggyback off the lookups). DSAP provides domains a method to expose what is expected, unexpected and optional. Cover the boundary conditions to close loop holes that exist. Too many holes. — HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 9:55 AM Murray S. Kucherawy wrote: > On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > >> > For certain >> >constrained but hopefully reasonable scenarios of mailing list >> >modifications, we might be able to distinguish the sources of content. >> >> People have been suggesting this forwver, but it really doesn't scale. >> There are a lot more list hosts with a lot more configurations that >> any of us have individually ever seen. In many cases they add or >> rewrite MIME parts which is extremely hard to unwind enough to see if >> a DKIM signature would have been valid. >> > > I have to agree. For as many times as this notion has been proposed, it's > never been given serious consideration, and this is the reason: We can't > possibly describe all the MLM mutations that exist, even if the mechansim > for doing so is made extensible. > > I think the one thing we haven't discussed is: Could the 80-20 rule apply > here? > +1 > That is, if we start off with something like what > draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), > might it make enough of a dent to get us through this stalemate, and then > we can figure out what to do with the rest of it? > +1 I think that's a good start or some subset. -Wei > > -MSK, participating > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > It appears that Wei Chuang said: > >1) We know that a sender intends to send a message down some path that may > >include a mailing list, that got to me safely. This is to avoid DKIM > >replay and FROM spoofing attacks. > > I think we can do that by looking at the To/Cc addresses to check if > they include the list that forwarded the mail. > +1 One approach might be to chain together recipients/sender pairs across forwarders, and sign the recipients. (Another approach might be to tie together SMTP transactions between sending-service/receiving-service pairs) > > >2) That we can identify the contributors to the content of the message in > >that path to distinguish malicious vs benign contributors. > > Isn't that what ARC is for? You can look back through the list headers > to see what the state of the message was like on the way in. While I > am not a fan of applying DMARC policies to the output of forwarders > like mailing lists, they work to filter inbound mail to a list. With ARC and a modifying mailing list, we hopefully will see that an expected DKIM-signature fails and hopefully at least a terminating ARC-Message-Signature that passes. With these tools, the receiver isn't able to see which part of the message was contributed by the sender vs the mailing list. If there's spammy content, the receiver can't distinguish which party contributed to that content, then so has to attribute that spammy content to both parties, but at the cost of harming the innocent one. Despite that issue I should mention that ARC/DMARC still helps us in knowing who your sender is, which is helpful. -Wei > > > For certain > >constrained but hopefully reasonable scenarios of mailing list > >modifications, we might be able to distinguish the sources of content. > > People have been suggesting this forwver, but it really doesn't scale. > There are a lot more list hosts with a lot more configurations that > any of us have individually ever seen. In many cases they add or > rewrite MIME parts which is extremely hard to unwind enough to see if > a DKIM signature would have been valid. > > R's, > John > smime.p7s Description: S/MIME Cryptographic Signature ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
On Mon, Apr 10, 2023 at 8:15 AM John Levine wrote: > > For certain > >constrained but hopefully reasonable scenarios of mailing list > >modifications, we might be able to distinguish the sources of content. > > People have been suggesting this forwver, but it really doesn't scale. > There are a lot more list hosts with a lot more configurations that > any of us have individually ever seen. In many cases they add or > rewrite MIME parts which is extremely hard to unwind enough to see if > a DKIM signature would have been valid. > I have to agree. For as many times as this notion has been proposed, it's never been given serious consideration, and this is the reason: We can't possibly describe all the MLM mutations that exist, even if the mechansim for doing so is made extensible. I think the one thing we haven't discussed is: Could the 80-20 rule apply here? That is, if we start off with something like what draft-kucherawy-dkim-transform proposed (or even a trivial subset of it), might it make enough of a dent to get us through this stalemate, and then we can figure out what to do with the rest of it? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] not really such a thing as AOL-compatible mailing lists
It appears that Wei Chuang said: >1) We know that a sender intends to send a message down some path that may >include a mailing list, that got to me safely. This is to avoid DKIM >replay and FROM spoofing attacks. I think we can do that by looking at the To/Cc addresses to check if they include the list that forwarded the mail. >2) That we can identify the contributors to the content of the message in >that path to distinguish malicious vs benign contributors. Isn't that what ARC is for? You can look back through the list headers to see what the state of the message was like on the way in. While I am not a fan of applying DMARC policies to the output of forwarders like mailing lists, they work to filter inbound mail to a list. > For certain >constrained but hopefully reasonable scenarios of mailing list >modifications, we might be able to distinguish the sources of content. People have been suggesting this forwver, but it really doesn't scale. There are a lot more list hosts with a lot more configurations that any of us have individually ever seen. In many cases they add or rewrite MIME parts which is extremely hard to unwind enough to see if a DKIM signature would have been valid. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
