Creating HTML emails with mutt

martin f krafft madduck at madduck.net
Mon Oct 28 23:41:44 UTC 2019


Hi Kevin,

Thanks for sharing your thoughts and plans on this. This all reads 
really well, and I think it would go most of the way towards the 
ideal solution.

I have a couple of points/questions about some of the things you 
propose:

>If there were an error sending, the alternative would be stripped 
>before returning to the compose menu.  So it would not be exposed 
>to the compose menu.  I *might* add a function to preview the 
>output as raw text and via mime from the compose menu though.

The ability to preview sounds great, and I would greatly appreciate 
it.

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

>Anyway, that's my current plan.  The problem is cleaning up some 
>other parts of mutt to deal with bouncing, reuse as a template, 
>etc.

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.

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

Processing a message to be attached, or a message to be bounced, 
seems to me like a really bad idea, especially since it should only 
ever be applied to messages that were locally authored. Maybe this 
would mean storing with the locally recorded message a little bit of 
metadata suggesting that Mutt generated an alternative part for this 
message when it was sent?

Yeah, this can get ugly fast, and maybe the right way forward is 
instead to store the generated content when saving a message 
locally, but to teach Mutt to discard any multipart/alternative 
non-text/plain part when reusing a message as a template, similarly 
to how that part is discarded on error before it's returned to the 
compose menu?

Best regards,

-- 
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
the english take english for granted.
but if we explore its paradoxes,
we find that quicksand can work slowly.
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1118 bytes
Desc: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20191029/43e286d4/attachment-0001.asc>


More information about the Mutt-users mailing list