From mboxrd@z Thu Jan 1 00:00:00 1970 From: steffen@sdaoden.eu (Steffen Nurpmeso) Date: Tue, 14 Mar 2017 11:49:43 +0100 Subject: [TUHS] attachments: MIME and uuencode In-Reply-To: <201703132214.v2DMEM8d032173@coolidge.cs.Dartmouth.EDU> References: <201703121813.v2CIDtRH099094@tahoe.cs.Dartmouth.EDU> <20170313113745.lSbbS%steffen@sdaoden.eu> <20170313202154.BNV4w%steffen@sdaoden.eu> <201703132214.v2DMEM8d032173@coolidge.cs.Dartmouth.EDU> Message-ID: <20170314104943.Zn7LG%steffen@sdaoden.eu> Doug McIlroy wrote: |>|Turning off the HTML text part takes a button click (or took once ||i looked last) | |No offense taken, but there's no way to turn off the HTML part |when that's the only part--and that is often the case. It is the decision of the sending party what type of message is produced, this i hope is still possible even for purely web-based mail clients. This sender-side decision i was referring to in the post quoted above. Unfortunately your observation is correct, but luckily on this list, and also on most lists that i read! But it seems many administrator tools only ever generate HTML or other rich text log files and statistics, and so on request generating mails to send these as the main body my MUA will support in the future (even though very primitive yet, disallowing additional signature injection, for example). The world turns, and integration progresses, and if you don't move you will be left behind: this is not necessarily something bad. E.g., on FreeBSD many tools in the base system now use a XO (i think) library for generating output, so that the output can be plain text, as normal, but also JSON or XML, and maybe even binary CBOR at some future time, and if there is a correct MIME type then why should Mail not be a valid transport for this, that then can be correctly decoded on the receiver side according to the MIME content type. I for one very much prefer plain text in human interaction. --steffen