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
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
