[development] zoneminder 1.37.64 emailed imaged sent via zmfilter.pl do not render in (some?) mail clients

[sprda]

Debian GNU/Linux 12 (bookworm)

Emails with Options->NEW_MAIL_MODULES enabled (Use a newer perl method to send emails) and/or Options->SSMTP_MAIL enabled via a zmfilter.pl do not get rendered in android K9mail or windows Thunderbird clients.

OFF TOPIC DISCUSSION: While debugging I realized some dependencies/options are no longer maintained: MIME::Lite https://metacpan.org/pod/MIME::Lite (debian) sSMTP https://wiki.debian.org/sSMTP

I modified some code to use Email::Stuffer (no reason for selecting the module, just something I came across) to get the feature I use running again. Wondering if it's time to update some of the mail package dependencies It's may simplify the code and add additional features (TLS Transports?). I'd be willing to help with coding, though I havn't perl'd in ages.

[welcome[bot]]

Thanks for opening your first issue here! Just a reminder, this forum is for Bug Reports only. Be sure to follow the issue template!

[connortechnology]

Which clients do they not render in? The code to do inline images is a bit hairy and took a lot of trial and error to get to it's current state. I tested with K9, gmail, Apple Mail and Outlook 365.

I would certainly agree that the email code should be cleaned up, but I would not be ok with breaking people's working setups, so there's that.

Also not interested in using an immature module like Email::Stuffer. Whatever we use has to have been around for a while.

[gurka]

I recently worked with a similar issue in an unrelated project. Two things two consider (if the inline images are base64-encoded):

1. Some clients does not support base64-encoded images at all
2. Some clients will only display parts of an email if the size is too large. e.g. Gmail only displays the first 102kBs of an email, so if the image data is in the middle of that 102kB offset, it won't render properly