Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-failure-reporting-04.txt

[Douglas Foster <[e-mail]>]

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 <[e-mail]> wrote:

> On Wednesday, August 17, 2022 11:12:32 AM EDT John Levine wrote:
> > It appears that Alessandro Vesely  <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>