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