Re: [dmarc-ietf] auth-res vs. dmarc

[Alessandro Vesely <[e-mail]>]

On Wed 30/Dec/2020 18:12:22 +0100 Hector Santos wrote:
> 
> Any A-R evaluation looking for the specific DMARC verification bits as part of 
> its algorithm, but sees none, MUST use the default input and output values for 
> a domain that lacks a DMARC record.  For DMARC, when no record exist, the 
> default values are (please confirm, I am going off my 
> https://secure.winserver.com/public/wcDMARC wizard form values).
> 
> p=none
> sp=none
> adkim=relaxed
> aspf=relaxed
> pct=100%
> rua=0
> ruf=0
> rf=afrf
> ri=86400
> 
> The dmarc= value SHOULD not be dmarc=fail nor dmarc=pass because no DMARC 
> record exist.  So if an A-R is written for a non-DMARC domain, it should be 
> perhaps write:
> 
>    dmarc=unknown author.d=gmail.com signer.d=gmail.com (originating signer);
> 
> or
> 
>    dmarc=none author.d=gmail.com signer.d=gmail.com (originating signer);


I like better the latter (except that author.d should be header.from and 
signer.d is useless as there must be one or more dkim=pass with a matching 
header.d=gmail.com or spf=pass with matching helo/ mailfrom property.)


> Although the dmarc=none could erroneously suggest a DMARC record exist with a 
> p=none policy


Having no record or just "v=DMARC1; p=none;" should be equivalent.  ADSP 
explicitly said so, preferring an existing record with default values for DNS 
caching performance.

IMHO, we're being somewhat fussy by /requiring/ p=none.


> when a real policy exist, then a policy= tag used in our A-R, like:
> 
>    dmarc=dkim-fail policy=none author.d=gmail.com signer.d=gmail.com 
> (originating signer);


should be:

     dmarc=fail policy.dmarc=none

The moment that you deploy existing software, using unregistered properties 
becomes problematic.  Reporting the domain where a DMARC record was found might 
be useful.  However, if you want to use it you should register it.  I'd suggest 
dns.zone=gmail.com, as that ptype.property is already registered, albeit for a 
different method.


> which reads:
> 
> The author.d=gmail.com has a DMARC none policy. It has an aligned author and 
> signer domain, but DMARC failed due to a dkim-fail signature which the A-R dkim 
> line shows:
> 
>    dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=gmail.com header.s=20161025 
> header.i=gmail.com;


Obviously, SPF failed too.  It makes little sense to specify all possible 
failure reason on the A-R line.


> I am not suggesting this or no DMARC A-R line should be written when the domain 
> lacks a DMARC record.
> 
> If a A-R dmarc line is recorded, it should be readable by humans. It should not 
> erroneously misdirect an A-R evaluator routine when a DMARC does not exist. 
> Using the comment field SHOULD be reserved for non-standard HUMAN readable 
> data.  But some of used it to fill in the gaps we wanted A-R for verification 
> results, i.e. for SPF, the ip name field.
> 
> Overall, I agree, resolving the A-R name space technical issue SHOULD be 
> resolved in the WG for DMARC-bis. I think it is well worth the effort to define 
> what we need and then use this for the update up the A-R specs to create a more 
> common and useful name space to all.


Right.


Best
Ale
--