If RFC7591bis is attempted, I suggest that we need result types for authenticated reception, such as - SMTP Auth of Mailfrom address - SMTP Auth of server using an address other than MailFrom - SMTP whitelist of server IP - Trusted server via VPN Tunnel
The particular concern relates to outbound filtering and relay services. Those vendors have some mechanism for distinguishing clients from non-clients, and clients from each other. That mechanism has to involve more than SPF and DKIM. Lacking an alternative way to document trust, I noticed a Microsoft server using ARC to assert DMARC PASS on a message for which it was never more than a relay agent on behalf of the originating domain. DF On Thu, Aug 18, 2022, 11:08 AM Scott Kitterman <skl...@kitterman.com> wrote: > 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
