On Fri 20/Oct/2023 21:35:48 +0200 Murray S. Kucherawy wrote:
(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?
The PolicyPublishedType includes entries for reporting the policy:
<!-- The policy published for messages from the domain. -->
<xs:element name="p" type="DispositionType"
minOccurs="1" maxOccurs="1"/>
<!-- The policy published for messages from subdomains. -->
<xs:element name="sp" type="DispositionType"
minOccurs="1" maxOccurs="1"/>
They are defined as follows:
<!-- The policy actions specified by p and sp in the
DMARC record. -->
<xs:simpleType name="DispositionType">
<xs:restriction base="xs:string">
<xs:enumeration value="none"/>
<xs:enumeration value="quarantine"/>
<xs:enumeration value="reject"/>
</xs:restriction>
</xs:simpleType>
np= is missing.
In order to allow to report errors, I see two possible ways. One is to add an
"error" to the enumeration. An other, better way, is to set minOccurs to 0,
saying in the text or comments that the element has to be omitted when it
cannot be determined, not even applying defaults; that is, when it is invalid.
In addition, we should add a generic element, possibly free text/ enum like
policy overrides, to signal parsing errors or bad settings in the published record.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
