Subject: Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)

From: "Kurt Andersen (b)" <[email-masked]>
Date: Wed, 11 May 2016 13:35:29 -0700

On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely <[email-masked]> wrote:

> On Wed 11/May/2016 19:09:45 +0200 Kurt Andersen (b) wrote:
> >
> > What would an AS[0] assertion provide that would not be already asserted
> by
> > the originator's DKIM-Signature?
>
> Nothing, except that the originator's DKIM-Signature is broken after MLM
> processing.  In that respect, ARC-Seal is similar to weak signatures.
>
> > If AS[1] is untrustworthy (using the term advisedly), but AS[0] still
> > verifies, then presumably the original DKIM-Signature would also still
> > verify and ARC-based information is not needed to have a pass for the
> DMARC
> > evaluation.
>
> If the body was altered the original DKIM-Signature is broken.  If AS(0) is
> good --which is possible since it didn't sign the body-- and rfc5322.from
> matches the AS(0) signer, can we then bypass DMARC validation?  To address
> Brandon's concern, high value targets should never produce an AS(0) in the
> first place.
>

AS[0] will not be "good" in the way you propose because nearly all of the
transformations that will break DKIM will also break the AMS
(ARC-Message-Signature) and, per
https://tools.ietf.org/html/draft-andersen-arc-04#section-5.1.1.5 bullet 3,
AMS must pass for the overall ARC set to be considered valid.

I'd like to respectfully suggest that "bypassing DMARC validation" is
pretty far out of scope for what we've intended with ARC.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 12 May 2016 09:28:41 +0200

On Wed 11/May/2016 22:35:29 +0200 Kurt Andersen (b) wrote:
> On Wed, May 11, 2016 at 11:40 AM, Alessandro Vesely wrote:
> 

That requirement is not necessarily about AMS(0).  It can be AMS(i), i > 0.
(Indeed, the current spec contemplates i > 0 only.)

> pretty far out of scope for what we've intended with ARC.

Yet, I share the feeling which originated this thread, namely that ARC can do
more than validate email address portability (via forwarding) among a private
group of huge mailbox providers.

If a single solution can be used for both solving DMARC's indirect mail flows
problem and participating in safe forwarding, that can make life easier for
mail system maintainers.

Ale