sup

commit 6d6909aaff8c9111de2103b61ac069e6701a5912
parent 9602714be5bc88611e8f42403ea248c2dbf43b69
Author: William Morgan <wmorgan-sup@masanjin.net>
Date:   Sat, 12 Sep 2009 13:06:18 -0400

Merge branch 'crypto-mime-fix' into next

Diffstat:

1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
@@ -128,8 +128,26 @@ class CryptoManager
         end
       end
 
+      # This is gross. This decrypted payload could very well be a multipart
+      # element itself, as opposed to a simple payload. For example, a
+      # multipart/signed element, like those generated by Mutt when encrypting
+      # and signing a message (instead of just clearsigning the body).
+      # Supposedly, decrypted_payload being a multipart element ought to work
+      # out nicely because Message::multipart_encrypted_to_chunks() runs the
+      # decrypted message through message_to_chunks() again to get any
+      # children. However, it does not work as intended because these inner
+      # payloads need not carry a MIME-Version header, yet they are fed to
+      # RMail as a top-level message, for which the MIME-Version header is
+      # required. This causes for the part not to be detected as multipart,
+      # hence being shown as an attachment. If we detect this is happening,
+      # we force the decrypted payload to be interpreted as MIME.
+      msg = RMail::Parser.read(decrypted_payload)
+      if msg.header.content_type =~ %r{^multipart/} and not msg.multipart?
+        decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload
+        msg = RMail::Parser.read(decrypted_payload)
+      end
       notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display"
-      [notice, sig, RMail::Parser.read(decrypted_payload)]
+      [notice, sig, msg]
     else
       Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n")
     end