Re: Forwarding inconsistency
On Fri, Jun 10, 2022 at 10:51:42PM +0100, ckeader wrote: Thank you, Kevin! Yes, the patch works for this specific case, and I haven't tested it any further. Great. Thanks for testing it out. I've been taking a closer look, and I believe that fix is the correct one - it looks like it was just a mistake in the message attachment function. The correct behavior is found, for instance, in the set_copy_flags() function. I'll commit the fix to stable this weekend. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Forwarding inconsistency
Kevin J. McCarthy writes: > 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! Yes, the patch works for this specific case, and I haven't tested it any further. - I 1 /tmp/mutt-zool-2345234-23782-1092984390679[text/plain, 7bit, utf-8, 0.1K] - I 2 Original Subject [message/rfc822, 8bit, 909K]
Re: Forwarding inconsistency
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
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
