In my recent travails getting s/mime working seamlessly with mutt, I
have been testing my setup with an associate, who knows even less than I
do. The clincher is, he is using Novell GroupWise 6.0.3.Beta. Both of
us are using Thawte's personal email certificates.
I can send signed and/or encrypted messages to him without problems. It
is possible for me to successfully verify his signed messages and to
decrypt his encrypted messages; but, not without a hitch.
All of his s/mime messages to me contain this *SAME* header:
Content-Type: application/x-pkcs7-mime; name=smime.p7m
Whether he simply signs the message, -OR- encrypts the message, that is
the Content-Type header that he sends.
I have examined several messages from me to me, and from him to me, and
I have found the following header allows me to decrypt encrypted
messages:
Content-Type: application/x-pkcs7-mime; smime-type=enveloped-data;
name="smime.p7m"
Notice this difference:
smime-type=enveloped-data
In other words, when the Content-Type header tells me that it contains
`enveloped-data', then I can decrypt it.
I have tried to catch those Content-Type headers and add that data
element via Procmail; but, then his signed-only messages fail.
Notice, my messages have a _different_ header for signed-only:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
micalg=sha1; boundary="Enx9fNJ0XV5HaWRu"
So, we have two (2) problems:
[1] His MUA does not use the `pkcs7-signature' mime type; and
[2] His MUA does not tell me when it has `enveloped-data'.
What do you think?
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
Attachment:
signature.asc
Description: Digital signature