Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228171 > unrolled thread

Replacement Email Client

Back to article view | Back to linux.debian.user

Contents

  Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 01:10 +0200
    Re: Replacement Email Client Dan Ritter <dsr@randomstring.org> - 2020-10-25 01:40 +0200
      Re: Replacement Email Client Ed <ed-debian@s5h.net> - 2020-10-25 09:00 +0100
        Re: Replacement Email Client Dan Ritter <dsr@randomstring.org> - 2020-10-25 15:10 +0100
          Re: Replacement Email Client Dan Ritter <dsr@randomstring.org> - 2020-10-25 15:20 +0100
        Re: Replacement Email Client David Wright <deblis@lionunicorn.co.uk> - 2020-10-25 15:20 +0100
    Re: Replacement Email Client Leslie Rhorer <lesrhorer@att.net> - 2020-10-25 02:00 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 18:30 +0100
    Re: Replacement Email Client Gene Heskett <gheskett@shentel.net> - 2020-10-25 03:00 +0100
      Re: Replacement Email Client Keith Bainbridge <ke1thozgroups@gmx.com> - 2020-10-25 07:30 +0100
        Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 16:00 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 18:30 +0100
    Re: Replacement Email Client Mark Allums <maa@allums.com> - 2020-10-25 04:40 +0100
    Re: Replacement Email Client Oliver Schoede <oliver.schode@online.de> - 2020-10-25 06:00 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 18:30 +0100
    Re: Replacement Email Client Teemu Likonen <tlikonen@iki.fi> - 2020-10-25 06:30 +0100
      Re: Replacement Email Client John Hasler <jhasler@newsguy.com> - 2020-10-25 14:40 +0100
        Re: Replacement Email Client <tomas@tuxteam.de> - 2020-10-25 15:00 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 18:40 +0100
        Re: Replacement Email Client John Hasler <jhasler@newsguy.com> - 2020-10-25 20:10 +0100
          Re: Replacement Email Client Charles Curley <charlescurley@charlescurley.com> - 2020-10-25 21:20 +0100
            Re: Replacement Email Client "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-25 21:40 +0100
              Re: Replacement Email Client Charles Curley <charlescurley@charlescurley.com> - 2020-10-25 22:10 +0100
          Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-26 01:30 +0100
            Re: Replacement Email Client Carl Fink <carlf@panix.com> - 2020-10-26 01:50 +0100
              Re: Replacement Email Client John Hasler <jhasler@newsguy.com> - 2020-10-26 02:20 +0100
                Re: Replacement Email Client Carl Fink <carlf@panix.com> - 2020-10-26 02:50 +0100
                  Re: Replacement Email Client Dan Ritter <dsr@randomstring.org> - 2020-10-26 03:00 +0100
                    Re: Replacement Email Client Michael <ml@hemathor.de> - 2020-10-26 12:40 +0100
                      Re: Replacement Email Client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-26 13:00 +0100
                        Re: Replacement Email Client Michael <ml@hemathor.de> - 2020-10-26 13:10 +0100
                        Re: Replacement Email Client Curt <curty@free.fr> - 2020-10-26 15:10 +0100
                          Re: Replacement Email Client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-26 15:20 +0100
                            Re: Replacement Email Client Linux-Fan <Ma_Sys.ma@web.de> - 2020-10-26 15:30 +0100
                            Re: Replacement Email Client Joe <joe@jretrading.com> - 2020-10-26 21:50 +0100
                              Re: Replacement Email Client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-26 22:00 +0100
                              Re: Replacement Email Client David Wright <deblis@lionunicorn.co.uk> - 2020-10-26 22:10 +0100
                          Re: Replacement Email Client "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-26 15:30 +0100
                            Re: Replacement Email Client Curt <curty@free.fr> - 2020-10-26 16:30 +0100
                    Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-26 23:50 +0100
                      Re: Replacement Email Client <tomas@tuxteam.de> - 2020-10-27 09:20 +0100
                        Re: Replacement Email Client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-27 12:50 +0100
              Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-26 23:20 +0100
                Re: Replacement Email Client Carl Fink <carlf@panix.com> - 2020-10-27 02:30 +0100
                  Re: Replacement Email Client Curt <curty@free.fr> - 2020-10-27 10:00 +0100
                  Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-27 21:50 +0100
                    Re: Replacement Email Client Dan Ritter <dsr@randomstring.org> - 2020-10-27 22:10 +0100
                      Re: Replacement Email Client "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-27 23:30 +0100
                        Re: Replacement Email Client David Wright <deblis@lionunicorn.co.uk> - 2020-10-28 05:10 +0100
                          Re: Replacement Email Client "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-28 13:50 +0100
                            Re: Replacement Email Client David Wright <deblis@lionunicorn.co.uk> - 2020-10-29 18:40 +0100
                        Re: Replacement Email Client Eric S Fraga <e.fraga@ucl.ac.uk> - 2020-11-03 10:00 +0100
                    Re: Replacement Email Client conover@rahul.net (John Conover) - 2020-10-28 00:20 +0100
                      Re: Replacement Email Client <tomas@tuxteam.de> - 2020-10-28 09:40 +0100
                        Free-services lead to increased RAM and CPU requirements (was: Re: Replacement Email Client) rhkramer@gmail.com - 2020-10-28 12:20 +0100
                          Re: Free-services lead to increased RAM and CPU requirements (was:  Re: Replacement Email Client) Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-28 12:50 +0100
                          Re: Free-services lead to increased RAM and CPU requirements John Hasler <jhasler@newsguy.com> - 2020-10-28 14:30 +0100
                            Re: Free-services lead to increased RAM and CPU requirements Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-28 16:00 +0100
                              Re: Free-services lead to increased RAM and CPU requirements John Hasler <jhasler@newsguy.com> - 2020-10-28 16:40 +0100
                        Re: Replacement Email Client Joe <joe@jretrading.com> - 2020-10-28 13:30 +0100
                          Re: Replacement Email Client John Hasler <jhasler@newsguy.com> - 2020-10-28 14:40 +0100
                Re: Replacement Email Client Greg Wooledge <wooledg@eeg.ccf.org> - 2020-10-27 12:50 +0100
                  Re: Replacement Email Client Joe <joe@jretrading.com> - 2020-10-27 17:10 +0100
                  Re: Replacement Email Client Joe <joe@jretrading.com> - 2020-10-27 17:20 +0100
                    Re: Replacement Email Client John Hasler <jhasler@newsguy.com> - 2020-10-27 17:40 +0100
                    Re: Replacement Email Client rhkramer@gmail.com - 2020-10-27 20:30 +0100
                      Re: Replacement Email Client Joe <joe@jretrading.com> - 2020-10-27 22:40 +0100
            Re: Replacement Email Client conover@rahul.net (John Conover) - 2020-10-26 06:00 +0100
        Re: Replacement Email Client Eric S Fraga <e.fraga@ucl.ac.uk> - 2020-10-27 14:00 +0100
    Re: Replacement Email Client ghe2001 <ghe2001@pm.me> - 2020-10-25 07:00 +0100
      Re: Replacement Email Client <tomas@tuxteam.de> - 2020-10-25 09:10 +0100
        Re: Replacement Email Client grumpy@mailfence.com - 2020-10-25 11:50 +0100
          Re: Replacement Email Client Kenneth Parker <sea7kenp@gmail.com> - 2020-10-25 12:00 +0100
            Re: Replacement Email Client Teemu Likonen <tlikonen@iki.fi> - 2020-10-25 12:10 +0100
              Re: Replacement Email Client Kenneth Parker <sea7kenp@gmail.com> - 2020-10-28 05:50 +0100
    Re: Replacement Email Client didier gaumet <didier.gaumet@gmail.com> - 2020-10-25 10:20 +0100
      Re: Replacement Email Client ed <ed-debian@s5h.net> - 2020-10-25 12:20 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 19:00 +0100
        Re: Replacement Email Client didier gaumet <didier.gaumet@gmail.com> - 2020-10-25 20:10 +0100
          Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-26 01:10 +0100
            Re: Replacement Email Client mick crane <mick.crane@gmail.com> - 2020-10-26 06:50 +0100
            Re: Replacement Email Client <tomas@tuxteam.de> - 2020-10-26 10:50 +0100
    Re: Replacement Email Client Michael <ml@hemathor.de> - 2020-10-25 13:20 +0100
      Re: Replacement Email Client Patrick Bartek <nemommxiv@gmail.com> - 2020-10-25 19:10 +0100

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#228279

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#228284

On Tue, Oct 27, 2020 at 09:11:42AM +0100, tomas@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.

[toc] | [prev] | [next] | [standalone]

#228267

On Sun, 25 Oct 2020 20:45:50 -0400
Carl Fink <carlf@panix.com> 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 

[toc] | [prev] | [next] | [standalone]

#228277

On 10/26/20 6:16 PM, Patrick Bartek wrote:
> On Sun, 25 Oct 2020 20:45:50 -0400
> Carl Fink <carlf@panix.com> 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                           nitpicking@nitpicking.com

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

[toc] | [prev] | [next] | [standalone]

#228280

On 2020-10-27, Carl Fink <carlf@panix.com> 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)).

[toc] | [prev] | [next] | [standalone]

#228328

On Mon, 26 Oct 2020 21:23:59 -0400
Carl Fink <carlf@panix.com> wrote:

> On 10/26/20 6:16 PM, Patrick Bartek wrote:
> > On Sun, 25 Oct 2020 20:45:50 -0400
> > Carl Fink <carlf@panix.com> 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 <form> 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

[toc] | [prev] | [next] | [standalone]

#228331

Patrick Bartek wrote: 
> On Mon, 26 Oct 2020 21:23:59 -0400
> Carl Fink <carlf@panix.com> wrote:
> 
> I don't know if there is a <form> 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-

[toc] | [prev] | [next] | [standalone]

#228333

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.

[toc] | [prev] | [next] | [standalone]

#228338

On Tue 27 Oct 2020 at 22:22:16 (+0000), 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.

[toc] | [prev] | [next] | [standalone]

#228352

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.

[toc] | [prev] | [next] | [standalone]

#228383

On Wed 28 Oct 2020 at 12:45:49 (+0000), 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.

[toc] | [prev] | [next] | [standalone]

#228436

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

[toc] | [prev] | [next] | [standalone]

#228334

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, conover@rahul.net, http://www.johncon.com/

[toc] | [prev] | [next] | [standalone]

#228343

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

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

On Wednesday, October 28, 2020 04:35:46 AM tomas@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.

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Mi, 28 oct 20, 07:12:19, rhkramer@gmail.com wrote:
> On Wednesday, October 28, 2020 04:35:46 AM tomas@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

[toc] | [prev] | [next] | [standalone]

#228354 — Re: Free-services lead to increased RAM and CPU requirements

rhkramer writes:
> Investigations started in the US congress (and, iirc, in the EC
> counterparts) may lead to de-monopolizing some of those services.

If you are referring to the efforts to gut the DMCA "safe harbor"
provisions that will have the opposite effect.  Same for the efforts to
impose Chinese-style "voluntary" censorship.  These sorts of things
impose large costs which do not scale with the size of the organization.
This will lead to an oligopoly of a few very large heavily regulated
organizations, leading to calls for even more regulation.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#228356 — Re: Free-services lead to increased RAM and CPU requirements

[Multipart message — attachments visible in raw view] — view raw

On Mi, 28 oct 20, 08:26:15, John Hasler wrote:
> rhkramer writes:
> > Investigations started in the US congress (and, iirc, in the EC
> > counterparts) may lead to de-monopolizing some of those services.
> 
> If you are referring to the efforts to gut the DMCA "safe harbor"
> provisions that will have the opposite effect.  Same for the efforts to
> impose Chinese-style "voluntary" censorship.  These sorts of things
> impose large costs which do not scale with the size of the organization.
> This will lead to an oligopoly of a few very large heavily regulated
> organizations, leading to calls for even more regulation.

It seems to me rhkramer is referring to this:
https://www.nytimes.com/2020/10/06/technology/congress-big-tech-monopoly-power.html

(just one of the articles I quickly found via a web search that appears 
to be readable without a subscription)

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

[toc] | [prev] | [next] | [standalone]

#228358 — Re: Free-services lead to increased RAM and CPU requirements

Andrei writes:
> It seems to me rhkramer is referring to this:
> https://www.nytimes.com/2020/10/06/technology/congress-big-tech-monopoly-power.html

So institute regulations forcing Amazon to shut down its "marketplace"
and sell only its own products (or rather ones they purchase: they make
nothing), Facebook to merge its two social media utilities into a single
subsiduary (which would have no effect on what the users see but would
make coordination easier), etc.

Anything to avoid changing the tax laws (i.e., capital gains exemptions
and double taxation) the are the incentive for companies to choose
growth over dividends.
-- 
John Hasler 
jhasler@newsguy.com
Elmwood, WI USA

[toc] | [prev] | [next] | [standalone]

#228351

On Wed, 28 Oct 2020 09:35:46 +0100
<tomas@tuxteam.de> 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

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | linux.debian.user

csiph-web