Re: Replacement Email Client
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.
Reply to: