Version: 2.1.1 (using KDE 4.6.5) OS: Linux If I create a new mail with S/MIME sign, the the mail is not readable some email client (example on iphone). The problem is a smime.p7m attachment. Is the p7m the S/MIME encrypted mail? Or not? If I remove out this line (on my IMAP server): Content-Disposition: attachment; filename="smime.p7m" ...then the mail is readable on iphone Reproducible: Always Steps to Reproduce: 1. Create a new mail with "any body" 2. sign the mail with smime 3. send 4. read the mail on iphone: - Not see the "any body" - see a smime.p7m Expected Results: The Thunderbird and Claws-mail are working right.
My iPad and some Outlook-Web recipients are experiencing the same problem. A signed but not encrypted email has Content-Disposition: smime.p7m header, which seems to confuse them. I looked at email S/MIME signed by other clients, they don't have Content-Disposition header in the main body. It seems though that KMail is creating a correctly enveloped S/MIME message. Per RFC 2633, S/MIME message doesn't have to be encrypted. http://tools.ietf.org/html/rfc2633#section-3.3 Not sure what to do. Fat chance changing Apple or Microsoft. **** My email (KMail) … User-Agent: KMail/4.6.1 (Linux/2.6.37.6-smp; KDE/4.6.5; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2611496.STdDYbFXGI"; micalg="sha1"; protocol="application/pkcs7-signature" Content-Disposition: attachment; filename="smime.p7m" Content-Transfer-Encoding: 7Bit … --nextPart2611496.STdDYbFXGI Content-Type: multipart/alternative; boundary="nextPart1735059.Y8m6fQfRX9" Content-Transfer-Encoding: 7Bit --nextPart1735059.Y8m6fQfRX9 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" … **** S/MIME signed email that works (Outlook) X-Mailer: Microsoft Office Outlook 11 Content-Type: multipart/signed; boundary="----=_NextPart_000_0031_01CCBBD2.D648E710"; micalg=SHA1; protocol="application/x-pkcs7-signature" … This is a multi-part message in MIME format. ------=_NextPart_000_0031_01CCBBD2.D648E710 **** Another signed only message that works (Apple) … Content-Type: multipart/signed; boundary="Apple-Mail=_C326CAAF-0EAF-4005-8DCC-325090799426"; protocol="application/pkcs7-signature"; micalg=sha1 … --Apple-Mail=_C326CAAF-0EAF-4005-8DCC-325090799426 Content-Type: multipart/alternative; boundary="Apple-Mail=_F5D2039F-FF8C-4312-AD04-6F811B8119B7" --Apple-Mail=_F5D2039F-FF8C-4312-AD04-6F811B8119B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 … --Apple-Mail=_F5D2039F-FF8C-4312-AD04-6F811B8119B7-- --Apple-Mail=_C326CAAF-0EAF-4005-8DCC-325090799426 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 **** Yet another S/MIME signed (Thunderbird) **** Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070706070308090400050105" This is a cryptographically signed message in MIME format. --------------ms070706070308090400050105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit … --------------ms070706070308090400050105 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
Actually this newer RFC (http://tools.ietf.org/html/rfc3851#section-3.4) says it better. 3.4. Creating a Signed-only Message There are two formats for signed messages defined for S/MIME: application/pkcs7-mime with SignedData, and multipart/signed. In general, the multipart/signed form is preferred for sending, and receiving agents MUST be able to handle both. 3.4.1. Choosing a Format for Signed-only Messages There are no hard-and-fast rules when a particular signed-only format is chosen because it depends on the capabilities of all the receivers and the relative importance of receivers with S/MIME facilities being able to verify the signature versus the importance of receivers without S/MIME software being able to view the message. Messages signed using the multipart/signed format can always be viewed by the receiver whether they have S/MIME software or not. They can also be viewed whether they are using a MIME-native user agent or they have messages translated by a gateway. In this context, "be viewed" means the ability to process the message essentially as if it were not a signed message, including any other MIME structure the message might have. Messages signed using the SignedData format cannot be viewed by a recipient unless they have S/MIME facilities. However, the SignedData format protects the message content from being changed by benign intermediate agents. Such agents might do line wrapping or content-transfer encoding changes which would break the signature. It seems that KMail is sending signed messages as "multipart/signed", but using SignedData, which is incorrect.
kmail creates corrent SMIME messages in both formats based on the RFC3851: SMIME and SMIME Opaque. tested with kmail 4.10.1