Re: Going GUI...er
disclaimer: I have not reviewed this thread in its entirety. Grant Edwards wrote on Sat, 2 May 2020 at 12:16:45 EDT in : > _Nobody_ I work with uses an email client that properly displays > plaintext as sent by mutt. ... > Most of my family and friends do almost all of their e-mail on phones. > Plaintext is very hard to read on small screans because it doesn't > re-flow to fit the screen width. Forcing people to read plaintext on > small screens is, IMO, inconsiderate. This is not an attribute of mutt or plaintext. It is an attribute of plaintext with a particular kind of fixed line breaks. Personally, I send mail via mutt and do not place hard line breaks at the end of each line, but effectively send every paragraph as a single very long line. (I often compose using Emacs' M-x visual-line-mode.) I think this is not as good as proper format/flowed, but there seem to be technical difficulties making that work reliably, so it's an OK substitute. > Insisting that the world switch from HTML to plaintext for e-mail is > just tilting at a windmill. I think this view is correct. -- jh...@alum.mit.edu John Hawkinson
Re: Going GUI...er
On Sat, May 02, 2020 at 04:16:45PM -, Grant Edwards wrote: > Insisting that the world switch from HTML to plaintext for e-mail is > just tilting at a windmill. I don't insist that the world switch from HTML to plaintext. I do ask that, at least, compatibility be maintained. (By a similar token, I don't insist that everybody use step-free access, but I do ask that it be provided in as many buildings as possible.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
Il 02 maggio 2020 alle 10:51 Derek Martin ha scritto: > In practice, it isn't really. The obvious "solution" is to render the > message [...] I understand that plain-text vs. html has a (tangential) relevance to the topic at hand, but this link is getting more and more tenuous as the Re:'s pile up. Please consider opening a new thread -F
Re: Going GUI...er
On 2020-05-02, Derek Martin wrote: > On Tue, Apr 28, 2020 at 06:57:14PM +0100, Sam Kuper wrote: >> Moreover, you appear to be committing the logical fallacy called >> "argumentum ad populum" (aka "majoritarianism"). > > No, because accepted practice is determined by the majority (in this > case overwhelmingly so), so it's actually the point, not a logic > fallacy. Indeed. E-mail is like a language. It's defined by everyday usage. To claim that you get to define what's "proper usage", when 99% of the other users disagree with you would make Humpty-Dumpyty pround. I would prefer that everybody in the world used e-mail clients that could handle plaintext. But they don't. _Nobody_ I work with uses an email client that properly displays plaintext as sent by mutt. For a while, I used muttdown to generage mixed/alternatve plaintext and html. That worked very nicely. Now "they" have shut off the Exchange SMTP/IMAP services, so I had to switch to hiri/OWA. [I still write much of my e-mail in markdown and paste the result into hiri/OWA.] Most of my family and friends do almost all of their e-mail on phones. Plaintext is very hard to read on small screans because it doesn't re-flow to fit the screen width. Forcing people to read plaintext on small screens is, IMO, inconsiderate. Insisting that the world switch from HTML to plaintext for e-mail is just tilting at a windmill. -- Grant
Re: Going GUI...er
On Tue, Apr 28, 2020 at 06:57:14PM +0100, Sam Kuper wrote: > > When you're talking about a population of people, who is being > > inconsiderate, those who do what the majority prefer, or the minority > > who have made up their own mind that their way is better despite > > what everyone else does? > > That's a false dichotomy. In practice, it isn't really. The obvious "solution" is to render the message as multipart, but in so doing it looses information--the formatting--which was the point of not using plain text in the first place. And if much of the content is in images, it's much harder to piece together the bits, which is the entire point of using non-ascii mail. That's exactly where we are today, and it's why this thread exists. The obvious solution is no solution at all. You're also counting on the overwhelming majority of e-mail users, who are non-technical, to understand these points and make accommodations, which is impractical and nonsensical, particularly when it is clear to all of them that you, stubbornly clinging to your preferences, is a choice that you've made in the face of (what virtually everyon thinks) are much better choices, and placing an inconvenient burden upon literally the rest of the world for your stubbornness. And that's the essence of the issue. By choosing to use an incapable mail client, you are in a tiny minority of e-mail users, you're causing problems for the overwhelming majority of people who are doing it the normal, accepted way, when you know better, and they don't. You're demanding that those less capable make consessions to your preferences when it would be trivial for you to handle what they sent you by simply choosing one of a myriad of other clients that can do so. Most of them never even heard of Mutt and have no idea there even exist mail clients that can't easily handle the messages they're sending. THAT is SUPREMELY inconsiderate, and your whole argument is stubborn and selfish. And that's why the ascii ribbon campaign died... eventually people realized common practice had moved well past them and they were just wrong. And yes, I continue to use Mutt, and I'm in that tiny cohort. The difference is when there's a breakdown I recognize that *I* am at fault, and I make the necessary accommodations, however begrudgingly. > Moreover, you appear to be committing the logical fallacy called > "argumentum ad populum" (aka "majoritarianism"). No, because accepted practice is determined by the majority (in this case overwhelmingly so), so it's actually the point, not a logic fallacy. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Wed, Apr 29, 2020 at 08:56:16AM -0400, Mark H. Wood wrote: > Two cultures in contact, which do not share customs and manners, can > disengage; they can fight; or they can agree on protocols that they > *will* share, even though the protocols make no sense *within* either > culture. > > So how can the flat-text and rich-text and all-up-graphics cultures > play nicely together, with nobody surrendering and being subjugated by > anybody else? The conventional, mutually acceptable approach has, for years, been as follows: - People who prefer to send plain text emails, or plain text emails with attachments intended to be viewed in software other than the MUA, continue to do so, because this approach is compatible with just about every extant MUA in the world. - People who prefer to send rich-text emails do so as multi-part messages that include a plain text part. (The latter is typically generated automatically from the rich text part by the sender's MUA; e.g. translated from HTML into Markdown, so that *emphasis* makes it through to the plain text version.) For maximum compatibility, no part/attachments should require the recipient's MUA to parse HTML or other files into a graphical representation, because not all MUAs can do this. The difficulty experienced by Derek, IIUC, and also by other people on this list, is that some people in the second culture have stopped following the convention above, and have instead begun sending emails that are compatible only with a restricted subset of not-very-secure MUAs. I realise that in many cases, the people in the second culture who have started doing that have done so unwittingly. For instance, because the developers of their MUA changed the MUA's behaviour so that it no longer sends emails that are compatible with traditional MUAs. (Not by default, anyway, and maybe not at all.) One or more variants of Outlook seem to be particularly at fault here. But the emails those people send are of limited compatibility nonetheless, and cannot be viewed as intended without an increased risk of exposure to spyware/malware. For these reasons, the new behaviour is (in my view) inconsiderate. (Insofar as this shift away from compatibility has been caused by corporate software developers, it is reminiscent of General Motors tearing up the streetcar tracks that they had acquired - "People have cars now. They won't need these old things anymore!" - with little care for people who depended upon streetcars for transportation. Or, to use my other analogy, it would be like a handful of maintenance corporations sending workers to their clients' buildings, unbidden, to remove the wheelchair ramps: "Ramps? They're so last century. Everyone should be using an app!") What's the solution to this inconsiderateness? The first response should be to notify the sender. If the sender fails to correct their (or their MUA's) behaviour to bring it back into universal compatibility, then they should be asked again. If they still fail, then they should be treated as the recipient would treat any other antisocial lout, e.g. given a wide berth. Additionally, if the recipient has a disability and the sender's inconsiderate behaviour renders the sender's emails inaccessible to the recipient (even though the recipient can read compatible emails just fine), then the recipient might, in some jurisdictions, be able to bring a legal case against the sender. (IANAL.) This emphasises the closeness of my second analogy above, about the ramps. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Tue, Apr 28, 2020 at 06:57:14PM +0100, Sam Kuper wrote: > On Thu, Apr 23, 2020 at 03:52:53PM -0500, Derek Martin wrote: [snip] > > which is how you have to define what is considerate. Inconsiderate is > > doing something that is not preferred. That which is least preferred > > is most inconsiderate. > > Again, no. You are conflating two different concepts, as shown by the > following counterexample. In some *urban* subcultures, driving large > 4x4 cars is preferred: > https://www.macmillandictionary.com/buzzword/entries/chelsea-tractor.html > . Yet that is clearly not considerate. I think that there is a simpler argument in here. Abstractions (such as The Majority) do not have preferences; individuals do. At most, it is possible to identify abstractions whose members share certain preferences. So, yes, inconsiderate is doing something that is not preferred, and that which is least preferred is most inconsiderate. This is simple manners. But I want to ask myself: preferred by whom? Each camp has legitimate concerns to which, if we wish to communicate politely, the other camps would do well to make reasonable accommodations. Two cultures in contact, which do not share customs and manners, can disengage; they can fight; or they can agree on protocols that they *will* share, even though the protocols make no sense *within* either culture. So how can the flat-text and rich-text and all-up-graphics cultures play nicely together, with nobody surrendering and being subjugated by anybody else? -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Going GUI...er
On Tue, Apr 28, 2020 at 06:57:14PM +0100, Sam Kuper wrote: > On Thu, Apr 23, 2020 at 03:52:53PM -0500, Derek Martin wrote: >> On Mon, Apr 20, 2020 at 03:49:46PM +0100, Sam Kuper wrote: > If you want to read my emails [...] By which I meant "If you want to read emails that I have sent ...". >>> 2. You said earlier that "If you're talking about historical >>> precedence then time scale very much is the point." But then you >>> said, "I may be off by a few years ... It doesn't really matter." >> >> 2-3 years is a much smaller discrepancy than several millenia. There >> was vastly more precedence for roads being used by non-car things >> than there was widespread e-mail use not involving GUI clients, >> discounting the previously mentioned small fraction of the population >> who are technically-oriented humans, whether it happened in 3 years >> or 6. Thank you for clarifying your meaning here. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Thu, Apr 23, 2020 at 03:52:53PM -0500, Derek Martin wrote: > On Mon, Apr 20, 2020 at 03:49:46PM +0100, Sam Kuper wrote: >> On Fri, Apr 17, 2020 at 06:08:37PM -0500, Derek Martin wrote: >>> On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote: On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: >>> Sorry, but this is an archaic way of looking at the problem. >>> People have been doing this for decades now, has become the >>> norm, common practice, and really it is therefore WE who are >>> being inconsiderate by not accepting de facto standards that >>> have been widely adopted for a very long time. >> >> I disagree. You have made a "roads were built for cars" >> argument*: it assumes that today's "de facto standard" trumps >> historical precedent and considerate behaviour. >>> >>> And by the way, I ignored this point originally, but doesn't it? >> >> No, it doesn't. >> >> Inconsiderate behaviour is by definition inconsiderate. > > When you're talking about a population of people, who is being > inconsiderate, those who do what the majority prefer, or the minority > who have made up their own mind that their way is better despite > what everyone else does? That's a false dichotomy. >> Likewise, the fact that something is currently popular does not make >> it good. > > It does make it *preferred* though, If you mean "preferred" in the sense of "popular", then yes; that's tautological. But if you mean it in the sense of "good", then you seem to have conceded my point. Bad passwords are popular. They are not preferred. > which is how you have to define what is considerate. Inconsiderate is > doing something that is not preferred. That which is least preferred > is most inconsiderate. Again, no. You are conflating two different concepts, as shown by the following counterexample. In some *urban* subcultures, driving large 4x4 cars is preferred: https://www.macmillandictionary.com/buzzword/entries/chelsea-tractor.html . Yet that is clearly not considerate. It is inconsiderate because those cars are less safe than alternatives of similar or lower cost, including alternatives that provide comparable luggage space and legroom, etc. Specifically, the large 4x4s, compared to those other vehicles in those contexts, are less safe for occupants (lower occupant safety scores), for bystanders (lower bystander safety scores), and for the local and global environments (higher emissions of particulate and climate change pollutants). Moreover, you appear to be committing the logical fallacy called "argumentum ad populum" (aka "majoritarianism"). > If you can't agree with that, we may as well stop discussing it. Up to you. I've been trying to respond constructively to your points, because: - on the one hand, I sympathise with your wish to have an email client that is even more capable than Mutt while sacrificing none of Mutt's good qualities; - on the other hand, some of your arguments are unsound, and this undercuts the strength of your case. That said, I'm not sure I'll continue to contribute to this thread. >>> Technological evolution is about as democratic as it gets... >> >> I disagree. Consumption is ultimately constrained by the choices >> available to consumers. > > No, it isn't. If you are skilled, you can obtain resources to make > what you want. First of all, nobody has infinite skill. As for real people: no, they can't necessarily "obtain resources to make what [they] want". They are, as I stated, constrained by the choices available to them. Those constraints include: - the laws of physics. (Counterexample to prove my point: want to travel faster than light? Good luck with that.); - the laws of economics/psychology (Counterexample to prove my point: want people to work for you, when the company next door offers better pay for otherwise the exact same terms and prospects? Good luck with that.); - the resources available to them (Counterexample to prove my point: want to open a public gay bar in your hometown, but you grew up in Riyadh? Good luck with that.). >> If a region's developers and government planners, etc, space houses >> far apart and provide negligible public transport or cycling >> infrastructure but plentiful cars and car-oriented infrastructure, >> cars will predominate there because the region's consumers are >> hampered in pursuing other choices. > > You've just made the case that the roads WERE built for cars. The > ones we have today, anyway. =8^) No. First of all, many of the roads that exist today, in many parts of the world, predate cars. Secondly, many of the other roads that exist today were intended for multiple classes of vehicle. I do belive (and have never denied) that *some* roads were built exclusively for cars, high-speed
Re: Going GUI...er
On Mon, Apr 20, 2020 at 03:49:46PM +0100, Sam Kuper wrote: > On Fri, Apr 17, 2020 at 06:08:37PM -0500, Derek Martin wrote: > > On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote: > >> On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > >>> On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: > On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > > Sorry, but this is an archaic way of looking at the problem. > > People have been doing this for decades now, has become the norm, > > common practice, and really it is therefore WE who are being > > inconsiderate by not accepting de facto standards that have been > > widely adopted for a very long time. > > I disagree. You have made a "roads were built for cars" argument*: > it assumes that today's "de facto standard" trumps historical > precedent and considerate behaviour. > > > > And by the way, I ignored this point originally, but doesn't it? > > No, it doesn't. > > Inconsiderate behaviour is by definition inconsiderate. When you're talking about a population of people, who is being inconsiderate, those who do what the majority prefer, or the minority who have made up their own mind that their way is better despite what everyone else does? > Likewise, the fact that something is currently popular does not make it > good. It does make it *preferred* though, which is how you have to define what is considerate. Inconsiderate is doing something that is not preferred. That which is least preferred is most inconsiderate. If you can't agree with that, we may as well stop discussing it. And if you do agree with that, then I'm clearly correct, and we may as well stop discussing it. =8^) > > Even in the case of cars, which you can argue have had deleterious > > effects on society (but I think there's plenty of support for the > > counter-argument), we got to where we got to because it was what most > > people wanted. Technological evolution is about as democratic as it > > gets... > > I disagree. Consumption is ultimately constrained by the choices > available to consumers. No, it isn't. If you are skilled, you can obtain resources to make what you want. And if there are enough people who want it, you can make it for them to feed their demand. And you can make a very good living doing it. > If a region's developers and government planners, etc, space houses far > apart and provide negligible public transport or cycling infrastructure > but plentiful cars and car-oriented infrastructure, cars will > predominate there because the region's consumers are hampered in > pursuing other choices. You've just made the case that the roads WERE built for cars. The ones we have today, anyway. =8^) > Technological evolution is no more democratic than is a gerrymandered > district rife with vote suppression and dubious publicity. Of course it is. I have dollars. I can spend them on new technology or not. Just because it exists, doesn't mean I must buy it. In that regard, I directly influence what gets made. If no one buys it, that company will cease to exist, and stop making their thing--and another will sprout with a different thing. Rinse and repeat. The things that are the most popular win (get made and sold). That's basically the definition of democracy. I have no direct influence over what gerrymanderers do. The most I can do is vote for whomever is not a member of the currently in-power party and hope that enough people do that the new electees will effect legislation to gerrymander to keep their own party in power, rather than the current one. It's largely not worth even considering. > > Just ask BetaMax. > > That's a quagmire of a topic! But it's a well-known example that, details aside, succinctly captures the essence of both sides of a particular debate. > It's also not relevant here. But it very much is! > Betamax machines couldn't generally play or record VHS tapes and > vice versa: "Customers had to choose between the two as tapes and > machines were not compatible between the two Exactly. e-mail users have to chose between the two email formats and clients are not (fully) compatible between the two... Every decision has tradeoffs. One choice may be better for YOU, but not necessarily for the majority. The majority clearly prefer HTML mail. Opinion polls show that, and my epxerience outside of technical mailing lists overwhelmingly supports it. That's exactly what the BetaMax example is (always) meant to point out--succinctly, that consumer choice wins, regardless of what YOU happen to think the technical merits are. > By contrast, non-GUI MUAs *can* often render at least some parts of HTML > emails And by not being able to render them whole, they are deficient compared to those which can. > I've nothing against people sending emails with multiple > attachments. But expecting the recipient's MUA to parse multiple >
Re: Going GUI...er
On Fri, Apr 17, 2020 at 06:08:37PM -0500, Derek Martin wrote:
> On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote:
>> On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote:
>>> On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote:
On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote:
> Sorry, but this is an archaic way of looking at the problem.
> People have been doing this for decades now, has become the norm,
> common practice, and really it is therefore WE who are being
> inconsiderate by not accepting de facto standards that have been
> widely adopted for a very long time.
I disagree. You have made a "roads were built for cars" argument*:
it assumes that today's "de facto standard" trumps historical
precedent and considerate behaviour.
>
> And by the way, I ignored this point originally, but doesn't it?
No, it doesn't.
Inconsiderate behaviour is by definition inconsiderate.
Likewise, the fact that something is currently popular does not make it
good.
It is better to be considerate of others, and to evaluate the merits of
one's proposed approach, before acting.
> Even in the case of cars, which you can argue have had deleterious
> effects on society (but I think there's plenty of support for the
> counter-argument), we got to where we got to because it was what most
> people wanted. Technological evolution is about as democratic as it
> gets...
I disagree. Consumption is ultimately constrained by the choices
available to consumers.
If a region's developers and government planners, etc, space houses far
apart and provide negligible public transport or cycling infrastructure
but plentiful cars and car-oriented infrastructure, cars will
predominate there because the region's consumers are hampered in
pursuing other choices. For example, see:
https://en.wikipedia.org/wiki/File:Revised_petrol_use_urban_density.jpg
or
https://www.cambridge.org/core/journals/journal-of-economic-history/article/entrepreneurship-and-the-american-automobile-industry/127DE4B6237E8510ED8501D65DB6C973
Propaganda (e.g. advertising) also has an effect.
Technological evolution is no more democratic than is a gerrymandered
district rife with vote suppression and dubious publicity.
> You can assert that a different solution is better, and your argument
> might be correct on technical merit, but if most people don't agree
> your correctness is irrelevant; you still lose.
If most people dismiss an argument that is technically correct, then we
very likely *all* suffer.
That suffering is not the fault of the people who back the technically
correct argument; it is the fault of the people who dismiss it.
> Just ask BetaMax.
That's a quagmire of a topic!
It's also not relevant here. Betamax machines couldn't generally play
or record VHS tapes and vice versa: "Customers had to choose between
the two as tapes and machines were not compatible between the two
standards," per
https://www.jbs.cam.ac.uk/fileadmin/user_upload/research/workingpapers/wp0720.pdf
By contrast, non-GUI MUAs *can* often render at least some parts of HTML
emails, and GUI MUAs *can* render plain text emails.
It's also not clear that Betamax was "better" than VHS, as you seem to
imply. Betamax's primary advantage over VHS seems only to have been
Betamax's smaller cassette size.
Betamax was *worse* than VHS in terms of recording time:
- Early Betamax tapes could only record 1 hour whereas VHS could record
2 hours at similar quality. So of the two, only VHS tapes could be
used for (typically 90-120 minute) movies.
- Early Betamax tapes could only record 2 hour whereas VHS could record
4 hours at similar quality. So of the two, only VHS tapes could be
used for (typically 3-hour) NFL games and other lengthy events.
Betamax camcorders ("Betamovie") were *worse* than VHS ones insofar as
they could only record tapes, not play them back, whereas VHS camcorders
could do both.
These factors were compounded by Sony's reluctance (and high fees) to
license Betamax so that other manufacturers could profit or innovate
within the format, or even simply rebrand Sony products. I.e. unlike
email, Betamax technologies were not open standards that anyone could
implement. (VHS was much more widely licensed, and therefore more
widely implemented, than Betamax.)
All of the foregoing means that equating text email with Betamax and
"rendered" (for want of a better word) email with VHS, just seems too
much of a leap to be historically or technologically meaningful.
In any case, Betamax and VHS (and derivations thereof) both survived for
about the same duration: their products were manufactured in some form
from ~1975 (Betamax) or ~1976 (VHS) until at least the 2010s. Betamax
and derived technologies captured a large share of the professional
video market in the 1980s; VHS the home market. So, even the idea that
there was a clear winner *overall* (rather than just in the home
Re: Going GUI...er
Derek Martin wrote: > Me personally, I just want the ability to render italics, to represent > emphasis. And to be able to read what my boss sent me... whatever it > might be. Yes, I love mutt for its programmability but when you need to see something your boss sent you, I think the best/easiest way is to bounce or save the entire message and display it via an external GUI MUA, rather than saving the html and possibly other attachments and viewing it via an external web browser. But if I had to do it 50 times a day, or reply to those emails with full formatting, the GUI MUA would have to win. Luckily for me, that's not the case. cheers, raf
Re: Going GUI...er
On Fri, Apr 10, 2020 at 01:09:12PM +0100, Sam Kuper wrote: > On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: > >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > >>> Sorry, but this is an archaic way of looking at the problem. > >>> People have been doing this for decades now, has become the norm, > >>> common practice, and really it is therefore WE who are being > >>> inconsiderate by not accepting de facto standards that have been > >>> widely adopted for a very long time. > >> > >> I disagree. You have made a "roads were built for cars" argument*: > >> it assumes that today's "de facto standard" trumps historical > >> precedent and considerate behaviour. And by the way, I ignored this point originally, but doesn't it? Even in the case of cars, which you can argue have had deleterious effects on society (but I think there's plenty of support for the counter-argument), we got to where we got to because it was what most people wanted. Technological evolution is about as democratic as it gets... you vote with your dollars, and the most popular solution wins, regardless of the merits. You can assert that a different solution is better, and your argument might be correct on technical merit, but if most people don't agree your correctness is irrelevant; you still lose. Just ask BetaMax. > >> I've nothing against people sending emails with multiple attachments. > >> But expecting the recipient's MUA to parse multiple attachments into > >> some kind of combined document is presumptuous, because clearly not > >> everyone's MUA does this. > > > > There's a HUGE difference. Roads existed for millenia before > > cars. > > The timescale isn't the point. My analogy refers only to your argument > that today's "de facto standard" trumps historical precedent and > considerate behaviour. In this respect, the analogy is accurate. If you're talking about historical precedence then time scale very much is the point. If your historical precedent was 5 minutes old that doesn't make for a compelling argument. If your time scale includes a period when something was not in widespread use, and then suddently it was, that too seems pretty uncompelling. But even so, you're basically saying, "It was this way, and so it must always be; no evolution of technology should be permitted." That's asinine. Assembled email documents became a thing basically as soon as technical limitations which prevented it from being practical were overcome. It was a natural, and I think inevitable, evolution of technology that happened pretty quickly, once critical mass was realized. Basically people made e-mail do what they could already do for quite a long time with books and other physical print media: format text with pictures to provide efficient presentation of information with previously well-established conventions, i.e. precedence. Now delivered to your own inbox. > I *disagree* that by the mid 90s, most GUI MUAs could handle this. I may be off by a few years, and it's fairly difficult to collect data about what e-mail clients supported what features when, but I certainly recall getting tons of complaints about it by the time I was in my first sysadmin job where I also had to do desktop support, which was in 1997. It doesn't really matter. The point is by now, the feature has been available in the vast majority of major e-mail clients for a very long time, and is in widespread use. You can rail against technological evolution if you like, but that doesn't help people get work done. All I'm after is to not have to fight with my tools to get them to show me what everyone else around me can see effortlessly. At that particular thing, Mutt sucks quite a lot. I used to be one of the people who argued vehemently against non-plaintext e-mail. But over time, the arguments against it have largely become moot for most people, and the fact is it IS better, because of its ability to more efficiently (in terms of what is visually rendered, not necessarily in how it is encoded) present other kinds of information besides simple unformatted plain text. Me personally, I just want the ability to render italics, to represent emphasis. And to be able to read what my boss sent me... whatever it might be. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Thu, Apr 09, 2020 at 09:32:01AM -0500, Derek Martin wrote: > On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: >> On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: >>> Sorry, but this is an archaic way of looking at the problem. >>> People have been doing this for decades now, has become the norm, >>> common practice, and really it is therefore WE who are being >>> inconsiderate by not accepting de facto standards that have been >>> widely adopted for a very long time. >> >> I disagree. You have made a "roads were built for cars" argument*: >> it assumes that today's "de facto standard" trumps historical >> precedent and considerate behaviour. >> >> I've nothing against people sending emails with multiple attachments. >> But expecting the recipient's MUA to parse multiple attachments into >> some kind of combined document is presumptuous, because clearly not >> everyone's MUA does this. > > There's a HUGE difference. Roads existed for millenia before > cars. The timescale isn't the point. My analogy refers only to your argument that today's "de facto standard" trumps historical precedent and considerate behaviour. In this respect, the analogy is accurate. But to avoid sidetracks, I retract it. Sorry it caused confusion. > By the time e-mail was in widespread use (the mid-90's... just > because you may have had it before then does not mean it was wide > spread before that), MIME was already a standard, and the vast > majority of e-mail clients had support for it. The GUI ones had it > built in. I think you are conflating two different things: - The sending of emails with multiple parts/attachments (e.g. via MIME). As noted above, I've nothing against this as long as the attachments *don't* need the MUA to parse and combine them into a new document/rendering. I *agree* that by the mid 90s, many GUI MUAs could handle such emails. - The sending of emails that *do* require the recipient's MUA to parse and combine their parts/attachments in some way. E.g. emails that require the recipient's MUA to parse an HTML part/attachment, figure out which "src" attributes in the HTML refer to images that were also attached to the email, and render the HTML accordingly with the images inline (which requires the MUA to contain or wrap a web browser). I *disagree* that by the mid 90s, most GUI MUAs could handle this. > So your argument is a straw man. Not that I can see. >> And even if yours does: should it? As several people in this thread >> have pointed out (and as is also illustrated in the "Efail" paper by >> Poddebniak et al, linked in my footer), using such an MUA massively >> increases your attack surface. > > Just because the current batch of GUI MUAs does this does not mean > yours *needs* to. That would be the beauty of a GUI Mutt--it already > has the philosophy of not automatically exposing you to all those same > attack vectors. After all, text-based Mutt has exactly the same > attack vetctors; it just does not expose you to them by default--you > have to take action to expose yourself to them. I agree that ideally no MUA, GUI or otherwise, should automatically expose you to attack vectors. Especially not to remote resources. In the case of the Efail vulnerabilities, you will see from Poddebniak, et al, that both Claws (a GUI MUA) *and* Mutt avoided the attacks. So clearly, there are some attacks that both classes of MUA can protect against. As I say, you and I are in agreement on this point. But I disagree that text-based Mutt has "exactly the same attack vectors" as a "GUI Mutt" would have, if that "GUI Mutt" were to parse, combine and render attachments as outlined above. Why? A text-based MUA is very hard to get right. It's not coincidental that Mutt's slogan is "All mail clients suck. This one just sucks less." Nor that despite decades in development, neither Mutt nor any other feature-rich text-based MUA is definitely secure and bug-free. A web browser, especially a graphical web browser, is *much* harder to get right. It has much greater complexity, and consequently a much greater attack surface. For instance, Mutt doesn't need to protect you against the Billion Laughs attack, but an XHTML- or SVG-capable "GUI Mutt" (or the XML library that it calls) would need to. Mutt doesn't need to protect you against raster image decoding vulnerabilities, but a "GUI Mutt" (or the image decoding library that it calls) would need to. And so on. Conclusion: for the same software development resources, you can expect more bugs (including more security bugs) in a GUI MUA that includes or wraps a web browser, than in a text-based MUA. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 12:45:09PM -0700, Felix Finch wrote:
> On 20200405, Akkana Peck wrote:
> > Is there any way to configure mutt to alert me at the top of the
> > message if there are any text/calendar or image/* attachments
> > anywhere in the message, even as part of a multipart/alternative?
> > I feel like I miss a lot in mail messages because mutt doesn't tell
> > me about attachments.
>
> I wonder if the number of attachments could be shown in the index?
>
> I don't know if that would be sufficient; a lot of work emails are loaded
> with stupid company logos and such.
>
> Maybe the index could include a count of attachments only of specific types
> enumerated in a mutt var. Or maybe a count of attachments not enumerated in
> a mutt var.
>
> set show_attachments=text/calendar;text/html
> set hide_attachments=image/png
>
> %p is unused. Let it stand for the number of parts:
>
> set index_format="%4C %Z %{%b %d} %-15.15L %p (%?l?%4l&%4c?) %s"
>
%X is already defined as the number of attachments.
%Maybe that would suffice instead of a new %p.
Jon
> Just spitballin'!
>
> --
>... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
> Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
> GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
> I've found a solution to Fermat's Last Theorem but I see I've run out of room
> o
>>> End of included message <<<
--
Jon H. LaBadie j...@jgcomp.com
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (703) 935-6720 (C)
Re: Going GUI...er
On 20200409, Derek Martin wrote: On Thu, Apr 09, 2020 at 09:05:52AM -0700, Felix Finch wrote: Someone mention a Torpedo extension to Thunderbird recently. so I installed Thunderbird just to try it. Nope: Thunderbird doesn't even have a preference to send text only email. Yes it does: https://www.lifewire.com/plain-text-message-thunderbird-1173199 You are correct -- seems there are different entry points into account preferences. Thanks. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
On Thu, Apr 09, 2020 at 09:05:52AM -0700, Felix Finch wrote: > On 20200409, Derek Martin wrote: > > And honestly, most mailers have the ability to avoid these attack > > vectors--they just don't by default, because that's what the average > > person wants. Mutt users typically are not average e-mail users, and > > know better. > > The few times I've imagined what kind of GUI email reader I would > like enough to use, it mostly comes down to plain text by default > and not opening any attachments or links until requested. > Attachments would show as prompts; you could see or save them all at > once or individually. You could have whitelists and blacklists, by > sender and by URL. That's all I would really ask. Exactly. Pretty much the way Mutt works today--just GUIfied. > Someone mention a Torpedo extension to Thunderbird recently. so I installed > Thunderbird just to try it. Nope: Thunderbird doesn't even have a preference > to send text only email. Yes it does: https://www.lifewire.com/plain-text-message-thunderbird-1173199 It might be useful for those few emails where I need to see the pictures to make any sense of it, but I will never use it regularly, or to reply. > > I get maybe one email a week or month which makes no sense as > rendered text. At work (where I still do use Mutt) I get them every day. At home I get them far less often, but I still do get them, mostly from businesses I do business with. I hate it, but I do need to be able to read them. In many of these, the content you need is in image files... sometimes multiple ones, and often enough it's hard (but yes, not impossible) to peice together what it all means if you're not looking at it as a whole entity. YMMV, but face it, nearly all e-mail clients can handle it just fine, and if you used one of them you would hardly even have any reason to notice or care, much less call it "inconsiderate." Mutt just isn't one of those, and in that regard it does not "suck less." -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On 20200409, Derek Martin wrote: Just because the current batch of GUI MUAs does this does not mean yours *needs* to. That would be the beauty of a GUI Mutt--it already has the philosophy of not automatically exposing you to all those same attack vectors. After all, text-based Mutt has exactly the same attack vetctors; it just does not expose you to them by default--you have to take action to expose yourself to them. And honestly, most mailers have the ability to avoid these attack vectors--they just don't by default, because that's what the average person wants. Mutt users typically are not average e-mail users, and know better. The few times I've imagined what kind of GUI email reader I would like enough to use, it mostly comes down to plain text by default and not opening any attachments or links until requested. Attachments would show as prompts; you could see or save them all at once or individually. You could have whitelists and blacklists, by sender and by URL. That's all I would really ask. Someone mention a Torpedo extension to Thunderbird recently. so I installed Thunderbird just to try it. Nope: Thunderbird doesn't even have a preference to send text only email. It might be useful for those few emails where I need to see the pictures to make any sense of it, but I will never use it regularly, or to reply. I get maybe one email a week or month which makes no sense as rendered text. I save the HTML part as xxx.html and bring it up in an editor, and maybe in a browser. It's always corporate email, and I doubt that tells them much they don't already know or guess. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
On Thu, Apr 09, 2020 at 12:26:43AM +0100, Sam Kuper wrote: > On Wed, Apr 08, 2020 at 03:08:45PM -0400, Ben Boeckel wrote: > > On Wed, Apr 08, 2020 at 14:43:47 -0400, Kurt Hackenberg wrote: > >> On 2020-04-07 22:18, Derek Martin wrote: > >> > >>> Then again, maybe I should just move everything to gmail and be done > >>> with it. > >> > >> Please remember that Google reads your mail. > > https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours Exactly. And as it turns out, even though in principle I am a big advocate of privacy, in practice I don't really care. I don't say anything in e-mail that I'm ashamed of or that is likely to get me in any legal trouble, and if I did move entirely over to gmail but found I had reasons to do those things, I certainly know how to avoid google to do it. > So Derek, if you really are shopping around for webmail, please try > Posteo in addition to (or instead of) Gmail or Fastmail. I'm not really... I don't like it much, and I'd much rather have full control over my mail (there is a reason I use Mutt, after all)... But if I went that route I'd most likely use gmail because I already am all over Google's ecosystem. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Wed, Apr 08, 2020 at 07:59:45AM -0400, Mark H. Wood wrote: > On Tue, Apr 07, 2020 at 09:18:37PM -0500, Derek Martin wrote: > > I've said it before--I too would love a mutt-based (or mutt-similar) > > GUI mail client. Frankly, no matter how much I love Mutt (and you > > know I do), trying to make the case that Mutt's handling of modern, > > every-day common e-mail messages is anything but clunky and backward > > is insane. > > Go ahead and call me crazy, then. For me, Mutt's handling of modern, > every-day common e-mail messages is a feature. It strips away all of > the distracting, intelligence-free clutter and lets me *read the > message*. Except increasingly, because of how typical users use e-mail, it doesn't. That's entirely the problem. And you can say it's their fault, and technically that's right, but it doesn't matter in practice, if you NEED to read their messages and can't (easily). > If I were condemned to use only one of those gooey-fied MUAs, I would > be working on a plugin to configure-off all of the formatting, gather > the attachments into a menu to be viewed or ignored as I choose, pop > up an "are you sure?" dialog before following links, and generally > make it more like Mutt. But that is exactly what I'm advocating for/want. A MUTT gui. Maybe when I retire, I'll write one... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Wed, Apr 08, 2020 at 01:17:12PM +0100, Sam Kuper wrote: > On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > > On Sun, Apr 05, 2020 at 12:09:55AM +0100, Sam Kuper wrote: > > Sorry, but this is an archaic way of looking at the problem. People > > have been doing this for decades now, has become the norm, common > > practice, and really it is therefore WE who are being inconsiderate by > > not accepting de facto standards that have been widely adopted for a > > very long time. > > I disagree. You have made a "roads were built for cars" argument*: it > assumes that today's "de facto standard" trumps historical precedent and > considerate behaviour. > > I've nothing against people sending emails with multiple attachments. > But expecting the recipient's MUA to parse multiple attachments into > some kind of combined document is presumptuous, because clearly not > everyone's MUA does this. There's a HUGE difference. Roads existed for millenia before cars. By the time e-mail was in widespread use (the mid-90's... just because you may have had it before then does not mean it was wide spread before that), MIME was already a standard, and the vast majority of e-mail clients had support for it. The GUI ones had it built in. So your argument is a straw man. > And even if yours does: should it? As several people in this thread > have pointed out (and as is also illustrated in the "Efail" paper by > Poddebniak et al, linked in my footer), using such an MUA massively > increases your attack surface. Just because the current batch of GUI MUAs does this does not mean yours *needs* to. That would be the beauty of a GUI Mutt--it already has the philosophy of not automatically exposing you to all those same attack vectors. After all, text-based Mutt has exactly the same attack vetctors; it just does not expose you to them by default--you have to take action to expose yourself to them. And honestly, most mailers have the ability to avoid these attack vectors--they just don't by default, because that's what the average person wants. Mutt users typically are not average e-mail users, and know better. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Thu, Apr 09, 2020 at 00:26:43 +0100, Sam Kuper wrote: > On Wed, Apr 08, 2020 at 03:08:45PM -0400, Ben Boeckel wrote: > > On Wed, Apr 08, 2020 at 14:43:47 -0400, Kurt Hackenberg wrote: > >> Please remember that Google reads your mail. > > https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours Yeah, that's the post I was remembering. Thanks. > > I have been migrating to fastmail for my stuff (though mailing lists > > have not all been migrated yet). I'm happy with it at least. > > Fastmail is clearly preferable to Gmail, but that isn't saying much. > > Unlike both of those two: > > - Posteo's HQ and data center are both in the same, *relatively* > privacy-friendly, jurisdiction as each other (Germany), which reduces > its legal attack surface; Unfortunately, I learned of them after I had gotten moved to fastmail. However, looking, they do not support custom domains, so I'd have likely chosen fastmail anyways for my needs. --Ben
Re: Going GUI...er
On Wed, Apr 08, 2020 at 03:08:45PM -0400, Ben Boeckel wrote: > On Wed, Apr 08, 2020 at 14:43:47 -0400, Kurt Hackenberg wrote: >> On 2020-04-07 22:18, Derek Martin wrote: >> >>> Then again, maybe I should just move everything to gmail and be done >>> with it. >> >> Please remember that Google reads your mail. https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours > I have been migrating to fastmail for my stuff (though mailing lists > have not all been migrated yet). I'm happy with it at least. Fastmail is clearly preferable to Gmail, but that isn't saying much. Unlike both of those two: - Posteo's HQ and data center are both in the same, *relatively* privacy-friendly, jurisdiction as each other (Germany), which reduces its legal attack surface; - Posteo's web front end is free software; and - Posteo's servers run on renewable energy. So Derek, if you really are shopping around for webmail, please try Posteo in addition to (or instead of) Gmail or Fastmail. (I don't work for Posteo or have any other affiliation with them. I'm just a customer.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
Mark H. Wood wrote: > If I were condemned to use only one of those gooey-fied MUAs, I would > be working on a plugin to configure-off all of the formatting, gather > the attachments into a menu to be viewed or ignored as I choose, pop > up an "are you sure?" dialog before following links, and generally > make it more like Mutt. There is a brilliant "are you sure?" addon for Thunderbird. It's called Torpedo by secuso.org. Not only does it make you wait 3 seconds and confirm before following any link to a domain that you haven't already gone to a few times before, it shows the URL in a way that makes it clear where you're going (e.g. https://paypal.com.evil.com/blah would show evil.com in bold), and if the URL is something like a tinyurl, it'll fetch the real URL and display that instead. It's a fantastic solution to phishing that all GUI MUAs should be doing by default but aren't. cheers, raf
Re: Going GUI...er
On Wed, Apr 08, 2020 at 14:43:47 -0400, Kurt Hackenberg wrote: > On 2020-04-07 22:18, Derek Martin wrote: > > > Then again, maybe I should just move everything to gmail and be done > > with it. > > Please remember that Google reads your mail. I have been migrating to fastmail for my stuff (though mailing lists have not all been migrated yet). I'm happy with it at least. As for gmail reading your mail, with gmail getting some large percentage of email anyways, it's something that if I wanted to make sure, I'd use GPG or some other encryption mechanism. --Ben
Re: Going GUI...er
On 2020-04-07 22:18, Derek Martin wrote: Then again, maybe I should just move everything to gmail and be done with it. Please remember that Google reads your mail.
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:18:37PM -0500, Derek Martin wrote: > I've said it before--I too would love a mutt-based (or mutt-similar) > GUI mail client. Frankly, no matter how much I love Mutt (and you > know I do), trying to make the case that Mutt's handling of modern, > every-day common e-mail messages is anything but clunky and backward > is insane. If I could find a GUI mailer that had half the power of > Mutt without the crashing/corruption of Claws and similar, I'd marry > that software. =8^) I haven't used it myself so can't personally recommend it, and don't entirely agree with your views above, but mu4e might more closely match your desires: https://www.djcbsoftware.nl/code/mu/mu4e/Viewing-images-inline.html https://www.djcbsoftware.nl/code/mu/mu4e/Displaying-rich_002dtext-messages.html -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: > On Sun, Apr 05, 2020 at 12:09:55AM +0100, Sam Kuper wrote: >> I'll assume you mean that the email has multiple parts or >> attachments, one (or more) of which is an HTML file and one (or more) >> of which is an image file, and that the HTML file has an "img" >> element with a "src" attribute whose value is the name of the image >> file (at some path). >> >> (That is an inconsiderate way to send "email", but some people do >> it.) > > Sorry, but this is an archaic way of looking at the problem. People > have been doing this for decades now, has become the norm, common > practice, and really it is therefore WE who are being inconsiderate by > not accepting de facto standards that have been widely adopted for a > very long time. I disagree. You have made a "roads were built for cars" argument*: it assumes that today's "de facto standard" trumps historical precedent and considerate behaviour. I've nothing against people sending emails with multiple attachments. But expecting the recipient's MUA to parse multiple attachments into some kind of combined document is presumptuous, because clearly not everyone's MUA does this. And even if yours does: should it? As several people in this thread have pointed out (and as is also illustrated in the "Efail" paper by Poddebniak et al, linked in my footer), using such an MUA massively increases your attack surface. Making an MUA that works the way you are calling for and that is also secure might be possible, but I don't know of anyone who has achieved it yet. In the meantime, don't rue the functionality you feel you are missing. Please be thankful for the security and control that you have, and help others to achieve and be thankful for the same. * Historically, roads were *not* built for cars. See: https://www.theguardian.com/books/2014/dec/23/roads-were-not-built-for-cars-carlton-reid-review https://www.theguardian.com/environment/bike-blog/2013/apr/16/roads-not-built-for-cars-book -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:18:37PM -0500, Derek Martin wrote: > I've said it before--I too would love a mutt-based (or mutt-similar) > GUI mail client. Frankly, no matter how much I love Mutt (and you > know I do), trying to make the case that Mutt's handling of modern, > every-day common e-mail messages is anything but clunky and backward > is insane. Go ahead and call me crazy, then. For me, Mutt's handling of modern, every-day common e-mail messages is a feature. It strips away all of the distracting, intelligence-free clutter and lets me *read the message*. Compared to the competition, I find that use of Mutt is much more relaxing and pleasant. If I were condemned to use only one of those gooey-fied MUAs, I would be working on a plugin to configure-off all of the formatting, gather the attachments into a menu to be viewed or ignored as I choose, pop up an "are you sure?" dialog before following links, and generally make it more like Mutt. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Going GUI...er
On Tue, Apr 07, 2020 at 09:23:34PM -0500, Derek Martin wrote: Sorry, but this is an archaic way of looking at the problem. People have been doing this for decades now, has become the norm, common practice, and really it is therefore WE who are being inconsiderate by not accepting de facto standards that have been widely adopted for a very long time. Still, there is a limit as to practices which should be tolerated. To me, the great advantage of email is that it allows both me and those with whom I am corresponding to read and to reply at times which are convenient for each of us, though those times may not be coincident. Some are morning people; I am a nightowl. One of the parties with whom I was corresponding by email is a physician who receives urgent calls day and night on his cellular phone. Years ago (before the smartphone became ubiquitous) his well-meaning but not-so-bright daughter configured his mail client to ring his cellular phone whenever a email arrives. Not long after, I received an angry phone call from his wife, complaining that a conversational email which I sent off at 2am or 3am awakened them. The fact that someone is so stupid or so arrogant as not to secure a telephone number and an email address reserved for vital matters should not force me to look at the clock or consider time zones before composing and sending messages by email. Nor should it be necessary for me to accommodate the smartphone by limiting the length messages I compose. Similar considerations appertain to the practice of top-posting in a message thread. It is wrong to allow caprice on the part of the stupid and the ignorant to overthrow good traditions and good practices which have developed over the years. RLH
Re: Going GUI...er
On Sun, Apr 05, 2020 at 12:09:55AM +0100, Sam Kuper wrote: > I'll assume you mean that the email has multiple parts or attachments, > one (or more) of which is an HTML file and one (or more) of which is an > image file, and that the HTML file has an "img" element with a "src" > attribute whose value is the name of the image file (at some path). > > (That is an inconsiderate way to send "email", but some people do it.) Sorry, but this is an archaic way of looking at the problem. People have been doing this for decades now, has become the norm, common practice, and really it is therefore WE who are being inconsiderate by not accepting de facto standards that have been widely adopted for a very long time. OK, I'm done ranting now. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Sat, Apr 04, 2020 at 02:29:02PM -0400, Fred Smith wrote: > When God invented email, He intended that it be plain text! :) > As such, rich-text/html/images in email is the spawn of the devil. :) :) Ignoring the aspect about sky fairies inventing anything, this is still largely untrue. Sure, in 1973, when RFC 524 (the first RFC related to transfer of electronic messages) was published, there was nothing else but ASCII available to the vast majority of systems capable of handling e-mail. No RFC ever said any such thing as, "e-mail is now and forever shall be ASCII text only." MIME came along in 1992, when people started having more reasonable access to computers that had more capable facilities, and RFC 1521 goes to great lengths to define how e-mail message bodies can be basically any arbitrary data. That was almost 30 years ago folks. And I mean come on--low-tech physical media printing could handle mixed pictures and formatted text long, long before that. It's time to get with the program. I've said it before--I too would love a mutt-based (or mutt-similar) GUI mail client. Frankly, no matter how much I love Mutt (and you know I do), trying to make the case that Mutt's handling of modern, every-day common e-mail messages is anything but clunky and backward is insane. If I could find a GUI mailer that had half the power of Mutt without the crashing/corruption of Claws and similar, I'd marry that software. =8^) I keep thinking I really need to give Kmail another look. Then again, maybe I should just move everything to gmail and be done with it. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Going GUI...er
On Sat, Apr 04, 2020 at 07:18:42PM +0200, steve wrote: > Hi, > > Le 04-04-2020, à 09:41:59 +0200, Vegard Svanberg a écrit : > > >Hi, > > > >I love Mutt. > > Me too. > > >However, I'm increasingly finding myself having to resort to various > >tricks to deal with HTML only emails (with picture attachments), > >calendar invites, and other oddities and awkward stuff people send. > > I can display images, read pdf's, etc… but one thing I never managed to do is > open an html file containing images. I mean, I can send the html part to > firefox but the images don't follow. > > How do you guys cope with that? In my ~/.mailcap: image/gif; \ gpicview %s; \ print=lpr %s; image/jpeg; \ gpicview %s; \ print=lpr %s; image/png; \ gpicview %s; \ print=lpr %s; Then open the message, hit 'v' to view the structure, select an image and hit Enter. This works with actual attachments. Some emails (usuall SPAM) have only links to images. For those, I first read the reasonable messages using Mutt, and then make a second pass using Thunderbird to read the unreasonable ones that I didn't just discard in pass 1. If the only text in a message is "you need to view this in HTML," I typically just hit 'd'. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Going GUI...er
On Sun, Apr 05, 2020 at 05:57:53PM -0500, Greg Marks wrote: > I realize this isn't an answer to Vegard Svanberg's original question, > but I think it's a point worth raising: isn't the fact that mutt is > text-based a security feature? > > Thunderbird, which I consider the second-best e-mail client, does have > security settings to prevent it from automatically loading certain > content that might contain exploits. But it seems to me that mutt does > it one better by, for example, forcing users to take extra steps to click > on hyperlinks, which is a bit of extra defense against spear phishing. > Indeed, by seeing the raw HTML you can avoid a malicious hyperlink that > doesn't match the link text displayed. This is one of my big reasons for using Mutt: it doesn't open *any* attachment unless and until I tell it to. If I don't trust an attachment, I can copy it out and use my kit of file torture tools to extract its secrets. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu signature.asc Description: PGP signature
Re: Going GUI...er
Akkana Peck wrote: > Felix Finch writes: > > On 20200405, Sam Kuper wrote: > > > In the meantime, you can just reply to the message (which, after all, > > > was sent as an email): "Thanks, I accept your invitation to the meeting > > > at 5pm PDT on 5th May 2020." > > > > Now that's an idea I hadn't considered! I was thinking more about > > the calendar program keeping tabs on who had accepted or not. But > > you're right, no need to emulate that. Just reply to the human. That's what I've always done. Nobody has complained yet but I don't get invited to many meetings. > Aside from the question of how to reply to calendar invites, my > problem is seeing them in the first place. I don't get calendar > attachments often, but when I do, I never know they're there. > This happens for two reasons: > [...] > > Is there any way to configure mutt to alert me at the top of the > message if there are any text/calendar or image/* attachments > anywhere in the message, even as part of a multipart/alternative? > I feel like I miss a lot in mail messages because mutt doesn't tell > me about attachments. > > ...Akkana I think you're looking for these [but I'm wrong, see below]: auto_view type[/subtype] [ ... ] unauto_view type[/subtype] [ ... ] This commands permits you to specify that mutt should automatically convert the given MIME types to text/plain when displaying messages. For this to work, there must be a mailcap(5) entry for the given MIME type with the copiousoutput flag set. A subtype of “*” matches any subtype, as does an empty sub‐ type. implicit_autoview Type: boolean Default: no If set to “yes”, mutt will look for a mailcap entry with the “copiousoutput” flag set for every MIME attachment it doesn't have an internal viewer defined for. If such an entry is found, mutt will use the viewer defined in that entry to convert the body part to text form. MIME attachments with 'text' types, with the only exception of text/html, are excluded: they will be shown as they are unless auto_view is specified. I didn't know about implicit_autoview but I have the same problem as you. I just never thought to find a solution. Thanks for asking! I've always had this in my .muttrc: auto_view text/calendar with the appropriate entry in my .mutt.mailcap file: text/calendar; $HOME/bin/mutt.vcalendar.filter; copiousoutput But I didn't know about implicit_autoview so it would only work if I thought to look for attachments. I've just added this to my .muttrc: set implicit_autoview = yes Hmm. It didn't work. I assumed that it would automatically view the attachments with copiousoutput mailcap entries. It doesn't. It seems that implicit_autoview is just an alternative to using the auto_view option and having to list every mimetype. Sorry this didn't help. It seems that "view" here actually means translate into something viewable upon request. It doesn't mean automatically render attachments for which there is such a translation. Such an option would be great. Actually, I've just thought of a non-ideal solution but it'll take some work. If I add support for translating text/calendar to my textmail program, then procmail could be used to process incoming emails just to translate those attachments into text/plain and then mutt would render them automatically because it would see them as text/plain attachments. It implies a dependency on procmail or similar so it might not be suitable in all cases but it would work for me. I don't know how it would work for IMAP accounts. And it would replace the original attachment with its text/plain version which might not always be what you want. A mutt option to automatically render attachments that are automatically translatable to text would be ideal. Perhaps it could be called something like auto_translate / implicit_autotranslate or auto_render / implicit_autorender. cheers, raf
Re: Going GUI...er
On 20200405, Greg Marks wrote: I realize this isn't an answer to Vegard Svanberg's original question, but I think it's a point worth raising: isn't the fact that mutt is text-based a security feature? I have always used that as an excuse when corporate drones get annoyed with my text email. It's somewhat pointless when I save PDFs, pictures, etc to look at outside mutt, but I don't mention that :-) Still, most links to 1x1 invisible gifs and javascript are rendered harmless. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
I realize this isn't an answer to Vegard Svanberg's original question, but I think it's a point worth raising: isn't the fact that mutt is text-based a security feature? Thunderbird, which I consider the second-best e-mail client, does have security settings to prevent it from automatically loading certain content that might contain exploits. But it seems to me that mutt does it one better by, for example, forcing users to take extra steps to click on hyperlinks, which is a bit of extra defense against spear phishing. Indeed, by seeing the raw HTML you can avoid a malicious hyperlink that doesn't match the link text displayed. Obviously all of this is not a panacea, and no doubt you can still be harmed by opening a malware attachment in mutt. But am I wrong to think that these things that seem to be a hassle are actually good for us? Best regards, Greg Marks signature.asc Description: PGP signature
Re: Going GUI...er
On 20200405, m...@amrx.net wrote: No! The ultimate goal should be do accept calendar invitations from your calendar! Your mail client is reserved for reading email. MIME attached ics files to coordinate meeting attendance is an atrocity. Not even the email client is that restricted. It is commonly used to send tarballs, Linux patches, all sorts of things which are not "reading email". Email itself is not that restricted; I have used email for all sorts of remote control, like turning thermostats up or down, turning on lights, etc. SMTP is a tool, a nice general purpose tool, not some holy grail of RFCs never to be used for other purposes, and mutt is one of the many implementations. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
On 20200405, Fred Smith wrote:
On Sun, Apr 05, 2020 at 12:45:09PM -0700, Felix Finch wrote:
On 20200405, Akkana Peck wrote:
>Is there any way to configure mutt to alert me at the top of the
>message if there are any text/calendar or image/* attachments
>anywhere in the message, even as part of a multipart/alternative?
>I feel like I miss a lot in mail messages because mutt doesn't tell
>me about attachments.
I wonder if the number of attachments could be shown in the index?
I don't know about the number, but it IS possible to show a flag
in the index indicating the presence of one or more attachments...
I set mine that way, but don't remember how. I'll take a quick
gander at my muttrc and maybe it'll jump out at me...
# the default format
#set index_format="%4C %Z %{%b %d} %-15.15L (%?l?%4l&%4c?) %s"
# this one shows attachments
#set index_format="%4C %Z %{%b %d} %-15.15L %?X?{%2X}&%4c? %s"
set index_format="%4C %Z %{%b %d} %-20.20L %?X?^&%4c? %s"
OK, that last one is what sets the attachment indicator. Looks like
it is the "^&" out near the end.
No, the & is part of the trinary ?& operator. %X is the number of attachments.
Prolly a good idea to look it up in the mutt doc before butchering
yours, though.
Indeed :-) I wondered how I missed it ... I will try that, but I'm not sure
it's useful when corporate email has so many useless attachments.
Just tried it on corporate email, and it only showed for one email, which had a
single text attachment. Other emails with multiple image/png attachment showed
nothing. I'll experiment more later.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
On Sun, Apr 05, 2020 at 04:43:20PM -0400, Fred Smith wrote:
> On Sun, Apr 05, 2020 at 12:45:09PM -0700, Felix Finch wrote:
>> On 20200405, Akkana Peck wrote:
>> >Is there any way to configure mutt to alert me at the top of the
>> >message if there are any text/calendar or image/* attachments
>> >anywhere in the message, even as part of a multipart/alternative?
>> >I feel like I miss a lot in mail messages because mutt doesn't tell
>> >me about attachments.
>>
>> I wonder if the number of attachments could be shown in the index?
>
> I don't know about the number, but it IS possible to show a flag
> in the index indicating the presence of one or more attachments...
>
> set index_format="%4C %Z %{%b %d} %-20.20L %?X?^&%4c? %s"
>
> OK, that last one is what sets the attachment indicator. Looks like
> it is the "^&" out near the end.
Unless I am mistaken (quite possible), that flag does not reliably
appear in the presence of text/calendar parts in a multi-part email,
unfortunately.
If I am not mistaken, then this might be a bug :/
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 01:08:05PM -0700, m...@amrx.net wrote: > On Sun, Apr 05, 2020 at 08:48:35PM +0100, Sam Kuper wrote: >> If/when it becomes possible to RSVP, in a machine-readable fashion >> directly from Mutt, to calendar-invites-sent-via-email, I'll switch >> to that. > > No! The ultimate goal should be do accept calendar invitations from > your calendar! I'm not opposed to this in principle. But first of all, this isn't primarily about my calendar (which might be on paper, or on an offline PDA), it's about RSVPing to invitations sent by other people who do use digital calendars, so that they don't have to manually record the contents of my RSVP on my behalf. I would not want to put them to that trouble if I could easily avoid it. Secondly, even if I had a piece of calendaring software on my PC that I wanted to use for accepting calendar invitations - as you suggest - which protocol should it use for retrieving and replying to those invitations? Where should it retrieve them from, and where should it send the responses? How should I identify my friend John Smith from his and my mutual friend John Smith , if not by their email addresses? How would any of these processes be secured from malfeasance? These are genuine questions. I guess you might suggest CalDAV over HTTPS as the protocol, and propose that my PC's calendaring software should be a CalDAV client. Also that I should run a CalDAV server that can receive meeting invites and that can also forward RSVPs from me to other people's CalDAV servers. And perhaps that I should continue to use email addresses as identifiers though not calendar invite/RSVP destinations. But I'm not aware of any calendaring software that supports anything close to all of this. So, I'm open to enlightenment. > Your mail client is reserved for reading email. MIME attached ics > files to coordinate meeting attendance is an atrocity. As long as it isn't abused as some kind of substitute for having a text/plain message, how is it any more of an atrocity than any other kind of attachment? (Again, this is a genuine question.) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 12:45:09PM -0700, Felix Finch wrote:
> On 20200405, Akkana Peck wrote:
> >Is there any way to configure mutt to alert me at the top of the
> >message if there are any text/calendar or image/* attachments
> >anywhere in the message, even as part of a multipart/alternative?
> >I feel like I miss a lot in mail messages because mutt doesn't tell
> >me about attachments.
>
> I wonder if the number of attachments could be shown in the index?
I don't know about the number, but it IS possible to show a flag
in the index indicating the presence of one or more attachments...
I set mine that way, but don't remember how. I'll take a quick
gander at my muttrc and maybe it'll jump out at me...
# the default format
#set index_format="%4C %Z %{%b %d} %-15.15L (%?l?%4l&%4c?) %s"
# this one shows attachments
#set index_format="%4C %Z %{%b %d} %-15.15L %?X?{%2X}&%4c? %s"
set index_format="%4C %Z %{%b %d} %-20.20L %?X?^&%4c? %s"
OK, that last one is what sets the attachment indicator. Looks like
it is the "^&" out near the end.
Prolly a good idea to look it up in the mutt doc before butchering
yours, though.
Fred
--
Fred Smith -- fre...@fcshome.stoneham.ma.us -
"For him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy--to the only God our Savior
be glory, majesty, power and authority, through Jesus Christ our Lord, before
all ages, now and forevermore! Amen."
- Jude 1:24,25 (niv) -
Re: Going GUI...er
No! The ultimate goal should be do accept calendar invitations from your calendar! Your mail client is reserved for reading email. MIME attached ics files to coordinate meeting attendance is an atrocity. On Sun, Apr 05, 2020 at 08:48:35PM +0100, Sam Kuper wrote: > On Sun, Apr 05, 2020 at 08:05:29AM -0700, m...@amrx.net wrote: > > Truly, sending the human an E-Mail, to read, is a great response, but > > could trigger a frustrating conversation about auto populating > > calendar items, be prepared to defend your mutt way of life. > > Been there, done that. Several times. Still standing, > > If/when it becomes possible to RSVP, in a machine-readable fashion > directly from Mutt, to calendar-invites-sent-via-email, I'll switch to > that. > > At least, as long as the feature is sensibly implemented. Based on > Mutt's track reccord, it probably will be. > > -- > A: When it messes up the order in which people normally read text. > Q: When is top-posting a bad thing? > > () ASCII ribbon campaign. Please avoid HTML emails & proprietary > /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 12:19:58PM -0600, Akkana Peck wrote: This happens for two reasons: 1. Mutt shows attachments at the bottom of a message, which was reasonable in the days before everyone top-posted; but now I never 2. Calendar invites are often part of a MIME multipart/alternative: I feel like I miss a lot in mail messages because mutt doesn't tell me about attachments. Rather than bastardize Mutt to accommodate mis-use of e-mail (using it for generalized transport, rather than for communication) and perversions such as top-posting, a proper approach is to have two email addresses, and to run a different mail user agent for each. The first address is for efficient communication with rational and knowledgeable individuals; such communication is handled by Mutt. The second is for communication (which, regrettably, often is essential) with fluff-heads and with entities of the corporate realm (which is chained to M$); for this, use an agent such as Thunderbird. The more needs accommodated, the fewer needs served well. RLH
Re: Going GUI...er
On Sun, Apr 05, 2020 at 08:05:29AM -0700, m...@amrx.net wrote: > Truly, sending the human an E-Mail, to read, is a great response, but > could trigger a frustrating conversation about auto populating > calendar items, be prepared to defend your mutt way of life. Been there, done that. Several times. Still standing, If/when it becomes possible to RSVP, in a machine-readable fashion directly from Mutt, to calendar-invites-sent-via-email, I'll switch to that. At least, as long as the feature is sensibly implemented. Based on Mutt's track reccord, it probably will be. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On 20200405, Akkana Peck wrote:
Is there any way to configure mutt to alert me at the top of the
message if there are any text/calendar or image/* attachments
anywhere in the message, even as part of a multipart/alternative?
I feel like I miss a lot in mail messages because mutt doesn't tell
me about attachments.
I wonder if the number of attachments could be shown in the index?
I don't know if that would be sufficient; a lot of work emails are loaded with
stupid company logos and such.
Maybe the index could include a count of attachments only of specific types
enumerated in a mutt var. Or maybe a count of attachments not enumerated in a
mutt var.
set show_attachments=text/calendar;text/html
set hide_attachments=image/png
%p is unused. Let it stand for the number of parts:
set index_format="%4C %Z %{%b %d} %-15.15L %p (%?l?%4l&%4c?) %s"
Just spitballin'!
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
Felix Finch writes: > On 20200405, Sam Kuper wrote: > > In the meantime, you can just reply to the message (which, after all, > > was sent as an email): "Thanks, I accept your invitation to the meeting > > at 5pm PDT on 5th May 2020." > > Now that's an idea I hadn't considered! I was thinking more about the > calendar program keeping tabs on who had accepted or not. But you're right, > no need to emulate that. Just reply to the human. Aside from the question of how to reply to calendar invites, my problem is seeing them in the first place. I don't get calendar attachments often, but when I do, I never know they're there. This happens for two reasons: 1. Mutt shows attachments at the bottom of a message, which was reasonable in the days before everyone top-posted; but now I never get anywhere near the end of a message, so if there's an image or a calendar invite attached, I never find out. (For images I find out later when people reply "Wow, amazing photo!" after I've already deleted the original message.) 2. Calendar invites are often part of a MIME multipart/alternative: I 1 [multipa/alternativ, 7bit, 17K] I 2 ├─>[text/plain, quoted, iso-8859-1, 0.4K] I 3 ├─> [text/html, quoted, iso-8859-1, 1.0K] I 4 └─> [text/calendar, base64, utf-8, 15K] Mutt sensibly shows me the text/plain part, and I never know that there's also a calendar attachment. It seems broken that the calendar attachment would be part of the multipart/alternative when clearly you want to see both the text or HTML AND the calendar, but that's Microsoft for you (the invites have headers like "x-ms-exchange-calendar-series-instance-id:" so I'm guessing it's Exchange doing this). Is there any way to configure mutt to alert me at the top of the message if there are any text/calendar or image/* attachments anywhere in the message, even as part of a multipart/alternative? I feel like I miss a lot in mail messages because mutt doesn't tell me about attachments. ...Akkana
Re: Going GUI...er
Propagating the notion that E-Mail and Calendar are separate things is probably the best thing to do, to undo their evil marriage. The calendar related RFC's that I have looked at indicate that the protocols were designed work and communicate completely independent of E-Mail, yet the majority of people believe these things are designed or must to go together. Truly, sending the human an E-Mail, to read, is a great response, but could trigger a frustrating conversation about auto populating calendar items, be prepared to defend your mutt way of life. On Sun, Apr 05, 2020 at 11:44:16AM +0100, Sam Kuper wrote: > On Sat, Apr 04, 2020 at 09:06:13AM -0700, Felix Finch wrote: > > On 20200404, Sam Kuper wrote: > >>This ~/.mailcap works tolerably under Gnome [...] > > > > I've been using something similar for several years, and one thing > > missing from this is a way to respond to invites. Perhaps it's an > > Outlook-only thing, but I invariable get followup emails asking me to > > click "Accept", and I never see any such links. Looking at it in the > > Outlook webmail, there is an RSVP section with buttons for Accept > > Yes/No. > > AFAICT, this is just another Micro$oft lock-in attempt. > > > > Looking at the actual mime part, each invitee has an RSVP section. > > > >ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe > > Blow :mailto:jb...@megacorp.com > > > > [...] Do any calendar filters replicate this RSVP business? [...] > > I, too, would be grateful to know this. Not because I support lock-in, > but because simplifying calendar invites/RSVPs should not be beyond the > means of free (as in freedom) software. (Compatibility with proprietary > implementations should be a secondary concern.) The key difficulty is > likely to be broken time zone implementations (see below). > > > In the meantime, you can just reply to the message (which, after all, > was sent as an email): "Thanks, I accept your invitation to the meeting > at 5pm PDT on 5th May 2020." > > N.B. I strongly suggest including the time, zone and date in your reply, > as above, because sometimes automated invites: > > - use the wrong time zone for the event, AND > - do not specify the time zone that they are assuming! > > > > The only "http" links are for zoom. > > Don't be shy about alerting those senders that they are sending you > links to malware. Seriously. See: https://gu.com/p/dtx4g > > N.B. Even MS Outlook should not be sending Zoom links by default (not > because Micro$oft cares about giving you malware, but because Zoom is > non-Micro$oft). So, those senders presumably installed or configured > something at their end that causes those links to be inserted. > > -- > A: When it messes up the order in which people normally read text. > Q: When is top-posting a bad thing? > > () ASCII ribbon campaign. Please avoid HTML emails & proprietary > /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On 2020-04-04, Vegard Svanberg wrote: > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. I hever had that much trouble _reading_ HTML email. What forced me to give up on mutt completely for work and almost completely for personal use was the difficulty in _generating_ HTML email. 99% of the people to whom I send email can't deal with text/plain. Plain text doesn't work well on narrow (phone) UIs since it doesn't re-flow. None of the popular e-mail clients display plaintext in fixed-width fonts, so even on wide screens tables of values, lists and countless other things don't work. I used muttdown for the last few years to generate alternative HTLM and plaintext. It was effective, but clumsy and added a lot of work. -- Grant
Re: Going GUI...er
On 20200405, Sam Kuper wrote: On Sat, Apr 04, 2020 at 09:06:13AM -0700, Felix Finch wrote: On 20200404, Sam Kuper wrote: This ~/.mailcap works tolerably under Gnome [...] I've been using something similar for several years, and one thing missing from this is a way to respond to invites. Perhaps it's an Outlook-only thing, but I invariable get followup emails asking me to click "Accept", and I never see any such links. Looking at it in the Outlook webmail, there is an RSVP section with buttons for Accept Yes/No. AFAICT, this is just another Micro$oft lock-in attempt. Looking at the actual mime part, each invitee has an RSVP section. ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe Blow :mailto:jb...@megacorp.com [...] Do any calendar filters replicate this RSVP business? [...] I, too, would be grateful to know this. Not because I support lock-in, but because simplifying calendar invites/RSVPs should not be beyond the means of free (as in freedom) software. (Compatibility with proprietary implementations should be a secondary concern.) The key difficulty is likely to be broken time zone implementations (see below). In the meantime, you can just reply to the message (which, after all, was sent as an email): "Thanks, I accept your invitation to the meeting at 5pm PDT on 5th May 2020." Now that's an idea I hadn't considered! I was thinking more about the calendar program keeping tabs on who had accepted or not. But you're right, no need to emulate that. Just reply to the human. N.B. I strongly suggest including the time, zone and date in your reply, as above, because sometimes automated invites: - use the wrong time zone for the event, AND - do not specify the time zone that they are assuming! -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:06:13AM -0700, Felix Finch wrote: > On 20200404, Sam Kuper wrote: >>This ~/.mailcap works tolerably under Gnome [...] > > I've been using something similar for several years, and one thing > missing from this is a way to respond to invites. Perhaps it's an > Outlook-only thing, but I invariable get followup emails asking me to > click "Accept", and I never see any such links. Looking at it in the > Outlook webmail, there is an RSVP section with buttons for Accept > Yes/No. AFAICT, this is just another Micro$oft lock-in attempt. > Looking at the actual mime part, each invitee has an RSVP section. > >ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe Blow > :mailto:jb...@megacorp.com > > [...] Do any calendar filters replicate this RSVP business? [...] I, too, would be grateful to know this. Not because I support lock-in, but because simplifying calendar invites/RSVPs should not be beyond the means of free (as in freedom) software. (Compatibility with proprietary implementations should be a secondary concern.) The key difficulty is likely to be broken time zone implementations (see below). In the meantime, you can just reply to the message (which, after all, was sent as an email): "Thanks, I accept your invitation to the meeting at 5pm PDT on 5th May 2020." N.B. I strongly suggest including the time, zone and date in your reply, as above, because sometimes automated invites: - use the wrong time zone for the event, AND - do not specify the time zone that they are assuming! > The only "http" links are for zoom. Don't be shy about alerting those senders that they are sending you links to malware. Seriously. See: https://gu.com/p/dtx4g N.B. Even MS Outlook should not be sending Zoom links by default (not because Micro$oft cares about giving you malware, but because Zoom is non-Micro$oft). So, those senders presumably installed or configured something at their end that causes those links to be inserted. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sun, Apr 05, 2020 at 10:47:56AM +1000, raf wrote: > For other document attachments, I use various mailcap > filters to render things as text such as catdoc, > xls2csv, mutt.octet.filter and mutt.vcard.filter by > David A Pearson, vcalendar-filter by Martyn Smith etc. I knew about some of those, but not all of them. Thank you :) > In my younger, more fanatical days, I wrote a tool > (textmail) to convert everything to plain text as it > arrived to keep my mailbox small. That wouldn't help > you. :-) This one? http://raf.org/textmail/ Again, thank you :) -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat, Apr 04, 2020 at 07:18:42PM +0200, steve wrote: > I can display images, read pdf's, etc… but one thing I never managed > to do is open an html file containing images. I mean, I can send the > html part to firefox but the images don't follow. > > How do you guys cope with that? Depends what you mean by "an html file containing images". I'll assume you mean that the email has multiple parts or attachments, one (or more) of which is an HTML file and one (or more) of which is an image file, and that the HTML file has an "img" element with a "src" attribute whose value is the name of the image file (at some path). (That is an inconsiderate way to send "email", but some people do it.) If so, probably the simplest way of coping with that is: - View the HTML file via your preferred browser. - Then view the images separately (hit 'v' in Mutt to see the mail's attachments/parts; move the cursor to the relevant entry; hit 'Enter' to view that image). - Alert the sender of the email to the fact that their email was problematic. - If the sender is unsympathetic, then try to minimise email communications with that person in the future. (Basically, treat them approximately as if they were sending you spam or malware.) Alternatively, you could save the HTML file and the images to some directory, and fix the HTML's "src" attributes if needed to ensure that they point to the image files. Relative paths would be the best choice. (I suppose this could be scripted using Bash/Sed, Perl, Python, or whatever.) You'd then open the HTML file in an image-capable browser, and it should look roughly as the sender intended. Good luck. -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
Re: Going GUI...er
On Sat Apr 04, 2020 at 09:41:59 +0200, Vegard Svanberg wrote: However, I'm increasingly finding myself having to resort to various tricks to deal with HTML only emails (with picture attachments), calendar invites, and other oddities and awkward stuff people send. I don't know how I would survive with a regular GUI client like Thunderbird or Evolution. I've tried, but they all suck. Mutt's keybindings, search and navigation features are irreplaceable. Suggestions? What does everyone else do? The solution I found was to create on the mail server an account for "ugly mail", install Thunderbird on my main machine, and configure Thunderbird to retrieve from the "uglymail" account; that way, Thunderbird does not mess with my maildir structure. Then, when, using Mutt, I encounter an uglymessage, I bounce it to the uglymail account, with the command ":exec bounce-message". Afterward, I use Thunderbird to view or otherwise process the uglymessage and attachments. RLH
Re: Going GUI...er
Vegard Svanberg wrote: > Hi, > > I love Mutt. > > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. > > My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't > seem to exist. > > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? > > -- > Vegard Svanberg [*Takapa@IRC (EFnet)] I use mutt over ssh to read mail on a virtual machine out there somewhere that is also my mail server, so I can't really "display" anything therei (X11 not installed). For most HTML emails, lynx is enough: .mutt.mailcap: text/html; lynx -dump %s; copiousoutput; description=HTML Message; nametemplate=%s.html But when it's not, I have a macro that bounces the email to a local IMAP account: .muttrc: macro index BR bbounce.raf@virt.raf.org\ny and it's fetched by Thunderbird on my laptop. Once read, I delete it in Thunderbird. I concluded that that was the easiest thing to do in my environment and it means that hardly any emails make it to my actual laptop, only the ones I choose to allow there, and they're always work-related ones that I've already seen and know to be legitimate. For other document attachments, I use various mailcap filters to render things as text such as catdoc, xls2csv, mutt.octet.filter and mutt.vcard.filter by David A Pearson, vcalendar-filter by Martyn Smith etc. The vcalendar-filter is very useful for me these days. In my younger, more fanatical days, I wrote a tool (textmail) to convert everything to plain text as it arrived to keep my mailbox small. That wouldn't help you. :-) cheers, raf
Re: Going GUI...er
Honestly? I just filter between addresses. I use this address soley for mailing lists and personal emails I know won't contain HTML and if they do it's minimal enough to use elinks for. Everything else I just send to a collection of junk gmail accounts that act as archives for service emails that will definitely contain junk HTML. Maybe this helps, probably doesn't.. hope you can figure it out. On Sat Apr 04, 2020 at 09:41:59 +0200, Vegard Svanberg wrote: > Hi, > > I love Mutt. > > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. > > My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't > seem to exist. > > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? > > -- > Vegard Svanberg [*Takapa@IRC (EFnet)] >
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote: > Hi, > > I love Mutt. > > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. > > My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't > seem to exist. > > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? A long time ago when I was a UNIX instructor I spent most of my time at client sites. The many security aware sites blocked my ssh back home for mail reading but generally allowed access to yahoo's email site. Again, at that time, yahoo allowed "?reverse pop?", i.e. I could send my emails received at home (my business site) to my yahoo email account. I created a second user "jonpop" which got a copy of all my emails and filtered out those I did not care to see when traveling. The rest got uploaded to yahoo. Yahoo no longer allows this, nor do I need it anymore. But the jonpop account still gets everything and filters out little. I have Thunderbird on most of my computers and rather than connect to "jon" they all connect to "jonpop". If I want to see a fancy email I read it in Tbird. While in mutt, if I want to get the gist of a fancy email I have a function key macro that tries to render the html. At times it has used lynx, elinks, w3m, and firefox. Jon -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: Going GUI...er
On 2020-04-04 03:41, Vegard Svanberg wrote: Currently I'm running Mutt from a machine which I ssh into from 5 other computers I use frequently (IMAP backend - self-hosted). Suggestions? What does everyone else do? Meaning Mutt runs on the same computer that runs your IMAP server, and you use Mutt from elsewhere through SSH? Why not run Mutt on the computer you sit in front of, using Mutt's IMAP client to fetch mail to display? That is, use IMAP across the net instead of SSH. That wouldn't give Mutt a GUI, but some things would be nicer. Passing off HTML and images to some other program would work smoothly; those other programs would also run on the computer in front of you, and so could do graphics directly. Or did I misunderstand your setup?
Re: Going GUI...er
On 20200404, Patrick Shanahan wrote: * Fred Smith [04-04-20 14:32]: [...] When God invented email, He intended that it be plain text! :) As such, rich-text/html/images in email is the spawn of the devil. :) :) amen, good only for advertising and junk mail but now w/o the cost of a stamp. That may be how it started, but tons of internal corporate email and ordinary business-to-customer email includes embedded html pages and pictures. I'm sure most of us have gotten huge emails which could have been written in a few lines of text. But here we are anyway. Are there any mutt ways to view these pages as a whole in a browser, rather than individually? -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
* Fred Smith [04-04-20 14:32]: [...] > When God invented email, He intended that it be plain text! :) > As such, rich-text/html/images in email is the spawn of the devil. :) :) amen, good only for advertising and junk mail but now w/o the cost of a stamp. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Re: Going GUI...er
On Sat, Apr 04, 2020 at 07:18:42PM +0200, steve wrote: > Hi, > > Le 04-04-2020, à 09:41:59 +0200, Vegard Svanberg a écrit : > > >Hi, > > > >I love Mutt. > > Me too. > > >However, I'm increasingly finding myself having to resort to various > >tricks to deal with HTML only emails (with picture attachments), > >calendar invites, and other oddities and awkward stuff people send. > > I can display images, read pdf's, etc… but one thing I never managed to do is > open an html file containing images. I mean, I can send the html part to > firefox but the images don't follow. > > How do you guys cope with that? > > Thx When God invented email, He intended that it be plain text! :) As such, rich-text/html/images in email is the spawn of the devil. :) :) -- --- .Fred Smith / ( /__ ,__. __ __ / __ : / // / /__) / / /__) .+' Home: fre...@fcshome.stoneham.ma.us // (__ (___ (__(_ (___ / :__ 781-438-5471 Jude 1:24,25 -
Re: Going GUI...er
Hi, Le 04-04-2020, à 09:41:59 +0200, Vegard Svanberg a écrit : Hi, I love Mutt. Me too. However, I'm increasingly finding myself having to resort to various tricks to deal with HTML only emails (with picture attachments), calendar invites, and other oddities and awkward stuff people send. I can display images, read pdf's, etc… but one thing I never managed to do is open an html file containing images. I mean, I can send the html part to firefox but the images don't follow. How do you guys cope with that? Thx
Re: Going GUI...er
On 20200404, Sam Kuper wrote: This ~/.mailcap works tolerably under Gnome: text/calendar; /home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter; copiousoutput vcalendar-filter is from https://github.com/terabyte/mutt-filters I've been using something similar for several years, and one thing missing from this is a way to respond to invites. Perhaps it's an Outlook-only thing, but I invariable get followup emails asking me to click "Accept", and I never see any such links. Looking at it in the Outlook webmail, there is an RSVP section with buttons for Accept Yes/No. Looking at the actual mime part, each invitee has an RSVP section. ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Joe Blow :mailto:jb...@megacorp.com The only "http" links are for zoom. Do any calendar filters replicate this RSVP business? -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Going GUI...er
* At 2020-04-04T09:41+0200, Vegard Svanberg wrote: > Suggestions? What does everyone else do? I've documented my attachment opening setup here: https://wtf.hijacked.us/wiki/index.php/Mutt#Open_attachments_on_remote_machine It allows me to open the attachment menu (v) and press A on any attachment to open it remotely on my desktop (using xdg-open). This also works for HTML bodies and attachments, so it solves the HTML mail problem for me also. -- Stian Sletner
Re: Going GUI...er
On Sat, 4 Apr 2020, at 09:41, Vegard Svanberg wrote: > Suggestions? What does everyone else do? If you're already SSHing to your mutt instance, that is, using email online-only, it doesn't like like webmail would be the worst bet you could make. I can recommend Fastmail.com; their webmail application can be driven 100% by keyboard shortcuts [1] in all modes (index, reading, composition), the UI is very fast and response, layout-customizable in some degree, and their email capabilities are pretty much complete (MFA with app passwords, standards-compliant IMAP, Sieve/filters, SPF/DKIM, identity management, they have labels/tags a la G-Suite as well in their beta by way of their JMAP implementation). When compared to G-Suite, Office365, Rainmail, Roundcube, Zoho, Open-Xchange, and a few others I've tried, Fastmail is the fastest and most power-user friendly solution there is at the moment. You buy these advantages with a lack of customizability: there's more of a take-it-or-leave-it component to it than to mutt, but I think that the same goes for Thunderbird, Sylpheed, and other GUI clients. My personal setup is actually dual: I use Fastmail in the web client most of the time, and for server side search, but as part of my offline strategy, I always have a local setup with mutt, notmuch, 100% synced IMAP content using isync/mbsync. Effectively, I use both mutt on the desktop and webmail on the web. Works great together. So from personal experience, I'd recommend a dual mutt-desktop+imap plus webmail+imap setup that gives you all the advantages and none of the drawbacks. You'll have to evaluate the webmail offerings first, of course. [1] https://www.fastmail.com/help/receive/kbshortcuts.html
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote:
> I'm increasingly finding myself having to resort to various tricks to
> deal with HTML only emails (with picture attachments), calendar
> invites, and other oddities and awkward stuff people send.
AKA "stuff awkward people send" ;)
This ~/.mailcap works tolerably under Gnome:
text/html; lynx %s; nametemplate=%s.html
text/html; lynx -force_html -width=72 -dump %s | sed -e
's/^[[:space:]][[:space:]][[:space:]]//' ; nametemplate=%s.html; copiousoutput
text/calendar;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/ics;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/pdf; evince %s
image/jpeg; /usr/bin/eog %s
(I have attached a copy of the .mailcap file, in case the above was
line-wrapped in transmission.)
Evince and EOG ("Eye of Gnome") are Gnome's PDF and image viewer,
respectively. Use other programs for those tasks if you like.
vcalendar-filter is from https://github.com/terabyte/mutt-filters
Finally, the postscript below (above my email footer) is a snippet from
my muttrc file, that I find helpful for viewing emails and their
attachments, in conjunction with the above .mailcap .
To you: good luck! And to Mutt's creators and maintainers: thank you!
Sam
# == Attachments ==
set attach_format="%u%D%I %t%4n %T%.40d %> %-1.20m/%-12.12M| %17.20e|
%11.12C| %4.12s"
# == Read ==
set pager_context=5
set pager_index_lines=8
set pager_stop=yes # Paging down at end of a msg? Don't jump to next msg
alternative_order text/plain text/enriched text/html # Try HTML last
# See ~/.mailcap for details of auto_view lines
auto_view text/html
auto_view text/calendar
auto_view application/ics
# This line gets rid of iso 8859 issues with attachments
set rfc2047_parameters
# Header weeding
ignore *
unignore from date subject to cc
unignore Message-ID: In-Reply-To: posted-to:
--
A: When it messes up the order in which people normally read text.
Q: When is top-posting a bad thing?
() ASCII ribbon campaign. Please avoid HTML emails & proprietary
/\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you.
text/html; lynx %s; nametemplate=%s.html
text/html; lynx -force_html -width=72 -dump %s | sed -e
's/^[[:space:]][[:space:]][[:space:]]//' ; nametemplate=%s.html; copiousoutput
text/calendar;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/ics;
/home/sampablokuper/src/mutt_and_neomutt_and_related/mutt-filters/vcalendar-filter;
copiousoutput
application/pdf; evince %s
image/jpeg; /usr/bin/eog %s
Re: Going GUI...er
* Vegard Svanberg [01-01-70 12:34]: [...] > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. [...] I run mutt on my server inside a tmux (or screen) session and access by ssh to the tmux session. For html, I pipe the html attachment to a file on my server and access it via what-ever browser is available. If photos are attached, I can view them directly from mutt since I forward X in ssh. It does require running a web server, which I do anyway. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Re: Going GUI...er
Hei hei, On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote: > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. This is mostly true for business related stuff. > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? I more or less divided home/hobby and business accounts, or let's say, I don't get all that HTML/Calendar/Attachement stuff for my private mail and there I use mutt, basically the same way you do, self hosted IMAP, ssh into the machine running mutt. Every now and then I use Thunderbird for accessing this, but seldomly. At work with all those creepy stuff (we're not even allowed to send plain text mail except for mailing lists requiring that) I currently don't use mutt at all, but KMail, Thunderbird and the webmailer of OpenExchange. It's not mutt, but I can live with that for the content I get there. Greets Alex -- /"\ ASCII RIBBON | »With the first link, the chain is forged. The first \ / CAMPAIGN | speech censured, the first thought forbidden, the X AGAINST | first freedom denied, chains us all irrevocably.« / \ HTML MAIL| (Jean-Luc Picard, quoting Judge Aaron Satie) signature.asc Description: PGP signature
Re: Going GUI...er
I set this up long ago and now at the age of 80 I am beginning to forget what I did. Basically I have mutt set up so when the cursor is on a message, typing 'v' shows the bits of it. If only html, or if there are several sections I move the cursor to the html section. I them hit 'm' and it opens the html in google. It is messy but it works. On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote: > Hi, > > I love Mutt. > > However, I'm increasingly finding myself having to resort to various > tricks to deal with HTML only emails (with picture attachments), > calendar invites, and other oddities and awkward stuff people send. > > My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't > seem to exist. > > I don't know how I would survive with a regular GUI client like > Thunderbird or Evolution. I've tried, but they all suck. Mutt's > keybindings, search and navigation features are irreplaceable. > > Currently I'm running Mutt from a machine which I ssh into from 5 other > computers I use frequently (IMAP backend - self-hosted). > > Suggestions? What does everyone else do? > > -- > Vegard Svanberg [*Takapa@IRC (EFnet)] -- On two occasions I have been asked [by members of Parliament], "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?". I am not able rightly to comprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage Brian Salter-Duke (Brian Duke) Email: brian(DOTjames(DOTduke(AT)gmail(DOT)com
Re: Going GUI...er
On Sat, Apr 04, 2020 at 09:41:59AM +0200, Vegard Svanberg wrote:
> Hi,
>
> I love Mutt.
>
> However, I'm increasingly finding myself having to resort to various
> tricks to deal with HTML only emails (with picture attachments),
> calendar invites, and other oddities and awkward stuff people send.
>
> My Holy Grail, which would be a native Mutt GUI client, I guess, doesn't
> seem to exist.
>
> I don't know how I would survive with a regular GUI client like
> Thunderbird or Evolution. I've tried, but they all suck. Mutt's
> keybindings, search and navigation features are irreplaceable.
>
> Currently I'm running Mutt from a machine which I ssh into from 5 other
> computers I use frequently (IMAP backend - self-hosted).
>
> Suggestions? What does everyone else do?
>
I run mutt similarly on my home desktop and ssh into that from a
laptop when I'm away or elsewhere in the house.
To view HTML E-Mails which are beyond lynx or whatever I fire the
E-Mail at my browser (firefox).
So my the relevant bits of .mailcap on my desktop machine are:-
text/html; /home/chris/bin/muttfox %s
text/html; lynx -dump %s; copiousoutput; nametemplate=%s.html
... and muttfox is:-
#!/bin/bash
#
#
# muttfox: script called by mutt via mailcap to use firefox to view HTML,
and
# also some types attachments, currently:- PDF, JPG
#
# It is necessary for HTML files because /usr/bin/firefox exits
# before firefox has actually loaded the HTML file, this is especially
# true when it's remote but it also happens when running locally.
#
# It's not actually necessary for PDF and JPG files but it speeds up
# remote (i.e. running mutt via ssh) viewing considerably because it
# doesn't run the viewing program across the X connection. It works
# OK for local files so everything works the same.
#
# The temporary file to be viewed by Firefox is copied to directory
# /srv/mutt on esprimo if running locally or to the same place on the
# remote system if running via ssh. The copy to the remote system is
# done via an ssh reverse tunnel on port 50022 using a passwordless key
# and rrsync at the remote end to make it reasonably secure.
#
dir=/srv/mutt/
#
#
# if there's no DISPLAY variable then Firefox can't run, so skip the whole
thing
#
if [ -n "$DISPLAY" ]
then
chmod 0644 $1
if [ -n "$SSH_CLIENT" ]
then
rsync -e 'ssh -p 50022 -i /home/chris/.ssh/np_id_rsa' $1
localhost:$(basename $1)
else
cp $1 $dir$(basename $1)
chmod 0644 $dir$(basename $1)
fi
/usr/bin/firefox http://localhost/mutt/$(basename $1)
fi
#
#
# Clear out any old files left on esprimo by this script, doing it here
# saves adding a special crontab task (but a crontab task is needed on
t470)
#
find $dir -mtime +7 -exec rm {} \;
Because of the way that Firefox works the E-Mail pops up in the
existing Firefox running on the remote client machine, I'm not sure if
other browsers do the same sort of thing. Oh, esprimo is my desktop
machine and t470 is my laptop, the above works both when the laptop is
at home on my LAN and when away somewhere more remote.
--
Chris Green
Re: Going GUI...er
I used sylpheed and claws-mail until recently when I switched to mutt. What annoyed me most is that claws mail crashed occasionally and messed up configuration and folder settings after the crash. For html mails which don't render readable in text I have a binding to open them in an already running firefox instance. This sucks only a little. Certainly less than claws-mail's performance and stability Christopher On April 4, 2020 9:41:59 AM GMT+02:00, Vegard Svanberg wrote: >Hi, > >I love Mutt. > >However, I'm increasingly finding myself having to resort to various >tricks to deal with HTML only emails (with picture attachments), >calendar invites, and other oddities and awkward stuff people send. > >My Holy Grail, which would be a native Mutt GUI client, I guess, >doesn't >seem to exist. > >I don't know how I would survive with a regular GUI client like >Thunderbird or Evolution. I've tried, but they all suck. Mutt's >keybindings, search and navigation features are irreplaceable. > >Currently I'm running Mutt from a machine which I ssh into from 5 other >computers I use frequently (IMAP backend - self-hosted). > >Suggestions? What does everyone else do? http://gmerlin.de OpenPGP: http://gmerlin.de/christopher.pub CB07 DA40 B0B6 571D 35E2 0DEF 87E2 92A7 13E5 DEE1
