Subject: Re: [dmarc-ietf] implementation update

From: Brandon Long <[email-masked]>
Date: Thu, 11 May 2017 16:08:03 -0700

As an update, as of Monday our ARC signing has gone to 100% and now that's
it's been live for 4 days, seems unlikely to be rolled back at this point.

As someone else asked off list, yes, we're signing all incoming mail, and
resigning any mail that goes back outbound and has been modified by a
system where we expect modifications (Google Groups, GSuite mail policies,
Gmail forwarding).  Yes, with more effort, we could probably not sign
everything on inbound, but given the number of ways our mail system can be
used, it's easier to use the signing as a point of trust than some
alternatives, what's an order of magnitude or so of extra signatures?

Everything appears on our end to be working as expected.

We're still a couple weeks away from using this information in dmarc
evaluation.

Brandon

On Fri, Apr 28, 2017 at 11:26 AM, Brandon Long <[email-masked]> wrote:

> Gmail/Google has deployed our implementation of ARC to our mail system.
>
> At this point, we aren't creating new ARC chains, yet, but any message
> with an existing arc chain will be validated and signed.
>
> Let us know if you see any issues.
>
> We expect to start creating our own chains in the next couple weeks,
> baring issues.
>
> Brandon
>

---

From: Hector Santos <[email-masked]>
Date: Tue, 23 May 2017 11:27:02 -0400

> We're still a couple weeks away from using this information in dmarc

If my understanding is correct of the ARC work done, and thanks to 
Murray for his draft rewrite ("better" flow, mail tech read),  ARC 
will allow an "indirect" message, i.e. list message, to survive the 
original author domain signature, provided the final receiver reads 
the ARC headers with a 3rd party ARC seal?

If so, are we still missing a *deterministic* author domain 3rd party 
signature authorization procedure/protocol that links DMARC with ARC?

When I last left this work, I called that a "Registration" scheme, 
process, I thought was inherently missing in all the DKIM "policy" 
proposed solutions.

Before I begin to look at implementing ARC for our mail server,  I am 
still hopeful for a "registration" DKIM/POLICY protocol.   This is 
could be as simple as an extended DMARC "arc" tag, hopefully as an 
optional signal to augment something like ATPS (Authorized Third Party 
Signature). Maybe a ATPAS (Authorized Third Party Arc Seal)?

Thanks

-- 
HLS

---

From: Brandon Long <[email-masked]>
Date: Tue, 23 May 2017 08:51:40 -0700

Why should the sender be involved in determining which forwarding is
allowed?

The arc chain specifies each of the hops, and the receiving domain is in
the best position to know about the intermediaries.

I can imagine a whitelist style rbl allowing folks to know which
intermediaries to trust, but I don't get having to have each sender know
all intermediaries ahead of time.

Brandon

On May 23, 2017 8:27 AM, "Hector Santos" <[email-masked]> wrote:

> If my understanding is correct of the ARC work done, and thanks to Murray
> for his draft rewrite ("better" flow, mail tech read),  ARC will allow an
> "indirect" message, i.e. list message, to survive the original author
> domain signature, provided the final receiver reads the ARC headers with a
> 3rd party ARC seal?
>
> process, I thought was inherently missing in all the DKIM "policy" proposed
> solutions.
>
> still hopeful for a "registration" DKIM/POLICY protocol.   This is could be
> as simple as an extended DMARC "arc" tag, hopefully as an optional signal
> to augment something like ATPS (Authorized Third Party Signature). Maybe a
> ATPAS (Authorized Third Party Arc Seal)?
>
> Thanks
>
> --
> HLS
>
>
>