In article <623afe11-a57e-49f3-b845-7e48a9ae5...@kitterman.com> you write: >I don't think 8460 needed to update 6376, since valid service values are >defined by the registry, not by 6376. The mistake was >not updating the registry. > >After looking at it again, I see your point about ignoring unknown service >types. I agree a second signature for regular email >stream validation (e.g. DMARC) would make sense.
Agreed. It's worth clarifying that the s=tlsrpt signature is purely for the benefit of RFC8460 report consumers and will have no effect on the process of getting the message to that consumer through the mail stream. And if you really want to do that, there should be a way to tell the DKIM verifier called by the report consumer to look for a tlsrpt signature, not an email signature. The whole thing still seems like gratuitous overkill. If you deliver the report by https POST, there's no validation of the report sender at all. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
