About ARC: When evaluating a forwarded message, I want to know the pre-forwarding values of the 4 key identifiers: - Source IP - Helo - MailFrom - From (Reverse DNS is also important, but can be computed at evaluation time.)
The pre-forwarding identifiers are needed to apply a correct sender reputation based on those original values. Sophisticated parsing can create guesses for some of those values, but the preferred method is for the forwarder to declare that information. Consequently, ARC is essential. Unfortunately, ARC is written with an emphasis on test results rather than test parameters, so those identifiers are only presented if SPF and DMARC are tested. Even then, there is no assurance that the identifiers will be explicitly presented with the test results. I gain no benefit from knowing that a message was not impersonated if I don't know what identifier was not impersonted. The focus on test results also means that ARC is only appropriate when a message has been received via unauthenticated SMTP, where SPF and DMARC are applicable. We need to provide a way for message originators to document the original values of a message. Microsoft is already misusing ARC to do this, and Google's DARA proposal has identified the same need. To fix this problem, we should tweak ARC to allow a result of "NotTested" (or "Null"), to indicate that identifiers are being supplied even though the test was not performed or is not applicable to the current point in message processing. Additionally, we need to state that, to be considered minimally useful, an ARC set should include at least MailFrom, From, SourceIP, and Helo. Doug Foster On Mon, Jul 31, 2023 at 2:59 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Mon, Jul 31, 2023 at 4:27 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Murray has said that we cannot impose obligations on mailing lists, >> because he does not perceive them as DMARC participants. >> > > I don't recall saying that. My perspective is that the "lists are > misbehaving" assertion has no basis, and that the idea of demanding all > lists the world over start munging From fields (or whatever mutation we > claim is now mandatory) will not happen in short order no matter how much > we wish it would. > > >> But to my mind, "Trusted Attestation" means that the mailing list SHOULD >> provide an ARC Set and MUST do so if it wants the benefit of this paragraph. >> > > As I mentioned on Friday at 117, ARC is a four year old experiment now. I > suggest that we need to resolve whether ARC is mature enough and provide > enough valuable signal to start using as a building block, or concede that > it's not giving us what we need and leave it behind. > > -MSK, participating >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
