S/MIME handling
- To: Mutt Users List <mutt-users@xxxxxxxx>
- Subject: S/MIME handling
- From: Sertaç Ö. Yıldız <sertac.liste@xxxxxxxxx>
- Date: Sun, 15 Oct 2006 01:47:54 +0300
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:mime-version:content-type:content-disposition:content-transfer-encoding:user-agent; b=F0JjojToCfAlI1YSNxGthZRwNwgiorUHcJMbUFY2LVIqrdG0aeSCPxyytexMFdchMDQJxokx8jqB76HPYqRP8zgibCecp1knfLNftaOLnNPfpDt9Ylkse95Onyl6lhbOUzKWdoTYiTjlsvQsBl1wmAzuVT8+z4hx/2b19Dkchlk=
- List-unsubscribe: <mailto:mutt-users-request@mutt.org?body=unsubscribe>
- Mail-followup-to: Mutt Users List <mutt-users@xxxxxxxx>
- Sender: owner-mutt-users@xxxxxxxx
- User-agent: Mutt/1.5.13 (2006-08-11)
Hi,
I'm having some difficulties with verifying the signatures of some
messages I receive with mutt. These messages generally have this
pattern:
| MIME-Version: 1.0
| Content-Type: multipart/signed;
| protocol="application/x-pkcs7-signature";
| micalg=SHA1;
| boundary="----=_NextPart_000_8FAF4_01C6EBA2.320E8700"
| Content-Transfer-Encoding: quoted-printable
| X-Mailer: Microsoft CDO for Windows 2000
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
| Status: RO
| Content-Length: 6711
| Lines: 126
|
| This is a multi-part message in MIME format.
|
| ------=_NextPart_000_8FAF4_01C6EBA2.320E8700
| Content-Class: urn:content-classes:message
| Content-Type: text/html;
| charset="iso-8859-9"
| Content-Transfer-Encoding: quoted-printable
| [..snipped..]
| ------=_NextPart_000_8FAF4_01C6EBA2.320E8700
| Content-Disposition: attachment;
| filename="smime.p7s"
| Content-Type: application/pkcs7-signature;
| name="smime.p7s"
| Content-Transfer-Encoding: base64
| [..snipped..]
| ------=_NextPart_000_8FAF4_01C6EBA2.320E8700--
Since the Content-Type headers do not conform to RFC1847, I get
"Inconsistent multipart/signed structure" error. But both evolution and
openssl can display/verify the same message without problem. Shouldn't
mutt be a little more tolerant about this kind of standards violations?
Furthermore, If I edit the content type with ctrl-e to fix it, I still
receive an error saying "Error reading S/MIME message". When I checked
the temporary file mutt feeds to OpenSSL, it had part of the message
message and part of the signature. Might there be a bug in parsing the
message?
--
~sertaç