I have some mails which appear to be PKCS7 SMIME bodypart..
containing... PKCS7 SMIME bodypart.
In my $DAYJOB, I deal with a lot of these as you can imagine. My
reading of the relevant specs is that the first encapsulation is
encryption, and the second is signing. The encryption is what I care
about, since in our environment that's typically encrypted using a
key on a smartcard.
It's like some emailers have to super-encode things. I haven't done
much debug, and I know this is being super-lazy, but even the Mail.app
on OSX barfs on it. I suspect its O365 which is sending it.
Well, it depends what you're talking about.
As far as I know, Mail.app works fine as long as it's "vanilla" S/MIME,
including the double signing/encryption. What messes things up is
if Microsoft products generate a TNEF-format file, which is their
proprietary MIME-like format. Mail.app cannot handle that, unfortunately.
In theory Microsoft products aren't supposed to be doing that when sending
external email, but it happens.
So.. is there a trick to get NMH to know to unwrap-the-unwrap?
Yes. You mentioned OS X, so I'll tell you what I do:
- mhstore the first S/MIME part, which will probably end up a file called
smime.p7s (or something close to that)
- Use the MacOS X command "security cms -D < smime.p7s > output" to decode
the signed data. If the outer part is signed you don't need a private
key at this point.
- Edit "output" and convert it to Unix-style line endings to deal with a bug
in nmh (fixed in current).
- Use "mhstore -file output" to store the raw S/MIME data; you can also
use "mhlist -file output" to see the MIME parts (but in this case there
is typically only one).
- Use the same "security" command again to decrypt the data. At this point
you will need the appropriate certificate/private key in your keychain
or on a smartcard (you can specify it, but if there is an associated
certificate the security command usually can find it).
I have a plan to eventually add S/MIME support to nmh, but ... so little
time.
--Ken