>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
