On Wed, Nov 25, 2020 at 4:52 PM Michael Thomas <m...@mtcc.com> wrote:
> But what about DKIM? And why do they need to be processed differently? > When I first saw this, I looked at the ARC-Signature which looks identical > to a DKIM signature (i didn't notice the i= at the time), and am like what > is this? The i= counter could be trivially be grafted onto DKIM if it were > needed, which I'm still sort of dubious (though it is a nice to have > feature, I admit). That way you only need a single DKIM signature with the > OAR's signed. As far as I can tell, that would fall back gracefully for > non-implementing DKIM verifiers. Do you disagree? > ARC was developed over months, even before this WG started, and I remember all of these conversations happening involving the questions you're now asking. We landed at what became ARC. I suppose an appendix might've been nice enumerating everything that was considered and discarded, but that record doesn't really exist. What that means is that I couldn't tell you now why we rejected a pure DKIM/OAR solution to this specific problem, but I know it was considered. Maybe others who helped with RFC 8617 remember. > > Yeah, quantifying the problems kinda seems like the first order of > business if you ask me. I mean, how many of these scenarios are in reality > goofy self-inflicted wounds? I can't say but there seems to be a lot more > "this can happen" than "this is how often this happens" from what I've see > thus far on this thread. > Where do you suggest we go from here? > > When you say "easy to see", do you mean for software or for humans? > > Software. Only software can pry apart that ball of header spaghetti. But I > think with the simple a mailing list it is pretty easy to determine, which > now that I think about it I actually did back in the day when I was > experimenting with recovering mailing list modifications. It didn't occur > to me that that was supposed to be hard. > I haven't put hand to coding keyboard on this problem yet, but I'm trying to imagine how it would be easy to determine (a) that Subject had been modified (for example), (b) what the specific modification was, and (c) which hop did it. You could say a message failing to validate an author signature with "[...]" at the front of Subject was likely tagged by an MLM, or that everything after "--" should be ignored, or that those probably happened at non-submission hop #1, but those are heuristics, and I think we're hoping for something more deterministic. The 80/20 rule isn't sufficient. But it's late and maybe I'm missing something. What did you have in mind? > Sure, but the easier answer: to use my mailing list, you must have either > DKIM, SPF or both. Sounds like a good way to not be essentially an open > relay. Don't mailing lists have those sorts of policies these days? I would > say that ones that don't probably shouldn't have good reputations since > they are, in effect... open relays. > That requires MLMs to change their behavior, which I believe is something all of these protocols are hoping to avoid (or, at least, MLMs should decide that on their own, not because the IETF forced them to by wielding DMARC and ARC at them). > Mike > > PS: it's been, what, 15 years since our interop, partner? :) > 2007. Still got the t-shirt. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
