Subject: Re: bug#70338: message-fcc-externalize-attachments has no effect

From: Eric Abrahamsen <[email-masked]>
Date: Sat, 20 Apr 2024 17:28:58 -0700

On 04/20/24 19:29 PM, Nicolas Graner wrote:
> Eric Abrahamsen <[email-masked]> wrote on 2024-04-20 08:36:
>> So far I don't see that this option would actually do anything in an FCC
>> context. `message-fcc-externalize-attachments' is only used in
>> `message-do-fcc`, where its value is let-bound to
>> `mml-externalize-attachments'.
>>
>> But `mml-externalize-attachments' is only consulted in
>> `gnus-inews-do-gcc', which already doesn't sound very promising. That
>> function first let-binds `mml-externalize-attachments' to nil, before
>> doing its own setting, so any dynamic value is getting overridden
>> anyway.
>>
>> I tried starting with `gnus-gcc-externalize-attachments' and sending a
>> message with an attachment, just to see how it's supposed to work.
>> Nothing seemed to happen.
>>
>> Can you tell me what the desired effect is supposed to be? Does the
>> "gcc" version of this option work for you?
>>
>> Eric
>
> When you attach a file to a mail message you are writing, only an anchor
> with the file name is inserted in the message buffer. When the message
> is sent, the anchor is replaced with the actual MIME-encoded contents of
> the attached file. The copy of the message that is written to the FCC
> file also includes the MIME-encoded attached file.
>
> I was expecting that externalization would mean that the copy in the FCC
> file would only include an anchor rather than the attachment, which
> would be extremely useful. I must admit this was only a guess (wishful
> thinking?) since the documentation is not explicit at all.

Oh, that sounds very useful, I've often wanted that.

> I don't use gnus. To test the gnus version of the variable, I guess I
> would need access to a free, public NNTP server, which I don't know
> where to find. Can you help?

I think most of us use news.gmane.io

I tested the GCC version again (now that I know what it's supposed to
do), and it did work -- the version of the message in my Sent folder had
a mime part of "message/external-body".

Long story short, the encoded body of the message is cached during
sending, and the cached version is re-used during GCC/FCC handling. If
the user has requested the externalization of attachments, the GCC
version of the code knows to use that as a flag to dump the cache and
re-generate it with externalized attachments; the FCC code doesn't do
the equivalent.

I've pushed a change that fixes this issue in my testing -- are you
using Emacs master? If not, I've attached the commit here, I hope you'll
be able to test it.

Thanks,
Eric

>From 3dfca6f9c7f4da512fff48cf6957c6492e2c0449 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <[email-masked]>
Date: Sat, 20 Apr 2024 17:25:20 -0700
Subject: [PATCH] Re-encode message bodies with externalized attachments during
 FCC

Bug#70338

* lisp/gnus/message.el (message-do-fcc): If the user has requested to
externalize attachments, we can't use the cached version of the message
body from sending. This mirrors an equivalent check for GCC in
`gnus-inews-do-gcc'.
---
 lisp/gnus/message.el | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 979d2fecf56..b2805774162 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -5768,8 +5768,10 @@ message-do-fcc
       (with-temp-buffer
 	(insert-buffer-substring buf)
 	(message-clone-locals buf)
-	;; Avoid re-doing things like GPG-encoding secret parts.
-	(if (not encoded-cache)
+	;; Avoid re-doing things like GPG-encoding secret parts, unless
+	;; the user has requested that attachments be externalized, in
+	;; which case we have to re-encode the message body.
+	(if (or mml-externalize-attachments (not encoded-cache))
 	    (message-encode-message-body)
 	  (erase-buffer)
 	  (insert encoded-cache))
-- 
2.44.0