On Sunday, March 29, 2020 4:03:42 PM EDT John R Levine via dmarc-discuss wrote: ... > The C libopendkim and perl Mail::DKIM libraries have hard-coded tests for > 'email' or '*'. Python dkimpy has a kludge that accepts 'tlsrpt' along > with the other two. None of them have a way to say to look for a service > type other than 'email', > > Beyond the kludge in dkimpy I don't see how to make mta-sts work properly > with DMARC other than by even more grotesque kludges.
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. > 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? I think what the latest version is doing is what is defined in RFC 6376 and RFC 8460 (there are some additional restrictions on tlsrpt processing defined in RFC 8460). Before RFC 8460 came up dkimpy ignored s= completely because there wasn't anything specific to do for specific service types and anything is valid. On a related note, RFC 8460 neglected to register the new service type. I've filed an erratum about that: https://www.rfc-editor.org/errata/eid5889 Scott K _______________________________________________ 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)
