On 11/26/20 1:56 AM, Murray S. Kucherawy wrote:
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.
Yeah, like I said that's sort of a common failing of IETF documents in
general. I mean, I understand at a very low level what's going on here,
but given the document I am completely clueless of the *why* of things
are going on. It's very frustrating, doubly so when it's a self-labeled
experiment.
Where do you suggest we go from here?
I would think that an informational RFC might come in really handy both
to answer the questions in ARC itself, and any other subsequent
questions the wg deems needed since then. Leaving ARC in an experimental
state ad infinitum doesn't seem optimal. Basically: 1) was it needed at
all 2) did it help. 3) if it helped, how much did it help. (1) in
particular is what interests me because adding two new signatures seems
*really* heavy handed. That would go a long way toward answering the
questions of whether it's should go standards track.
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?
Our motivation at the time was one in particular: spear phishing. From
an enterprise situation spear phishing is scary af, and not one that
providers have much care about. That's what John gets wrong when he says
that 90% pass rate is useless: for enterprise not wanting to get spear
phished, a 10% false positive rate issuing warnings might be acceptable,
and since we were grappling the intractable mailing list reputation (at
least from our standpoint), maybe a better option.
But it was a combination of the l= value in the original signature to
clip off what the mailing list added, and some heuristics on the subject
line to remove added text. I had quite a few of them, and they were
certainly pretty dodgy, but by and large they worked. The object was not
to get to 100%, but just an acceptable false positive rate. At the time
I mentioned that maybe it would be good to create a DKIM-friendly
mailing list BCP, but that was scoffed at by the usual suspects because
there was supposedly a massive long tail of transformations that can
happen that nobody would quantify as to how common or important they
were. Hence my desire of this being driven at least in part by numbers.
Sure, but the easier answer: to use my mailing list, you must have
either DKIM, SPF or both. Sounds like a good way t
o 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).
I don't see making mailing lists coerced into better behavior as a
non-starter. Everybody has had to change over the years to get mail
delivered, and mailing lists, etc, shouldn't be viewed as sacred cows.
If they want to forward their mail, they need to play by the evolving
rules so as to make for a less spammy and phishy world. Back when DKIM
was the new kid on the block, that might have been a valid argument.
Today, not so much.
PS: it's been, what, 15 years since our interop, partner? :)
2007. Still got the t-shirt.
But we interoped the combined DK and IIM spec a couple of years earlier,
right? What a great day that was... we dunn'em proud, Murray :)
Mike
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
