On 20/10/2023 21:35, Murray S. Kucherawy wrote:
A couple of things here:
(1) As written, the text says (to me) that the handling of a message
might change depending on this mapping of a broken value to "none",
but only if "rua" is present; absent "rua", the record is treated as
junk and DMARC doesn't apply. That seems a peculiar decision tree to
me. We might want to tease these apart: Does the policy handling
change in the presence of a typo, or does the reporting logic change,
or both? And don't gate it on the "rua" tag. (And if "quarantine" is
misspelled, how do we know "rua" isn't?)
(2) Mapping a misspelled "reject" or "quarantine" to "none" even only
in the report will be confusing; the domain owner will be told there's
a "none" out there when there isn't. A non-thorough domain owner
might conclude that the receiver is broken and not debug their
problem. The guidance here ought to result in the report indicating
somehow that the receiver assumed "none" because what it extracted
from the DNS appeared to be junk. Should the report include a
mechanism making this explicit?
-MSK, participating
As we can see this text is to prone to multiple interpretation. I would
said that there is the "naive" one that is only looking at the RFC
itself (Murray's and mine) and the "logic" one (Alessandro's and Neil's)
that interprets the RFC on a practical way and as experienced DMARC user.
In my opinion, not only this exception does not contribute something
constructive, from an operative point of view it also complicates
implementation.
I would argue that the documents (RFC 7489 and Dmarcbis) already contain
enough parsing information and I would rather ignore the spelling
mistake for sp= and np= and reject the record if p= is not valid.
However, it leads to writing an errata for RFC 7489.
Regards,
Olivier
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
