Re: [dmarc-ietf] ARC questions

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Nov 25, 2020 at 11:03 AM Michael Thomas <[e-mail]> wrote:

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

I imagine it could've been done as an Applicability Statement over DKIM and
AR, but I'm not sure now whether that would've been simpler.

> 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.

When you say "easy to see", do you mean for software or for humans?

> 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.

If the MLM enforces DMARC, that's slightly better, but I think ARC was
meant to be an incremental drop-in for MLM operators that don't (or won't)
do DMARC.

-MSK