[arc-discuss] [dmarc-discuss] A bit quiet?
dcrocker at gmail.com
Thu Nov 26 10:35:34 PST 2015
On 11/26/2015 3:59 AM, Roland Turner wrote:
> At the very least, ARC is a different kind of input to DMARC than SPF or
> DKIM is; the latter tell the receiver things about the RFC5322.From
> domain registrant's intentions, the former provides a form of telemetry
> about what happened along the way.
>> ...Do all DMARC verifiers have to
>> change now? And what would it mean in terms of compliance if one
> No, ARC makes sense only as local policy input
At the least, discussing this now might help everyone's sense of the
place of ARC in the scheme of inbound mail validation.
ARC does do the 'what happened along the way' thing, but ARC's use is
expected to (typically) begin with an assertion of DKIM/SPF validation.
The perspective on ARC has evolved from its initial discussions, where
the entire goal was to propagate the results of DKIM/SPF evaluation at
the node breaking their authentication. By my reading of the current
spec, this feature -- reporting authentication results at the site of
breakage -- has become optional. I think that's fine, but this feature
does reflect the primary market "pull" for ARC. That is, the feature is
formally optional to use, but the use is likely to be quite popular.
Anyhow, I'll claim that when ARC provides carriage of earlier
authentication results it is, in effect, a DKIM/SPF reporting mechanism.
Architecturally, that's a layer above these mechanisms, but it is
obviously closely tied to them.
As such, it would be entirely reasonable to eventually have DMARC
normatively include use of ARC.
But no, that's not required now.
It's fine to have ARC be an independent spec, for now, with no explicit
linkage to formal DMARC documentation and instead described as a local
enhancement to the use of DMARC.
If/when ARC gains popularity, the community might want to encourage
further adoption by enhancing the DMARC spec to make ARC normative.
More information about the arc-discuss