In article <3074162.RNaZIRUnTP@l5580> you write: >RFC 6376, Section 3.6.1, in the s= paragraphs says: > >> * matches all service types > >If libopendkim and Mail::DKIM are looking for a literal '*' as the service >type, rather than accepting any value for service type, they are buggy and >should be fixed AFAICT.
If there's an s= tag, they accept "*" or a colon separated list that contains "email". My locally patched libopendkim does what pydkim does and also accepts a list with "tlsrpt". The language in 6376 says if a key record has an s= tag and it doesn't have a value we like, we ignore the record. That's why the DKIM signatures with s=tlsrpt don't validate, since that's not a key that's valid for the 'email' service. >> RFC 8460 says the key SHOULD have s=tlsrpt and the recipient MAY ignore >> reports without that service type. I'm inclined to consider that an error >> in view of experience with it. Different service types are for messages >> delivered some way other than SMTP. > >I'm not sure that follows if service types are correctly processed. I am >curious what you think it a kludge in dkimpy? Since RFC 8460 doesn't update 6376, I'm confident that an s=tlsrpt key shouldn't validate a signature on ordinary e-mail not intended as a TLS report. Arguably, it shouldn't validate e-mail even if it *is* intended as a report, since the spec says s= is there for "other services" and TLS reports aren't another service, they're e-mail. If you want to make RFC 8460 happy, add another signature separate from the one that email uses. My recollection from back when that language was written 15 years ago is that we meant service in the RFC 6335 sense, different things that would never show up in the same stream as e-mail messages. The specific example was signing SIP headers, which I think would have been a better idea than much more complex STIR/SHAKEN. It still might be interesting to put DKIM signatures on HTTP messages. R's, John _______________________________________________ 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)
