Re: Forwarding inconsistency

2022-06-11 Thread Kevin J. McCarthy
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

Re: Forwarding inconsistency

2022-06-10 Thread ckeader
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

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

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,