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
On March 29, 2020 10:36:50 PM UTC, John Levine wrote:
>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
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
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
While fiddling with scripts to analyze mta-sts reports, I noticed some
peculiar DKIM validation failures in reports from socketlabs. RFC 8460
which defines the reports says that mail reports have to be DKIM signed
and the DKIM validation key should say "s=tlsrpt" rather than the usual
s=email
