On 11/24/20 8:19 PM, Murray S. Kucherawy wrote:
On Tue, Nov 24, 2020 at 7:27 PM Douglas Foster <dougfoster.emailstanda...@gmail.com <mailto:dougfoster.emailstanda...@gmail.com>> 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

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to