On Sun 30/Oct/2022 19:31:04 +0100 Douglas Foster wrote:
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.
Section 2.1.2's title is *DKIM Signatures in Aggregate Report*. Are you
proposing to change its title? Otherwise why a generic sentence about SPF?
I wouldn't say that a message /originates/ with SPF PASS. An spf=pass result
will only be obtained on reception. Messages originate at MUAs and may be
revamped at MSAs. Neither of those has to have an IP registered at the
domain's SPF record. SPF IPs are those of the boundary servers.
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.
Allowing domain holders to have insight into which IP addresses are sending on
their behalf is not a side effect, it is the primary focus of DMARC reporting.
There is a field in aggregate reports which states the reason why the domain's
policy was overridden. And it is there by design.
Consequently, only aligned identifiers are relevant for Aggregate Reporting,
in the same way that only aligned identifiers are relevant for determining a
DMARC result.
How you derive that consequence is obscure to me. Any identifier, especially
if authenticated, is relevant.
DMARCbis allows non-aligned identifiers to be included in report rows, for
compatibility with RFC 7489, but the practice is deprecated.
Disagreed.
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.
Evaluating DKIM signatures is indeed a burden, especially if using long keys.
The cost of adding an evaluated identifier to a report, in comparison, is
totally negligible. Nobody is going to evaluate a signature at report
generation time, because the message might have been deleted and/or DKIM keys
revoked after some hours. The only issue is how to store and retrieve the
results. That's how the content of aggregate reports is determined.
Considerations on what to evaluate don't belong to aggregate reporting spec.
DMARCbis requires only one aligned DKIM identifier to be reported per message.
Disagreed.
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.
As long as aggregate reporting also serves to convey an insight on abuse,
authenticated identifiers have some relevance. Reporting failed identifiers
serves to direct domain owners to fix their signing practices, and is only
relevant during the initial period of deploying the signing software.
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.
I don't think this leads to significant savings. My understanding is that the
size limiting suffix of the rua= URI was stroked because reports exceeding the
commonly accepted 10Mb size have not been observed. That is to say,
fragmentation doesn't seem to be an issue.
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.
Agreed, but this statement doesn't belong to aggregate report spec.
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.
I don't recall a report with more than 10 signatures, but if it arrived it
couldn't cause any DoS nor any interoperability issue.
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>
I see no reason to put such a limit.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
