Re: [dmarc-ietf] ARC questions

[Michael Thomas <[e-mail]>]

On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
> On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Michael, I think the purpose is stated well enough:   Mailing
>     lists want to keep adding their content to messages, without being
>     blocked by recipients.   This means that they have to provide
>     recipients with enough information for them to accept the
>     forwarded content.  Google and Microsoft seem to be on-board with
>     this project, so it seems pretty successful already.   This train
>     is not easily stopped.
>
>
> That sounds about right.  Put another way: DMARC's success is at least 
> in part stymied by what MLMs do that invalidates DKIM; ARC is an 
> attempt to carry forward from the MLM, in a credible way, an 
> indication of what the MLM saw in terms of DKIM results when the 
> message got to the MLM.  So then, although an author signature will 
> fail post-MLM, the MLM signature will pass, and the ARC data will tell 
> you that the author signature was good when the MLM got it.  If you 
> trust the chain, then that can be an alternative to the DKIM input 
> when the final recipient performs a DMARC evaluation.

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.


>
> Sections 1 and 7.2.1 of RFC 8617 do say all of this, though perhaps 
> not as concretely as one might like.
>
>     In my opinion, ARC does leave a lot of unanswered questions about
>     how you use the data that ARC provides.   Again, the big
>     organizations have the brain power at their disposal to figure
>     that out for themselves, later.
>
>
> This is why it was published as Experimental.  Its efficacy is not 
> (yet) known, nor are any side effects. Although, now that you have me 
> thinking about it: It's been a year; have we any meaningful data about 
> this yet?

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.

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.

Mike