Creating HTML emails with mutt

[Kevin J. McCarthy]

On Tue, Oct 29, 2019 at 12:41:44PM +1300, martin f krafft wrote:
>>Script output would be the content-type, a blank line, then the 
>>generated content.
>
>This makes me itch, but I cannot really devise a better approach. I 
>want to say that the script needs to return the complete MIME part, 
>including Content-Transfer-Encoding and other headers, or are you 
>confident that Mutt can deduce all these parameters from the generated 
>content?

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.

I think it would be okay for a charset to optionally be included in the 
content-type.  I have to think about whether to force-charset in that 
case, or still respect $send_charset.

But I don't think allowing other headers would help.  Mutt can determine 
the best content-encoding, and I think it's fair to set disposition to 
inline.  If the approach turns out to be insufficient, we can add 
features.

>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.

>However — and I just experienced this — forwarding a message as 
>attachment now means that it'll be plain-text only.

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.

-- 
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20191029/8808bbdf/attachment.asc>