Here is proposed language to amend the Aggregate Reporting draft.
1) Replace section 2.1.2 with this:
DMARC Aggregate Reporting provides information needed for domain owners to
ensure that their messages originate with SPF PASS for the RFC5321.MailFrom
domain and aligned DKIM PASS for the RFC5321.From domain.
As a side effect, Aggregate Reporting also provides information about
servers that choose to deliver messages which are not authenticated by the
domain owner's DMARC policy. DMARC is not designed to determine the
motivation behind a server which delivers unauthenticated messages.
Consequently, only aligned identifiers are relevant for Aggregate
Reporting, in the same way that only aligned identifiers are relevant for
determining a DMARC result. DMARCbis allows non-aligned identifiers to be
included in report rows, for compatibility with RFC 7489, but the practice
is deprecated.
DMARCbis seeks to maximize reporting participation by minimizing the
processing burden placed on evaluators during both message evaluation and
report generation. A specific design goal is to require only that
evaluation-time processing which is required to determine a result for the
SPF and DKIM components, both of which MUST be evaluated for each reported
message.
DMARCbis requires only one aligned DKIM identifier to be reported per
message. When the aligned DKIM result is PASS, the identifier which
generated the PASS result is reported. When all aligned DKIM identifiers
produce FAIL, the aligned signature which is closest to the top of the
message should be chosen, because it is most likely the last one applied
and therefore the one least likely to be superceded. Additional aligned
identifiers MAY be reported at the discretion of the evaluator.
By reporting on the most important DKIM identifier only, aggregation levels
are increased, report generation complexity is reduced, and report sizes
will be reduced. Smaller reports lower the bandwidth burden for message
transmission and reduce the need to fragment reports into multiple messages.
Because an excessive number of signatures might be used as an attack
method, evaluators are cautioned to limit the maximum number of DKIM
signatures that they evaluate. For similar reasons, and to ensure
interoperability between report generators and report receivers, report
generators that provide more than the one required DKIM result, must limit
results to a maximum of 10 concurrent DKIM signatures.
2) Change the XML schema to limit the maximum number of DKIM results:
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="10"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
