Re: Creating HTML emails with mutt

2019-11-03 Thread Patrick Shanahan
* raf  [11-03-19 18:23]:
> Derek Martin wrote:
> 
> > TBH most of the time, if I really need to see what's in an HTML mail,
> > I just bounce it to gmail.  But sometimes that doesn't work either due
> > to DNS-based spam prevention.
> 
> Forwarding the email as an attachment rather than bouncing it should solve 
> that.

If I wish to view an html email that w3m fails to render satisfactory, I
copy the html portion to a particular location with a key combo/mutt-macro
and open it with firefox or waterfox or seamonkey or ...

I do not post html, even from gmail.
-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-11-03 Thread raf
Derek Martin wrote:

> TBH most of the time, if I really need to see what's in an HTML mail,
> I just bounce it to gmail.  But sometimes that doesn't work either due
> to DNS-based spam prevention.

Forwarding the email as an attachment rather than bouncing it should solve that.

cheers,
raf



Re: Creating HTML emails with mutt

2019-11-03 Thread José María Mateos

On Sun, Nov 03, 2019 at 07:56:34AM -0500, Mark H. Wood wrote:

I like that Mutt presents emails simply.  It ignores all the fancy
to-the-pixel formatting, pointless images, distracting backgrounds,
and flashing multicolored nonsense.  I find that reading mail with
Mutt is more restful than with other MUAs.  Occasionally I do
encounter a message whose text/plain part says only "you must enable
HTML mail to read this message."  I interpret this as "you do not need
or want to read this message," and I happily hit "d" and move on.


My bank still sends me this in the text/plain part of the message every 
month:


Your %%MONTH%% %%ACCOUNTTYPE%% %%STATEMENTRECEIPT%% is ready

But yes, I've also learned to ignore it.

Also, I also want to thank you for writing this down. All the reasons 
why I use mutt boil down to essentially this.


Cheers,

--
José María (Chema) Mateos || https://rinzewind.org/


Re: Creating HTML emails with mutt

2019-11-03 Thread Patrick Shanahan
* Mark H. Wood  [11-03-19 07:58]:
> On Sat, Nov 02, 2019 at 12:31:29PM -0400, Patrice Levesque wrote:
> > 
> > > […] virtually all of the people who use mutt either as their only
> > > email client or along with others, chose mutt because of its
> > > simplicity.
> > 
> > People who want a simple text mail client will use Alpine or similar.
> > Mutt's possibly the most “complicated” text MUA.
> > 
> > I don't use mutt because of its “simplicity”, I use it because of its
> > power and flexibility.
> 
> Yes.  There is simple and then there is simple.  I choose Mutt because
> I can adjust it to be simple in the ways I want it to be simple, and
> sophisticated in the ways I want it to be sophisticated.  That exacts
> a cost in configuration complexity which I'm quite willing to pay.

 [...]

> What it boils down to is that Mutt is a tool rather than an appliance,
> and I prefer tools.  An appliance does the work for me, the same way
> it does it for everyone else; a tool enhances my ability to do the work
> using my skills and expressing my intent.

thankyou.  you have expressed most elegantly my feelings and adjustments
to utilize mutt to read and send email over the last +20 years and I hope
another 20 or so.

and we are neighbors and I used to photograph for IUPUI men's soccer.


-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-11-03 Thread Mark H. Wood
On Sat, Nov 02, 2019 at 12:31:29PM -0400, Patrice Levesque wrote:
> 
> > […] virtually all of the people who use mutt either as their only
> > email client or along with others, chose mutt because of its
> > simplicity.
> 
> People who want a simple text mail client will use Alpine or similar.
> Mutt's possibly the most “complicated” text MUA.
> 
> I don't use mutt because of its “simplicity”, I use it because of its
> power and flexibility.

Yes.  There is simple and then there is simple.  I choose Mutt because
I can adjust it to be simple in the ways I want it to be simple, and
sophisticated in the ways I want it to be sophisticated.  That exacts
a cost in configuration complexity which I'm quite willing to pay.

I like that Mutt presents emails simply.  It ignores all the fancy
to-the-pixel formatting, pointless images, distracting backgrounds,
and flashing multicolored nonsense.  I find that reading mail with
Mutt is more restful than with other MUAs.  Occasionally I do
encounter a message whose text/plain part says only "you must enable
HTML mail to read this message."  I interpret this as "you do not need
or want to read this message," and I happily hit "d" and move on.

I like that Mutt can be configured to handle signing and encryption
well using the tools that I use for these operations in other
contexts.

I like that Mutt gives me ready access to the structure of MIME
messages.  I like that Mutt understands me when I add an attachment,
and sets the Content-Type correctly instead of just blowing it off as
application/octet-stream.

I like that Mutt just asks me what I want to do with this funky
attachment, instead of trusting it and performing it without my
leave.  I like that Mutt makes me stop and think about following that
URL.

I like that Mutt lets me choose my editor and just accepts what I have
composed with it.  For some messages I really need EMACS.

I like that Mutt treats me as someone who takes the trouble to
understand the medium, and facilitates my use of that knowledge.

Most of that was not simple to achieve but, having achieved it, Mutt
makes sending and reading email *my way* simple for me, and that is
the simplicity which I value most highly in a MUA.

What it boils down to is that Mutt is a tool rather than an appliance,
and I prefer tools.  An appliance does the work for me, the same way
it does it for everyone else; a tool enhances my ability to do the work
using my skills and expressing my intent.

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-11-03 Thread martin f krafft

Regarding the following, written by "Kurt Hackenberg" on 2019-11-03 at 00:11 
Uhr -0400:
Mutt runs an external text editor to 
compose plain text; it could do the same 
for this -- run some external composition 
program that would return both HTML and 
plain text.


There is nothing stopping you from setting `$editor` to a HTML 
editor, and defining `$content_type` to be `text/html`, and then 
using Kevin's `multipart/alternative` functionality to generate a 
`text/plain` part.


The only issue with this approach would be that you'd now have the 
`text/plain` part after the `text/html`, which means that dumb 
clients such as Gmail and Outlook and Thunderbird too would actually 
prefer the plain-text message over the HTML one.


Getting mutt to sort those into order might get really messy though, 
and while I think it it wouldn't be too hard to ensure that 
`text/html` always comes after `text/plain`, anything beyond that 
would require a new command, but `alternative_order` is already 
taken for something else, and cannot be reused, I don't think.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"no work of art ever puts forward views.

 views belong to people
 who are not artists."
  -- oscar wilde
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-11-02 Thread Kurt Hackenberg

Sorry, I'm coming into this late.

Early on, Kevin McCarthy said:


Native support for multipart/alternative composition isn't in my todo
list.


Too bad -- that would be conceptually clean, to generate 
multipart/alternative as part of composition.


Mutt runs an external text editor to compose plain text; it could do the 
same for this -- run some external composition program that would return 
both HTML and plain text. That external program could be anything, could 
be user's choice. It could be a GUI HTML editor that generates HTML and 
plain text in parallel from what the user does. It could be a shell 
script, that runs a text editor where the user types Markdown, and then 
converts that to HTML and returns both.


From there, I guess Mutt would treat that multipart/alternative the 
same as a simple body part of plain text: build a MIME tree around it, 
with attachments and GPG signature. Would that work?


Re: Creating HTML emails with mutt

2019-11-02 Thread Patrice Levesque

> […] virtually all of the people who use mutt either as their only
> email client or along with others, chose mutt because of its
> simplicity.

People who want a simple text mail client will use Alpine or similar.
Mutt's possibly the most “complicated” text MUA.

I don't use mutt because of its “simplicity”, I use it because of its
power and flexibility.

And I'm closely following this thread because I'm one of the “strange”
people who'd _like_ mutt to be able to handle outgoing multipart
messages; I was trying to achieve exactly that, three years ago:
https://www.mail-archive.com/mutt-users@mutt.org/msg50518.html


> It seems to be contrary to the direction and purpose of mutt to make
> it do everything anybody wants.

The current number of configuration options suggests otherwise, and mutt
would lose most of its appeal for me if it trimmed down the number of
options.


> The harm of making the app more complicated and adding a lot of code
> is real, and it directly affects the user of mutt whether he's new or
> old.

There are dozens of mutt options I turn off, yet I won't argue they need
to be removed just because they're not part of _my_ use case.  I can
appreciate everyone's needs are different and what works best for me
will likely not work best for everyone.



-- 
· Patrice Levesque
· http://ptaff.ca/
· mutt.wa...@ptaff.ca
--



signature.asc
Description: Digital signature


Re: Creating HTML emails with mutt

2019-11-02 Thread martin f krafft

Regarding the following, written by "martin f krafft" on 2019-11-02 at 23:40 
Uhr +1300:
How does this message fare? I’ve hacked up 
my script so that it actually keeps the ‘>’ 
even in the HTML, but uses CSS to hide it.


Yeah, so I am not convinced at all, because all the html2text 
converters won't ignore that extra '>', and it just gets really 
ugly.


Assuming that Thunderbird users are the only ones that actually know 
how to quote (and we can safely ignore Outlook/Gmail, who all 
top-quote anyway), maybe this is a bug to be taken up with 
Thunderbird devs?


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"es ist gut, eine sache doppelt auszudrücken und ihr einen

 rechten und linken fuß zu geben. auf einem bein kann die wahrheit
 zwar stehen; mit zweien aber wird sie gehen und herumkommen."
  -- friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-11-02 Thread martin f krafft

Regarding the following, written by "Martin Trautmann" on 2019-11-02 at 10:22 
Uhr +0100:
However, the usage of blockquote within HTML is something where 
there is not necessarily a proper way of handling this - 
Thunderbird does not do it properly, as you see above. How does 
handle html itself nested blockquote levels?


Oh, interesting corner case you spotted there. HTML does nesting of 
blockquotes just fine. The problem here seems to be that Thunderbird 
doesn't recognise blockquote as a quote, and needs the leading '>'.


How does this message fare? I've hacked up my script so that it 
actually keeps the '>' even in the HTML, but uses CSS to hide it. 
:grin:


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
in africa some of the native tribes have a custom of beating the

ground with clubs and uttering spine chilling cries. anthropologists
call this a form of primitive self-expression. in america they call
it golf.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-11-02 Thread Martin Trautmann
On 19-11-01 11:37, martin f krafft wrote:
> Regarding the following, written by “Stefan Hagen” on 2019-11-01 at
> 08:53 Uhr +0100:
> 
> While I was able to just write an email and send it, it is now a
> process of carefully “coding” an email, previewing, correcting,
> previewing, sending…
> 
> There’s a lot of good things to be said about carefully crafting emails!
> 
> Regardless, to most of us who’ve been writing text/plain emails all of
> our lives, using ASCII characters for emphasis and hand-crafting
> numbered and itemised lists, Markdown will hardly even have a learning
> curve.

Your setup for plain text is very reasonable, using format-flowed and >
as quote character.

However, the usage of blockquote within HTML is something where there is
not necessarily a proper way of handling this - Thunderbird does not do
it properly, as you see above. How does handle html itself nested
blockquote levels?

How does outlook handle it? I guess it's not an issue over there.
Outlook users do use full quotes below without ever reading them!?

Schönen Gruß
Martin



signature.asc
Description: OpenPGP digital signature


Re: Creating HTML emails with mutt

2019-11-01 Thread Grant Edwards
On 2019-11-01, Stefan Hagen  wrote:
>
>> .
>
> This is interesting - I'm trying this...
>
> I'm using this MIMEBellish script to transform plaintext mail to
> multipart mail with HTML for a few years and it works quite well:
> http://nosubstance.me/post/mutt-secret-sauce/
>
> Personally, I find the change from text as WYSIWYG representation to
> text as source code (markdown is source code in a way) challenging.
> While I was able to just write an email and send it, it is now a process
> of carefully "coding" an email, previewing, correcting, previewing,
> sending...

That is indeed the tradeoff.  The reward is that you get nice quoting,
lists, code-blocks, italics, bold, etc.  The cost is that it's more
work.  It's simpler to just create an HTML part by taking the
text/plain (with appropriate escaping) and shoving it inside
tags with trivial amount of CSS to pick a fixed font.  The
drawback to that is that paragraphs are not "flowable" by the renderer
and it looks like crap on narrow display (e.g. phones).

Another benifit to the markup-language apparoach is that for some
reason I find that when proof-reading something in a different
"format" I spot more errors than I do when proof-reading the "source"
as I typed it. I remember the same being true from my days using
TeX/LaTeX.  But that might just be me...

-- 
Grant Edwards   grant.b.edwardsYow! Like I always say
  at   -- nothing can beat
  gmail.comthe BRATWURST here in
   DUSSELDORF!!



Re: Creating HTML emails with mutt

2019-11-01 Thread martin f krafft

Regarding the following, written by "Stefan Hagen" on 2019-11-01 at 08:53 Uhr 
+0100:
While I was able to just write an email and send it, it is now a 
process of carefully "coding" an email, previewing, correcting, 
previewing, sending...


There's a lot of good things to be said about carefully crafting 
emails!


Regardless, to most of us who've been writing text/plain emails all 
of our lives, using ASCII characters for emphasis and hand-crafting 
numbered and itemised lists, Markdown will hardly even have a 
learning curve.


The only thing to watch out for is the "false positives", like I had 
the other day when part of an email of mine was interpreted by 
pandoc to be LaTeX math. I've since disabled the pandoc extension in 
[my script I use with mutt][1], though there remain quite a number 
of extensions allowing for funky corner case surprises, especially 
in quotes from other people! Fun times ahead!


[1]: https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/markdown2html

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"america may be unique in being a country which has leapt

 from barbarism to decadence without touching civilization."
  -- john o'hara
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-11-01 Thread martin f krafft

Regarding the following, written by "Kevin J. McCarthy" on 2019-11-01 at 14:45 
Uhr +0800:
I've merged the branch into master.  For those who want to give it 
a try, please see the documentation under "MIME 
Multipart/Alternative" 
.


I've sent over 100 emails using this, and it's been working 
spotlessly.


If you want to quickly try it out, here's a [little script][1] I 
hacked up, which uses pandoc to create a `text/html` alternative by 
parsing your message as if it were Markdown.


[1]: https://git.madduck.net/etc/mutt.git/blob_plain/HEAD:/.mutt/markdown2html

Feedback welcome!

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"the word yellow wandered through his mind in search of something to

 connect with."
 -- hitchhiker's guide to the galaxy
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-11-01 Thread Stefan Hagen

Kevin J. McCarthy wrote:

On Tue, Oct 29, 2019 at 06:28:34PM +0800, Kevin J. McCarthy wrote:
I'll be working on this in the 'kevin/multipart-alternative' branch, 
but just fyi that I force-push to my development branches, and they 
are usually "work in progress".


I've merged the branch into master.  For those who want to give it a 
try, please see the documentation under "MIME Multipart/Alternative" 
.


This is interesting - I'm trying this...

I'm using this MIMEBellish script to transform plaintext mail to
multipart mail with HTML for a few years and it works quite well:
http://nosubstance.me/post/mutt-secret-sauce/

Personally, I find the change from text as WYSIWYG representation to
text as source code (markdown is source code in a way) challenging.
While I was able to just write an email and send it, it is now a process
of carefully "coding" an email, previewing, correcting, previewing,
sending...

Best Regards,
Stefan

--
Stefan Hagen | (gopher|https)://codevoid.de/0/gpg
CBD3 C468 64B4 6517 E8FB B90F B6BC 2EC5 52BE 43BA


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-11-01 Thread Kevin J. McCarthy

On Tue, Oct 29, 2019 at 06:28:34PM +0800, Kevin J. McCarthy wrote:
I'll be working on this in the 'kevin/multipart-alternative' branch, 
but just fyi that I force-push to my development branches, and they 
are usually "work in progress".


I've merged the branch into master.  For those who want to give it a 
try, please see the documentation under "MIME Multipart/Alternative" 
.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-31 Thread Derek Martin
On Thu, Oct 31, 2019 at 10:20:21AM +, John Long wrote:
> On Wed, 30 Oct 2019 15:49:05 -0500
> Derek Martin  wrote:
> 
> > On Wed, Oct 30, 2019 at 11:31:21AM +, John Long wrote:
> > > That doesn't really help. From my point the issue is not only what I
> > > have to configure or what can be configured, but also how much code
> > > is behind doing that. Less code is easier to manage than more code.
> > > I can't see the benefit of junking up mutt with HTML or anything
> > > else that is out of scope for a command-line mail client. Remember,
> > > some of us use mutt on a console with no GUI  
> > 
> > Who is harmed more?  Users who have the feature but don't want it, or
> > users who need the feature but can't get it?
> 
> That doesn't fall into the category of harmed. I'm not sure of the
> timing but I believe in most cases people chose to use mutt after HTML
> email was already in common (ab)use.

Mutt's been around since 1995.  Many of us have been using it since
the beginning, or soon after.  HTML mail was not nearly so prevalent
then as it is now.

> And I would venture to say that virtually all of the people who use
> mutt either as their only email client or along with others, chose mutt
> because of its simplicity.

I'll have to beg to differ.  In my experience most people use Mutt
because of its power.  Mutt is just not simple... all that power comes
at a cost.

> It seems to be contrary to the direction and purpose of mutt to make
> it do everything anybody wants.

And if you search the archives for my posts, you will very frequently
see me making that same argument.  But not when it comes to
functionality that is an essential part of handling e-mail, which,
like it or not, this now is for many/most people.  Mutt's lack of
ability to handle HTML e-mail *well*, *natively*, gets in my way just
about every single day.  If that's not true for you, great!  That in
no way means it isn't true for lots of people.

> The harm of making the app more complicated and adding a lot of code is
> real,

For sure.

> and it directly affects the user of mutt whether he's new or old.
 

This is false.  The issue is not how it affects the user--Mutt's
longstanding practice is to make such features able to be entirely
configured out of the program, which means they impact the user
exactly zero, once configure is run (if you want that, that is--you do
need to compile it yourself if you're that anal about what features
are compiled in since the distros generally (correctly) expect that
users want all the features available).  Then, even if you don't
compile it out, it still doesn't impact the user at all if they don't
*use* it.  This sort of feature is not one that complicates code paths
that you always hit; it's one that sits entirely separate and lies
dormant if you don't use the feature.

The real issue is that more code makes the code base more complex and
harder to maintain.  There's always a tradeoff between that and in
providing features.  When the feature is a fundamental aspect of doing
what your application does, then the chioce should be to add the
functionality.  You can argue handling HTML mail is not a core
function of handling e-mail all you like, but if you do you're just
wrong.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-31 Thread Derek Martin
On Thu, Oct 31, 2019 at 11:43:07AM +, John Long wrote:
> On Thu, 31 Oct 2019 23:47:38 +1300
> martin f krafft  wrote:
> 
> > Regarding the following, written by "John Long" on 2019-10-31 at
> > 10:30 Uhr +:
> > >1. Commonly done != standard. There are standards for things like
> > >MIME, POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards
> > >that say that HTML email is a thing.  
> > 
> > Quoting the HTML RFC from 1995: "The Hypertext Markup Language 
> > (HTML) is a simple markup language used to create hypertext 
> > documents that are platform independent. HTML documents are SGML 
> > documents with generic semantics that are appropriate for 
> > representing information from a wide range of domains. HTML markup 
> > can represent hypertext news, **mail**, documentation, and 
> > hypermedia; …"
> 
> That's the tail wagging the dog. I'm saying I haven't seen an *email*
> RFC that says "HTML may/should be used for email."

The MIME standard (RFC-1341, 1992) is what you're looking for:  Multipurpose
Internet *Mail* Extensions.  It defines (quoting the RFC):

2.  A Content-Type header field, generalized from  RFC  1049
 [RFC-1049],  which  can be used to specify the type and
 subtype of data in the body of a message and  to  fully
 specify  the  native  representation (encoding) of such
 data.

This allows for "data in the body of a message" to be in arbitrary
formats, which includes literally anything (including experimental or
user-defined X-* types), which most certainly includes HTML.

And FWIW, I *was* discussing (very limited, completely text-based)
support for HTML messages in Mutt.  I want it, have wanted it for a
long time, because all of the available options for dealing with it
have serious drawbacks at least some of the time.  This thread seems
to have revealed that I'm far from alone in thinking so.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-31 Thread Dave Woodfall
On Thu 31 Oct 2019 09:24,
martin f krafft  put forth the proposition:
> Regarding the following, written by "Dave Woodfall" on 2019-10-30 at 11:25 
> Uhr +:
> > When messages turn up with no plain text part to them at all, or one
> > that's completely useless, it's wrong.
>
> I'd guess we all agree on that point.
>
> We're currently discussing the creation of multipart/alternative
> containers, which place the HTML part as an alternative to the plain-text
> part, so you can freely choose which one to read. Nobody is suggesting
> mutt no longer sends text/plain by default.

I know.  I was just thinking about some of the problems that seem to
occur at times in connection with receiving HTML messages these days.
I got a bit sidetracked.

-dw


Re: Creating HTML emails with mutt

2019-10-31 Thread 雨宫恋叶
I'm uninterested about this thread now.
-- 
存在于未知的空间


Re: Creating HTML emails with mutt

2019-10-31 Thread John Long
On Thu, 31 Oct 2019 23:47:38 +1300
martin f krafft  wrote:

> Regarding the following, written by "John Long" on 2019-10-31 at
> 10:30 Uhr +:
> >1. Commonly done != standard. There are standards for things like
> >MIME, POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards
> >that say that HTML email is a thing.  
> 
> Quoting the HTML RFC from 1995: "The Hypertext Markup Language 
> (HTML) is a simple markup language used to create hypertext 
> documents that are platform independent. HTML documents are SGML 
> documents with generic semantics that are appropriate for 
> representing information from a wide range of domains. HTML markup 
> can represent hypertext news, **mail**, documentation, and 
> hypermedia; …"

That's the tail wagging the dog. I'm saying I haven't seen an *email*
RFC that says "HTML may/should be used for email."

But I'm ok with not discussing this anymore, if you are ;)

/jl


Re: Creating HTML emails with mutt

2019-10-31 Thread John Long
On Thu, 31 Oct 2019 23:49:37 +1300
martin f krafft  wrote:

> Regarding the following, written by "John Long" on 2019-10-31 at
> 10:17 Uhr +:
> >> The approach Kevin proposed is completely HTML-agnostic and leaves
> >> it up to the user to provide an external tool that provides the
> >> HTML. Mutt then just does the required MIME-handling, which is
> >> clearly within the domain of a MUA.  
> >
> >I thought there was already the capability in mutt to pipe email to 
> >another application?  
> 
> Sure, you can filter your text/plain part through aspell. But you 
> cannot currently create multipart/alternative emails.
> 
> >> There is no GUI requirement in any of this.  
> >
> >I meant to say that HTML email becomes much less useful and in some 
> >cases worthless without a GUI. You can't display pictures or see 
> >advertising links on the console. I have tried to use various
> >console browsers like links and lynx and I'm unable to use them with
> >almost any webpage.  
> 
> So you'll have your client configured to prefer text/plain when 
> given the choice between alternatives. Which mutt already supports.
> 
> Can we please move on?

"I am going to stop participating in this "HTML is good or bad for 
Email" debate, and I'd like to invite you all to consider doing the 
same."

Easier said than done ;)

/jl


Re: Creating HTML emails with mutt

2019-10-31 Thread martin f krafft

Regarding the following, written by "John Long" on 2019-10-31 at 10:17 Uhr 
+:
The approach Kevin proposed is completely HTML-agnostic and leaves it 
up to the user to provide an external tool that provides the HTML. 
Mutt then just does the required MIME-handling, which is clearly 
within the domain of a MUA.


I thought there was already the capability in mutt to pipe email to 
another application?


Sure, you can filter your text/plain part through aspell. But you 
cannot currently create multipart/alternative emails.



There is no GUI requirement in any of this.


I meant to say that HTML email becomes much less useful and in some 
cases worthless without a GUI. You can't display pictures or see 
advertising links on the console. I have tried to use various console 
browsers like links and lynx and I'm unable to use them with almost any 
webpage.


So you'll have your client configured to prefer text/plain when 
given the choice between alternatives. Which mutt already supports.


Can we please move on?

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
"der besitz der wahrheit ist nicht schrecklich,

 sondern langweilig, wie jeder besitz."
 - friedrich nietzsche
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-10-31 Thread martin f krafft

Regarding the following, written by "John Long" on 2019-10-31 at 10:30 Uhr 
+:
1. Commonly done != standard. There are standards for things like MIME, 
POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards that say 
that HTML email is a thing.


Quoting the HTML RFC from 1995: "The Hypertext Markup Language 
(HTML) is a simple markup language used to create hypertext 
documents that are platform independent. HTML documents are SGML 
documents with generic semantics that are appropriate for 
representing information from a wide range of domains. HTML markup 
can represent hypertext news, **mail**, documentation, and 
hypermedia; …"


So yes, HTML was designed pretty much from the start to be used for 
mail.


And then "MIME" came along. Which is a standard, and RFC 2854 makes 
text/html a standard.


Anyway, none of this is relevant, because:


2. Mutt hasn't had HTML support


… and won't get HTML support. We're working on the ability to create 
multipart/alternative containers.


I am going to stop participating in this "HTML is good or bad for 
Email" debate, and I'd like to invite you all to consider doing the 
same.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net
 
a Hooloovoo is a superintelligent shade of the color blue.

-- douglas adams, "the hitchhiker's guide to the galaxy"
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-10-31 Thread John Long
On Wed, 30 Oct 2019 16:29:31 -0500
Derek Martin  wrote:

> On Wed, Oct 30, 2019 at 11:29:31AM +, John Long wrote:
> > > I don’t think this is about right and wrong, and not only because
> > > there is no objectivity. multipart/alternative is an accepted
> > > standard, and so is HTML. You might not like how things have
> > > developed, and neither do I, but that doesn’t make it wrong.  
> > 
> > HTML is for web pages. It is wrong for email, yes.  
> 
> This is just not a supportable position based on anything logical or
> evicence-based.  HTML in e-mail has been a de-facto standard for about
> as long as most people have been using e-mail (admittedly, much less
> true for the folks on this list).  It has almost universal adoption of
> native support in almost every e-mail client of note.  Even alpine can
> now display HTML mail as plain text natively.  Mutt is the only
> laggard in this regard that I am aware of.

1. Commonly done != standard. There are standards for things like MIME,
POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards that say
that HTML email is a thing. SPAM is by far the biggest part of email
traffic. Do we say that SPAM is a standard?

2. Mutt hasn't had HTML support and people still chose it. I believe
they chose it for simplicity and lightness and being able to run on a
console. 

> A majority of e-mail users PREFER HTML mail.

I don't think there is any proof, given 99% of the world uses Microsoft
Windows and is non-technical, that this supports the idea anybody knows
what peoples' email preferences are. It's much more likely and from
my experience, people just use whatever they get. Outhouse is "the
standard" in that regard, everybody has it, and the default is HTML
email...

I suppose this means a majority of PC users prefer Windows? We know the
reality is the vast majority of people get it on every piece of Intel
hardware they buy, don't know anything else exists, etc. 

> So I think the notion that HTML mail is wrong is just wrong-headed.  I
> certainly have no issue if you want to say you hate it, and I would
> sympathize.  But when you say it's wrong... I think you have no leg to
> stand on.

Likewise, I think trying to bring proofs from usage statistics that
things that just happened (and are mostly targeted at making SPAM and
commercial emails "better") are "standards" isn't compelling.

> > Lots of Microsoft crap seems like an "accepted standard"  
> 
> This has turned out to be remarkably difficult to prove, but I don't
> think HTML mail was invented by Microsoft, or predominated by it.
> AFAICT MS didn't even support HTML in e-mail until 1998, and I'm
> pretty positive Netscape Mail supported it in its first version,
> released the same year.

I think you are probably right. I was just trying to remember the
history as I read your note. At any rate, Microsoft is certainly the
biggest offender.

> > Simplicity and constantly adding new features that are inessential
> > are at odds with each other.   
> 
> This is true and should be considered, but not to the point of leaving
> the application functionally incomplete.

Yes, but people have been adopting and using mutt even when they knew
from the beginning it didn't support HTML. There are already enough GUI
clients that support HTML, why join the fray?

> > I think it's pretty clear the people who use mutt prefer simplicity
> > or they would have chosen something else.   
> 
> I think this is totally crazy.  Mutt is anything but simple, from the
> user point of view.  It is a beast to configure with a monstrous
> learning curve.  Part of what gives it that is the requirement to
> configure how to handle even things like HTML mail, which today pretty
> much no one would exclude from the idea of what is essential e-mail
> functionality.  Everyone, that is, except a subset of Mutt users. =8^)

There are several kinds of simplicity. One is in the UI. Once you set
up mutt you don't have to do anything. When you use it you don't need
to use a mouse or click buttons or go through pages of UI settings.
It's clear what mutt does and doesn't do. It can run on the console
without X. For those reasons I consider it simple.

/jl


Re: Creating HTML emails with mutt

2019-10-31 Thread John Long
On Wed, 30 Oct 2019 15:49:05 -0500
Derek Martin  wrote:

> On Wed, Oct 30, 2019 at 11:31:21AM +, John Long wrote:
> > That doesn't really help. From my point the issue is not only what I
> > have to configure or what can be configured, but also how much code
> > is behind doing that. Less code is easier to manage than more code.
> > I can't see the benefit of junking up mutt with HTML or anything
> > else that is out of scope for a command-line mail client. Remember,
> > some of us use mutt on a console with no GUI  
> 
> Who is harmed more?  Users who have the feature but don't want it, or
> users who need the feature but can't get it?

That doesn't fall into the category of harmed. I'm not sure of the
timing but I believe in most cases people chose to use mutt after HTML
email was already in common (ab)use.

And I would venture to say that virtually all of the people who use
mutt either as their only email client or along with others, chose mutt
because of its simplicity. It seems to be contrary to the direction and
purpose of mutt to make it do everything anybody wants.

The harm of making the app more complicated and adding a lot of code is
real, and it directly affects the user of mutt whether he's new or old.

/jl


Re: Creating HTML emails with mutt

2019-10-31 Thread John Long
On Thu, 31 Oct 2019 09:29:23 +1300
martin f krafft  wrote:

> Regarding the following, written by “John Long” on 2019-10-30 at
> 11:31 Uhr +:
> > 
> > From my point the issue is not only what I have to configure or
> > what can be configured, but also how much code is behind doing
> > that. Less code is easier to manage than more code. I can’t see the
> > benefit of junking up mutt with HTML …
> 
> Fully agreed on all of the above.
> 
> The approach Kevin proposed is completely HTML-agnostic and leaves it
> up to the user to provide an external tool that provides the HTML.
> Mutt then just does the required MIME-handling, which is clearly
> within the domain of a MUA.

I thought there was already the capability in mutt to pipe email to
another application?

> Also, mutt already does receiving/reading multipart/alternative, so
> it only makes sense to figure out how to properly add creation of
> such containers. After all, mutt can sign GPG signatures, not just
> verify them.

I'm not sure what this means since with the PGP config it can verify
also.

> > 
> > Remember, some of us use mutt on a console with no GUI.
> 
> There is no GUI requirement in any of this.

I meant to say that HTML email becomes much less useful and in some
cases worthless without a GUI. You can't display pictures or see
advertising links on the console. I have tried to use various console
browsers like links and lynx and I'm unable to use them with almost any
webpage.

/jl


Re: Creating HTML emails with mutt

2019-10-30 Thread Derek Martin
On Wed, Oct 30, 2019 at 11:29:31AM +, John Long wrote:
> > I don’t think this is about right and wrong, and not only because
> > there is no objectivity. multipart/alternative is an accepted
> > standard, and so is HTML. You might not like how things have
> > developed, and neither do I, but that doesn’t make it wrong.
> 
> HTML is for web pages. It is wrong for email, yes.

This is just not a supportable position based on anything logical or
evicence-based.  HTML in e-mail has been a de-facto standard for about
as long as most people have been using e-mail (admittedly, much less
true for the folks on this list).  It has almost universal adoption of
native support in almost every e-mail client of note.  Even alpine can
now display HTML mail as plain text natively.  Mutt is the only
laggard in this regard that I am aware of.

A majority of e-mail users PREFER HTML mail.

  https://www.clickz.com/real-world-email-client-usage-the-hard-data/47429/
  https://www.slideshare.net/HubSpot/the-science-of-email-marketng/32

So I think the notion that HTML mail is wrong is just wrong-headed.  I
certainly have no issue if you want to say you hate it, and I would
sympathize.  But when you say it's wrong... I think you have no leg to
stand on.

> Lots of Microsoft crap seems like an "accepted standard"

This has turned out to be remarkably difficult to prove, but I don't
think HTML mail was invented by Microsoft, or predominated by it.
AFAICT MS didn't even support HTML in e-mail until 1998, and I'm
pretty positive Netscape Mail supported it in its first version,
released the same year.

> Simplicity and constantly adding new features that are inessential are
> at odds with each other. 

This is true and should be considered, but not to the point of leaving
the application functionally incomplete.

> I think it's pretty clear the people who use mutt prefer simplicity
> or they would have chosen something else. 

I think this is totally crazy.  Mutt is anything but simple, from the
user point of view.  It is a beast to configure with a monstrous
learning curve.  Part of what gives it that is the requirement to
configure how to handle even things like HTML mail, which today pretty
much no one would exclude from the idea of what is essential e-mail
functionality.  Everyone, that is, except a subset of Mutt users. =8^)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread Derek Martin
On Wed, Oct 30, 2019 at 11:31:21AM +, John Long wrote:
> That doesn't really help. From my point the issue is not only what I
> have to configure or what can be configured, but also how much code is
> behind doing that. Less code is easier to manage than more code. I
> can't see the benefit of junking up mutt with HTML or anything else
> that is out of scope for a command-line mail client. Remember, some of
> us use mutt on a console with no GUI

Who is harmed more?  Users who have the feature but don't want it, or
users who need the feature but can't get it?

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread Derek Martin
On Tue, Oct 29, 2019 at 07:04:48PM +, John Long wrote:
> > so you cater to people who have no idea, and cannot be bothered.
> 
> Which is probably 99.9% of everybody in corp. offices worldwide.
> 
> Don't get me wrong, I'm not advocating for HTML support in mutt. HTML
> has absolutely no place in email. 

Sadly, the masses have decided this for us, and this opinion has lost
the battle.  And TBH while I mostly sympathize, using underlining,
bold, and italics in type have been common for emphasis and similar
purposes for centuries.  And color more recently, but certainly
decades.  It would be nice to be able to make use of these instead of
relying on ASCII art to attempt to convey them.  And before someone
brings up RTF, just... no.

> But I do understand the problem very well after doing some
> contracting for big corporations and realizing 100s of millions of
> Windows victims can barely use a computer at all and email is just
> the tip of the iceberg.
> 
> My solution is to use something other than mutt in those cases. There
> is no way to win...

TBH most of the time, if I really need to see what's in an HTML mail,
I just bounce it to gmail.  But sometimes that doesn't work either due
to DNS-based spam prevention.

I'm well aware there are "solutions" to this problem.  I've used them
all.  They all suck (fail to handle some edge case very well or at
all).

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread martin f krafft


Regarding the following, written by “John Long” on 2019-10-30 at 11:31 Uhr +:

From my point the issue is not only what I have to configure or what can be configured, but also how much code is behind doing that. Less code is easier to manage than more code. I can’t see the benefit of junking up mutt with HTML …

Fully agreed on all of the above.
The approach Kevin proposed is completely HTML-agnostic and leaves it up to the user to provide an external tool that provides the HTML. Mutt then just does the required MIME-handling, which is clearly within the domain of a MUA.
Also, mutt already does receiving/reading multipart/alternative, so it only makes sense to figure out how to properly add creation of such containers. After all, mutt can sign GPG signatures, not just verify them.

Remember, some of us use mutt on a console with no GUI.

There is no GUI requirement in any of this.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "all i know is that i'm being sued for unfair business practices by micro$oft. hello pot? it's kettle on line two."-- michael robertson spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-30 Thread martin f krafft


Regarding the following, written by “Mark H. Wood” on 2019-10-30 at 08:22 Uhr -0400:

Even Outlook seems incapable of badly damaging blocks of text, indented blocks of text, emphasis, underscore/italics, or lists.

I think this is the perfect reason why mutt needs to learn creating multipart/alternative parts, and to do it right, so that it can continue to suck the least of all MUAs.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "nothing can cure the soul but the senses, just as nothing can cure the senses but the soul."  -- oscar wilde spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-30 Thread martin f krafft


Regarding the following, written by “Dave Woodfall” on 2019-10-30 at 11:25 Uhr +:

When messages turn up with no plain text part to them at all, or one that’s completely useless, it’s wrong.

I’d guess we all agree on that point.
We’re currently discussing the creation of multipart/alternative containers, which place the HTML part as an alternative to the plain-text part, so you can freely choose which one to read. Nobody is suggesting mutt no longer sends text/plain by default.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the only difference between a car salesman and a computer salesman  is that the car salesman knows he's lying. spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-30 Thread Grant Edwards
On 2019-10-30, Derek Martin  wrote:
> On Tue, Oct 29, 2019 at 10:31:19PM -, Grant Edwards wrote:
>> On 2019-10-29, martin f krafft  wrote:
>> That's true (as I understood the problem, anyway).  Fortunately, I
>> never needed to send a signed message with an attachment (or just a
>> signed message, AFAIR).  Nobody I know would have the faintest idea
>> what to do with a signed message.
>
> Half the people in this thread are sending them, so I think that must
> not be entirely true. =8^)

I don't know anybody in this thread (or list, for that matter).

-- 
Grant Edwards   grant.b.edwardsYow! Are we THERE yet?
  at   
  gmail.com



Re: Creating HTML emails with mutt

2019-10-30 Thread Derek Martin
On Tue, Oct 29, 2019 at 10:31:19PM -, Grant Edwards wrote:
> On 2019-10-29, martin f krafft  wrote:
> That's true (as I understood the problem, anyway).  Fortunately, I
> never needed to send a signed message with an attachment (or just a
> signed message, AFAIR).  Nobody I know would have the faintest idea
> what to do with a signed message.

Half the people in this thread are sending them, so I think that must
not be entirely true. =8^)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread Derek Martin
On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote:
> El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin 
> escribió:
> 
> > > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks
> > 
> > Perhaps not, but the fact that it keeps coming up here is pretty clear
> > indication that it's a feature that would be useful to a lot of
> > people...
> 
> Well, do you speak for you or for a 'lot of people'? Who they are?
> I speak only for my own interests (as I said: I do not need this).

I speak for myself, but you seemed eager to bring your authority into
it, with giving your length of experience using Mutt.  If you want to
do that, then I'm happy to point out that in the 23+ years *I've* been
a member of the Mutt community, frequent poster, and occasional code
contributor here, I've seen lots and lots and lots of people asking
about how (better) to handle HTML mail.  If you want to know who they
are, feel free to search the archives.

Mutt is a mail user agent, and like it or not, a large amount of mail
is now sent in HTML format.  Isn't the MUA's job to handle e-mail?
Well, I think it is, and Mutt does not do a complete job of it, for a
large subset of e-mail messages.  This thread has highlighted that
lots of people have issues dealing with the available solutions.  They
all "work" to some degree, but they often have failings that simply
can't be overcome, or require a very specific set of tools that may
not even be available to you, if you are reading mail on a system you
do not manage.

If Mutt handled HTML mail natively in some fashion, these issues would
cease to be issues.  That's exactly why I think support very much
belongs in Mutt proper.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread Grant Edwards
On 2019-10-30, Sean Greenslade  wrote:

> Of course there's massive selection bias in this list. No question
> about that. I just wanted to point out that there definitely are
> some younger Mutters out there. Though I tend to fall more on the
> grumpy about HTML mails side of this argument, so maybe age isn't
> that relevant.

Just because I've realized that my need for effective communication
requires that I create multipart HTML/plaintext messages it doesn't
mean I'm not grumpy about HTML mails...

I just know when I've lost the battle.

-- 
Grant Edwards   grant.b.edwardsYow! Of course, you
  at   UNDERSTAND about the PLAIDS
  gmail.comin the SPIN CYCLE --



Re: Creating HTML emails with mutt

2019-10-30 Thread John Long
On Wed, 30 Oct 2019 07:53:30 -0700
Sean Greenslade  wrote:

> Of course there's massive selection bias in this list. No question
> about that. I just wanted to point out that there definitely are some
> younger Mutters out there. Though I tend to fall more on the grumpy
> about HTML mails side of this argument, so maybe age isn't that
> relevant.

True enough, "Old Fart" and "Grumpy Old Man" are states of mind :D

/jl


Re: Creating HTML emails with mutt

2019-10-30 Thread Sean Greenslade
On October 30, 2019 7:41:34 AM PDT, Patrick Shanahan  wrote:
>* Sean Greenslade  [10-30-19 10:37]:
>> On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan
> wrote:
>> >* Mark H. Wood  [10-30-19 08:26]:
>> >> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
>> >> >I'd love to see some statistics about the age of mutt users.
>> >> 
>> >> 62
>> >
>> >78
>> 
>> Not sure if these are guesses at the average or reported data points.
>If
>> it's the latter, I'll offer my own:
>> 
>> 26
>
>since the request was rather non-specific and limited to only those
>interested in reading the thread, not sure it makes any difference. 
>almost like polling results related by politicians.

Of course there's massive selection bias in this list. No question about that. 
I just wanted to point out that there definitely are some younger Mutters out 
there. Though I tend to fall more on the grumpy about HTML mails side of this 
argument, so maybe age isn't that relevant.

--Sean



Re: Creating HTML emails with mutt

2019-10-30 Thread Patrick Shanahan
* Patrick Shanahan  [10-30-19 10:42]:
> * Sean Greenslade  [10-30-19 10:37]:
> > On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan  
> > wrote:
> > >* Mark H. Wood  [10-30-19 08:26]:
> > >> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
> > >> >I'd love to see some statistics about the age of mutt users.
> > >> 
> > >> 62
> > >
> > >78
> > 
> > Not sure if these are guesses at the average or reported data points. If
> > it's the latter, I'll offer my own:
> > 
> > 26
> 
> since the request was rather non-specific and limited to only those
> interested in reading the thread, not sure it makes any difference. 
> almost like polling results related by politicians.

s/request /request as stated/

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-10-30 Thread Patrick Shanahan
* Sean Greenslade  [10-30-19 10:37]:
> On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan  
> wrote:
> >* Mark H. Wood  [10-30-19 08:26]:
> >> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
> >> >I'd love to see some statistics about the age of mutt users.
> >> 
> >> 62
> >
> >78
> 
> Not sure if these are guesses at the average or reported data points. If
> it's the latter, I'll offer my own:
> 
> 26

since the request was rather non-specific and limited to only those
interested in reading the thread, not sure it makes any difference. 
almost like polling results related by politicians.


-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-10-30 Thread Sean Greenslade
On October 30, 2019 5:29:01 AM PDT, Patrick Shanahan  wrote:
>* Mark H. Wood  [10-30-19 08:26]:
>> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
>> >I'd love to see some statistics about the age of mutt users.
>> 
>> 62
>
>78

Not sure if these are guesses at the average or reported data points. If it's 
the latter, I'll offer my own:

26

--Sean



Re: Creating HTML emails with mutt

2019-10-30 Thread Patrick Shanahan
* Mark H. Wood  [10-30-19 08:26]:
> On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
> >I'd love to see some statistics about the age of mutt users.
> 
> 62

78


-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-10-30 Thread Mark H. Wood
On Wed, Oct 30, 2019 at 11:37:43PM +1300, martin f krafft wrote:
>I'd love to see some statistics about the age of mutt users.

62

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread Mark H. Wood
On Wed, Oct 30, 2019 at 12:57:59PM +1300, martin f krafft wrote:
>Regarding the following, written by "Martin Trautmann" on 2019-10-30 at
>00:14 Uhr +0100:
> 
>  That's such a strange thing.
>  [...]
>  since they never learned, how proper threading and quoting could
>  have worked?
> 
>78 characters wide text/plain is just not the lowest common denominator
>anymore. I am not going to sing an ode to HTML email, but being able to
>use Markdown to create more expressive emails than using ASCII art is
>not something I find utterly offensive.

Here, I think, is the point at which various posters' results diverge.
I've never had anyone complain about my text/plain emails, but I've
never had any need to write fancy stuff.  Even Outlook seems incapable
of badly damaging blocks of text, indented blocks of text, *emphasis*,
_underscore/italics_, or lists.

(Or else my correspondents are more tolerant than I'd thought they
needed to be.)

-- 
Mark H. Wood
Lead Technology Analyst

University Library
Indiana University - Purdue University Indianapolis
755 W. Michigan Street
Indianapolis, IN 46202
317-274-0749
www.ulib.iupui.edu


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-30 Thread John Long
On Wed, 30 Oct 2019 23:37:43 +1300
martin f krafft  wrote:

> Regarding the following, written by “Nuno Silva” on 2019-10-30 at
> 09:21 Uhr +:
> > 
> > There are users who don’t need text/html. It’s okay to want some
> > way to use HTML for e-mail in mutt, but I’d say it’s not okay to
> > say everybody needs it.
> 
> I’d love to see some statistics about the age of mutt users.
> 
> Just to be clear: any solution will be configurable, so nobody will
> be forced to use it. --

That doesn't really help. From my point the issue is not only what I
have to configure or what can be configured, but also how much code is
behind doing that. Less code is easier to manage than more code. I
can't see the benefit of junking up mutt with HTML or anything else
that is out of scope for a command-line mail client. Remember, some of
us use mutt on a console with no GUI

/jl


Re: Creating HTML emails with mutt

2019-10-30 Thread Dave Woodfall
On Wed 30 Oct 2019 23:53,
martin f krafft  put forth the proposition:
> Regarding the following, written by "Dave Woodfall" on 2019-10-30 at 10:05 
> Uhr +:
> > I don't think embracing wrong email practices is the way forward.
>
> I don't think this is about right and wrong, and not only because there is
> no objectivity. multipart/alternative is an accepted standard, and so is
> HTML. You might not like how things have developed, and neither do I, but
> that doesn't make it wrong.

When messages turn up with no plain text part to them at all, or one that's
completely useless, it's wrong.  If people use clients that produce things like
that then I'd say it's better to try to educate people to do it right, rather
than to adapt to their ways.

(I've mostly had this problem with email from a few shops, who use some kind of
PHP mailer that messes things up.  There's a thread here about how to set up a
list of 'htmlers' to deal with those.)

> The fact that the vast majority have adopted HTML for emails means you
> cannot really ignore it anymore. Mutt already handles receiving/reading
> alternative parts quite well. Being able to produce those parts will mean
> it'll suck less for those who need or want this functionality.

It's not about ignoring it.  It's not new and there are clients out there that
handle HTML with images, and all the other bells and whistles, more better than
mutt will ever do.

I am probably a bit biased here, because I don't run X11 99% of the time, and
elinks is my main web browser, so I use it a lot.  I rarely need to start X to
run GUI applications.

Most of the messages I receive are from other *nix users on technical mailing
lists like this, who wouldn't dream of sending HTML.  If I had to live in a
Windows world then I'd probably do things differently.

Fortunately, I don't.

-dw

--

Government's Law:
There is an exception to all laws.



Re: Creating HTML emails with mutt

2019-10-30 Thread John Long
On Wed, 30 Oct 2019 23:53:40 +1300
martin f krafft  wrote:

> Regarding the following, written by “Dave Woodfall” on 2019-10-30 at
> 10:05 Uhr +:
> > 
> > I don’t think embracing wrong email practices is the way forward.
> 
> I don’t think this is about right and wrong, and not only because
> there is no objectivity. multipart/alternative is an accepted
> standard, and so is HTML. You might not like how things have
> developed, and neither do I, but that doesn’t make it wrong.

HTML is for web pages. It is wrong for email, yes.

Lots of Microsoft crap seems like an "accepted standard" but that's
really just bullying, because they come preinstalled on 99% of
Intel/AMD hardware. Just because everybody says the world is flat does
not mean it's true.

> The fact that the vast majority have adopted HTML for emails means
> you cannot really ignore it anymore.

I read those emails with a GUI client that I don't like very much and
like less and less with each new release. I like mutt for mailing lists
and corresponding with technical people.

> Mutt already handles receiving/reading alternative parts quite well.
> Being able to produce those parts will mean it’ll suck less for those
> who need or want this functionality.

Simplicity and constantly adding new features that are inessential are
at odds with each other. I think it's pretty clear the people who use
mutt prefer simplicity or they would have chosen something else. There
are enough other email clients for people in other camps. Sometimes you
have to have more than one tool for different jobs, even though they're
superficially similar.

/jl


Re: Creating HTML emails with mutt

2019-10-30 Thread martin f krafft


Regarding the following, written by “Dave Woodfall” on 2019-10-30 at 10:05 Uhr +:

I don’t think embracing wrong email practices is the way forward.

I don’t think this is about right and wrong, and not only because there is no objectivity. multipart/alternative is an accepted standard, and so is HTML. You might not like how things have developed, and neither do I, but that doesn’t make it wrong.
The fact that the vast majority have adopted HTML for emails means you cannot really ignore it anymore. Mutt already handles receiving/reading alternative parts quite well. Being able to produce those parts will mean it’ll suck less for those who need or want this functionality.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "to me, vi is zen. to use vi is to practice zen. every command is a koan. profound to the user, unintelligible to the uninitiated. you discover truth everytime you use it." -- reddy ät lion.austin.ibm.com spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-30 Thread martin f krafft


Regarding the following, written by “Nuno Silva” on 2019-10-30 at 09:21 Uhr +:

There are users who don’t need text/html. It’s okay to want some way to use HTML for e-mail in mutt, but I’d say it’s not okay to say everybody needs it.

I’d love to see some statistics about the age of mutt users.
Just to be clear: any solution will be configurable, so nobody will be forced to use it.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net "everyone has a little secret he keeps, i like the fires when the city sleeps."  -- mc 900 ft jesus spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-30 Thread Dave Woodfall
On Wed 30 Oct 2019 12:57,
martin f krafft  put forth the proposition:
> Regarding the following, written by "Martin Trautmann" on 2019-10-30 at 00:14 
> Uhr +0100:
> > That's such a strange thing.
> > […]
> > since they never learned, how proper threading and quoting could have
> > worked?
>
> 78 characters wide text/plain is just not the lowest common denominator
> anymore. I am not going to sing an ode to HTML email, but being able to use
> Markdown to create more expressive emails than using ASCII art is not
> something I find utterly offensive.
>
> If you want someone to blame, shake your fist at Microsoft (for forcing HTML
> into email), and Google (for actively breaking threading and quoting rules).
> That said, Gmail is far easier to use if you want to refer back to content
> written earlier in a thread than mutt, where you either have to save a
> draft, or open a second instance, find the thread, and navigate around
> messages, or use clunky search.
>
> Society has moved on, and we all risk sounding like grumpy old folks
> reminiscing at the times when everyone knew what netiquette was if we don't
> embrace the progress that's been happening around us. And text/html is part
> of that progress, whether you like it or not.
>
> If we don't embrace progress, then mutt will not have any users in a decade
> or two.

I don't think embracing wrong email practices is the way forward.  If
I really needed HTML support then I'd use something like claws-mail,
and not change mutt to support it.

Most of my correspondence is with other *nix users though, who mostly
do it right.

For everyone else I press 'z'.

macro pager,index,attach z ":unauto_view 
text/html|~/.mutt/elinks:auto_view
text/html"



--

Q:  How many journalists does it take to screw in a lightbulb?
A:  Three.  One to report it as an inspired government program to bring
light to the people, one to report it as a diabolical government
plot to deprive the poor of darkness, and one to win a pulitzer
prize for reporting that Electric Company hired a lightbulb
assassin to break the bulb in the first place.

#!/bin/sh

TMPFILE="/tmp/mutt-elinks.html"
cat /dev/stdin | sed "s,$,,g" > "$TMPFILE"
elinks -force-html "$TMPFILE"


Re: Creating HTML emails with mutt

2019-10-30 Thread nunojsilva
On 2019-10-29, martin f krafft wrote:

[...]
> Society has moved on, and we all risk sounding like grumpy old folks
> reminiscing at the times when everyone knew what netiquette was if we
> don't embrace the progress that's been happening around us. And
> text/html is part of that progress, whether you like it or not.
>
> If we don't embrace progress, then mutt will not have any users in a
> decade or two.

There are users who don't need text/html. It's okay to want some way to
use HTML for e-mail in mutt, but I'd say it's not okay to say everybody
needs it.

-- 
Nuno Silva



Re: Creating HTML emails with mutt

2019-10-29 Thread Patrick Shanahan
* Grant Edwards  [10-29-19 18:27]:
> On 2019-10-29, Patrick Shanahan  wrote:
> > * Grant Edwards  [10-29-19 13:10]:
> >
> >> Muttdown (a "sendmail" filter) which creates mutlipart alternative
> >> html/text messages is the only reason I've been able to continue to
> >> use mutt for the past 5-6 years.  About 90% of the people to whom I
> >> send email can't deal with plaintext only. The display of plaintext is
> >> butchered horribly by Outlook, and using plaintext-only makes me look
> >> incompetent because I can't send an easy-to-read email (the recipient
> >> has to save it as a text file and open it with notepad++ in a fixed
> >> font for it to be readable).
> >
> > so you cater to people who have no idea, and cannot be bothered.
> 
> Yep.  If you're intent is to communicate with other poeple, you have
> to use a medium and language understood by them.  Otherwise you're
> just singing in the shower.
> 
> I suppose I could limit my social and professional interaction
> strictly to other mutt users.  Somebody should try that and let me
> know how it goes...

fwiw, I do not have that problem and continually communicate with others
and *still* am using mutt for nearly 20 years.  perhaps the problem is in
the chair in front of your keyboard.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-10-29 Thread martin f krafft


Regarding the following, written by “Martin Trautmann” on 2019-10-30 at 00:14 Uhr +0100:

That’s such a strange thing.
[…]
since they never learned, how proper threading and quoting could have worked?

78 characters wide text/plain is just not the lowest common denominator anymore. I am not going to sing an ode to HTML email, but being able to use Markdown to create more expressive emails than using ASCII art is not something I find utterly offensive.
If you want someone to blame, shake your fist at Microsoft (for forcing HTML into email), and Google (for actively breaking threading and quoting rules). That said, Gmail is far easier to use if you want to refer back to content written earlier in a thread than mutt, where you either have to save a draft, or open a second instance, find the thread, and navigate around messages, or use clunky search.
Society has moved on, and we all risk sounding like grumpy old folks reminiscing at the times when everyone knew what netiquette was if we don’t embrace the progress that’s been happening around us. And text/html is part of that progress, whether you like it or not.
If we don’t embrace progress, then mutt will not have any users in a decade or two.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net fighting for peace is like screwing for virginity.   -- the irish times, washington dc spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-29 Thread Martin Trautmann
On 19-10-29 18:09, Grant Edwards wrote:

> Muttdown (a "sendmail" filter) which creates mutlipart alternative
> html/text messages is the only reason I've been able to continue to
> use mutt for the past 5-6 years.  About 90% of the people to whom I
> send email can't deal with plaintext only. The display of plaintext is
> butchered horribly by Outlook, and using plaintext-only makes me look
> incompetent because I can't send an easy-to-read email (the recipient
> has to save it as a text file and open it with notepad++ in a fixed
> font for it to be readable).

That's such a strange thing.

Are those the same people who
- embed textual information within pictures
- send information as Word attachment instead of a simple
  text message within the mail
- and finally refuse to use email, claiming this is system is
  dead by now
  ... while they feel most comfortable with twitter and whatsapp
  messages, using plain text only

since they never learned, how proper threading and quoting could have
worked?

Schönen Gruß
Martin



signature.asc
Description: OpenPGP digital signature


Re: Creating HTML emails with mutt

2019-10-29 Thread Grant Edwards
On 2019-10-29, martin f krafft  wrote:
> [/home/grante/bin/unmime.py: html rendered using w3m]
> Regarding the following, written by “Grant Edwards” on 2019-10-29 at 17:09 Uhr
> -:
>
> Muttdown (a “sendmail” filter) which creates mutlipart alternative html/
> text messages is the only reason I’ve been able to continue to use mutt 
> for
> the past 5-6 years.
>
> Muttdown suffers from the same problems relating to attachments in signed
> messages as outlined in the initial post.

That's true (as I understood the problem, anyway).  Fortunately, I
never needed to send a signed message with an attachment (or just a
signed message, AFAIR).  Nobody I know would have the faintest idea
what to do with a signed message.

-- 
Grant Edwards   grant.b.edwardsYow! Half a mind is a
  at   terrible thing to waste!
  gmail.com



Re: Creating HTML emails with mutt

2019-10-29 Thread Grant Edwards
On 2019-10-29,  (Nuno Silva)  
wrote:
> On 2019-10-29, John Long wrote:
>
>> On Tue, 29 Oct 2019 14:50:05 -0400
>> Patrick Shanahan  wrote:
>>
>>> * Grant Edwards  [10-29-19 13:10]:
> [...]
>>> > Muttdown (a "sendmail" filter) which creates mutlipart alternative
>>> > html/text messages is the only reason I've been able to continue to
>>> > use mutt for the past 5-6 years.  About 90% of the people to whom I
>>> > send email can't deal with plaintext only. The display of plaintext
>>> > is butchered horribly by Outlook, 
>>
>> This is sadly, absolutely true. It's beyond frustrating to format an
>> email carefully in ASCII text and then have it look like a telegram
>> from Charles Manson by the time Outlook is done with it.
> [...]
>
> What about composing html in the text editor and changing the
> content-type to text/html with ^T in mutt?

The only what that's practical is to put everything inside 
with some embedded CSS to pick a fixed font.  In theory that could
work.

Muttdown is far, far simpler and produces very nice looking results.

It allows multi-level quoting, lists, code blocks, and so on.

The key is to bind a button/command in your editor to a 'preview'
command that runs the buffer through muttdown and shows the result in
a browser.  That gives you a pretty good idea what the recipient will
see.

> It might be inconvenient for more complex messages, but could perhaps
> help in these cases where you're sending something that would otherwise
> go as plain text to Outlook users.

-- 
Grant Edwards   grant.b.edwardsYow! Used staples are good
  at   with SOY SAUCE!
  gmail.com



Re: Creating HTML emails with mutt

2019-10-29 Thread Grant Edwards
On 2019-10-29, Patrick Shanahan  wrote:
> * Grant Edwards  [10-29-19 13:10]:
>
>> Muttdown (a "sendmail" filter) which creates mutlipart alternative
>> html/text messages is the only reason I've been able to continue to
>> use mutt for the past 5-6 years.  About 90% of the people to whom I
>> send email can't deal with plaintext only. The display of plaintext is
>> butchered horribly by Outlook, and using plaintext-only makes me look
>> incompetent because I can't send an easy-to-read email (the recipient
>> has to save it as a text file and open it with notepad++ in a fixed
>> font for it to be readable).
>
> so you cater to people who have no idea, and cannot be bothered.

Yep.  If you're intent is to communicate with other poeple, you have
to use a medium and language understood by them.  Otherwise you're
just singing in the shower.

I suppose I could limit my social and professional interaction
strictly to other mutt users.  Somebody should try that and let me
know how it goes...

-- 
Grant Edwards   grant.b.edwardsYow! for ARTIFICIAL
  at   FLAVORING!!
  gmail.com



Re: Creating HTML emails with mutt

2019-10-29 Thread martin f krafft


Regarding the following, written by “Grant Edwards” on 2019-10-29 at 17:09 Uhr -:

Muttdown (a “sendmail” filter) which creates mutlipart alternative html/text messages is the only reason I’ve been able to continue to use mutt for the past 5-6 years.

Muttdown suffers from the same problems relating to attachments in signed messages as outlined in the initial post.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net for four-fifths of our history,  our planet was populated by pond scum.  -- j.w. schopf spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-29 Thread nunojsilva
On 2019-10-29, John Long wrote:

> On Tue, 29 Oct 2019 14:50:05 -0400
> Patrick Shanahan  wrote:
>
>> * Grant Edwards  [10-29-19 13:10]:
[...]
>> > Muttdown (a "sendmail" filter) which creates mutlipart alternative
>> > html/text messages is the only reason I've been able to continue to
>> > use mutt for the past 5-6 years.  About 90% of the people to whom I
>> > send email can't deal with plaintext only. The display of plaintext
>> > is butchered horribly by Outlook, 
>
> This is sadly, absolutely true. It's beyond frustrating to format an
> email carefully in ASCII text and then have it look like a telegram
> from Charles Manson by the time Outlook is done with it.
[...]

What about composing html in the text editor and changing the
content-type to text/html with ^T in mutt?

It might be inconvenient for more complex messages, but could perhaps
help in these cases where you're sending something that would otherwise
go as plain text to Outlook users.

-- 
Nuno Silva



Re: Creating HTML emails with mutt

2019-10-29 Thread John Long
On Tue, 29 Oct 2019 14:50:05 -0400
Patrick Shanahan  wrote:

> * Grant Edwards  [10-29-19 13:10]:
> > On 2019-10-28, Matthias Apitz  wrote:  
> > > El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek
> > > Martin escribió: 
> > >> > FWIW, I (as a mutt user for 15++ years) do not need this.
> > >> > Thanks  
> > >> 
> > >> Perhaps not, but the fact that it keeps coming up here is pretty
> > >> clear indication that it's a feature that would be useful to a
> > >> lot of people...  
> > >
> > > Well, do you speak for you or for a 'lot of people'? Who they
> > > are?  
> > 
> > Muttdown (a "sendmail" filter) which creates mutlipart alternative
> > html/text messages is the only reason I've been able to continue to
> > use mutt for the past 5-6 years.  About 90% of the people to whom I
> > send email can't deal with plaintext only. The display of plaintext
> > is butchered horribly by Outlook, 

This is sadly, absolutely true. It's beyond frustrating to format an
email carefully in ASCII text and then have it look like a telegram
from Charles Manson by the time Outlook is done with it.

> > and using plaintext-only makes me
> > look incompetent because I can't send an easy-to-read email (the
> > recipient has to save it as a text file and open it with notepad++
> > in a fixed font for it to be readable).  
> 
> so you cater to people who have no idea, and cannot be bothered.

Which is probably 99.9% of everybody in corp. offices worldwide.

Don't get me wrong, I'm not advocating for HTML support in mutt. HTML
has absolutely no place in email. But I do understand the problem very
well after doing some contracting for big corporations and realizing
100s of millions of Windows victims can barely use a computer at all
and email is just the tip of the iceberg.

My solution is to use something other than mutt in those cases. There
is no way to win...

/jl


Re: Creating HTML emails with mutt

2019-10-29 Thread Patrick Shanahan
* Grant Edwards  [10-29-19 13:10]:
> On 2019-10-28, Matthias Apitz  wrote:
> > El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin 
> > escribió:
> >
> >> > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks
> >> 
> >> Perhaps not, but the fact that it keeps coming up here is pretty clear
> >> indication that it's a feature that would be useful to a lot of
> >> people...
> >
> > Well, do you speak for you or for a 'lot of people'? Who they are?
> 
> Muttdown (a "sendmail" filter) which creates mutlipart alternative
> html/text messages is the only reason I've been able to continue to
> use mutt for the past 5-6 years.  About 90% of the people to whom I
> send email can't deal with plaintext only. The display of plaintext is
> butchered horribly by Outlook, and using plaintext-only makes me look
> incompetent because I can't send an easy-to-read email (the recipient
> has to save it as a text file and open it with notepad++ in a fixed
> font for it to be readable).

so you cater to people who have no idea, and cannot be bothered.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode


Re: Creating HTML emails with mutt

2019-10-29 Thread Grant Edwards
On 2019-10-28, Matthias Apitz  wrote:
> El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin 
> escribió:
>
>> > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks
>> 
>> Perhaps not, but the fact that it keeps coming up here is pretty clear
>> indication that it's a feature that would be useful to a lot of
>> people...
>
> Well, do you speak for you or for a 'lot of people'? Who they are?

Muttdown (a "sendmail" filter) which creates mutlipart alternative
html/text messages is the only reason I've been able to continue to
use mutt for the past 5-6 years.  About 90% of the people to whom I
send email can't deal with plaintext only. The display of plaintext is
butchered horribly by Outlook, and using plaintext-only makes me look
incompetent because I can't send an easy-to-read email (the recipient
has to save it as a text file and open it with notepad++ in a fixed
font for it to be readable).

-- 
Grant Edwards   grant.b.edwardsYow! Go on, EMOTE!
  at   I was RAISED on thought
  gmail.comballoons!!



Re: Creating HTML emails with mutt

2019-10-29 Thread Kevin J. McCarthy

On Tue, Oct 29, 2019 at 10:15:22PM +1300, martin f krafft wrote:

Regarding the following, written by "Kevin J. McCarthy" on 2019-10-29 at 12:58 
Uhr +0800:
instead of the script returning content of a specific type, and thus 
always with the same content type (unless the filter script is 
interactive of sorts), what about a command or option that I can use to 
instruct mutt to generate an alternative of a given MIME type, which is 
then passed to the script, and the return data assumed as such.


I'll think about it, but that may be more designing than I can bite off 
right now.


Because the filter is configurable via a variable, you could certainly 
have a compose menu macro to change the value of the variable, combined 
with visual feedback from the :echo command.  The variable should also 
be able to accommodate a parameter (set by you).


It may be a bit more trouble for you the add the mime type + blank line 
in the output, but I think it gives more flexibility.  If others have 
opinions, please chime in though!


Now, I could configure mutt to always add a text/html alternative, but 
also have a command from the compose menu allowing me to add e.g. 
text/enriched, or application/pdf.


Note also, this iteration is only going to be able to generate a single 
alternative.


Yes, this is one of the places I need to look at.  My plan is the 
simplest, as you mentioned: discard the alternative when generating 
anything that goes through the compose menu.


… but not on messages that are being forwarded as attachments. Those 
don't get touched, right?


Sorry, I got confused.  If we're talking about $mime_forward, then no, 
it shouldn't get touched.  $forward_attachments (version 1.12+) runs 
through the decoder though.  I think the places I have to worry about 
are templates and resuming, but I need to look more closely.


I'll be working on this in the 'kevin/multipart-alternative' branch, but 
just fyi that I force-push to my development branches, and they are 
usually "work in progress".


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-29 Thread martin f krafft


Regarding the following, written by “Kevin J. McCarthy” on 2019-10-29 at 12:58 Uhr +0800:

The part creation (and removal) will be in Mutt’s pipeline, and so will follow normal processing that Mutt does. That include encoding, delimiters, charset conversion, etc. So I would like the script to simply produce the HTML (or PDF, or whatever) output, without trying to “mailify” the output.

Makes perfect sense.
At the risk of overcomplicating things at this stage, I do want to put one more idea out there, which is that instead of the script returning content of a specific type, and thus always with the same content type (unless the filter script is interactive of sorts), what about a command or option that I can use to instruct mutt to generate an alternative of a given MIME type, which is then passed to the script, and the return data assumed as such.
Now, I could configure mutt to always add a text/html alternative, but also have a command from the compose menu allowing me to add e.g. text/enriched, or application/pdf.

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.
For this iteration, I didn’t plan on going here. $fcc_attach would still just remove attachments, the main content would be stored as it were generated (i.e. including multipart/alternatives). Maybe in the next iteration I could add an option to strip the alternative.

The more I think about this, the less I think this should be an option. Even $fcc_attach is already quite a problem, especially since it means that the message stored locally isn’t the same as the one you sent, with a different GPG signature and all.

Yes, this is one of the places I need to look at. My plan is the simplest, as you mentioned: discard the alternative when generating anything that goes through the compose menu.

… but not on messages that are being forwarded as attachments. Those don’t get touched, right?
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net who's general failure, and why's he reading my disk? spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-28 Thread Kevin J. McCarthy

On Tue, Oct 29, 2019 at 12:41:44PM +1300, martin f krafft wrote:
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?


The part creation (and removal) will be in Mutt's pipeline, and so will 
follow normal processing that Mutt does.  That include encoding, 
delimiters, charset conversion, etc.  So I would like the script to 
simply produce the HTML (or PDF, or whatever) output, without trying to 
"mailify" the output.


I think it would be okay for a charset to optionally be included in the 
content-type.  I have to think about whether to force-charset in that 
case, or still respect $send_charset.


But I don't think allowing other headers would help.  Mutt can determine 
the best content-encoding, and I think it's fair to set disposition to 
inline.  If the approach turns out to be insufficient, we can add 
features.


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.


For this iteration, I didn't plan on going here.  $fcc_attach would 
still just remove attachments, the main content would be stored as it 
were generated (i.e. including multipart/alternatives).  Maybe in the 
next iteration I could add an option to strip the alternative.


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


Yes, this is one of the places I need to look at.  My plan is the 
simplest, as you mentioned: discard the alternative when generating 
anything that goes through the compose menu.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-28 Thread Akkana Peck
Matthias Apitz writes:
> So, run mutt in an unicode-rxvt terminal. It presents URLs underlined
> and click-able. I do so and sometimes I do hate it: you click into your

Definitely not by default. I'm using rxvt-unicode, and I've tried
the "matcher" and "selection" extensions but neither one worked for
selecting multiline URLs. Do you know one that does? I only recently
switched to urxvt and I've been surprised at how bad it is at
URL selection compared to xterm (xterm has charClass and cutChars
resources you can configure that work very well for URLs).

I get the impression the mutt pager breaks long URLs anyway, which
makes it harder for a terminal to select them. It would be great to
have an option not to break them and just let the terminal wrap them
(I know that makes it harder to predict how many lines the display is).

If we're counting votes, I'm another longtime mutt fan who'd love to
be able to compose and send simple HTML messages. There are lots of
options for displaying incoming HTML messages -- none of them are
perfect, e.g. the link-clicking problem, but they're okay -- but
replying to HTML messages in mutt without losing all the formatting
is much more difficult. I spent a week or so several years ago and
never managed it (I ended up writing a python script for the once or
twice a year when I really need to send HTML mail) so I'm reading this
thread with interest to see what solutions other people come up with.

...Akkana


Re: Creating HTML emails with mutt

2019-10-28 Thread Matthias Apitz
El día lunes, octubre 28, 2019 a las 06:33:19p. m. -0400, José María Mateos 
escribió:

> On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote:
> >Well, do you speak for you or for a 'lot of people'? Who they are?
> >I speak only for my own interests (as I said: I do not need this).
> 
> Talking for myself, I really don't need point 1 (composing of HTML 
> messages), but number 2, opening links in an easy way, would be a nice 
> to have. I can always user urlview or send the HTML file to Firefox, but 
> any of these solutions is slower than simply being able to somehow tell 
> mutt "open URL #12 from this e-mail", and have that sent to the web 
> browser.

So, run mutt in an unicode-rxvt terminal. It presents URLs underlined
and click-able. I do so and sometimes I do hate it: you click into your
terminal to get the focus to it, or even as an accident, and hit an URL and
it jumps off to FF.

matthias


-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 
aus: https://www.jungewelt.de/2019/10-02/index.php


Re: Creating HTML emails with mutt

2019-10-28 Thread Matthias Apitz
El día martes, octubre 29, 2019 a las 11:19:43a. m. +1300, martin f krafft 
escribió:

> Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 
> Uhr +0100:
> >Well, do you speak for you or for a 'lot of people'? Who they are? 
> >I speak only for my own interests (as I said: I do not need this).
> 
> Matthias, any such feature would of course be optional, and probably 
> default to off for a long time, so you have nothing to worry about.

I don't worry about this. I only do not like people expressing their own
interests with a 'lot of people demand xyz'.

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 
aus: https://www.jungewelt.de/2019/10-02/index.php


Re: Creating HTML emails with mutt

2019-10-28 Thread Dave Woodfall
> 2. The ability to natively display a subset of HTML (the same subset)
>with the ability to trigger links to open in a browser (or perhaps
>execute an arbitrary configured command).  Modern terminal windows
>can handle all of the formatting required to do just this much...

elinks -dump can display HTML using autoview, or it can be bound to run
manually too, in its normal browser manner.

urlview can open links in plain text messages.

--

LIGHTHOUSE:
A tall building on the seashore in which the government
maintains a lamp and the friend of a politician.



Re: Creating HTML emails with mutt

2019-10-28 Thread martin f krafft

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.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-10-28 Thread José María Mateos

On Mon, Oct 28, 2019 at 10:40:16PM +, Chris Green wrote:

Isn't that handled by your terminal program?  Mine certainly allows
one to right click on any URL to open it.


Not if the URL spans several lines. I think it's a common issue across 
several terminal programs and last time I read about it I think it's due 
to the way mutt handles URLs, but perhaps I'm mistaken.


--
José María (Chema) Mateos || https://rinzewind.org/


Re: Creating HTML emails with mutt

2019-10-28 Thread Chris Green
On Mon, Oct 28, 2019 at 06:33:19PM -0400, José María Mateos wrote:
> On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote:
> > Well, do you speak for you or for a 'lot of people'? Who they are?
> > I speak only for my own interests (as I said: I do not need this).
> 
> Talking for myself, I really don't need point 1 (composing of HTML
> messages), but number 2, opening links in an easy way, would be a nice to
> have. I can always user urlview or send the HTML file to Firefox, but any of
> these solutions is slower than simply being able to somehow tell mutt "open
> URL #12 from this e-mail", and have that sent to the web browser.
> 
Isn't that handled by your terminal program?  Mine certainly allows
one to right click on any URL to open it.

-- 
Chris Green


Re: Creating HTML emails with mutt

2019-10-28 Thread José María Mateos

On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote:

Well, do you speak for you or for a 'lot of people'? Who they are?
I speak only for my own interests (as I said: I do not need this).


Talking for myself, I really don't need point 1 (composing of HTML 
messages), but number 2, opening links in an easy way, would be a nice 
to have. I can always user urlview or send the HTML file to Firefox, but 
any of these solutions is slower than simply being able to somehow tell 
mutt "open URL #12 from this e-mail", and have that sent to the web 
browser.


Cheers,

--
José María (Chema) Mateos || https://rinzewind.org/


Re: Creating HTML emails with mutt

2019-10-28 Thread martin f krafft

Regarding the following, written by "Matthias Apitz" on 2019-10-28 at 23:11 Uhr 
+0100:
Well, do you speak for you or for a 'lot of people'? Who they are? 
I speak only for my own interests (as I said: I do not need this).


Matthias, any such feature would of course be optional, and probably 
default to off for a long time, so you have nothing to worry about.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"if they can get you asking the wrong questions,
they don't have to worry about answers."
  -- thomas pynchon

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Re: Creating HTML emails with mutt

2019-10-28 Thread Matthias Apitz
El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin escribió:

> > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks
> 
> Perhaps not, but the fact that it keeps coming up here is pretty clear
> indication that it's a feature that would be useful to a lot of
> people...

Well, do you speak for you or for a 'lot of people'? Who they are?
I speak only for my own interests (as I said: I do not need this).

matthias
-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 
aus: https://www.jungewelt.de/2019/10-02/index.php


Re: Creating HTML emails with mutt

2019-10-28 Thread Derek Martin
On Mon, Oct 28, 2019 at 10:06:18PM +0100, Matthias Apitz wrote:
> El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin 
> escribió:
> 
> > FWIW, my two biggest wishlist items for Mutt are:
> > 
> > 1. the ability to create and send at least simple HTML messages, with
> >or without multipart alternatives, specifically for basic text
> >formatting (bold, italics, color) and hypertext links.  [It's
> >expected that an external HTML editor would need to be spawned to
> >generate the HTML.  It makes sense to be able to specify a filter
> >to convert this to an alternative form for multipart.]
> > 
> > 2. The ability to natively display a subset of HTML (the same subset)
> >with the ability to trigger links to open in a browser (or perhaps
> >execute an arbitrary configured command).  Modern terminal windows
> >can handle all of the formatting required to do just this much...
> > 
> 
> FWIW, I (as a mutt user for 15++ years) do not need this. Thanks

Perhaps not, but the fact that it keeps coming up here is pretty clear
indication that it's a feature that would be useful to a lot of
people...

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-28 Thread Matthias Apitz
El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin escribió:

> FWIW, my two biggest wishlist items for Mutt are:
> 
> 1. the ability to create and send at least simple HTML messages, with
>or without multipart alternatives, specifically for basic text
>formatting (bold, italics, color) and hypertext links.  [It's
>expected that an external HTML editor would need to be spawned to
>generate the HTML.  It makes sense to be able to specify a filter
>to convert this to an alternative form for multipart.]
> 
> 2. The ability to natively display a subset of HTML (the same subset)
>with the ability to trigger links to open in a browser (or perhaps
>execute an arbitrary configured command).  Modern terminal windows
>can handle all of the formatting required to do just this much...
> 

FWIW, I (as a mutt user for 15++ years) do not need this. Thanks

matthias

-- 
Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

3. Oktober! Wir gratulieren! Der Berliner Fernsehturm wird 50 
aus: https://www.jungewelt.de/2019/10-02/index.php


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-28 Thread Derek Martin
On Sun, Oct 27, 2019 at 10:02:38AM +0800, Kevin J. McCarthy wrote:
> On Sat, Oct 26, 2019 at 11:16:25AM +1300, martin f krafft wrote:
> Native support for multipart/alternative composition isn't in my todo list.
> However, I do have a plan to allow external filter generation of the
> alternative.  Originally, this was on my list for the next development
> cycle, but let me see what I can do before the 1.13 release.
> 
> The current idea is a quadaption (names may change, but...)
> $compose_multipart_alternative combined with a script
> $compose_multipart_alternative_script.

FWIW, my two biggest wishlist items for Mutt are:

1. the ability to create and send at least simple HTML messages, with
   or without multipart alternatives, specifically for basic text
   formatting (bold, italics, color) and hypertext links.  [It's
   expected that an external HTML editor would need to be spawned to
   generate the HTML.  It makes sense to be able to specify a filter
   to convert this to an alternative form for multipart.]

2. The ability to natively display a subset of HTML (the same subset)
   with the ability to trigger links to open in a browser (or perhaps
   execute an arbitrary configured command).  Modern terminal windows
   can handle all of the formatting required to do just this much...

While I still mostly prefer plain text for its brevity, being able to
provide emphasis and other basic formatting is nice.  It's hard to
deny that HTML mail has become the defacto standard for most people,
and I think Mutt really falls short in its ability to handle this
stuff out of the box.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-26 Thread Kevin J. McCarthy

On Sat, Oct 26, 2019 at 11:16:25AM +1300, martin f krafft wrote:
I need to start sending out `text/html` alternative parts to my 
messages with mutt.


Hi martin,

Native support for multipart/alternative composition isn't in my todo 
list.  However, I do have a plan to allow external filter generation of 
the alternative.  Originally, this was on my list for the next 
development cycle, but let me see what I can do before the 1.13 release.


The current idea is a quadaption (names may change, but...) 
$compose_multipart_alternative combined with a script 
$compose_multipart_alternative_script.


The script would be run post-compose menu, after checks such as 
$abort_noattach and $abort_nosubject, but before signing/encryption; it 
would not be run when postponing.


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.


Script output would be the content-type, a blank line, then 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.  So, 
again, not sure I can deliver this before 1.13.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature


Re: Creating HTML emails with mutt

2019-10-26 Thread martin f krafft


Regarding the following, written by “Amit Ramon” on 2019-10-26 at 09:03 Uhr +0300:

A few years back I developed a simple filter that does, more or less, what you’re looking for.
[…]
https://github.com/amitramon/plainMail2HTML

Thanks for the pointer. If messages aren’t PGP/MIME-signed, then both muttdown and my own tool work just fine. The question is more about how it should be done properly, than it is about which tool can do this.
Thank you anyway, and I do wish I had seen your work (and muttdown) before writing it all up by myself.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net heisenberg may have been here. spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-26 Thread Amit Ramon

martin f krafft  [2019-10-26 11:16 +1300]:


Folks,

I need to start sending out text/html alternative parts to my messages with
mutt. However, this is a rabbit hole, so if you’re afraid of those, stop
reading now.

My requirements are, in decreasing order of priority:

1. Compatible with all Gmail, Outlook, Hotmail, Apple Mail, Thunderbird, and
   whatever else many people are using these days.
2. Markdown processing of text/plain
3. multipart/alternative result, MIME compliant
4. Attachments
5. Sensible integration with mutt
6. PGP signatures
7. Inline images

and after surveying the field, and spending hours with the solutions I found
during various web searches, I am writing in to you for some feedback, input,
guidance, psycological help, and maybe even some hugs.


A few years back I developed a simple filter that does, more or less,
what you're looking for. I believe it fulfills your first 5
requirements. I've not designed nor tested it with PGP signatures or
inline images.

It serves as a replacement to Mutt's sendmail command, it processes the
text using reStructuredText (that should be easily switched with
markdown), and the result is a multipart/alternative that contains the
original message as text/plain and a text/html.

I don't know how well it complies with standards, and I haven't tested
the resulted mail with all possible email clients. I believe it works
well with Gmail and thunderbird.

If this sounds interesting, you can find it at

https://github.com/amitramon/plainMail2HTML

Hope it helps,

Amit



Re: Creating HTML emails with mutt

2019-10-25 Thread martin f krafft


Regarding the following, written by “José María Mateos” on 2019-10-25 at 18:32 Uhr -0400:

If you want to accomplish this, wouldn’t it be enough not to wrap the text? That way the client/screen will do its own wrapping, no need to go the HTML way.

That would indeed take care of the extraneous line breaks. However, when I wrote “given how email has evolved”, I’m also talking about the kind of information that is being conveyed, which often isn’t plain-text anymore. For instance, being able to send links, some markup, and tables, in an email (rather than having to resort to an attachment) has its benefits.
-- @martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net the reason that every major university  maintains a department of mathematics  is that it's cheaper than  institutionalizing all those people. spamtraps: madduck.bo...@madduck.net



Re: Creating HTML emails with mutt

2019-10-25 Thread José María Mateos
On Sat, 26 Oct 2019 11:16:25 +1300 martin f krafft
 wrote:
> In any case, given how email has changed in the last 20 years, and how 
> text/plain messages are causing display issues across different device types 
> (e.g. they are not “responsive”)

If you want to accomplish this, wouldn't it be enough not to wrap the
text? That way the client/screen will do its own wrapping, no need to go
the HTML way.

Cheers,

-- 
José María (Chema) Mateos || https://rinzewind.org/