Re: Forwarding inconsistency

2022-06-09 Thread Kevin J. McCarthy

On Thu, Jun 09, 2022 at 09:05:47AM -0700, Kevin J. McCarthy wrote:
I won't have time to investigate until this weekend, but it looks like 
this is an issue with encrypted S/MIME.  The forward handler is always 
specifying to decode.


There *is* code to properly decrypt-only, but I need to take a closer 
look to see if that was an oversight or there are other issues 
involved. If not, then this may be an easy fix.


Again, I'll investigate more this weekend.  But you are welcome to try 
the attached patch and see if it works for you.


Thank you.

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
From 9fceb55099b6d4eec53c0ae668fbb631b7b353b2 Mon Sep 17 00:00:00 2001
From: Kevin McCarthy 
Date: Thu, 9 Jun 2022 09:22:03 -0700
Subject: [PATCH] wip: decrypt s/mime when mime-forwarding with
 $forward_decrypt

---
 sendlib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sendlib.c b/sendlib.c
index b0b94b4f..d9429c2e 100644
--- a/sendlib.c
+++ b/sendlib.c
@@ -1383,8 +1383,8 @@ retry:
 else if ((WithCrypto & APPLICATION_SMIME) &&
  ((mutt_is_application_smime (hdr->content) & SMIMEENCRYPT) == SMIMEENCRYPT))
 {
-  chflags |= CH_MIME | CH_TXTPLAIN;
-  cmflags = MUTT_CM_DECODE | MUTT_CM_CHARCONV;
+  chflags |= CH_MIME | CH_NONEWLINE;
+  cmflags = MUTT_CM_DECODE_SMIME;
   pgp &= ~SMIMEENCRYPT;
 }
   }
-- 
2.35.1



signature.asc
Description: PGP signature


Re: Forwarding inconsistency

2022-06-09 Thread Kevin J. McCarthy

On Thu, Jun 09, 2022 at 10:19:24AM +0100, ckeader wrote:
I've come across what I believe is an inconsistency in message 
forwarding.  It seems that encrypted and non-encrypted messages are 
treated differently.  When I forward a full message as 
"message/rfc822", I expect the same result, regardless of encryption 
status.


Thank you for the bug report.

I won't have time to investigate until this weekend, but it looks like 
this is an issue with encrypted S/MIME.  The forward handler is always 
specifying to decode.


There *is* code to properly decrypt-only, but I need to take a closer 
look to see if that was an oversight or there are other issues involved. 
If not, then this may be an easy fix.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Forwarding inconsistency

2022-06-09 Thread ckeader
Hi all,

I've come across what I believe is an inconsistency in message forwarding.
It seems that encrypted and non-encrypted messages are treated differently.
When I forward a full message as "message/rfc822", I expect the same result,
regardless of encryption status.

With current settings,

set forward_decode=no
set mime_forward=ask-yes

I can forward a whole message as "message/rfc822", including all attachments.
But only if it is not encrypted. If the message is encrypted (in my case,
using S/MIME - I have not investigated PGP/MIME) and has, say, a pdf
attachment, after answering the "Forward as attachment?" question (yes),
the pdf attachment is displayed just like when the message is viewed (via the
auto_view mechanism), then the editor is opened, and upon exit, the compose
menu is shown. Here, one can clearly see that the new attachment is much
smaller than the original message, it contains only the text part.

Original encrypted message:

  I 1   [multipa/alternativ, 7bit, 11K]
  I 2 |->  [text/plain, 8bit, iso-8859-1, 1.4K]
  I 3 `-> [text/html, quoted, iso-8859-1, 9.5K]
  A 4 ghostbusters.pdf  [applica/pdf, base64, 289K]

Forwarded message (before sending):

- I 1 /tmp/mutt-zool-2345234-1522-66787906246857[text/plain, 7bit, utf-8, 
0.1K]
- I 2 Original Subject   [message/rfc822, 8bit, 
3.4K]

The result is the same regardless of "include_encrypted" no/yes, but
then that is to be expected as the manual states it covers separately
encrypted attachment contents only, which is not the case here.

I have taken the manual's notice about "accidental  exposure of encrypted
contents" on board. But in this case, the warning is moot as the forwarded
message defaults to the same encryption status as the original.

Thx.