Hello Adrian. Please do not post images unless it is to describe something indescribable :)
(In fact i am unpleasantly surprised, and do not understand why mailman waved through the images, i am absolutely sure that images are not in PASS_MIME_TYPES.) [email protected] wrote in <[email protected]>: |I had a somewhat complex report prepared. |But it boils down to asking list recipients |if and how they can use "s-nail" to usefully |view the attachment to this message. |(Assuming the listserv passes it on |appropriately). | |My diagnosis (using something like) |"set pipe-image/jpeg=' cat - > /tmp/o.$$ '" cat(1) does not understand "-". If you leave that away the above will work with newer S-nail's. |is that the input sent to the command used |by "mimeview" is missing all carriage-return |characters (octal 015). Sort of annoying |because if it could be sent the base64 |encoding, it could be made to work. |(Although yes, that would be bundling |the encoding back into the file format). | |I observed the problem under both | Ubuntu 18.04 (s-nail v14.9.6) | Ubuntu 20.04 (s-nail v14.9.15) There were fixes with MIME type handlers in the past. The problem you described has been fixed in v14.9.9, March 2018. I just compiled v14.9.15, and with the setting as below i can `mimeview' the correct contents with it. I do not know how you could achieve that, but in Debian / Ubuntu there is v14.9.19 in "testing" and "unstable" (in Ubuntu "Groovy Gorilla", active development only, hm). With it we smoothly integrate in ~/.mailcap handling. But also with pipe-image/jpeg you could leave temporary file creation up to S-nail, guaranteed to not overwrite existing data. For example, via ? set pipe-image/jpeg=?=?: i got "s-nail-mimetypefill-InZi7". With ~/.mailcap you could simply use a nametemplate=%s.jpg instead. The manual has examples (in "The Mailcap files"). |Is the actual "s-mailx" package being distributed anywhere yet? No, that will not happen before late, late 2021. Sorry. |FWIW, the mime viewing "just works" when I |email the message to another lxc container I wish i would find time to try out LXC containers. Or at least run servers in isolated namespaces directly, or build a system where i can share the normal installation and only use overlays for LXC containers, for data which changes etc. And 5.4 kernels. And block-encryption. And ZFS. And .. ? |which runs inn2 and saves the message as a |news article which I view using "trn". |(I.e. the version of "trn" does the |decoding and display correctly). I am sorry that there were bugs. I hope the increasing number of tests catches more of them in the future. |The cartoon also displays properly |(in non-list test runs) using a basically |1990's version of "mail" spliced with a |frozen version of "metamail", etc. Hm. Well. I feel sad myself that i am stuck at the moment, i had new releases of s-web42, s-cdda and am still fighting with s-cdda-to-db in order to make that work with that MusicBrainz service that i do not like, because the decades of work of tens of thousands of people who created the FreeDB content has been thrown into the trashbin, as FreeDB is no more. But work is very slowly since many weeks. Initially i planned to be able to use OpenPGP with midsummer, but that will not work out. Ciao, and greetings from grey and rainy Germany, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
