On 11/25/20 4:14 PM, Murray S. Kucherawy wrote:
On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas <m...@mtcc.com
<mailto:m...@mtcc.com>> wrote:
That's been known for over 15 years. I'm still trying to
understand the assertion that DKIM signatures are a "bad fit". I
just looked at a random message off of this thread and they look
identical except for the i= field. another field could trivially
be added to DKIM and auth-res -- since unknown fields are supposed
to be ignored -- if this binding property is absolutely needed,
which I remain unconvinced by as well.
I'm not sure about "bad fit". The original plan was to have an
Authentication-Results (AR) clone called
Original-Authentication-Results (OAR) which was specifically the AR
content generated at the first non-submission MTA. There was some
friction (mostly from me, as I recall) about having two header fields
with identical syntax and nearly identical semantics. There was
further complication in the fact that one ADMD could apply multiple
ARs on a single message (for multiple methods, or multiple instances
of the same method, or a combination of those), or they could be
reordered, etc. To make it more resilient, things like instance
numbers were added. The work was eventually generalized to be a
"chain of custody" sort of model, and in doing that I think the
decision was made to make a new name to ensure ARC and DKIM would be
processed differently.
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?
If you ask me, part of the experiment should be able to show use
cases that DKIM + auth-res (or maybe old-auth-res if needed)
CANNOT address that ARC can, and most especially what percentage
of email traffic we're actually talking here. As far as I can see
ARC doesn't bring anything especially new for the mailing list
kind of use cases since it really easy to see who the
intermediary was that broke the signature. I have been told there
are some vague other kinds of use cases but is unclear whether
those use cases actually happen before or after the message
arrives at the front door of the final receiving domain. Yes, i
read section 7, but it doesn't tell me why this can't be handled
with current technology.
Obviously it's too late to include this in RFC 8617, but those would
indeed be interesting data to have.
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.
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.
It seems to me that the lynchpin is whether I trust the domain
that broke the signature and resigned. That's either a previously
solved or unsolved problem depending on your perspective. If I
trust the intermediary domain to not send me spam via reputation,
I forward it along to be delivered and ignore the DMARC record.
Why do I care whether it originally validated from the sending
domain or not? If you ask me, that's the intermediary domain's
problem since they have an incentive to keep their reputation and
not send spam through.
Suppose you're sending to a list that I'm on, I enforce DMARC, I trust
that MLM not to send spam via reputation, you have a good reputation,
and you publish a DMARC "reject" policy. That means if a bad actor
sends a message to the list as you but doesn't sign it at all, I'll
still accept it because I trust that MLM even though according to your
policy request, I should bounce it. ARC provides the missing data I
need to enforce your request.
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.
Mike
PS: it's been, what, 15 years since our interop, partner? :)
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
