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)

Reply via email to