[imp] PGP bug? - compliance with RFCs 3156 & 1847

[Chris Hastie]

I've been puzzled by why a PGP encrypted message sent from Imp displays 
as empty my other MUA, Turnpike.

Comparing the raw text for two similar encrypted test messages, one 
generated by Imp and one by Turnpike nothing obvious leaps out.

However, decrypting the encrypted section manually, I see Imp has:

|This is a test.
|
|--
|Chris Hastie

whilst Turnpike has

|Content-Type: text/plain;charset=us-ascii
|
|This is a test
|--
|Chris Hastie

RFC3156 states

|4.  OpenPGP encrypted data
|
|   Before OpenPGP encryption, the data is written in MIME canonical
|   format (body and headers).

which is not the clearest statement I've ever seen, but could it mean 
that there should be headers in the encrypted section too, as per the 
Turnpike message?

RFC1847 is somewhat clearer:

|   When creating a multipart/encrypted body part, the following sequence
|   of steps describes the processing necessary.  It must be emphasized
|   that these steps are descriptive, not prescriptive, and in no way
|   impose restrictions or requirements on implementations of this
|   specification.
|
|   (1)  The contents of the body part to be protected is prepared according
|        to a local convention.  The contents are then transformed into a
|        MIME body part in canonical MIME format, including an appropriate
|        set of MIME headers.
|
|   (2)  The body part (headers and content) to be encrypted is prepared for
|        encryption according to the value of the protocol parameter.  The
|        MIME headers of the encrypted body part are included in the
|        encryption to protect from disclosure the MIME labeling of the
|        data that is encrypted.
|
|   (3)  The prepared body part is made available to the encryption |process
|        according to a local convention.  The encryption process must make
|        available to a MIME implementation two data streams: the control
|        information necessary to decrypt the body part, which the MIME
|        implementation will place in the first body part and label
|        according to the value of the protocol parameter, and the
|        encrypted body part, which the MIME implementation will place in
|        the second body part and label application/octet-stream.  Thus,
|        when used in a multipart/encrypted, the application/octet-stream
|        data is comprised of a nested MIME body part.

I also note that the decrypted section from Imp has LF line terminators 
rather than CRLF. Given that this should decrypt to a plain text email, 
this seems a strange choice.
-- 
Chris Hastie