unable to decrypt / verfiy attachments.

[Philj34]

Using Win7-64, gpg4win 2.2.0, Thunderbird 24.0.1, enigmail 1.5.2

A new correspondent has sent me emails with no text in body but only an encrypted attachment which he named 'encrypted.asc'. Enigmail help confirms that such named attachment should be able to be opened by selecting the appropriate option after right-clicking on it.

I find that the 2 options 'Decrypt and open' & 'Decrypt and save as ' are both greyed out and cannot be used. The only gpg option available is 'Import Openpgp key' and that fails because first block is not a key block. In any case, I already have his public key on my keyring.

The only way I can access the attachment is to save it in my file structure and use GpgEX to decrypt.

What can be done to get enigmail to handle this attachment 'in place'?

[Patrick Brunschwig]

Without knowing any details, I suspect that this is an incorrect PGP/MIME message. If you provide the complete message headers including the first line of the message body from the message source, I'll be able to tell you more.

[Philj34]

I attach the message headers from the source (headers.txt). There was nothing at all in the body of the email.

There were 2 attachments : the first was called "Part1.1" and turned out to be a clear text file containing just 'Version 1' (this is attached to each of the mails he has sent me - I suppose auto generated by some part of his system). This appears from lines 15-21 of the attached file where I note it has 'Content-disposition: inline' although it is received each time as the first attachment.

The second attachment was the encrypted message called 'encrypted.asc' and is described on lines 23 -30 of my attached file.

The sender apparently uses a mac with gpgtools.

[Philj34]

Sorry - I clicked to add attachment but didn't get any invite to add a file - don't understand why. Here is the file using cut and paste :

X-Pgp-Agent: GPGMail (null)
From: YYYY xxxxxx <xxxxxx@xxxxxx>
In-Reply-To: <52606F4A.3060006@ZZZZZZZZ>
Date: Fri, 18 Oct 2013 11:11:54 +0200
Message-Id: <2BC8BB67-86EE-4878-81BD-F5F426EDDF99@DDDDDDDD.GG>
References: <52606F4A.3060006@UUUUUUU.PP>
To: RRRR TTTTTT <RRRR.TTTTTT@HHHHHHH>
X-Mailer: Apple Mail (2.1510)
MIME-Version: 1.0
Content-Type: multipart/mixed;
    boundary="b9_multipart_boundary_0=_"
Content-Description: OpenPGP encrypted message

--b9_multipart_boundary_0=_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

--b9_multipart_boundary_0=_
Content-Type: application/pgp-encrypted
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Description: PGP/MIME Versions Identification

Version: 1

--b9_multipart_boundary_0=_
Content-Type: application/octet-stream
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
    filename="encrypted.asc"
Content-Description: OpenPGP encrypted message

-----BEGIN PGP MESSAGE-----

[Ludwig Hügelschäfer]

Content-Type: multipart/mixed;

Should have been "multipart/encrypted"

Without this, Enigmail will not be triggered and Thunderbird displays the mail as it is described by the MIME structure: Body empty and an attachment containing the ciphertext.

This is usually not the fault of GPGtools on the Mac of the sender (they're doing a pretty good job), much more likely is that some mail server destroyed the MIME structure. Most prominent: Microsoft Exchange.

[Philj34]

Thank-you Ludwig for that info. I suppose nothing can be done in this case to prevent future occurrences ?

The inconvenience of having to save the attachment and decrypt using GpgEX is that the verification of the signature does not seem to occur. When I strip out the signature into a separate file and use the verification process, it fails quoting the id of an 'unknown' signature - which when I check, is exactly the correct id I have in the keyring.

It would clearly be preferable for me to have the verification confirmed automatically by enigmail / gpg4win.

[Patrick Brunschwig]

That's currently correct. I'm thinking about ways to overcome this, but so far I haven't found any possibility.

[Philj34]

I'm revisiting this question.

I've just looked at the message source of encrypted emails that I've sent out. They all have "Content-Type: multipart/mixed;" and my emails are originated and sent by Thunderbird 24.0.1 using enigmail 1.6
These emails from the 'sent' box have never left my Windows 7-64bit machine.

Seeing those headers after the statement above that the type should be multipart/encrypted gives me cause for doubt even though Ludwig seemed to have no doubt.

[Patrick Brunschwig]

In this case you sent inline-PGP messages. The difference to the problem you have with received messages is that for inline-PGP each message part is encrypted individually, whereas the message you posted all message parts are encrypted in one go. These are two different protocols that both rely on OpenPGP for encryption. Apart from this, inline-PGP and PGP/MIME don't have much in common.

[Olav Seyfarth]

I just had the same case with a friend with PGP/MIME ENCRYPTED and PGP/MIME SIGNED+ENCRYPTED messages (only). No issues with PGP/MIME SIGNED ONLY messages or with INLINE SIGNED and/or ENCRYPTED messages.

He received a message but only sees an empty mail body with two attachments, "PGPMIME version identification" and "encrypted.asc". No OpenPGP signed/encrypted indicators in the message preview window.

So I sent him test messages using TB 24.1 + EM 1.6 + GnuPG 2.0.22. He uses the same Programs to receive them.

A test message in my SENT box reads:

...
Content-Type: multipart/encrypted;
 protocol="application/pgp-encrypted";
 boundary="some_boundary_characters"

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--some_boundary_characters
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--some_boundary_characters
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.22 (MingW32)

hQQOAyySX20ZWVZSEBAAgCyeBWhmRyrSFKvOf22mspMkS3FaHgRRd3/6f2/vAp6c
...
eJrGdZzRFIYiAeDQK9xWiht48+EyzMA62zVZvPJd7Am6hXUlUHO9W7ISgmQk
=S/Ro
-----END PGP MESSAGE-----

--some_boundary_characters--

The SAME message in his INBOX reads:

...
Content-Type: multipart/mixed;
    boundary="OTHER_boundary_characters"
MIME-Version: 1.0

--OTHER_boundary_characters
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

--OTHER_boundary_characters
Content-Type: application/pgp-encrypted; name="PGPMIME version
identification"
Content-Description: PGP/MIME version identification
Content-Disposition: attachment; filename="PGPMIME version identification";
    size=76; creation-date="some_date_and_time";
    modification-date="some_date_and_time"
Content-Transfer-Encoding: base64

VmVyc2lvbjogMQ0K

--OTHER_boundary_characters
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message.asc
Content-Disposition: attachment; filename="encrypted.asc"; size=2543;
    creation-date="some_date_and_time";
    modification-date="some_date_and_time"
Content-Transfer-Encoding: base64

LS0tLS1CRUdJTiBQR1AgTUVTU0FHRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2Mi4wLjIyIChNaW5n
...
Ci0tLS0tRU5EIFBHUCBNRVNTQUdFLS0tLS0NCg==

--OTHER_boundary_characters--

So some MTA on the way must have fiddled with the message. Since there's only my postfix and his Exchange involved here and my messages arrive fine elsewhere, it's most probably a configuration issue with his Exchange server.

[Patrick Brunschwig]

Quite right. The problem here is that the parent content type for the encrypted message parts was changed from "multipart/encrypted" to "multipart/mixed". That's game over for Enigmail.

[Nicolai Josuttis]

With the latest nightly built (2014-06-05 for version 1.7) there is a workaround to try to show at least some of the contents of emails broken by a Exchange-Server (<=2010).