On Sun, Aug 23, 2026 at 08:46:52AM +0200, Rene Kita wrote:
On Sun, Aug 23, 2026 at 12:57:02PM +0800, Kevin J. McCarthy wrote:Editing an attachment after attaching it (with a normal tool; recode is known to be an aberration).I can't remember I ever saw that message, but I don't quite get it: Attachment #2 modified. Update encoding for /tmp/f? ([yes]/no): This is after an 'echo a >> /tmp/f'. Why "Update encoding"?
Mutt scans the attachment to determine whether to use 7-bit, 8-bit, QP, or Base64 encoding. It wants to make sure the encoding is still appropriate. This can also manually be edited via ^E <edit-encoding> in the compose menu.
It also scans text types to determine the charset to be used.
Honestly, the protections offered have been minimal, but they've been that way for 30 years without any tickets or reported issues. So, I'd need to be convinced this suddenly requires a redo using hashes.I wonder what behaviour people would expect these days, when attaching a file is it a link to the current version or a snapshot of the file when it was attached?
By default it points directly at the attachment, but you can use <get-attachment> to copy it to tmpdir, to prevent updates from touching mutt's version.
I'd guess it is the former. So I'd say that the reason that no one reported an issue might that people don't expect it and never notice. I don't look at the attachments in my +Sent.
Yeah, they might not. The receiver might notice if the encoding was wrong for a text attachment that suddenly had 8-bit chars added. I agree though, this is hard to say.
That being said, I think the approach in v2 looks good to me as a fix for the current behavior.
Thanks! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA
signature.asc
Description: PGP signature
