[arc-discuss] Gmail support of ARC headers from third-parties

Brandon Long blong at google.com
Wed Jan 31 16:01:15 PST 2018

As of today, Google's use of ARC only trusts Google, unfortunately.  This
has been true for ~6 months.  As it rolls out to other larger players, I
expect they'll build a whitelist for trusting those players.

Also, as it becomes more widely available, it should be added to the
current inbound gateway settings for GSuite, so individual GSuite customers
can create their own whitelist.  I would think that the current inbound
gateway settings (IP based) should work with Andrew's product, but maybe
I'm misunderstanding what he means.  In any case, I'm sure the larger
gateway providers would be added to the whitelist, this setting would
probably be more useful for smaller providers or for some of the other
things the inbound gateway setting does.

There is some design work for building a system to build a reputation
system for ARC to infer trust directly.  This work will take some time and
also requires quite a bit of adoption before we'll be comfortable with the

Unfortunately, there is a bit of chicken and egg problem here, designing /
building / deploying these systems requires a certain minimum usage in the
field, and most of what we've been seeing is a lot of smaller
intermediaries that just don't combine to enough volume to manage by hand
or to build a reliable signal yet.

So far, I see one larger US University, part of another mailbox provider
and then a long list of smaller domains including convivian.com.  It hasn't
been that long since openarc has been available, however, so I'm hoping
adoption in the next 6mos will be much higher.


On Wed, Jan 31, 2018 at 8:36 AM Jered Floyd via arc-discuss <
arc-discuss at dmarc.org> wrote:

> Andrew,
> A good question, but I'm not sure the answer is known (or, rather, shared
> outside Google).  I recently implemented ARC signing (that is, deployed
> OpenARC) in order to try and improve delivery results for Mailman lists.  I
> can verify that Google is successfully validating my ARC headers.  That's
> all I can verify.
> ARC only allows for validation of the earlier-hop Authentication-Results
> which, while useful for mailing lists where DMARC alignment is lost,
> depends on the recipient's trust of the relaying domain.  ARC has no
> guidance on how that trust is established, and Google has not provided a
> public interface for establishing trust.  ARC is not even discussed in the
> Google Postmaster Tools today, so they're clearly pretty early on in
> valuing ARC results as an input.
> In the end, ARC validation is one input into a scoring system (presumably
> driven by a deep-learning net) and probably a weak one compared to, say,
> your domain reputation.  The open source tools (like Rspamd) use ARC
> validationstatus as a very weak indicator, and I don't see a way to improve
> that.  Most of the spam that I see today has valid and aligned SPF and
> DKIM, so all ARC tells Google is "yup, that was sophisticated spam that got
> past his filters"!
> I've been getting a bit disillusioned about ARC as I don't see how it
> offers much help for us little guys.  GMail has established trust levels
> for my Domains/IPs based on inputs that are opaque to me.  They should
> trust me at the same level to do effective ingress filtering for relayed
> mail.  ARC only provides a weak signal for them to try and "second-guess"
> my ingress filters.  I think the delivery chain is a pretty weak indicator
> compared to the bulk content analysis they're able to do.  (I'd love to
> hear the counterpoint, though!)
> Regards,
> --Jered
> ----- On Jan 31, 2018, at 10:23 AM, Andrew B Goldberg via arc-discuss <
> arc-discuss at dmarc.org> wrote:
> I'm involved in developing an email gateway, and we're looking into
> incorporating ARC. Currently, without ARC, our mail gets marked up with a
> phishing warning in the Gmail web interface, linking to this:
> https://support.google.com/mail?hl=en&p=sent_warning  This makes sense,
> since the mail has been modified so it fails DKIM, and it also fails SPF
> since the real sender does not have the gateway IP listed as a permitted
> sender.
> From everything I've read, it sounds like ARC was designed to solve this
> exact problem. The gateway can verify SPF/DKIM/DMARC, add its own
> Authentication-Results header, and then add ARC headers to convey this all
> to the next hop (which in this case would be a Gsuite / Gmail account).
> My question is: Is anyone familiar enough with Gmail's internal handling
> of ARC to know if our ARC headers would make a difference? According to
> https://tools.ietf.org/id/draft-ietf-dmarc-arc-usage-03.html, a
> receiver/validator may implement any policy they want regarding ARC chains
> they observe. What is Gmail's policy?
> Thanks in advance,
> Andrew Goldberg
> _______________________________________________
> arc-discuss mailing list
> arc-discuss at dmarc.org
> http://lists.dmarc.org/mailman/listinfo/arc-discuss
> _______________________________________________
> arc-discuss mailing list
> arc-discuss at dmarc.org
> http://lists.dmarc.org/mailman/listinfo/arc-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dmarc.org/pipermail/arc-discuss/attachments/20180201/780a86ec/attachment.html>

More information about the arc-discuss mailing list