On Fri 21/Jun/2024 21:52:24 +0200 Todd Herr wrote:
On Fri, Jun 21, 2024 at 10:06 AM Alessandro Vesely <[email protected]> wrote:
On Thu 20/Jun/2024 18:24:30 +0200 Todd Herr wrote:
Both RFC 7489 and DMARCbis describe the 'd' and 's' values as requesting the
generation of a DKIM failure report (RFC 6651) or SPF failure report (RFC
6652). Is that what we want, or should it be a report in the format defined
in draft-ietf-dmarc-failure-reporting?
I think RFC 7489's usage of the terms DKIM and SPF in that context is a typo.
It meant to say, e.g., "Generate a DMARK failure report with DKIM
characteristics if..." rather than "Generate a DKIM failure report
if...". In fact, Section 7.3.1 extends AFRF in two flavors, dkim and spf.
They both have type "dmarc".
I'm not sure that I agree with your assertion here. I'd be more inclined to
think you correct if the text in 7489 didn't explicitly reference RFCs 6651
and 6652:
d: Generate a DKIM failure report if the message had a signature
that failed evaluation, regardless of its alignment. DKIM-
specific reporting is described in [AFRF-DKIM].
s: Generate an SPF failure report if the message failed SPF
evaluation, regardless of its alignment. SPF-specific
reporting is described in [AFRF-SPF].
If it was an error on the part of the authors of 7489 to describe 'd' and
's' in this way, it's on a scale that's much larger than just a typo.
Perhaps I'm wrong. I add Murray to recipients to prompt him to chime in.
Note that in RFC 6651 you don't find the phrase "DKIM failure report", nor in
RFC 6652 find "SPF failure report". Since DMARC reports have those two
flavors, it may make sense to call them that way when referring to those
specific sub-types. If not "typo", you can call it "underdetermination".
The last paragraph in that section explicitly says:
3. Authentication Failure Type "dmarc" is defined, which is to be
used when a failure report is generated because some or all of
the authentication mechanisms failed to produce aligned
identifiers. [...]
If, as John proposed and Scott agreed, you want to leave it ambiguous, just do
so. Don't add that the format depends on the value of fo=, as that would
require a completely different specification of fo=.
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
