Re: [Patch] fix broken decryption of s/mime messages loaded from imap

Hi Albrecht,
Thanks for the patches!
I'll have only a phone for a few days--will get to them on Monday.
Best, Peter

-------- Original message --------
From: Albrecht Dreß <albrecht dress arcor de>
Date: 2/9/19 6:54 AM (GMT-05:00)
To: balsa-list gnome org
Subject: Re: [Patch] fix broken decryption of s/mime messages loaded from imap

Am 08.02.19 18:52 schrieb(en) Albrecht Dreß:
> After digging through the code, I /think/ the problem is in libbalsa_mailbox_imap_fetch_structure() which loads only text/* and short messages completely (to be honest, I don't understand why multipart/* is working, though…).  At least, the attached trivial patch, just loading single-part S/MIME messages just as text/*, solves the issue for me.

Thinking again about this issue, I guess this approach is not completely correct.  If all multipart/* messages are handled at some other place (are they?), shouldn't *all* other top-level content types be loaded here?  The vast majority will (explicitly or implicitly) be text/*, and application/pkcs7-mime is already somewhat special.  But a message containing only a, say image/* or application/pdf as the only payload is absolutely legal (although I saw the latter with malspam attacks only…).

Thus, the more appropriate approach would be

diff --git a/libbalsa/mailbox_imap.c b/libbalsa/mailbox_imap.c
index d85e377c1..2ba010b43 100644
--- a/libbalsa/mailbox_imap.c
+++ b/libbalsa/mailbox_imap.c
@@ -2247,7 +2247,7 @@ libbalsa_mailbox_imap_fetch_structure(LibBalsaMailbox *mailbox,
         LIBBALSA_MESSAGE_GET_LENGTH(message)<8192 ||
         (message->headers &&
          (!message->headers->content_type ||
-         g_mime_content_type_is_type(message->headers->content_type, "text", "*"))) ){
+         !g_mime_content_type_is_type(message->headers->content_type, "multipart", "*")))) {
          /* we could optimize this part a little bit: we do not need to
           * keep reopening the stream. */
          GMimeStream *stream =

wouldn't it?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]