On Wednesday, August 17, 2022 11:12:32 AM EDT John Levine wrote: > It appears that Alessandro Vesely <ves...@tana.it> said: > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-dmarc-failure-reporting-04.htm > >> l > > > >This version requires some revision/ discussion by the WG. > > > >In particular, IANA considerations has two subsections which may neew the > >chairs approval. > > I see no need to invent new IANA registries and oppose the proposed > registries. > > It redefines the SPF-DNS report item defined in RFC 6591 in a way that is > neither forward nor backward compatible. I oppose this change. > > >The concept of debug messages might be dropped or expanded. > > I see no basis for this change either,
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. 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. 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. I don't think it's appropriate to specify only sending debugging messages when there's no mechanism for identifying such messages. 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. 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. 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). 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. 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. 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). Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
