Re: [dmarc-ietf] ARC-Seal is meaningless security theatre

[Hector Santos <[e-mail]>]

On 8/18/2017 2:10 PM, Murray S. Kucherawy wrote:

> Of course, the danger of proceeding along that line is that we do
> establish a deployed base, however small, that will be difficult to
> change later.

+1

> I don't know the answer to that question immediately,
> and admittedly I'm only going to be on the periphery of cleaning up
> whatever mess results.

Well, we should know this by now.  Are we in a project research or 
product research phase here?  We are well beyond the proof of concepts 
here.  We all know what the problems are when a DKIM Policy Model 
offers a method to handle strong, exclusive, restrictive polices 
whether it was SSP/DomainKeys o=-, ADSP DISCARDable and now DMARC 
p=reject.

IMO, there is nothing new added to the table other than more overhead, 
a ARC chain, across the transport path. Highly sensitive to breakage, 
until the originating domain says something about it, I don't see how 
it resolves the original problem.

I suggest the simplest solution is to augment ARC with an extended 
DMARC tag that informs receivers that its "OK" to relax p=reject only 
under X% ARC seal conditions  It could be 100% or it be partial, 
fuzzy, "SoftFail" concept, whatever.  Let the Originating Author 
Domain decide.

This would offer a reason to support ARC, to explore the 
experimentation, and best of all, we won't have the design change 
pressures to deal with the borderline "illegal," "unethical" 5222.From 
rewriting methods/kludges.  Lets remember it remains to be the only 
hash binding header requirement by DKIM.

-- 
HLS