Re: Replacement Email Client

[Eric S Fraga]

On Tuesday, 27 Oct 2020 at 22:22, Jeremy Nicoll wrote:
> In my experience such mails are usually forwarded jokes etc, and
> another problem is that they often contain forwards of forwards
> of forwards (etc) with nested sets of attachments (as a succession

This has finally led me to find a positive outcome of social media
(Facebook etc.): I no longer get these emails! :-)
-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4 on Debian bullseye/sid

Re: Replacement Email Client

[David Wright]

On Wed 28 Oct 2020 at 12:45:49 (+), Jeremy Nicoll wrote:
> On Wed, 28 Oct 2020, at 03:59, David Wright wrote:
> 
> > I've found those sorts of emails (loosely coupled images) are easy to
> > deal with. In mutt, for example, press v for the attachments menu,
> > and again on any multipart or message/rfc822 that needs opening,
> > exposing the attachments within.
> 
> Ages ago, using an email client that allowed one to edit the raw 
> content of emails (handy for doing things like splitting OT parts of 
> threads, changing Subjects to what meant something to me, etc) I
> had scripts that ran within my text editor which would do things like
> find all the attachments in an email and assign sensible names and 
> content types to them.  Then when that was saved the client's normal
> export/detach options could be used to process the files.

Sounds like those scripts might suit the OP, at least for one aspect
of the problem (complex pages of text and images). In which case,
mutt would be a suitable client, as it allows that kind of editing
(with 'e').

Cheers,
David.

Re: Replacement Email Client

[John Hasler]

Joe writes:
> But I don't think we're alone. I think many Windows users also stop
> seeing ads after a while, and the bottom line is that Net adverts
> don't really work. I think it was P&G proved that a year or two ago,
> pulling most of their 'digital' advertising and seeing no significant
> drop in sales. When enough large businesses realise that Net
> advertising isn't cost-effective, that many of their 'clicks' are
> fake, we will see a reduction in it.

Might happen.

> What funds the Net after that, I don't know.

Well, we *could* actually *pay* for the services we need.  I pay Newsguy
for handling my email and consequently when something goes wrong I can
communicate with them and they take action.  There are also many forums
run by volunteers and paid for by donations.

And there is Usenet...

Unfortunately, over time I am being pushed more and more to the
reluctant conclusion that most people, no matter how much they piss and
moan, actually *like* centralization.

-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replacement Email Client

[Jeremy Nicoll]

On Wed, 28 Oct 2020, at 03:59, David Wright wrote:

> I've found those sorts of emails (loosely coupled images) are easy to
> deal with. In mutt, for example, press v for the attachments menu,
> and again on any multipart or message/rfc822 that needs opening,
> exposing the attachments within.

Ages ago, using an email client that allowed one to edit the raw 
content of emails (handy for doing things like splitting OT parts of 
threads, changing Subjects to what meant something to me, etc) I
had scripts that ran within my text editor which would do things like
find all the attachments in an email and assign sensible names and 
content types to them.  Then when that was saved the client's normal
export/detach options could be used to process the files.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Replacement Email Client

[Joe]

On Wed, 28 Oct 2020 09:35:46 +0100
 wrote:


> For reference, I have a (severely restrained, no javascript [1])
> Firefox running. Just one tab open, showing just one jpeg from
> XKCD [2]).
> 
> Top shows it as the (by far hungriest) memory user, with 263 MB.
> Second, third and fourth are... WebContent, WebExtensions and
> WebContent, which are Firefox too, just in disguise.
> 
> Adding those four together towers up to roughly half a gigabyte.
> Even assuming that half of that is shared libs...
> 
> Oh, fifth is Emacs, with roughly 63 MB. But it has a 500K Org
> mode file in its belly (so it's doing something useful).
> 
> How did we end here? How did we end up paying for the ad
> industry's infrastrutcture, paying with our privacy, but
> also with our real money, having to buy RAM and CPU power
> just for their sake?
> 
> How do we get out of here?


For the most part, it's not 'we'. When your operating system requires
4GB to work at all (and Linux is catching up fast), and most of your use
of the Net (and the computer itself) involves web pages, then half a gig
for a browser is not too unreasonable.

Those of us who do not run Windows and don't live our lives through
Twitter and Facebook are a minority. Those of us who use significant ad
blocking, those of us who try to avoid getting shown 'targetted' ads,
and those of us who don't even see most of the ads that are shown to
us, are a smaller one still. Apart from not buying things we see
advertised, there's not a whole lot we can do, and as a minority, the
advertisers will not even notice that.

But I don't think we're alone. I think many Windows users also stop
seeing ads after a while, and the bottom line is that Net adverts don't
really work. I think it was P&G proved that a year or two ago, pulling
most of their 'digital' advertising and seeing no significant drop in
sales. When enough large businesses realise that Net advertising isn't
cost-effective, that many of their 'clicks' are fake, we will see a
reduction in it.

What funds the Net after that, I don't know.

-- 
Joe

Re: Free-services lead to increased RAM and CPU requirements (was: Re: Replacement Email Client)

[Andrei POPESCU]

On Mi, 28 oct 20, 07:12:19, rhkra...@gmail.com wrote:
> On Wednesday, October 28, 2020 04:35:46 AM to...@tuxteam.de wrote:
> > How did we end here? How did we end up paying for the ad
> > industry's infrastrutcture, paying with our privacy, but
> > also with our real money, having to buy RAM and CPU power
> > just for their sake?
> 
> Assuming that is not a rhetorical question, or answering for posterity, it 
> was 
> primarily by accepting the word "free" in their promises of free services at 
> face value.

Client-side scripting does enable services like ProtonMail to exist as 
well.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Free-services lead to increased RAM and CPU requirements (was: Re: Replacement Email Client)

[rhkramer]

On Wednesday, October 28, 2020 04:35:46 AM to...@tuxteam.de wrote:
> How did we end here? How did we end up paying for the ad
> industry's infrastrutcture, paying with our privacy, but
> also with our real money, having to buy RAM and CPU power
> just for their sake?

Assuming that is not a rhetorical question, or answering for posterity, it was 
primarily by accepting the word "free" in their promises of free services at 
face value.

> How do we get out of here?

Don't know.  It was / is a tradeoff.  For some of us, and with appropriate 
protective measures, maybe it has been and still is a reasonable tradeoff.

Investigations started in the US congress (and, iirc, in the EC counterparts) 
may lead to de-monopolizing some of those services.  I'm not sure that will 
help all that much, or to say it another way, when that happens, those 
companies will find more ways to try to achieve large profits (which, 
generally, 
are at our expense).

I wouldn't mind seeing some discussion of appropriate ideas.

Re: Replacement Email Client

[mick crane]

On 2020-10-28 08:35, to...@tuxteam.de wrote:


How did we end here? How did we end up paying for the ad
industry's infrastrutcture, paying with our privacy, but
also with our real money, having to buy RAM and CPU power
just for their sake?

How do we get out of here?


Good point.
Ad agencies have always pushed for doing more "clever" things.
The innovations in cinema were first made in the TV commercials.
But in that case the product manufacturer was paying.

mick
--
Key ID4BFEBB31

Re: Replacement Email Client

[tomas]

On Tue, Oct 27, 2020 at 04:18:40PM -0700, John Conover wrote:
> Patrick Bartek writes:
> > > >  
> > > >> On 10/25/20 8:28 PM, Patrick Bartek wrote:  
> > > >>> I'm not referring to viewing HTML emails. I already can do that in
> > > >>> Claws-Mail using its Dillo plugin. I'm talking about filling in
> > > >>> forms, etc. that are part of the HTML email and sending just the
> > > >>> data without "replying" in the normal sense.  This is beyond
> > > >>> Claws' and Dillo's capabilities.  I have to use a real browser,
> > > >>> log into that particular web mail account (like gmail), click on
> > > >>> that particular email, etc. to do so.
> > > >>>
> 
> Has anyone:
> 
> 1) ReBoot your machine.
> 2) login and launch claws-mail with the Dillo plugin, 
>and exit claws-mail
> 3) lsof -Pni > tempfile
> 
> and near the end of tempfile is 10 process running from Dillo, even
> through claws-mail has exited, (all listeners, something like 50 MB of
> memory.)

Wow. 50 MB.

For reference, I have a (severely restrained, no javascript [1])
Firefox running. Just one tab open, showing just one jpeg from
XKCD [2]).

Top shows it as the (by far hungriest) memory user, with 263 MB.
Second, third and fourth are... WebContent, WebExtensions and
WebContent, which are Firefox too, just in disguise.

Adding those four together towers up to roughly half a gigabyte.
Even assuming that half of that is shared libs...

Oh, fifth is Emacs, with roughly 63 MB. But it has a 500K Org
mode file in its belly (so it's doing something useful).

How did we end here? How did we end up paying for the ad
industry's infrastrutcture, paying with our privacy, but
also with our real money, having to buy RAM and CPU power
just for their sake?

How do we get out of here?

Cheers
 - t


signature.asc
Description: Digital signature

Re: Replacement Email Client

[Kenneth Parker]

On Sun, Oct 25, 2020 at 7:00 AM Teemu Likonen  wrote:

> * 2020-10-25 06:51:36-04, Kenneth Parker wrote:
>
> > On Sun, Oct 25, 2020, 6:40 AM  wrote:
> >> alpine
>
> > +1
>
> It would be useful to add some information how the suggested client
> (Alpine) serves the purpose that was asked by the original poster.
>

Fair Enough (and sorry it took me so long.  The system I use alpine on is
remote, and not easily reached through my Android Phone.

When I bring up an email, it shows me a summary of the email structure.
Its default is to show the rendered html part, but the option can be
changed,  here is a short excerpt (

||  Date: Fri, 29 Jun 2018 12:55:31 -0400
||  From: "redac...@gmail.com [hercules-os380]" <
hercules-os...@yahoogroups.com>
||  To: hercules-os...@yahoogroups.com
||  Subject: Re: [hercules-os380] b8000
||  Parts/Attachments:
||1   OK  38 lines  Text
||2 Shown496 lines  Text
||  
||
||
||
||  On 27 June 2018 at 03:53, 'Redacted redac...@gmail.com wrote:
||
||  >> Hercules is already doing exactly that. How far away is it from
being a
||  >> debugger?
||  >>
||  >> > MVSDDT uses (E)STAE; while the error path for 0Cx conditions is
||  >> > longer, it probably makes the code cleaner.
||  >>
[snip rest.  It was html, properly rendered to text]

But now, if I use the h command (for Full Headers), I get Full email
Headers, and then the html source of this email! (h again toggles back).

I believe the original poster was interested in html forms.  If in the
email itself, you get the Source of the Form Itself.  If it's in a link,
you see the link with the usual html "a" element.  (afraid to copy it here,
lest gmail Executes it!)

I will try to be more specific in the future.  ;-)

Kenneth Parker

Re: Replacement Email Client

[David Wright]

On Tue 27 Oct 2020 at 22:22:16 (+), Jeremy Nicoll wrote:
> On Tue, 27 Oct 2020, at 21:04, Dan Ritter wrote:
> 
> > - Use a good MUA and resign yourself to occasionally sending an 
> >   email to a browser. Despite your protestations of "logging
> >   in", having a browser display your email requires no such
> >   thing. The MUA saves the email to a file, then hands the file 
> >   to the browser to open it.
> 
> If the email also contained umpteen attachments each of which 
> was (typically) an image, then the MUA needs to create a folder
> containing the html and the unpacked images.  Depending on 
> the way that the html referred to those images, the MUA also 
> needs to revise the form of the image references inside the 
> written-out html so that the written-out image files can be found
> by the browser when it processes the html.  It's not quite as simple
> as you make out, especially if the code has to work on multiple 
> platforms / file systems.
> 
> In my experience such mails are usually forwarded jokes etc, and
> another problem is that they often contain forwards of forwards
> of forwards (etc) with nested sets of attachments (as a succession
> of technically naive users just forward the mail they received, 
> rather than creating a new original one with just once set of 
> contents).

I've found those sorts of emails (loosely coupled images) are easy to
deal with. In mutt, for example, press v for the attachments menu,
and again on any multipart or message/rfc822 that needs opening,
exposing the attachments within.

The problem is where the image attachments are tightly integrated
with the text, so that they really need displaying together.
I'm with Joe on that: I'd want to use a browser, that's what
they're designed for.

> Some email clients also don't assign separate names to the 
> attachments, so when they get written out the MUA has to 
> invent a name sequence (and of course modify the html 
> accordingly). 

Cheers,
David.

Re: Replacement Email Client

[John Conover]

Patrick Bartek writes:
> > >  
> > >> On 10/25/20 8:28 PM, Patrick Bartek wrote:  
> > >>> I'm not referring to viewing HTML emails. I already can do that in
> > >>> Claws-Mail using its Dillo plugin. I'm talking about filling in
> > >>> forms, etc. that are part of the HTML email and sending just the
> > >>> data without "replying" in the normal sense.  This is beyond
> > >>> Claws' and Dillo's capabilities.  I have to use a real browser,
> > >>> log into that particular web mail account (like gmail), click on
> > >>> that particular email, etc. to do so.
> > >>>

Has anyone:

1) ReBoot your machine.
2) login and launch claws-mail with the Dillo plugin, 
   and exit claws-mail
3) lsof -Pni > tempfile

and near the end of tempfile is 10 process running from Dillo, even
through claws-mail has exited, (all listeners, something like 50 MB of
memory.)

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: Replacement Email Client

[Jeremy Nicoll]

On Tue, 27 Oct 2020, at 21:04, Dan Ritter wrote:

> - Use a good MUA and resign yourself to occasionally sending an 
>   email to a browser. Despite your protestations of "logging
>   in", having a browser display your email requires no such
>   thing. The MUA saves the email to a file, then hands the file 
>   to the browser to open it.

If the email also contained umpteen attachments each of which 
was (typically) an image, then the MUA needs to create a folder
containing the html and the unpacked images.  Depending on 
the way that the html referred to those images, the MUA also 
needs to revise the form of the image references inside the 
written-out html so that the written-out image files can be found
by the browser when it processes the html.  It's not quite as simple
as you make out, especially if the code has to work on multiple 
platforms / file systems.

In my experience such mails are usually forwarded jokes etc, and
another problem is that they often contain forwards of forwards
of forwards (etc) with nested sets of attachments (as a succession
of technically naive users just forward the mail they received, 
rather than creating a new original one with just once set of 
contents).

Some email clients also don't assign separate names to the 
attachments, so when they get written out the MUA has to 
invent a name sequence (and of course modify the html 
accordingly). 

-- 
Jeremy Nicoll - my opinions are my own.

Re: Replacement Email Client

[Joe]

On Tue, 27 Oct 2020 15:23:11 -0400
rhkra...@gmail.com wrote:

> On Tuesday, October 27, 2020 12:15:46 PM Joe wrote:
> > On Tue, 27 Oct 2020 07:43:43 -0400
> > 
> > Greg Wooledge  wrote:  
> > > [1]I used to read slashdot regularly, and on slashdot, the front
> > > page had a bunch of news stories and a poll.  The poll was
> > > written as a vanilla HTML form.  If you participated in the poll,
> > > it would send you to a new instance of the home page, because a
> > > form *must* load a new page.  Doing that would lose my place,
> > > showing a new set of stories, even if I hadn't finished reading
> > > the ones on the previous instance.  
> > 
> > It doesn't have to be like that. Nearly all of my web applications
> > just use the one page, though of course it does have to be reloaded
> > after a submit. Anything I want to be persistent, I need to arrange
> > through hidden controls, appearing as parameters in the reloaded
> > page. If someone is showing you a large number of random entries on
> > a page, then of course it may be too much trouble to do this, but
> > it is certainly possible.  
> 
> Is what you describe doing something you do on a web page or in an
> email?

A web page, for my own use only. I don't send HTML email. No, it's off
the original topic a bit, but that looks unlikely to have a satisfactory
answer.

I'd be horrified at the idea of a new, full HTML/JS renderer being
embedded in an email client. It takes years to work the worst of the
security bugs out of a purpose-built web browser, which is one of the
most complex pieces of everyday software around.

-- 
Joe

Re: Replacement Email Client

[Dan Ritter]

Patrick Bartek wrote: 
> On Mon, 26 Oct 2020 21:23:59 -0400
> Carl Fink  wrote:
> 
> I don't know if there is a  or not.  Someone else suggested
> that.  It may be javascript.  Never checked email's code all that
> closely.  Next time I get one of those type emails, I'll look.
> 
> > I think you're getting normal email with a link to a form, but (as
> > you say) Dillo doesn't let you click the link, so you never realize
> > what it is. Those "rate us from 1-5" things are normally five
> > different links to the same online poll, with a parameter telling the
> > page what rating you selected. If You opened the links in an
> > HTML-aware mailer like Mutt, you could just select one of those to
> > open the form in a browser.
> 
> Yes, sometimes when I use a browser for these HTML emails and click on
> something, a new tab with a new URL opens.  Sometime not. Next time,
> I'll check the code.
> 
> Not that it matters all that much.  All I want is a lightweight email
> client that works with HTML emails, too, so I don't have to switch back
> and forth to a browser, login, etc. to get things done.  

I don't think you're going to get it.

You can't get everything right with a web page these days with
anything less than a second-rank browser. (First rank:
Chrome/Chromium, Firefox, IE/Edge/Chromium; second rank: Opera,
Brave, derivatives of first-rank and derivatives of old versions
of first-rank. Third-rank: everything else, including anything
that doesn't support modern JavaScript and HTML5.)

No browser in the first or second rank is light-weight.

QED.

You can:

- Use a webclient, including a very lightweight webclient like
  Rainloop. Rainloop literally does not store anything on the
  server side; it runs in your browser. It's great for small,
  well-organized IMAP accounts; terrible if you hoard millions
  of messages.

- Use a good MUA and resign yourself to occasionally sending an 
  email to a browser. Despite your protestations of "logging
  in", having a browser display your email requires no such
  thing. The MUA saves the email to a file, then hands the file 
  to the browser to open it.

- Write your own and make the world a better place!

-dsr-

Re: Replacement Email Client

[Patrick Bartek]

On Mon, 26 Oct 2020 21:23:59 -0400
Carl Fink  wrote:

> On 10/26/20 6:16 PM, Patrick Bartek wrote:
> > On Sun, 25 Oct 2020 20:45:50 -0400
> > Carl Fink  wrote:
> >  
> >> On 10/25/20 8:28 PM, Patrick Bartek wrote:  
> >>> I'm not referring to viewing HTML emails. I already can do that in
> >>> Claws-Mail using its Dillo plugin. I'm talking about filling in
> >>> forms, etc. that are part of the HTML email and sending just the
> >>> data without "replying" in the normal sense.  This is beyond
> >>> Claws' and Dillo's capabilities.  I have to use a real browser,
> >>> log into that particular web mail account (like gmail), click on
> >>> that particular email, etc. to do so.
> >>>
> >>> I'm getting the sense that I may not be able to find a client that
> >>> can do that.  
> >> I don't remember ever getting an emailed form that was anything but
> >> a link to a web page. Who is sending you emailed inline forms?  
> > The ones I respond to are known to me and are legit --
> > organizations, businesses, government agencies, etc. -- that I do
> > business with.  To respond, I must switch to a web browser, login to
> > my email account (like gmail), find that particular email, and
> > enter the requested data either by keyboard, drop-down menu,
> > buttons, etc., then SUBMIT it.  This happens all within the email.
> > I never get forwarded to another web site. I always stay on the web
> > mail page. As far as I can tell only the data is sent. The email
> > itself is not replied to.  That is, there's nothing in the "Sent"
> > folder.  
> 
> Meaning no offense, I doubt it. I have been using email since before
> Gopher, and I have literally never received an HTML  email with an
> embedded form (that I opened, at least). I find it hard to believe
> that you get many of them.

I don't know if there is a  or not.  Someone else suggested
that.  It may be javascript.  Never checked email's code all that
closely.  Next time I get one of those type emails, I'll look.

> I think you're getting normal email with a link to a form, but (as
> you say) Dillo doesn't let you click the link, so you never realize
> what it is. Those "rate us from 1-5" things are normally five
> different links to the same online poll, with a parameter telling the
> page what rating you selected. If You opened the links in an
> HTML-aware mailer like Mutt, you could just select one of those to
> open the form in a browser.

Yes, sometimes when I use a browser for these HTML emails and click on
something, a new tab with a new URL opens.  Sometime not. Next time,
I'll check the code.

Not that it matters all that much.  All I want is a lightweight email
client that works with HTML emails, too, so I don't have to switch back
and forth to a browser, login, etc. to get things done.  

B

Re: Replacement Email Client

[rhkramer]

On Tuesday, October 27, 2020 12:15:46 PM Joe wrote:
> On Tue, 27 Oct 2020 07:43:43 -0400
> 
> Greg Wooledge  wrote:
> > [1]I used to read slashdot regularly, and on slashdot, the front page
> > had a bunch of news stories and a poll.  The poll was written as a
> > vanilla HTML form.  If you participated in the poll, it would send you
> > to a new instance of the home page, because a form *must* load a new
> > page.  Doing that would lose my place, showing a new set of stories,
> > even if I hadn't finished reading the ones on the previous instance.
> 
> It doesn't have to be like that. Nearly all of my web applications just
> use the one page, though of course it does have to be reloaded after a
> submit. Anything I want to be persistent, I need to arrange through
> hidden controls, appearing as parameters in the reloaded page. If
> someone is showing you a large number of random entries on a page, then
> of course it may be too much trouble to do this, but it is certainly
> possible.

Is what you describe doing something you do on a web page or in an email?



> 
> I do use the very occasional smidgen of JS to replace things that have
> been left out of HTML, such as making a radio button group invoke a
> submit when changed, but on the whole I believe client-side scripting
> to be the work of the devil.

Re: Replacement Email Client

[John Hasler]

Greg Wooledge wrote:
> [1]I used to read slashdot regularly, and on slashdot, the front page
> had a bunch of news stories and a poll.  The poll was written as a
> vanilla HTML form.  If you participated in the poll, it would send you
> to a new instance of the home page, because a form *must* load a new
> page.  Doing that would lose my place, showing a new set of stories,
> even if I hadn't finished reading the ones on the previous instance.

In Firefox hold down  while clicking the button and the new page
will open in a new tab.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replacement Email Client

[Joe]

On Tue, 27 Oct 2020 07:43:43 -0400
Greg Wooledge  wrote:

>
> 
> [1]I used to read slashdot regularly, and on slashdot, the front page
> had a bunch of news stories and a poll.  The poll was written as a
> vanilla HTML form.  If you participated in the poll, it would send you
> to a new instance of the home page, because a form *must* load a new
> page.  Doing that would lose my place, showing a new set of stories,
> even if I hadn't finished reading the ones on the previous instance.
>
It doesn't have to be like that. Nearly all of my web applications just
use the one page, though of course it does have to be reloaded after a
submit. Anything I want to be persistent, I need to arrange through
hidden controls, appearing as parameters in the reloaded page. If
someone is showing you a large number of random entries on a page, then
of course it may be too much trouble to do this, but it is certainly
possible.

I do use the very occasional smidgen of JS to replace things that have
been left out of HTML, such as making a radio button group invoke a
submit when changed, but on the whole I believe client-side scripting
to be the work of the devil. 

-- 
Joe

Re: Replacement Email Client

[Joe]

On Tue, 27 Oct 2020 07:43:43 -0400
Greg Wooledge  wrote:

> On Mon, Oct 26, 2020 at 03:16:21PM -0700, Patrick Bartek wrote:
> > The ones I respond to are known to me and are legit --
> > organizations, businesses, government agencies, etc. -- that I do
> > business with.  To respond, I must switch to a web browser, login to
> > my email account (like gmail), find that particular email, and
> > enter the requested data either by keyboard, drop-down menu,
> > buttons, etc., then SUBMIT it.  This happens all within the email.
> > I never get forwarded to another web site. I always stay on the web
> > mail page.  
> 
> If you don't get a new page, then it was not a vanilla HTML form
> submission.  Those *always* give you a new page, as defined by the
> form's action field.  That's why people stopped using them.[1]
> 
> What you're describing sounds more like a Javascript button made to
> look like a form submission.  Those can do *anything*.
> 
> [1]I used to read slashdot regularly, and on slashdot, the front page
> had a bunch of news stories and a poll.  The poll was written as a
> vanilla HTML form.  If you participated in the poll, it would send you
> to a new instance of the home page, because a form *must* load a new
> page.  Doing that would lose my place, showing a new set of stories,
> even if I hadn't finished reading the ones on the previous instance.
> 
> At some point I wished fervently for the option to middle-click the
> form submit button to open the form's action page in a new tab/window.
> That never happened, obviously because web browser developers do not
> have the same priorities that I have.  They've proven that many times.
> 
> Eventually it became a moot point, because I stopped reading slashdot,
> and because web page designers have stopped using HTML forms.  They're
> just too limiting.  It's all custom Javascript stuff now.
> 

Re: Replacement Email Client

[Eric S Fraga]

On Sunday, 25 Oct 2020 at 10:36, Patrick Bartek wrote:
> On Sun, 25 Oct 2020 07:19:28 +0200
> Teemu Likonen  wrote:
>> GNU Emacs mail clients "Gnus" and "Notmuch Emacs" automatically render
>> HTML mail nicely as plain text. User can can also open HTML and other
>> MIME parts in external viewer like web browser.
>> 
>
> I can already view the text of HTML emails with Claws-Mail.  But I need
> to view the entire email: images, graphics, etc. and be able to interact
> with all the links, etc. and not just view them.  Want to get away from
> having to login to the mail account with a browser to do so.  So, EMACS
> won't work for me.

The emacs gnus HTML support is not just for viewing: you can interact as
well.  I do receive HTML emails, unfortunately, and can process most if
not all of them within Emacs.  But I've never received one with an
embedded form to submit (I wouldn't respond to such in any case).

-- 
Eric S Fraga via Emacs 28.0.50 & org 9.4 on Debian bullseye/sid

Re: Replacement Email Client

[Greg Wooledge]

On Tue, Oct 27, 2020 at 09:11:42AM +0100, to...@tuxteam.de wrote:
> We still don't know whether
> 
> - those forms are plain old HTML forms of yore with a "classical"
>   SUBMIT action
> - or they are some AJAX-y abomination in which a piece of Javascript
>   plays ping-pong with the server
> 
> In the first case I'm pretty sure you could teach your Claws/Dillo combo
> to cope with it. In the second case... I'd switch providers (I'm going
> to do this with my gas provider for a similar reason).

Or just ignore the survey.

Re: Replacement Email Client

[Greg Wooledge]

On Mon, Oct 26, 2020 at 03:16:21PM -0700, Patrick Bartek wrote:
> The ones I respond to are known to me and are legit --
> organizations, businesses, government agencies, etc. -- that I do
> business with.  To respond, I must switch to a web browser, login to
> my email account (like gmail), find that particular email, and
> enter the requested data either by keyboard, drop-down menu, buttons,
> etc., then SUBMIT it.  This happens all within the email. I never get
> forwarded to another web site. I always stay on the web mail page.

If you don't get a new page, then it was not a vanilla HTML form
submission.  Those *always* give you a new page, as defined by the
form's action field.  That's why people stopped using them.[1]

What you're describing sounds more like a Javascript button made to look
like a form submission.  Those can do *anything*.

[1]I used to read slashdot regularly, and on slashdot, the front page
had a bunch of news stories and a poll.  The poll was written as a
vanilla HTML form.  If you participated in the poll, it would send you
to a new instance of the home page, because a form *must* load a new
page.  Doing that would lose my place, showing a new set of stories,
even if I hadn't finished reading the ones on the previous instance.

At some point I wished fervently for the option to middle-click the
form submit button to open the form's action page in a new tab/window.
That never happened, obviously because web browser developers do not
have the same priorities that I have.  They've proven that many times.

Eventually it became a moot point, because I stopped reading slashdot,
and because web page designers have stopped using HTML forms.  They're
just too limiting.  It's all custom Javascript stuff now.

Re: Replacement Email Client

[Curt]

On 2020-10-27, Carl Fink  wrote:
>
> Meaning no offense, I doubt it. I have been using email since before Gopher,
> and I have literally never received an HTML  email with an embedded form
> (that I opened, at least). I find it hard to believe that you get many 
> of them.
>

>From what I've read html forms can be embedded in an email (and probably
have), but the chances of the recipient being able to submit them with
success from within his or her email client are problematic (sporadic
support is apparently the consecrated expression).

It seems like a corner case (and a very tiny corner at that). Maybe the
OP could show us the html code in question and lay all vaporous
speculation to rest (although it probably ain't worth the trouble ((but
then again we're doubtless soon to be confined here once again, and any
remedy for boredom might do, as the bars and bistros and brasseries may
be closed until further notice)).

Re: Replacement Email Client

[tomas]

On Mon, Oct 26, 2020 at 03:42:24PM -0700, Patrick Bartek wrote:

[...]

> Okay.  Here's a trivial one to keep it simple:
> 
> Recently I went to my bank in person. A few days later I get an HTML
> email [...]

I think we won't advance unless you look into that HTML.

(If you post it here: make sure to obliterate whatever might seem
confidential).

We still don't know whether

- those forms are plain old HTML forms of yore with a "classical"
  SUBMIT action
- or they are some AJAX-y abomination in which a piece of Javascript
  plays ping-pong with the server

In the first case I'm pretty sure you could teach your Claws/Dillo combo
to cope with it. In the second case... I'd switch providers (I'm going
to do this with my gas provider for a similar reason).

Cheers
 - t


signature.asc
Description: Digital signature

Re: Replacement Email Client

[Carl Fink]

On 10/26/20 6:16 PM, Patrick Bartek wrote:

On Sun, 25 Oct 2020 20:45:50 -0400
Carl Fink  wrote:


On 10/25/20 8:28 PM, Patrick Bartek wrote:

I'm not referring to viewing HTML emails. I already can do that in
Claws-Mail using its Dillo plugin. I'm talking about filling in
forms, etc. that are part of the HTML email and sending just the
data without "replying" in the normal sense.  This is beyond Claws'
and Dillo's capabilities.  I have to use a real browser, log into
that particular web mail account (like gmail), click on that
particular email, etc. to do so.

I'm getting the sense that I may not be able to find a client that
can do that.

I don't remember ever getting an emailed form that was anything but
a link to a web page. Who is sending you emailed inline forms?

The ones I respond to are known to me and are legit --
organizations, businesses, government agencies, etc. -- that I do
business with.  To respond, I must switch to a web browser, login to
my email account (like gmail), find that particular email, and
enter the requested data either by keyboard, drop-down menu, buttons,
etc., then SUBMIT it.  This happens all within the email. I never get
forwarded to another web site. I always stay on the web mail page. As
far as I can tell only the data is sent. The email itself is not
replied to.  That is, there's nothing in the "Sent" folder.


Meaning no offense, I doubt it. I have been using email since before Gopher,
and I have literally never received an HTML  email with an embedded form
(that I opened, at least). I find it hard to believe that you get many 
of them.


I think you're getting normal email with a link to a form, but (as you say)
Dillo doesn't let you click the link, so you never realize what it is. Those
"rate us from 1-5" things are normally five different links to the same
online poll, with a parameter telling the page what rating you selected. If
You opened the links in an HTML-aware mailer like Mutt, you could just
select one of those to open the form in a browser.

At least, I would bet money that this is the case, at even odds.

(I must be old. My fingers wanted to type "Dilly".)

--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 21:57:07 -0400
Dan Ritter  wrote:

> Carl Fink wrote: 
> > On 10/25/20 9:17 PM, John Hasler wrote:  
> > > Carl writes:  
> > > > I don't remember ever getting an emailed form that was anything
> > > > but a link to a web page.  
> > > I think that may be what he means.  
> > 
> > Can't be. He refers to having to log into a mail account
> > in the browser. That is never required for these mailed
> > links to forms--the form is not in your mailbox and can't
> > require you to log into GMail or whatever.  
> 
> I think we are all confused and the original questioner needs to 
> provide an example of the very strange email that they want
> to work with.

Okay.  Here's a trivial one to keep it simple:

Recently I went to my bank in person. A few days later I get an HTML
email wanting to know my level of satisfaction for the service I
received: 1 to 10, worse to best. There was a gadget in the email to
enter the number, and a SUBMIT button. That's it. I could view all this
in Claws through the Dillo plugin, but of course nothing is clickable.
So, would have to do the browser thing to respond. Not that I responded.
Too much a bother.

FWIW, all emails I get now from businesses, government agencies,
Windows users, etc. are HTML-based.  Text-based has mostly gone the way
of the dodo.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 20:45:50 -0400
Carl Fink  wrote:

> On 10/25/20 8:28 PM, Patrick Bartek wrote:
> > I'm not referring to viewing HTML emails. I already can do that in
> > Claws-Mail using its Dillo plugin. I'm talking about filling in
> > forms, etc. that are part of the HTML email and sending just the
> > data without "replying" in the normal sense.  This is beyond Claws'
> > and Dillo's capabilities.  I have to use a real browser, log into
> > that particular web mail account (like gmail), click on that
> > particular email, etc. to do so.
> >
> > I'm getting the sense that I may not be able to find a client that
> > can do that.  
> 
> I don't remember ever getting an emailed form that was anything but
> a link to a web page. Who is sending you emailed inline forms?

The ones I respond to are known to me and are legit --
organizations, businesses, government agencies, etc. -- that I do
business with.  To respond, I must switch to a web browser, login to
my email account (like gmail), find that particular email, and
enter the requested data either by keyboard, drop-down menu, buttons,
etc., then SUBMIT it.  This happens all within the email. I never get
forwarded to another web site. I always stay on the web mail page. As
far as I can tell only the data is sent. The email itself is not
replied to.  That is, there's nothing in the "Sent" folder.

This happens often enough now to make having to switch to the browser
instead of being able to respond with my usual email client an annoying
inconvenience. Hence, my search for a new email client.

B 

Re: Replacement Email Client

[David Wright]

On Mon 26 Oct 2020 at 20:48:26 (+), Joe wrote:
> On Mon, 26 Oct 2020 10:10:10 -0400 Greg Wooledge  wrote:
> > On Mon, Oct 26, 2020 at 01:49:05PM +, Curt wrote:
> > > On 2020-10-26, Greg Wooledge  wrote:  
> > > > On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:  
> > > >> he is talking about filling in forms, etc. that are part of the
> > > >> html email. guys, ever heard of the ... html tags?
> > > >> that's what he means.  
> > > >
> > > > But what would the form's Submit action be?  
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > HTML Forms
> > > 
> > > 
> > >   First name:
> > >   
> > >   Last name:
> > >   
> > >   
> > >  
> > > 
> > > If you click the "Submit" button, the form-data will be sent to
> > > a page called "/action_page.php".
> > > 
> > > 
> > >   
> > 
> > Yes, this is exactly my point.
> > 
> > If you've received this form from a WEB SERVER, then /action_page.php
> > refers to a script on that same web server.  Or the equivalent of a
> > script.
> > 
> > But if you're just reading this form in a FILE on your LOCAL MACHINE,
> > which is what email is, then what is /action_page.php supposed to do?
> > 
> 
> And if the full URL is present, will the website not still require a
> login before serving the page?

I don't know anything about the mechanisms that lie behind this, but
I don't think it would be sensible to email a form with an absolute
address on it. What happens when somebody mass emails a form with a
typo in the address, and people send their completed information to
one of these goog1e traps?

Cheers,
David.

Re: Replacement Email Client

[Greg Wooledge]

On Mon, Oct 26, 2020 at 08:48:26PM +, Joe wrote:
> On Mon, 26 Oct 2020 10:10:10 -0400
> Greg Wooledge  wrote:
> > But if you're just reading this form in a FILE on your LOCAL MACHINE,
> > which is what email is, then what is /action_page.php supposed to do?
> > 
> 
> And if the full URL is present, will the website not still require a
> login before serving the page?

Depends on the web page, doesn't it?

I've gotta say here, anyone who responds to an email containing an HTML
form is probably feeding information to spammers.  Even worse, in my
experience most web browsers provide NO way to know what a form's
Submit button does.  There's no mouseover hint or anything.  Not that
mouseover hints are of any use when Javascript is in effect, but that's
a different dead horse.

Re: Replacement Email Client

[Joe]

On Mon, 26 Oct 2020 10:10:10 -0400
Greg Wooledge  wrote:

> On Mon, Oct 26, 2020 at 01:49:05PM +, Curt wrote:
> > On 2020-10-26, Greg Wooledge  wrote:  
> > > On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:  
> > >> he is talking about filling in forms, etc. that are part of the
> > >> html email. guys, ever heard of the ... html tags?
> > >> that's what he means.  
> > >
> > > But what would the form's Submit action be?  
> > 
> > 
> > 
> > 
> > 
> > 
> > HTML Forms
> > 
> > 
> >   First name:
> >   
> >   Last name:
> >   
> >   
> >  
> > 
> > If you click the "Submit" button, the form-data will be sent to
> > a page called "/action_page.php".
> > 
> > 
> >   
> 
> Yes, this is exactly my point.
> 
> If you've received this form from a WEB SERVER, then /action_page.php
> refers to a script on that same web server.  Or the equivalent of a
> script.
> 
> But if you're just reading this form in a FILE on your LOCAL MACHINE,
> which is what email is, then what is /action_page.php supposed to do?
> 

And if the full URL is present, will the website not still require a
login before serving the page?

-- 
Joe

Re: Replacement Email Client

[Curt]

On 2020-10-26, Jeremy Nicoll  wrote:
> On Mon, 26 Oct 2020, at 13:49, Curt wrote:
>> On 2020-10-26, Greg Wooledge  wrote:
>
>> > But what would the form's Submit action be?
>
>> HTML Forms
>> 
>> 
>
> ... which works fine when someone is browsing a page served by some 
> website's own server... as that partial URL points to a php file which is
> part of the website concerned.

 
 
 

?

> But the point that Greg is making (I assume) is that if you view an html file
> that was part of an email, in a browser, that "/action_page" will not 
> point
> anywhere sensible unless it contains a full URL.
>


-- 

Re: Replacement Email Client

[Jeremy Nicoll]

On Mon, 26 Oct 2020, at 13:49, Curt wrote:
> On 2020-10-26, Greg Wooledge  wrote:

> > But what would the form's Submit action be?

> HTML Forms
> 
> 

... which works fine when someone is browsing a page served by some 
website's own server... as that partial URL points to a php file which is
part of the website concerned.

But the point that Greg is making (I assume) is that if you view an html file
that was part of an email, in a browser, that "/action_page" will not point
anywhere sensible unless it contains a full URL.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Replacement Email Client

[Linux-Fan]

Greg Wooledge writes:


On Mon, Oct 26, 2020 at 01:49:05PM +, Curt wrote:
> On 2020-10-26, Greg Wooledge  wrote:
> > On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:
> >> he is talking about filling in forms, etc. that are part of the html  
email.
> >> guys, ever heard of the ... html tags? that's what he means.
> >
> > But what would the form's Submit action be?
>
>
> 
> 
> 
>
> HTML Forms
>
> 
>   First name:
>   
>   Last name:
>   
>   
> 
>
> If you click the "Submit" button, the form-data will be sent to a page  
> called "/action_page.php".

>
> 
> 

Yes, this is exactly my point.

If you've received this form from a WEB SERVER, then /action_page.php
refers to a script on that same web server.  Or the equivalent of a
script.

But if you're just reading this form in a FILE on your LOCAL MACHINE,
which is what email is, then what is /action_page.php supposed to do?


In an e-mail form one would expect the `action` to point to an absolute URL.  
Consider this example (derived from above):




Absolute URL form test

https://www.google.com/search"; method="GET">
 Search Query:
 
 




Works independently of where the file is stored and could thus also run  
inside an e-mail client.


HTH
Linux-Fan

öö


pgpeCNz8p4K3t.pgp
Description: PGP signature

Re: Replacement Email Client

[Greg Wooledge]

On Mon, Oct 26, 2020 at 01:49:05PM +, Curt wrote:
> On 2020-10-26, Greg Wooledge  wrote:
> > On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:
> >> he is talking about filling in forms, etc. that are part of the html email.
> >> guys, ever heard of the ... html tags? that's what he means.
> >
> > But what would the form's Submit action be?
> 
> 
> 
> 
> 
> 
> HTML Forms
> 
> 
>   First name:
>   
>   Last name:
>   
>   
>  
> 
> If you click the "Submit" button, the form-data will be sent to a page 
> called "/action_page.php".
> 
> 
> 

Yes, this is exactly my point.

If you've received this form from a WEB SERVER, then /action_page.php
refers to a script on that same web server.  Or the equivalent of a
script.

But if you're just reading this form in a FILE on your LOCAL MACHINE,
which is what email is, then what is /action_page.php supposed to do?

Re: Replacement Email Client

[Curt]

On 2020-10-26, Greg Wooledge  wrote:
> On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:
>> he is talking about filling in forms, etc. that are part of the html email.
>> guys, ever heard of the ... html tags? that's what he means.
>
> But what would the form's Submit action be?






HTML Forms


  First name:
  
  Last name:
  
  
 

If you click the "Submit" button, the form-data will be sent to a page 
called "/action_page.php".

Re: Replacement Email Client

[Michael]

hey,

On Monday, October 26, 2020 12:57:18 PM CET, Greg Wooledge wrote:

But what would the form's Submit action be?


no idea. and i don't care. ask him...
i am not defending his desire using forms in an email client, i am just 
trying to translate what i think he wants.


but to answer your question:
afair, an html form usually initiates a post request with the contents of 
the form fields. so probably an external browser would be opened issueing 
that post request, if that's even possible. i don't know.
but a  submits a get request, which should work... not 
sure about this.


greetings...

Re: Replacement Email Client

[Greg Wooledge]

On Mon, Oct 26, 2020 at 12:38:36PM +0100, Michael wrote:
> he is talking about filling in forms, etc. that are part of the html email.
> guys, ever heard of the ... html tags? that's what he means.

But what would the form's Submit action be?

Re: Replacement Email Client

[Michael]

hey,

On Monday, October 26, 2020 2:57:07 AM CET, Dan Ritter wrote:
Carl Fink wrote: 
I think we are all confused and the original questioner needs to 
provide an example of the very strange email that they want

to work with.


really?

i think it's pretty clear what he wants:

On Monday, October 26, 2020 1:28:48 AM CET, Patrick Bartek wrote:

I'm not referring to viewing HTML emails.  I already can do that in
Claws-Mail using its Dillo plugin. I'm talking about filling in forms,
etc. that are part of the HTML email and sending just the data without
"replying" in the normal sense.


slowly:


I'm not referring to viewing HTML emails


his point is not to simply be able to 'view' html mails

I already can do that in Claws-Mail using its Dillo plugin. 


he can already do that in claws-mail using its dillo plugin


I'm talking about filling in forms, etc. that are part of the HTML email
[...]

he is talking about filling in forms, etc. that are part of the html email.
guys, ever heard of the ... html tags? that's what he means.


[...] and sending just the data without "replying" in the normal sense
he wants an email client that displays html email _with forms_ and fill in 
these forms _within the email client_, and send the data by clicking some 
kind of 'submit' button _within the email client_.


correct me, if i'm wrong...

greetings...

Re: Replacement Email Client

[tomas]

On Sun, Oct 25, 2020 at 05:07:05PM -0700, Patrick Bartek wrote:

[...]

> [...] One cannot interact and transmit data as I need to.

I think this is the core of the problem. Up to now you haven't taken
up the job to specify what that means: in the context of the Web, this
covers a broad field:

 - if it's the traditional GET/POST dance, possibly slinging around
   a couple of cookies, I'm pretty sure Dillo is up to the task;

 - if it involves Javascript (and many pages do, the stupid Web
   frameworks nearly force developers to!), then I don't know
   whether Dillo has a Javascript engine built in (if it has, I
   guess it is borrowed from somewhere, because no "normal" entity
   is able to survive the arm's race imposed by Da Googla (heck,
   even Microsoft gave in). But then, you're into full-grown
   Web browser territory anyway.

As it stands, your request reminds me of those customer requirements
à la "it has to work exactly as application X". It's a starting point,
but if the customer and me don't manage to advance significantly from
there, I usually decline the gig.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Replacement Email Client

[mick crane]

On 2020-10-26 00:07, Patrick Bartek wrote:
 I have Dillo configured NOT to show images initially. Do that for

security. Reloading page usually brings them up. It will follow some
links to other pages, but for viewing purposes only. One cannot
interact and transmit data as I need to.  I have to use a real browser
for that. And that means logging in through the browser to that
particular email account.


I think this is what is confusing people ( having to logon to gmail to 
see the HTML)
The email you receive has the text and the HTML stored as a file on your 
computer.

You organise the mail reader to process the HTML or not.
I don't know why everybody doesn't use Dovecot/Dovecot-sieve/roundcube 
=o)


mick

--
Key ID4BFEBB31

Re: Replacement Email Client

[John Conover]

Patrick Bartek writes:
> On Sun, 25 Oct 2020 14:07:00 -0500
> John Hasler  wrote:
> 
> > Patrick Bartek writes:
> > > But I need to view the entire email: images, graphics, etc. and be
> > > able to interact with all the links, etc. and not just view them.
> > > Want to get away from having to login to the mail account with a
> > > browser to do so.  So, EMACS won't work for me.  
> > 
> > Log in to what mail account?  Gnus calls the browser and passes the
> > HTML attachment to it.  No logging in involved.
> 
> I'm not referring to viewing HTML emails.  I already can do that in
> Claws-Mail using its Dillo plugin. I'm talking about filling in forms,
> etc. that are part of the HTML email and sending just the data without
> "replying" in the normal sense.  This is beyond Claws' and Dillo's
> capabilities.  I have to use a real browser, log into that particular
> web mail account (like gmail), click on that particular email, etc. to
> do so.
> 
> I'm getting the sense that I may not be able to find a client that can
> do that.
>

I'm just guessing, but Thunderbird's Preferences->General "Files &
Attachments" section should read something like "https Use Google
Chrome (default)", or whatever.

Mine does, and an HTML email calls chrome as a separate process with
the HTML email, (I did not attempt a reply after editing.)

My wife's Thunderbird has nothing in the Content Type section of
"Files & Attachments", and does not call chrome for the same email,
(and I could not find any way of making changes there, and
antagonizing Google didn't yield a way to do it, either-anyone know?)

Maybe ~/.mailcap, (and refresh via update-mime --local)?

Or maybe something in /etc/alternatives/*.

Or maybe some other riddle.

John

-- 

John Conover, cono...@rahul.net, http://www.johncon.com/

Re: Replacement Email Client

[Dan Ritter]

Carl Fink wrote: 
> On 10/25/20 9:17 PM, John Hasler wrote:
> > Carl writes:
> > > I don't remember ever getting an emailed form that was anything but a
> > > link to a web page.
> > I think that may be what he means.
> 
> Can't be. He refers to having to log into a mail account
> in the browser. That is never required for these mailed
> links to forms--the form is not in your mailbox and can't
> require you to log into GMail or whatever.

I think we are all confused and the original questioner needs to 
provide an example of the very strange email that they want
to work with.

-dsr-

Re: Replacement Email Client

[Carl Fink]

On 10/25/20 9:17 PM, John Hasler wrote:

Carl writes:

I don't remember ever getting an emailed form that was anything but a
link to a web page.

I think that may be what he means.


Can't be. He refers to having to log into a mail account
in the browser. That is never required for these mailed
links to forms--the form is not in your mailbox and can't
require you to log into GMail or whatever.

--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Replacement Email Client

[John Hasler]

Carl writes:
> I don't remember ever getting an emailed form that was anything but a
> link to a web page.

I think that may be what he means.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replacement Email Client

[Carl Fink]

On 10/25/20 8:28 PM, Patrick Bartek wrote:

I'm not referring to viewing HTML emails. I already can do that in
Claws-Mail using its Dillo plugin. I'm talking about filling in forms,
etc. that are part of the HTML email and sending just the data without
"replying" in the normal sense.  This is beyond Claws' and Dillo's
capabilities.  I have to use a real browser, log into that particular
web mail account (like gmail), click on that particular email, etc. to
do so.

I'm getting the sense that I may not be able to find a client that can
do that.


I don't remember ever getting an emailed form that was anything but
a link to a web page. Who is sending you emailed inline forms?
--
Carl Fink   nitpick...@nitpicking.com

Read my blog at blog.nitpicking.com.  Reviews!  Observations!

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 14:07:00 -0500
John Hasler  wrote:

> Patrick Bartek writes:
> > But I need to view the entire email: images, graphics, etc. and be
> > able to interact with all the links, etc. and not just view them.
> > Want to get away from having to login to the mail account with a
> > browser to do so.  So, EMACS won't work for me.  
> 
> Log in to what mail account?  Gnus calls the browser and passes the
> HTML attachment to it.  No logging in involved.

I'm not referring to viewing HTML emails.  I already can do that in
Claws-Mail using its Dillo plugin. I'm talking about filling in forms,
etc. that are part of the HTML email and sending just the data without
"replying" in the normal sense.  This is beyond Claws' and Dillo's
capabilities.  I have to use a real browser, log into that particular
web mail account (like gmail), click on that particular email, etc. to
do so.

I'm getting the sense that I may not be able to find a client that can
do that.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 11:42:20 -0700 (PDT)
didier gaumet  wrote:

> Le dimanche 25 octobre 2020 à 19:00:08 UTC+1, Patrick Bartek a écrit :
> 
> > Already have Dillo set up, but I need more than a viewer. I want a 
> > client that handles HTML as well as plain text emails, so I don't
> > have to login into the mail account via a browser to interact with
> > the email.  
> 
> I just tested the dillo plugin: I do not know if it is sufficient for
> your usage but after setting the plugin up, I was able to click on
> the links into the emails and most (not all) images were displayed

I have Dillo configured NOT to show images initially. Do that for
security. Reloading page usually brings them up. It will follow some
links to other pages, but for viewing purposes only. One cannot
interact and transmit data as I need to.  I have to use a real browser
for that. And that means logging in through the browser to that
particular email account.

> [...]
> > I installed Balsa in Devuan Beowulf which I'm testing, and it only 
> > installed a few libraries. Don't know if the same is true with
> > Buster. I'm still evaluating it. No opinion as yet. Wasn't able to
> > get it to receive mails, but could send. Probably an erroneous
> > setting somewhere. It was late.   
> 
> Just tested Balsa here (Buster+Gnome): I could read my emails but
> HTML was not rendered

Probably a missed setting somewhere.  But the more I look at Balsa, the
more I think it's just, for all practical purposes, a clone of
Claws-Mail.  I could be wrong.  We'll see.  Installing it for the third
try after purging it twice.

> If Claws HTML  rendering with the Dillo plugin is not satisfying
> enough for you, I fear you will need a heavy client like Thunderbird,
> Evolution or Kmail...

Oh, I hope not!!

B 

Re: Replacement Email Client

[Charles Curley]

On Sun, 25 Oct 2020 20:31:16 +
"Jeremy Nicoll"  wrote:

> I think there's a difference between a mail which has an html copy of 
> plain text, where images etc that might be required for the html page 
> can be fetched from servers - in that case a browser will be able to 
> display the page well ... and emails which contain html and a set of 
> associated image attachments.
> 
> In the latter case, just dumping the html into a temporary file and 
> pointing a browser at it won't also give the browser access to the
> associated images, unless (I suppose) a folder full of images are
> passed to the browser as well as the html page, AND the image 
> references inside the html somehow are modified from whatever
> would have worked inside an email client, so that they browser 
> can pick up the images in the folder.

Interesting. I don't recall seeing any of the latter, but then I
usually use claws-mail's built in HTML viewer, which strips images from
HTML emails before displaying them.

(Many email blasts use images from a server, with an especially encoded
URL, so that the sender knows exactly when the recipient opened the
email. That is one one of several reasons I don't load images.)

> 
> By "logging-in", I guess the OP is referring to using a webmail system
> where the webmail server presents an integrated view of the html page
> and the unpacked embedded attached images.

Ah. He abandons claws-mail entirely, and views the email on gmail (the
account from which he posts is a gmail account) in his browser. Yes,
that would be a PITA. I'd like to hear that from him before I
conjecture further.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Replacement Email Client

[Jeremy Nicoll]

On Sun, 25 Oct 2020, at 20:18, Charles Curley wrote:
 
> Indeed, same as claws-mail. M. Bartek is using claws-mail now, and
> wants to get away from it because he doesn't want to log in to the mail
> account? I'm not following, either.

I think there's a difference between a mail which has an html copy of 
plain text, where images etc that might be required for the html page 
can be fetched from servers - in that case a browser will be able to 
display the page well ... and emails which contain html and a set of 
associated image attachments.

In the latter case, just dumping the html into a temporary file and 
pointing a browser at it won't also give the browser access to the
associated images, unless (I suppose) a folder full of images are
passed to the browser as well as the html page, AND the image 
references inside the html somehow are modified from whatever
would have worked inside an email client, so that they browser 
can pick up the images in the folder.

By "logging-in", I guess the OP is referring to using a webmail system
where the webmail server presents an integrated view of the html page
and the unpacked embedded attached images.

-- 
Jeremy Nicoll - my opinions are my own.

Re: Replacement Email Client

[Charles Curley]

On Sun, 25 Oct 2020 14:07:00 -0500
John Hasler  wrote:

> Patrick Bartek writes:
> > But I need to view the entire email: images, graphics, etc. and be
> > able to interact with all the links, etc. and not just view them.
> > Want to get away from having to login to the mail account with a
> > browser to do so.  So, EMACS won't work for me.  
> 
> Log in to what mail account?  Gnus calls the browser and passes the
> HTML attachment to it.  No logging in involved.

Indeed, same as claws-mail. M. Bartek is using claws-mail now, and
wants to get away from it because he doesn't want to log in to the mail
account? I'm not following, either.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Replacement Email Client

[황병희]

> Any suggestions?  

Surprisingly, Gnus handle very well HTML emails.

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _和合團結_ 감사합니다_^))//

Re: Replacement Email Client

[John Hasler]

Patrick Bartek writes:
> But I need to view the entire email: images, graphics, etc. and be
> able to interact with all the links, etc. and not just view them.
> Want to get away from having to login to the mail account with a
> browser to do so.  So, EMACS won't work for me.

Log in to what mail account?  Gnus calls the browser and passes the HTML
attachment to it.  No logging in involved.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replacement Email Client

[didier gaumet]

Le dimanche 25 octobre 2020 à 19:00:08 UTC+1, Patrick Bartek a écrit :

> Already have Dillo set up, but I need more than a viewer. I want a 
> client that handles HTML as well as plain text emails, so I don't have 
> to login into the mail account via a browser to interact with the email.

I just tested the dillo plugin: I do not know if it is sufficient for your 
usage but after setting the plugin up, I was able to click on the links into 
the emails and most (not all) images were displayed

[...]
> I installed Balsa in Devuan Beowulf which I'm testing, and it only 
> installed a few libraries. Don't know if the same is true with Buster. 
> I'm still evaluating it. No opinion as yet. Wasn't able to get it to 
> receive mails, but could send. Probably an erroneous setting somewhere. 
> It was late. 

Just tested Balsa here (Buster+Gnome): I could read my emails but HTML was not 
rendered

If Claws HTML  rendering with the Dillo plugin is not satisfying enough for 
you, I fear you will need a heavy client like Thunderbird, Evolution or Kmail...

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 13:10:04 +0100
Michael  wrote:

> On Sunday, October 25, 2020 1:04:00 AM CEST, Patrick Bartek wrote:
> 
> > Any suggestions?
> 
> since this is a debian user mailinglist, my answer will be slightly
> off topic.
> 
> but i use 'trojita' (https://trojita.flaska.net) as a pure and simple
> imap based email client. but it is not in the debian repositories.

I've heard of it.  Haven't researched it.

> it does only one thing: handling email of one single imap account,
> but it does it well enough for me, so i stick with it. i don't like
> the other bloatware out there (kmail, thunderbird, claws-mail, etc.).

I have multiple imap email accounts.  If it can only handle a single
account, will be unsuitable.

> maybe it's worth a shot. ymmv
> 
>

Thanks

B

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 01:51:43 -0700 (PDT)
didier gaumet  wrote:

> Le dimanche 25 octobre 2020 à 01:10:06 UTC+2, Patrick Bartek a écrit :
> > Hi! All, 
> > 
> > Looking for recommendations for a lightweight email client that
> > will handle HTML as well as plain text to replace Claws-Mail. Have
> > been using Claws-Mail for years and before it Sylpheed. Claws used
> > to have a basic HTML plugin renderer which was sufficient, but
> > latest version does not.   
> 
> It seems that in the past, Debian provided the
> claws-mail-fancy-plugin package (a GTK2 HTML viewer). That is no
> longer the case but Debian is now providing  the
> claws-mail-dillo-viewer (a Dillo HTML viewer), and in addition to

Already have Dillo set up, but I need more than a viewer.  I want a
client that handles HTML as well as plain text emails, so I don't have
to login into the mail account via a browser to interact with the email.


> this, from Bulleye on, will be providing the
> claws-mail-litehtml-viewer package (a HTML viewer based on the
> litehml library).
> https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=all&keywords=claws+html
> 
> So, apparently, you do not need to replace claws-mail

Probably, I do.  Just a viewer plugin is insufficient.  Been using
viewers for years.  Time to move on.  Or, maybe, an interactive HTML
interpreter plugin?

> [...]
> > Both Thunderbird and Balsa have been rejected as T'bird is a
> > behemoth and no longer in development; and with Balsa, I don't want
> > to have to deal with GNOME-systemd, etc. dependencies. (I don't run
> > GNOME anyway, only a window manager Openbox, and use sysvinit and
> > not systemd as init.)   
> [...]
> 
> - As others have already stated, Thunderbird is still in development
> - I somewhat doubt installing Balsa will draw on any real Gnome or
> Systemd stuff
> https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=names&keywords=balsa

I installed Balsa in Devuan Beowulf which I'm testing, and it only
installed a few libraries.  Don't know if the same is true with Buster.
I'm still evaluating it. No opinion as yet. Wasn't able to get it to
receive mails, but could send. Probably an erroneous setting somewhere.
It was late.

Thanks for your input.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 07:19:28 +0200
Teemu Likonen  wrote:

> * 2020-10-24 16:04:00-07, Patrick Bartek wrote:
> 
> > Looking for recommendations for a lightweight email client that will
> > handle HTML as well as plain text to replace Claws-Mail.  Have been
> > using Claws-Mail for years and before it Sylpheed.  
> 
> GNU Emacs mail clients "Gnus" and "Notmuch Emacs" automatically render
> HTML mail nicely as plain text. User can can also open HTML and other
> MIME parts in external viewer like web browser.
> 

I can already view the text of HTML emails with Claws-Mail.  But I need
to view the entire email: images, graphics, etc. and be able to interact
with all the links, etc. and not just view them.  Want to get away from
having to login to the mail account with a browser to do so.  So, EMACS
won't work for me.

Thanks for your suggestion.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 05:55:02 +0100
Oliver Schoede  wrote:

> On Sat, 24 Oct 2020 16:04:00 -0700
> Patrick Bartek  wrote:
> 
> >
> >Looking for recommendations for a lightweight email client that will
> >handle HTML as well as plain text to replace Claws-Mail.  Have been
> >using Claws-Mail for years and before it Sylpheed.  Claws used to
> >have a basic HTML plugin renderer which was sufficient, but latest
> >version does not.  
> 
> I didn't even know it was gone, but apparently 3.17.7 just
> (re)introduced a light viewer duly taking care of people who need it.
> LiteHTML. It's packaged as claws-mail-litehtml-viewer, can't say if
> it's any good, there are other options though. Even something
> based on Dillo! ;) Not bad for a project with a different set of
> priorities. Don't like a plugin? Feeling more like using behemoth
> Firefox ('hate accessing mail through a browser'):
> 
> Config -> Preferences -> Message View -> External Programs
> 
> [snip]

I need more than just an HTML viewer.  I have dillo set up for that. It
is the default with the install. I need to be able to interact with the
HTML email without having to login via a browser to do so which I've
grown tired of.

Thanks for your reply.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sat, 24 Oct 2020 21:52:54 -0400
Gene Heskett  wrote:

> On Saturday 24 October 2020 19:04:00 Patrick Bartek wrote:
> 
> > Hi! All,
> >
> > Looking for recommendations for a lightweight email client that will
> > handle HTML as well as plain text to replace Claws-Mail.  Have been
> > using Claws-Mail for years and before it Sylpheed.  Claws used to
> > have a basic HTML plugin renderer which was sufficient, but latest
> > version does not. And I'm getting more and more important emails in
> > HTML where just the plain text is insufficient to fully read the
> > email.  That is, text in (or as) images contain some (or much) of
> > the content, etc. Also, hate accessing email through a browser. So
> > that option is out.
> >
> > Both Thunderbird and Balsa have been rejected as T'bird is a
> > behemoth and no longer in development; and with Balsa, I don't want
> > to have to deal with GNOME-systemd, etc. dependencies. (I don't run
> > GNOME anyway, only a window manager Openbox, and use sysvinit and
> > not systemd as init.)
> >
> > Any suggestions?
> >  
> Yes, kmail, as supplied NOT from KDE but from TDE. Its the older
> 

I'll look into it.

B

Re: Replacement Email Client

[Patrick Bartek]

On Sat, 24 Oct 2020 19:50:14 -0500
Leslie Rhorer  wrote:

> On 10/24/2020 6:04 PM, Patrick Bartek wrote:
> > 
> > Hi! All,
> > 
> > Looking for recommendations for a lightweight email client that will
> > handle HTML as well as plain text  
> 
>   I want to know that, myself.
> 
> > deal with GNOME-systemd, etc. dependencies. (I don't run GNOME
> > anyway, only a window manager Openbox, and use sysvinit and not
> > systemd as  
> 
>   I don't run Gnome, either, but I did take the plunge and
> learn enough about systemd to get along.  I still don't like it, and
> it remains a very obtuse system designed to do things that fail to
> impress me.  It seems it may be inevitable to become universal.
> 

As long as there are those who don't want systemd, someone out there
will fill that need. That's why Devuan exists (and some others).

I've been testing Devuan Beowulf (Buster) with the Openbox window
manager (my normal configuration) for several weeks now and it's stable,
has all the apps that Debian does. Works just fine without systemd. So,
it can be done. Time will tell.

B 

Re: Replacement Email Client

[Patrick Bartek]

On Sun, 25 Oct 2020 17:22:35 +1100
Keith Bainbridge  wrote:

> On 25/10/20 12:52 pm, Gene Heskett wrote:
> > Both Thunderbird and Balsa have been rejected as T'bird is a
> > behemoth and no longer in development;  
> 
> 
> Um.   Why then am I getting new versions every few weeks?
> Currently 83.0a1.  Sure it's bigger than claws, but many processes are
> easier in day to day operation.

Mozilla has ceased the development; however, it is still "supported" --
security, bug fixes? -- but privately.  Maybe, a group other than
Mozilla has taken over development.  Don't know.

B

Re: Replacement Email Client

[David Wright]

On Sun 25 Oct 2020 at 07:47:33 (+), Ed wrote:
> On 2020-10-24 19:35-0400, Dan Ritter wrote:
> > > Any suggestions?  
> > 
> > mutt, with a mailcap that includes:
> 
> +1 for mutt.
> 
> > X-Message-Flag: Cannot contact reaper.nsa.gov. Trying bucket.cia.gov..
> > X-Clacks-Overhead: GNU Terry Pratchett
> 
> Thanks for the laugh :) but not sure which client you're using ...
> 
> > that gets you a fast, sane mail client which will pop a message into
> > Firefox should you want to view it that way. (Hit "v" while looking
> > at the normal version of the message.  Nothing is going to render HTML
> > better than a browser.
> 
> True. But something makes me itchy about loading spam HTML from 
> anywhere, especially if it is one of those ransomware mails.

You could consider changing the line suggested for mailcap to

  text/html; /usr/bin/lynx -force-html -localhost -stdin

This will render the HTML when desired, and you can list the links,
but they can't be followed.

Cheers,
David.

Re: Replacement Email Client

[Dan Ritter]

Dan Ritter wrote: 
> Ed wrote: 
> > On 2020-10-24 19:35-0400, Dan Ritter wrote:
> > > mutt, with a mailcap that includes:
> > 
> > +1 for mutt.
> > 
> > > X-Message-Flag: Cannot contact reaper.nsa.gov. Trying bucket.cia.gov..
> > > X-Clacks-Overhead: GNU Terry Pratchett
> > 
> > Thanks for the laugh :) but not sure which client you're using ...
>  
> I'm using mutt on desktops and laptops, K9 on Android devices,
> and once in a great while Rainloop for some very particular
> situations.

Oh, and the X-Message-Flag: does absolutely nothing on most mail
clients, but Outlook will (or used to) scroll that header across the
bottom of the window when reading the message.

I haven't had an outraged email in a year or two; maybe they've
finally plugged that? Come to think of it, I got the attention
of someone senior working at Microsoft in that last bout.

-dsr-

Re: Replacement Email Client

[Dan Ritter]

Ed wrote: 
> On 2020-10-24 19:35-0400, Dan Ritter wrote:
> > > Any suggestions?  
> > 
> > mutt, with a mailcap that includes:
> 
> +1 for mutt.
> 
> > X-Message-Flag: Cannot contact reaper.nsa.gov. Trying bucket.cia.gov..
> > X-Clacks-Overhead: GNU Terry Pratchett
> 
> Thanks for the laugh :) but not sure which client you're using ...
 
I'm using mutt on desktops and laptops, K9 on Android devices,
and once in a great while Rainloop for some very particular
situations.

> > that gets you a fast, sane mail client which will pop a message into
> > Firefox should you want to view it that way. (Hit "v" while looking
> > at the normal version of the message.  Nothing is going to render HTML
> > better than a browser.
> 
> True. But something makes me itchy about loading spam HTML from 
> anywhere, especially if it is one of those ransomware mails.

And that should make you itchy, yes. w3m or lynx are a better
choice there.

-dsr-

Re: Replacement Email Client

[tomas]

On Sun, Oct 25, 2020 at 08:34:52AM -0500, John Hasler wrote:
> Teemu Likonen writes: 
> > GNU Emacs mail clients "Gnus" and "Notmuch Emacs" automatically render
> > HTML mail nicely as plain text. User can can also open HTML and other
> > MIME parts in external viewer like web browser.
> 
> I thought of suggesting Gnus as well, but that usually results in
> horrified outcries of "Eww! Emacs!"

But only from know-nothings :)

Cheers
 - t


signature.asc
Description: Digital signature

Re: Replacement Email Client

[John Hasler]

Teemu Likonen writes: 
> GNU Emacs mail clients "Gnus" and "Notmuch Emacs" automatically render
> HTML mail nicely as plain text. User can can also open HTML and other
> MIME parts in external viewer like web browser.

I thought of suggesting Gnus as well, but that usually results in
horrified outcries of "Eww! Emacs!"
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: Replacement Email Client

[Michael]

On Sunday, October 25, 2020 1:04:00 AM CEST, Patrick Bartek wrote:

Any suggestions?  


since this is a debian user mailinglist, my answer will be slightly off 
topic.


but i use 'trojita' (https://trojita.flaska.net) as a pure and simple imap 
based email client. but it is not in the debian repositories.


it does only one thing: handling email of one single imap account, but it 
does it well enough for me, so i stick with it. i don't like the other 
bloatware out there (kmail, thunderbird, claws-mail, etc.).


maybe it's worth a shot. ymmv

but, as with any software, there are also some negative aspects:
- state of development ist unclear (to me)
- as is any kind of support
- it is based on qt, so you will need rudimentary qt support
- reloading a complete mailbox with >100,000 messages results in a crash 
most of the time


greetings...

Re: Replacement Email Client

[ed]

On 2020-10-25 01:51-0700, didier gaumet wrote:
> It seems that in the past, Debian provided the claws-mail-fancy-plugin 
> package (a GTK2 HTML viewer).
> That is no longer the case but Debian is now providing  the 
> claws-mail-dillo-viewer (a Dillo HTML viewer), and in addition to this, from 
> Bulleye on, will be providing the claws-mail-litehtml-viewer package (a HTML 
> viewer based on the litehml library).
>  
> https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=all&keywords=claws+html

Sylpheed/Claws is very good. I did like the way that part of the mail 
could be selected for quoting with the mouse before pressing reply.

I stopped using Claws in favour of mutt some time back as text only mail 
reduced the visible spam, and most spam mail has some image content. 
Valid mail seems to have a good text/plain part, and those that don't 
tend to be readable with a lynx mailcap.

There's also a larger attack surface, if that bothers, with all the 
additional code required for page rendering. The next thing after 
needing to view mail that is HTML based is requiring something that can 
do javascript for some reason for modern web 2.0 compatibility. Heading 
down that route is moving the minimum communication requirements further 
away from people who are visually impaired. There will come a day when 
my eyes start fail me.

This is a preference though, if a GUI reader is required, Sylpheed 
variants seem good.

Ed

Re: Replacement Email Client

[Teemu Likonen]

* 2020-10-25 06:51:36-04, Kenneth Parker wrote:

> On Sun, Oct 25, 2020, 6:40 AM  wrote:
>> alpine

> +1

It would be useful to add some information how the suggested client
(Alpine) serves the purpose that was asked by the original poster.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


signature.asc
Description: PGP signature

Re: Replacement Email Client

[Kenneth Parker]

On Sun, Oct 25, 2020, 6:40 AM  wrote:

> On Sun, 25 Oct 2020, to...@tuxteam.de wrote:
>
> > Any suggestions?
>
> alpine
>

+1

Re: Replacement Email Client

[grumpy]

On Sun, 25 Oct 2020, to...@tuxteam.de wrote:


Any suggestions?


alpine

Re: Replacement Email Client

[didier gaumet]

Le dimanche 25 octobre 2020 à 01:10:06 UTC+2, Patrick Bartek a écrit :
> Hi! All, 
> 
> Looking for recommendations for a lightweight email client that will 
> handle HTML as well as plain text to replace Claws-Mail. Have been 
> using Claws-Mail for years and before it Sylpheed. Claws used to have 
> a basic HTML plugin renderer which was sufficient, but latest version 
> does not. 

It seems that in the past, Debian provided the claws-mail-fancy-plugin package 
(a GTK2 HTML viewer).
That is no longer the case but Debian is now providing  the 
claws-mail-dillo-viewer (a Dillo HTML viewer), and in addition to this, from 
Bulleye on, will be providing the claws-mail-litehtml-viewer package (a HTML 
viewer based on the litehml library).
 
https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=all&keywords=claws+html

So, apparently, you do not need to replace claws-mail

[...]
> Both Thunderbird and Balsa have been rejected as T'bird is a behemoth 
> and no longer in development; and with Balsa, I don't want to have to 
> deal with GNOME-systemd, etc. dependencies. (I don't run GNOME anyway, 
> only a window manager Openbox, and use sysvinit and not systemd as 
> init.) 
[...]

- As others have already stated, Thunderbird is still in development
- I somewhat doubt installing Balsa will draw on any real Gnome or Systemd stuff
 
https://packages.debian.org/search?suite=all§ion=all&arch=any&searchon=names&keywords=balsa

Re: Replacement Email Client

[tomas]

[...]

> > Any suggestions?
> 
> Have you looked at protonmail.com?  Encrypted all over the place.  Web based, 
> though.

Original poster was asking for a client, not for a service.

Much less for a commercial service.

And he clearly stated *not* web based.

Cheers
 - t


signature.asc
Description: Digital signature

Re: Replacement Email Client

[Ed]

On 2020-10-24 19:35-0400, Dan Ritter wrote:
> > Any suggestions?  
> 
> mutt, with a mailcap that includes:

+1 for mutt.

> X-Message-Flag: Cannot contact reaper.nsa.gov. Trying bucket.cia.gov..
> X-Clacks-Overhead: GNU Terry Pratchett

Thanks for the laugh :) but not sure which client you're using ...

> that gets you a fast, sane mail client which will pop a message into
> Firefox should you want to view it that way. (Hit "v" while looking
> at the normal version of the message.  Nothing is going to render HTML
> better than a browser.

True. But something makes me itchy about loading spam HTML from 
anywhere, especially if it is one of those ransomware mails.

Ed

Re: Replacement Email Client

[Keith Bainbridge]

On 25/10/20 12:52 pm, Gene Heskett wrote:

Both Thunderbird and Balsa have been rejected as T'bird is a behemoth
and no longer in development;



Um.   Why then am I getting new versions every few weeks?
Currently 83.0a1.  Sure it's bigger than claws, but many processes are
easier in day to day operation.

--
Keith Bainbridge

ke1thozgro...@gmx.com

Re: Replacement Email Client

[Teemu Likonen]

* 2020-10-24 16:04:00-07, Patrick Bartek wrote:

> Looking for recommendations for a lightweight email client that will
> handle HTML as well as plain text to replace Claws-Mail.  Have been
> using Claws-Mail for years and before it Sylpheed.

GNU Emacs mail clients "Gnus" and "Notmuch Emacs" automatically render
HTML mail nicely as plain text. User can can also open HTML and other
MIME parts in external viewer like web browser.

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450


signature.asc
Description: PGP signature

Re: Replacement Email Client

[Oliver Schoede]

On Sat, 24 Oct 2020 16:04:00 -0700
Patrick Bartek  wrote:

>
>Looking for recommendations for a lightweight email client that will
>handle HTML as well as plain text to replace Claws-Mail.  Have been
>using Claws-Mail for years and before it Sylpheed.  Claws used to have
>a basic HTML plugin renderer which was sufficient, but latest version
>does not.

I didn't even know it was gone, but apparently 3.17.7 just
(re)introduced a light viewer duly taking care of people who need it.
LiteHTML. It's packaged as claws-mail-litehtml-viewer, can't say if
it's any good, there are other options though. Even something
based on Dillo! ;) Not bad for a project with a different set of
priorities. Don't like a plugin? Feeling more like using behemoth
Firefox ('hate accessing mail through a browser'):

Config -> Preferences -> Message View -> External Programs

Not really a new feature either nor scratching CM's surface, but you
surely knew that too. I'm a CLI/TUI/oldskool devotee myself yet Mutt is
one of those things I never got around learning. Takes some time. Only
to fire up FF whenever you want to see a picture. Well I guess people
are different and some always have a browser flinging around anyway. See
what works for you.


Oliver

Re: Replacement Email Client

[Mark Allums]

Both Thunderbird and Balsa have been rejected as T'bird is a behemoth
and no longer in development;
Thunderbird has been spun off from Mozilla, and is actively being 
developed.  The thing is still pretty fat, but they recently added 
support for PGP/GPG encryption built-in.  I wouldn't outright dismiss it 
as a possibility.



Mark

Re: Replacement Email Client

[Gene Heskett]

On Saturday 24 October 2020 19:04:00 Patrick Bartek wrote:

> Hi! All,
>
> Looking for recommendations for a lightweight email client that will
> handle HTML as well as plain text to replace Claws-Mail.  Have been
> using Claws-Mail for years and before it Sylpheed.  Claws used to have
> a basic HTML plugin renderer which was sufficient, but latest version
> does not. And I'm getting more and more important emails in HTML where
> just the plain text is insufficient to fully read the email.  That is,
> text in (or as) images contain some (or much) of the content, etc.
> Also, hate accessing email through a browser. So that option is out.
>
> Both Thunderbird and Balsa have been rejected as T'bird is a behemoth
> and no longer in development; and with Balsa, I don't want to have to
> deal with GNOME-systemd, etc. dependencies. (I don't run GNOME anyway,
> only a window manager Openbox, and use sysvinit and not systemd as
> init.)
>
> Any suggestions?
>
Yes, kmail, as supplied NOT from KDE but from TDE. Its the older kmail 
with all but one bug fixed that KDE never fixed.  That "bug" is the 
number of messages it can store in a given maildir folder has the signed 
32 bit limit or 32766 messages.  On a busy mailing list, it can exceed 
that number of messages in a year, but I've been renaming the folders to 
a subdir incorporating the year for the last 2 years and have had no 
further problems.  Some of my busy and more valuable folders go back to 
2002.

TDE is itself a fork of KDE-3.5, and is still under quite active 
development, yet dead stable. But don't be surprised if you've not 
updated for a week or so, to see synaptic pull in 100 or more updated 
packages if you have the whole R14 release installed. But did I mention 
stable?, this machine, while being kept up to date with all that churn, 
still has a current uptime of 81 days and counting. But I'll not 
recommend it on smaller machines, this is an Asus X370 mainboard with a 
6 core i5, and 32 gigs of ram.

I am running TDE on two machines out of 5 here, the other machine is much 
less well endowed, only a 60GB SSD, and only 2GB of dram. It runs just 
fine but it only has one real job, running a 4 axis milling machine in 
real time.  That it does very well. But it doesn't have a UPS so its 
uptime is about 19 hours as we had a 2 second or less power failure at 
2:30 AM this morning that rebooted the 3 w/o a UPS. Not long enough to 
auto-start my 20kw generator.

> Thanks
>
> B


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: Replacement Email Client

[Leslie Rhorer]

On 10/24/2020 6:04 PM, Patrick Bartek wrote:


Hi! All,

Looking for recommendations for a lightweight email client that will
handle HTML as well as plain text


I want to know that, myself.


deal with GNOME-systemd, etc. dependencies. (I don't run GNOME anyway,
only a window manager Openbox, and use sysvinit and not systemd as


	I don't run Gnome, either, but I did take the plunge and learn enough 
about systemd to get along.  I still don't like it, and it remains a 
very obtuse system designed to do things that fail to impress me.  It 
seems it may be inevitable to become universal.  

Re: Replacement Email Client

[Dan Ritter]

Patrick Bartek wrote: 
> 
> Hi! All,
> 
> Looking for recommendations for a lightweight email client that will
> handle HTML as well as plain text to replace Claws-Mail.  Have been
> using Claws-Mail for years and before it Sylpheed.  Claws used to have
> a basic HTML plugin renderer which was sufficient, but latest version
> does not. And I'm getting more and more important emails in HTML where
> just the plain text is insufficient to fully read the email.  That is,
> text in (or as) images contain some (or much) of the content, etc.
> Also, hate accessing email through a browser. So that option is out.
> 
> Both Thunderbird and Balsa have been rejected as T'bird is a behemoth
> and no longer in development; and with Balsa, I don't want to have to
> deal with GNOME-systemd, etc. dependencies. (I don't run GNOME anyway,
> only a window manager Openbox, and use sysvinit and not systemd as
> init.)
> 
> Any suggestions?  

mutt, with a mailcap that includes:

text/html;  /usr/bin/firefox %s;test=test -n "$DISPLAY"; needsterminal;

and a .muttrc that includes:

auto_view text/html 
alternative_order text/plain text/enriched text/html  

that gets you a fast, sane mail client which will pop a message into
Firefox should you want to view it that way. (Hit "v" while looking
at the normal version of the message.  Nothing is going to render HTML
better than a browser.


-dsr-