[arc-discuss] [dmarc-discuss] A bit quiet?

Roland Turner roland at rolandturner.com
Thu Nov 26 03:59:56 PST 2015


On 11/01/2015 10:19 AM, Murray S. Kucherawy via arc-discuss wrote:

> In terms of formalities, I think we agree that ARC should be specified 
> on its own.  I'm just not sure I agree with the idea that DMARC should 
> never be extended to include it as a formal consumable.  Remember that 
> DMARC doesn't actually require DKIM or SPF either; it works fine with 
> just one or the other, so adding a third doesn't impose much on 
> anyone.  If ARC is successful, or is on the track to being so, then I 
> think adding it to a DMARC revision is the right thing to do if only 
> to encourage uptake.

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.

> But then we get to the question of how that would happen given DMARC 
> isn't really versioned in a way that's meaningful here.  That is: What 
> would it mean to publish, say, a Proposed Standard version of DMARC 
> that mandates ARC support as one of three methods evaluated by a 
> receiver, instead of one of only two?  Do all DMARC verifiers have to 
> change now?  And what would it mean in terms of compliance if one doesn't?

No, ARC makes sense only as local policy input (as above, it's not about 
the intentions of the domain registrant). A receiver who is using ARC as 
an input to their decision-making is going to report less damage to 
domain registrants, permitting the latter to adopt more aggressive 
policies earlier, but no other difference in domain registrant behaviour 
is required. In particular: all parts of ARC processing are outside the 
latter's control anyway.

> Actually having read the drafts in detail now, I'm starting to think 
> ARC could supplant DKIM entirely.  Am I wrong about that?

Not at all, that's certainly possible. I've been meaning to write up a 
note on ARC and independent origination (telco-provisioned BlackBerries, 
LinkedIn notifications, "own domain" sending from Gmail (the free 
webmail client rather than Google Apps), news site send-to-a-friend, 
etc.) to make the argument that ARC-signing can be used by independent 
originators to take responsibility for what they're doing and help 
receivers decide when to treat that as sufficient basis for disregarding 
the domain registrant's p=reject. A trivial extension of this idea is 
for domain registrant originators to do likewise, it will simply happen 
to be the case that the ARC-(Seal|Message-Signature) i=1 headers will 
have a d= value matching the RFC532.From domain. At this point, DKIM is 
architecturally superfluous.

- Roland


More information about the arc-discuss mailing list