---
Amended patch follows, with a better wording that I had seemingly not
committed. Sorry for the noise.
lib/sup/crypto.rb | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
index 8ec277b..acbc1d8 100644
--- a/lib/sup/crypto.rb
+++ b/lib/sup/crypto.rb
@@ -132,8 +132,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"
- [RMail::Parser.read(decrypted_payload), sig, notice]
+ [msg, sig, notice]
else
notice = Chunk::CryptoNotice.new :invalid, "This message could not be
decrypted", output.split("\n")
[nil, nil, notice]
--
1.6.3.3
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
