On Thu 18/Aug/2022 17:08:07 +0200 Scott Kitterman wrote:
I have similar concerns. Thoughts on the changes in this revision:
I think adding the reference to Section 3.2 about external destination
verification is good.
RFC 9091 says, "PSD DMARC feedback MUST be limited to Aggregate Reports." I
think that should be carried forward and so the SHOULD NOT consider RUF= tags
should be MUST NOT and the bit after the comma (unless there are ...) needs to
be deleted.
Done on Github copy.
I agree that 'aggregation techniques' should be changed since there's no
aggregation involved. I don't love 'pruning', but I think it's better.
Better terms?
I think the changes in the techniques list is problematic. I don't see why
sending a report to only the first recipient was dropped.
There is a paragraph a few lines above saying:
Where multiple URIs are selected to receive failure reports, the
report generator MUST make an attempt to deliver to each of them.
Isn't that the opposite of doing only the first recipient? A generator cannot
do both, unless it has a method to detect DDoS.
I don't think it's appropriate to specify only sending debugging messages
when there's no mechanism for identifying such messages.
Agreed. I was thinking something like Subject: [DEBUG] ... I'd drop that line
if we're not willing to specify a mechanism.
In any case, that's more of a privacy risk mitigation strategy than a denial
of service mitigation. > Generally for denial of service mitigation during
normal operations, debugging
would be one of the first things to go.
Yes, but it's still a pruning technique, no?
In 3.1 (1) I do not agree with the change to only require DKIM/SPF related
fields on failure instead of when the message was signed by DKIM or has an SPF
result. In the case of partial failures, the information is useful.
None of the failures I received quotes my SPF record. Albeit SPF actually
failed, they only report dmarc failure (Auth-Failure: dmarc). The spec
suggests a generator can independently issue an SPF failure report. Similar
argument for DKIM.
I don't think we can convince those generators to include more data. I'd
rather accept current practices.
Additionally, the limitation to aligned failures further excludes useful
information. The change in 3.1 (2) is also problematic as it is predicated on
the changes in 3.1 (1).
That change was for clarity. What does it mean "to produce an alignment"? Did
it fail or succeed? Reporting both doesn't say much, it would always be spf,
dkim, without telling which one verified or failed.
I think redefining SPF-DNS is a horrible idea. I agree that, in theory, the
txt/spf distinction is no longer needed, this would complicate receive
processing substantially (would need to be able to distinguish between the to
field formats and to process both) for the very negligible benefit of saving a
few bits on the wire.
Yes, I removed it in the Github copy.
I think the 3.2 change to more fully describe the conditions for the external
destination verification method is a good one.
For IANA considerations, I think updating the reference for Identity-Alignment
to this document is correct. I don't understand the need for a new
Authentication Failure Types registry. To the extent it may be a good idea, I
think this is the wrong place to do it. This kind of issue should be
addressed by any RFC6591bis effort that may be done at some point in the
future.
Having a place where all values are listed is somewhat practical, and may help
making ARF less of a mess than it is. I don't know if the bang is worth the buck.
Related to the failure reporting discussion for PSDs above, the Privacy
Considerations section of this draft needs to document the information leakage
potential associated with failure reporting based on PSD records (which is why
it needs to be a MUST NOT).
Should I add RFC6973 as an informative reference?
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
