Regarding the following, written by “Kevin J. McCarthy” on 2019-10-29 at 12:58 Uhr +0800:

The part creation (and removal) will be in Mutt’s pipeline, and so will follow normal processing that Mutt does. That include encoding, delimiters, charset conversion, etc. So I would like the script to simply produce the HTML (or PDF, or whatever) output, without trying to “mailify” the output.

Makes perfect sense.

At the risk of overcomplicating things at this stage, I do want to put one more idea out there, which is that instead of the script returning content of a specific type, and thus always with the same content type (unless the filter script is interactive of sorts), what about a command or option that I can use to instruct mutt to generate an alternative of a given MIME type, which is then passed to the script, and the return data assumed as such.

Now, I could configure mutt to always add a text/html alternative, but also have a command from the compose menu allowing me to add e.g. text/enriched, or application/pdf.

Reusing as a template would be resolved if we kept a local record >of the messages without the generated content, similar to how >$fcc_attach removes the attachments before storing.

For this iteration, I didn’t plan on going here. $fcc_attach would still just remove attachments, the main content would be stored as it were generated (i.e. including multipart/alternatives). Maybe in the next iteration I could add an option to strip the alternative.

The more I think about this, the less I think this should be an option. Even $fcc_attach is already quite a problem, especially since it means that the message stored locally isn’t the same as the one you sent, with a different GPG signature and all.

Yes, this is one of the places I need to look at. My plan is the simplest, as you mentioned: discard the alternative when generating anything that goes through the compose menu.

… but not on messages that are being forwarded as attachments. Those don’t get touched, right?

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

who's general failure, and why's he reading my disk?

spamtraps: madduck.bo...@madduck.net

Reply via email to