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 or default s=*. Socketlabs' keys do indeed have s=tlsrpt so the
signature validation fails.
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.
I suppose I could imagine defining an ad-hoc list of local addresses that
expect special DKIM service types, and somehow have the DKIM libraries
adjust the service type depending on the current RCPT TO, but ugh. I also
suppose we could encourage socketlabs to add another signature with the
same d= but an s=email key.
At the moment it's OK-ish because socketlabs' mail is SPF aligned, so even
if I were enforcing their p=reject policy, they'd pass. I have also seen
no fake mta-reports at all, and I'm finding it hard to imagine a plausible
threat model in which a bad guy could get the required signature with
s=email but not s=tlsrpt.
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.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
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)