Re: Question about message id
On Thu, Apr 11, 2024 at 02:35:30PM -0700, googly.negotiator...@aceecat.org wrote: > On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users wrote: > - if the mailing list does mess with msgid, it absolutely must do it > consistently for all copies of the message. For existing software that has problems with '/' (because it is a path separator), the solution is actually trivially simple. On the way in, replace it with one of the "specials" that are not allowed in a message ID, but IS allowed in your system's path names. On the way out, do the reverse transformation. You need only write a simple function that does each thing, and call them once, when the data is "on the way in" (from whichever source, either the RFC2822 message form or the on-disk form). Memory is cheap these days so just save both forms in your data structure and use the right one for the given context. Or don't, the perf hit will be imperceptible to the user (but it's more typing to call the function every time you need one or the other). There are probably only a handful of places you'd need to change, if you wrote suitably modular software--even in mail software, there are few cases where the message ID is at all interesting. -- 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: Question about message id
On Thu, Apr 11, 2024 at 01:13:52PM +1000, raf via Mutt-users wrote: > On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin > wrote: > > > On Sun, Apr 07, 2024 at 01:19:09PM +, Ебрашка wrote: > > > Question, what should I write in .muttrc to make my outgoing > > > mails have the same beautiful message-ID as Yandex mail? > > > > The unfathomable thing about this question is why you (or anyone) > > should care in the slightest what your message ID looks like. > > It's an esoteric detail about e-mail transfer, the specific > > contents of which have no value to users [...] > The link to a kernel mailing list message that was provided earlier > in this discussion said that the choice to use base64 results in the > possibility of / characters being included in the message id which > causes problems for their archived messages accessible via a web > browser. Yeah, but... > So it seems that there is a reason to care about this. I disagree, both for the actual stated case of wanting "the same beautiful message-ID as Yandex mail" and for the more general case of controlling message ID format. It's not something the USER should ever have to think about, for the reasons I said, quoted above--it's something only developers should ever have to care about, and even then only to the point where it complies with standards, which it does. If Mutt wants to accommodate broken list archive software (it IS broken, because it fails to handle the full range of decades-old standard, documented valid input values), then it should use a format that does that. No user should ever have reason to care about this. Seriously. > Although one could argue that the mailing list archiving system > should accept the responsibility of munging message ids to suit its > own needs. Indeed. But even that presupposes the design flaw that leads to the necessity of doing that. They could have simply organized the data differently (e.g. using a database, etc.) that does not have Unix path name issues. Also worth pointing out that if the software in question runs on Windows, there are additional allowed characters that cause breakage there. -- 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: Question about message id
On Tue, Apr 09, 2024 at 09:25:56AM -0700, Will Yardley wrote: > On Tue, Apr 09, 2024 at 11:33:55AM -0400, Derek Martin wrote: > > If so that feature may not be working correctly... > > That is the old format for the mutt version I'm using. The new format > looks like > > > > Thought you were on that long thread about this when it changed a while > back, but maybe remembering wrong. I was--but I guess the source of my confusion is I don't actually care what the message ID format is (as should no user), so I never bothered to internalize it, but I vaguely (mis)remembered it had (I thought one, but at least one) more dot-separated components. My issue was never with the specifics of the format, but rather the practical benefit of the changes and the spurious logic in favor of them vs. the cost of implementing and maintaining them. Cheers -- 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: Question about message id
On Tue, Apr 09, 2024 at 08:05:06AM -0700, Will Yardley wrote: > On Tue, Apr 09, 2024 at 10:53:41AM -0400, Derek Martin wrote: > > The unfathomable thing about this question is why you (or anyone) > > should care in the slightest what your message ID looks like. > > That's totally true, but I still like the classic Mutt message-id > format. Did you set your message ID format accordingly, then? Because the message I'm replying to carries this: Message-ID: <20240409150506.ga47...@aura.veggiechinese.net> If so that feature may not be working correctly... > Maybe it's just nostalgia, but either way, I'm not super > worried about leaking my PID etc... Nor should you be--as I pointed out then, the PID is only of any use to an attacker who is already on your system, which means either: 1. Your system is already compromised, or 2. They are a legitimate user on your system, in which case they can already easily get the pid of your mail client In no way can a process ID be construed as sensitive. If it were you'd have to disable the ps command, modify the logging of virtually every network daemon ever, and a whole bunch of other things. > I think some people mentioned some minor threading issues with the new > format? Is that so? I don't recall noticing anything about that... I'd love a pointer to some details, if anyone has that. Anyway, I said then, and maintain now, that changing the format and making it configurable was pointless and added complexity without good technical justification. You may have just proven that. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Question about message id
On Sun, Apr 07, 2024 at 01:19:09PM +, Ебрашка wrote: > Question, what should I write in .muttrc to make my outgoing mails have > the same beautiful message-ID as Yandex mail? The unfathomable thing about this question is why you (or anyone) should care in the slightest what your message ID looks like. It's an esoteric detail about e-mail transfer, the specific contents of which have no value to users, who in most cases won't even ever see the message ID, since most mail clients hide that detail from you by default. You have no practical reason to care what it is as long as everything is working correctly. It's literally not for you--it's for your MUA software. From a practical standpoint, the only thing that matters is that the generator intelligently makes a genuine effort to ensure the generated message ID is unique (and perhaps that it does not needlessly leak sensitive details about the user, though no message ID format that I'm aware of--including Mutt's original default format--ever did that, emphasis on "sensitive"). You should be able to trust your mail client to handle that detail on your behalf. If for some reason you can't, you should be using different e-mail software. Truthfully, Mutt typically shouldn't even be in the business of generating message IDs, where the expectation is that it will hand the mail off to the MTA running on the user's system, which should handle message ID generation, so that there is no possibility of overlap. [In practice this is unlikely to be a problem, because the format Mutt uses is different from the major mail transfer agents. The probability of an overlap is therefore exceedingly low, and thus uniqueness is maintained.] Other than that, as long as replies and message threading work properly in your mail client, don't even look at it--it is (or should be) completely opaque to you. -- 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: Mutt showing ? in place of space
On Sat, Mar 30, 2024 at 11:21:21AM -0700, googly.negotiator...@aceecat.org wrote: > ...this type of issue is really tricky because one has to be sure to > *build* against the packaged (i.e. non-base) libraries, including > cases like libncurses. IIRC this is far from automatic, some packages > as shipped link with the base ncurses. One has to inspect the package > build. Yeah. Getting this right is so ridiculously complex that even remembering all the things that you might need to check is genuinely challenging. This is why we really need a detailed FAQ that addresses all the things. I've sat down to write one several times, but I always get interrupted by something that seems to matter more at the time, so it hasn't happened. -_- -- 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: Mutt showing ? in place of space
Sandeep, On Sat, Mar 30, 2024 at 10:21:30AM +0800, Sadeep Madurange wrote: > On 2024-03-29 16:47:22, Derek Martin wrote: > > [*] Except in extremely rare and completely esoteric cases that apply > > only to experts... and by now should really apply to no one. > > Thank you for patiently explaining. That was very educational. This is > what I used to do on Linux in the past, though, without knowing why. > > Unfortunately, this doesn't seem to work on OpenBSD. So, perhaps this > qualifies as one of the esoteric cases. OpenBSD doesn't seem to pay much > attention to the LANG variable. Thw following is an excerpt from the > locale man page: I don't have an OpenBSD system to test on, so I can't investigate further, but I wouldn't think so, because: > "Programs in the OpenBSD base system ignore the locale except for the > character encoding..." Mutt is not part of the "base system" so the limitation on locale should not apply to it, and "except for the character encoding" absolutely SHOULD apply, since that is specifically what is at issue in your case. Reading the rest of the man page, I find some of the additional details should be applicable to your case as well: "If the value of LC_CTYPE ends in ‘.UTF-8’, programs in the OpenBSD base system ignore the beginning of it, treating for example zh_CN.UTF-8 exactly like en_US.UTF-8. Programs from packages(7) may however make a difference." Shocking antiquation aside, this certainly seems to suggest that the guts of what is necessary for Mutt to have what it needs for the locale to work correctly do exist on the system. And the behavior they describe isn't really all that different from what normally happens on modern systems with full locale support--the point of Unicode is that every language's character sets are available simultaneously, so from a charset perspective the actual language doesn't matter. The main difference here appears to be that their base system only has English translations, so it ignores other aspects of LANG. And then this: "LANG Fallback if any of the above is unset." This matches the behavior I explained already in my previous post... At least according to their man page, everything I described SHOULD work. In other words, according to their own man page, if you set LANG and leave the other variables unset, this should be exactly equivalent to setting LC_CTYPE for any library functions which honor that variable, i.e. ALL of the functions which Mutt uses to control that behavior. Separately, though not apparently related to any concerns you have, Mutt's translations are provided by Mutt--not the base system--so even that should work correctly if your locale is set properly. That said, setting only LC_CTYPE is fine, if you only care about using Unicode as your character set, and don't want the other behaviors related to e.g. date & time, money display, etc. to match whatever differences exist in a UTF-8 environment (in my experience with en_US.UTF-8 the only difference is default sort order, typically observable in the output of the ls command, and controlled specifically by LC_COLLATE). However I would point out that your own post said that you had left LANG unset. Did you try setting LANG (and unsetting all the other environment variables, and Mutt's charset variable) as I suggested? Did you then also look at the output of the locale command to ensure that the settings were correct, as expected based on that setting? I'd love to see that output, to confirm or refute whether your system is correctly honoring LANG, as its man page seems to say it should... And then once you confirmed that locale was correct, did you then try Mutt? In either case--whether you set only LANG or only LC_CTYPE--you should not then need to set Mutt's character set, because it should get it from LC_CTYPE (directly or indirectly through inheritance from LANG). All of this behavior that I've described is part of the POSIX standard, and has been for quite literally decades. If OpenBSD can't handle this, then perhaps that would make at least part of an argument for why end users shouldn't use it as their desktop OS... -- 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: Mutt showing ? in place of space
On Fri, Mar 29, 2024 at 03:03:54PM -0700, Bob Crochelt wrote: > Thank you Derek! > Bob Crochelt No problem, glad I could help. I had to figure this stuff all out the hard way 20 years ago, when I moved to Korea and suddently needed to be able to type in both English and Korean... I've been answering it on this list ever since... seriously, see this post from 2006: https://marc.info/?l=mutt-users=114434601817142=2 Things were A LOT worse then--Unicode hadn't really been adopted very much in 2004. Some of the finer details of how (or rather where) to set those settings keep changing (in part because young developers can't leave well enough alone when a solution has been working for literally decades), and most people don't need to futz with fonts anymore since Unicode is the default everywhere now, and the modern font rendering libraries handle all this automatically--but the basics of the problem and its solution are still the same. In another such post I commented that this topic comes up often enough that it really ought to be a FAQ. Some day I'll take the time to collect the details in a bit better format and provide 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. > On Fri, Mar 29, 2024, at 13:47, Derek Martin wrote: > > On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: > >> Initially, LANG was unset and LC_CTYPE="C". The character encoding was > >> US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale > >> settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you > >> are on to something. I will check this with OpenBSD community as well. > >> > >> In Xdefaults, I have set XTerm*utf-8 setting to true as well. > > > > Your problem is that these settings are not consistent (and you still > > have this problem, because the "solution" proposed by Sirius is > > incorrect--even if it appears to have solved your issue). By having > > LANG unset, you've told your shell (and therefore everything started > > by it) to use ASCII, but you've explicitly told xterm to use Unicode. > > That's wrong. > > > > The TL;DR of this is: > > > > 1. You should NEVER need to set Mutt's charset explicitly. [*] > > 2. Your shell, Mutt, and X should all inherit what they need from your > >LANG environment variable, assuming it is set properly for your > >system and environment (it definitely isn't in your case). > > 3. Setting Mutt's charset may appear to "work" but it's not the > >correct solution, because your shell and terminal settings are > >still inconsistent. You'll have trouble with other things later if > >you don't fix this. > > > > [*] Except in extremely rare and completely esoteric cases that apply > > only to experts... and by now should really apply to no one. > > > > > > The unfortunately lengthy details: > > -- > > > > Displaying characters properly is actually tricky business on modern > > computers, because of the legacy methods by which we tried to > > accommodate different languages, and the (relatively) recent advent of > > Unicode to unify that mess. All of the following must be set > > consistently: Your shell, your terminal program (or your operating > > system's console), your font, all of your application programs, and > > when appropriate, the X window system. If any of these are not > > consistently set, you can, and eventually WILL, have trouble. Most > > modern systems have the concept of a default locale, which is > > typically set for you at install time, and which every process you > > start inherits, unless you configure your user environment > > differently. > > > > Fortunately, there is a very simple mechanism by which this happens, > > which is the LANG environment variable. There are additional > > ancillary environment variables which start with "LC_*" but you > > usually should not have to set any of these, because they inherit > > their value from LANG if they are not explicitly set. When you run > > the locale command, values enclosed in quotes are inherited from LANG, > > and values NOT enclosed in quotes have been set explicitly: > > > > $ locale > > LANG=en_US.UTF-8 > > LANGUAGE= > > LC_CTYPE="en_US.UTF-8" > > LC_NUMERIC="en_US.UTF-8" > > LC_TIME=&qu
Re: Mutt showing ? in place of space
On Sat, Mar 23, 2024 at 07:41:45PM +0800, Sadeep Madurange wrote: > Initially, LANG was unset and LC_CTYPE="C". The character encoding was > US-ASCII. I changed these variables (i.e., LANG, LC_CTYPE and locale > settings) to en_US.UTF-8. Then the ? changed to ?. So, looks like you > are on to something. I will check this with OpenBSD community as well. > > In Xdefaults, I have set XTerm*utf-8 setting to true as well. Your problem is that these settings are not consistent (and you still have this problem, because the "solution" proposed by Sirius is incorrect--even if it appears to have solved your issue). By having LANG unset, you've told your shell (and therefore everything started by it) to use ASCII, but you've explicitly told xterm to use Unicode. That's wrong. The TL;DR of this is: 1. You should NEVER need to set Mutt's charset explicitly. [*] 2. Your shell, Mutt, and X should all inherit what they need from your LANG environment variable, assuming it is set properly for your system and environment (it definitely isn't in your case). 3. Setting Mutt's charset may appear to "work" but it's not the correct solution, because your shell and terminal settings are still inconsistent. You'll have trouble with other things later if you don't fix this. [*] Except in extremely rare and completely esoteric cases that apply only to experts... and by now should really apply to no one. The unfortunately lengthy details: -- Displaying characters properly is actually tricky business on modern computers, because of the legacy methods by which we tried to accommodate different languages, and the (relatively) recent advent of Unicode to unify that mess. All of the following must be set consistently: Your shell, your terminal program (or your operating system's console), your font, all of your application programs, and when appropriate, the X window system. If any of these are not consistently set, you can, and eventually WILL, have trouble. Most modern systems have the concept of a default locale, which is typically set for you at install time, and which every process you start inherits, unless you configure your user environment differently. Fortunately, there is a very simple mechanism by which this happens, which is the LANG environment variable. There are additional ancillary environment variables which start with "LC_*" but you usually should not have to set any of these, because they inherit their value from LANG if they are not explicitly set. When you run the locale command, values enclosed in quotes are inherited from LANG, and values NOT enclosed in quotes have been set explicitly: $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE=C LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Here you can see that I explicitly set LC_COLLATE=C. The rest are inherited from LANG. Typically most users will want to leave all of the LC_* variables unset, and inherit from LANG. I haven't tried a *BSD in a really long while, but if it doesn't ask you for your default locale during install, or if you made a mistake setting it up, then you should add the settings manually to your login shell environment. If you're using UTF-8 (which you should be--by now every modern OS uses it by default), the value of LANG should reflect that. Pretty much no one should be using ASCII anymore (i.e. LANG should NEVER be unset). The most portable way to do that would be to include the following in BOTH .profile and .kshrc (or whatever file you've set ENV to): LANG=en_US.UTF-8 export LANG [See the Invocation section of the ksh man page for exact details of which files you should put this in, but in general it's the ones I said.] Of course if you are not using English, change en_US to whatever your default language is, but you'll want to retain the ".UTF-8" portion. That *should* be sufficient to handle everything... however, there may be additional places you'll need to add it for your X applications, depending on exactly what OpenBSD does to initialize users' X sessions. In general, the X startup stuff is supposed to make sure that it sources the user's environment so that you don't need to figure out which of the 17 different files you actually need to put this stuff in... but over the years most vendors have bastardized how X sessions start up, so you may have to look up or trace out how your system does it to make sure everything works correctly. So you might have to also add it to .xinitrc or .xsession or similar. Or, if it does not already, you could simply have your X init thingy source your
Re: Disabling start and stop keys
On Mon, Nov 07, 2022 at 11:11:33PM -, Jeffery Small wrote: > I have a script that fires up mutt in an xfce4-terminal window. In my ksh > shell .kshrc file, I use stty to disable (undef) the stop (^S) and start > (^Q) characters. However, when I run mutt as follows: I don't have ksh installed to test (and I'm too lazy to install it), but I suspect your .kshrc file is not being read because the shell that xfce4-terminal launches to run mutt is not an interactive shell. But the question is, if you're doing this via a script to begin with, why rely on .kshrc? Run stty in the script before starting mutt... or better yet, make the thing that xfce4-terminal starts be the shell script that starts mutt, and consists of this: #!/bin/sh stty start undef stty stop undef exec /usr/local/bin/mutt Call that script, say, /foo/bin/mutt, and then start with xfce4-terminal $options -e /foo/bin/mutt -- 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: Is linewrap dead?
On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote: > Derek Martin wrote on Wed, 31 Aug 2022 > at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>: > > Evaluating the strength of a SHOULD requires looking at pragmatic > realities. And that reality is that lots of messages are sent > without hard line wraps. That's true but the vast majority of that is HTML mail, which has entirely different set of formatting rules and display parameters, and again, not applicable here. > Also, RFC5322 is not intended to be a standard that governs what > user should do. It's for MTAs and MUAs and other mail software. This is clearly not true, since it is the standard for the format of the message, and the stated purpose is to ensure that recipients are not negatively impacted by implementations of user interfaces that display these messages which may truncate, or disastrously wrap, the display of more than 78 characters per line. This isn't about transmission, it's about interface and display. The user, far more than the MUA, controls the format of the message by how they construct the message, which in your case does indeed "disastrously wrap, the display of more than 78 characters per line" on my end. Your MUA does nothing to correct it--though I could force mine to. But as you say, it's extra work that is annoying, and I've only even seen people do what you're doing a handful of times since the 80's... usually by accident, or because they were brand-new e-mail users unfamiliar with the etiquette... And for the record, of the 8 people posting in this subthread (starting with your post), 2 of them complained about your practice. Perhaps your messages aren't as universally readable as you think. Anyway, the reason this conversation ultimately never goes anywhere useful is because there's already a perfectly viable means of achieving your goal: HTML mail. Pretty formatting is literally what it's for, and unlike format=flowed, or anything else you can imagine, it's already widely adopted. That fact is largely why nothing else will ever will be (at least until the next new thing is invented with capabilities far superseeding HTML). If you're so concerned with ugly wrapping, that's what you should be using. Otherwise, you should wrap your lines like the standards and existing conventions say you should. If it's just jagged right margins you don't like that's easily fixed by justifying the text in your editor--solutions exist for common editors, google them. -- 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: Is linewrap dead?
On Wed, Aug 31, 2022 at 04:38:11PM -0400, John Hawkinson wrote: > I don't mean to monopolize the conversation, but: > > Derek Martin wrote on Wed, 31 Aug 2022 > at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>: > > > I don't see why this matters, because as I already pointed out, any > > desktop GUI MUA will have no trouble displaying 72 character lines > > wrapped as they are, and any *reasonable* mobile can do the same by > > rotating it. > > (1) I do not agree that it is reasonable to expect mobile users to > rotate their screens. That's merely your opinion, which you are entitled to. Being unwilling to make the smallest effort to rotate your screen, when it will give you optimal reading conditions, seems like the definition of "unreasonable" to me. > (a) I think many won't do it That is their choice, for which they may live with the consequences. Not my problem. > (b) Even if recipients *do* rotate, they will still have the > subconscious/psychological result that "Dealing with Derek's emails > takes more work, he is annoying." That, arguably, would be my problem, but in 33 years of using e-mail, has never been. Not once. Not because of the way I format e-mail, at any rate... =8^) > (2) On desktop GUIs, emails will be readable, but they will look > different from most other sender's emails. This again becomes a > variant of (1)(b). I think you are projecting a level of unadaptability on people that is uncommon. In any case, that, too, is not my problem... It's their choice, their consequences, as I keep saying. If they actually tried it, I dare say many if not most might find it preferable. > I think we can all accept that when people have to do more work I find the notion that turning your wrist slightly an amount of extra work that even bears consideration laughable. Exception granted for folks who have physical limitations which make that difficult or impossible, but I'm betting such people aren't reading e-mail on a phone. > > There actually is significant psychological research into the ideal > > line length for reading. There's some variation, but the consensus > > seems to come in at about 60-75 characters, at a width of roughly > > 4-5". > > Sure, but this assumes a lot of things. To be clear, we're talking about plain text e-mail here, since this discussion is irrelevant for variable-width HTML mail. My assumptions are pretty safe, at least for every GUI client I occasionally use, which thankfully does not include Outlook, so can't speak to that. Your belief that using long lines is fine also assumes a lot of things, about the MUA, MTA, and MDA software in use by you--wherever you may be sending it from--and by all of your recipients, not to mention any custom tools they may be using to process it. Safe enough for typical users--less so for atypical users--like most of the folks on this list. =8^) > > > As for standards-compliance, that's a red herring. Long lines are > > > not going to trip up any modern client, they're just not. > > > > It may be less relevant today, but it's still relevant. > > As noted by Kurt, this is up to the MUA to address, and is easily > fixed by encoding as quoted-printable. Probably other ways too. That's technically true but anything that can send mail is technically a MUA, and may or may not be capable of automatically converting your garbage in into lovely standards-compliant data out. Suppose you suddently have a need to send e-mail programmatically... You're in the habit of sending long lines because you're convinced it's "better"--will the tools you use care? Maybe. Maybe not. Will it matter? That depends on whether the e-mail you send matters, and maybe how time-sensitive it is... > > lines of plain text at 72 characters should ever need to display > > unreadably for any desktop user, or even anyone on any reasonable > > mobile device which can rotate lines parallel to their longer side, > > Hard disagree. People don't always rotate, shouldn't have to, and > will resent it when forced to do so. Again their choice, but fine--I will not, and should not have to change the way I compose e-mail from well-established standards and conventions, and will resent it if you try (and ultimately fail) to force me to. So where does that leave you? Rotating your phone is BY FAR the easiest, most practical and economical solution to that conundrum. Choose to or not, it's on you. > I don't really think we're flouting the standards. You're already aware that RFC 5322 (and a bunch of others) recommends keeping line lengths below 78 characters, and you're willfully dismissing that recommendation, so by definition yes you are. But conventions are also standards, and your failure to comply with established
Re: Is linewrap dead?
On Wed, Aug 31, 2022 at 05:43:41PM -0400, John Hawkinson wrote: > John Hawkinson wrote on Wed, 31 Aug 2022 > at 16:38:11 EDT in : > > > I suppose I should send some 2,000-character paragraph emails as > > tests to see what happens, but I very much doubt there will be > > problems as a result. > > Anyhow, if I send a 2,000-character line in mutt, it encodes it in > quoted-printable. So no standards problem. This is precisely what's concerning--you seem to think that this covers all the reasons why the standard exists, and the convention persists. That's the farthest thing from true. Mutt is not the ony thing that sends mail, and you have no idea what's happening in all the myriad of other things that do; nor do you on the receiving end or on any of the recipients, which may include custom tools that are thwarted by your refusal to adhere to the established convention. To be clear, I have no issue with YOU not wrapping your lines in mail you send with Mutt--after this thread ends I will just happily ignore your messages, since I find them annoying to deal with. It's the fact that you're actively advocating ignoring the standards as a general practice, possibly to the detriment of those who may be using e-mail differently than you are, who might be negatively impacted by doing so, or their recipients, as a result. That I find completely unacceptable. > Can we please move back to...I don't even know. Other suggestions on > ways to handle the problem of devices that don't display > hard-wrapped text well? There are no such devices, except those which are too small to display e-mail readably in the first place, so not worth considering. Beyond that there are only ones which some users may stubbornly refuse to use effectively. But in any case, no! Or to be more precise, you can discuss them all you like, but they won't happen, just as format=flowed has already failed (which TBH I find unfortunate). All you could possibly succeed in doing is to convince a few more people to send messages that are annoyingly hard to read in text-based clients, and risk transmission failure when they attempt to do so outside the extremely well-behaved confines of Mutt. -- 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: Is linewrap dead?
On Wed, Aug 31, 2022 at 07:57:43PM +0200, Francesco Ariis wrote: > > The problem is popular modern mobile and web-based MUAs don't handle > > this and can make unexpected linewrap decisions. It's no issue when > > emailing UNIX nerds, but non-nerds think I'm doing something wrong. > > I do not have a smartphone, can I ask someone to provide a .png on > how this or other similar messages look on a smartphone client? I am > very curious and hopefully a definite guideline will pop up from this > thread. There is already a well-established guideline: Wrap lines at ~70-72 characters. Here's a screenshot of what that looks like (one of the earlier messages I posted in this thread) on my mobile, properly rotated to be able to read it. http://www.pizzashack.org/images/mail.png If you think that has any sort of readability issue, I would encourage you to discuss that with a psychologist. From a scientific standpoint, I mean... =8^) Also don't forget to actually look at the image on your phone. The scale will obviously be out of whack if you view it on a desktop (but the readability will still not)! -- 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: Is linewrap dead?
On Wed, Aug 31, 2022 at 01:46:49PM -0400, John Hawkinson wrote: > Derek Martin wrote on Wed, 31 Aug 2022 > at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>: > > > It's been my experience that if you read your mail on anything other > > than a phone, the 72-character line width is fine, and even on a phone > > if you turn it sideways it's still fine. My preferred solution, then, > > has been to stick with following the standards and assume that if you > > insist on reading mail on a hand-held device that can't accommodate > > the standard, and/or refuse to rotate it so that it can, then you get > > what you get, it's your choice and the consequences of your choice are > > on you. > > That'd be true if we were sending emails to ourselves > but a lot of us send email to people who read their mail primarily > or exclusively on phones and in desktop GUIs that don't approximate > 72-chars. I don't see why this matters, because as I already pointed out, any desktop GUI MUA will have no trouble displaying 72 character lines wrapped as they are, and any *reasonable* mobile can do the same by rotating it. Where there IS significant difficulty, however, is with lines that wrap unevenly, because the display is too narrow to display the whole line, as well as with lines that are too long. Neither mobile nor desktop clients inherently impose this problem on their users; but YOU do, when you choose to manually wrap your lines either too long or too short, or not at all. If, as the user, your complaint is extra white space at the end of the line, increase the font size (either desktop or mobile) or change the width of your desktop client. That, too, is a choice that's on you. If your issue is that you have to make the text too big to fit so you can read it, then either you need to update the prescription of your glasses so you can make the text smaller, or if that's not a viable fix for you, then you have simply made the wrong choice of device for your needs. > What tends to happen is those people psychologically view > hard-wrapped 72-char emails as ugly and they become a far less > effective means of communication than other people's emails are, > regardless of conscious choice. This is unscientific nonsense. There actually is significant psychological research into the ideal line length for reading. There's some variation, but the consensus seems to come in at about 60-75 characters, at a width of roughly 4-5". I won't cite sources because they are ubiquitous; you can google them yourself. Long lines cause problems for readers because the length makes it difficult to find where (vertically) the lines begin and end. Short lines cause problems because of too much scanning back and forth, breaking the reader's rhythm. Works well for poetry (where the rhythm is largely the point), but not much else. Nearly all modern hand-helds are within a reasonable margin of being 4-5" long, and can easily display 75-character lines within their length, so again rotating the phone makes it perfectly readable, and actually provides pretty close to optimal reading conditions. Anyone who's reading e-mail regularly on a Nokia 8210 is an idiot, and deserves what they get for intentionally choosing to do something so idiotically counterproductive. > It's great if you can choose the people who read your emails I don't know anyone in that boat; and even if I did, it doesn't counter a single thing I've said. > As for standards-compliance, that's a red herring. Long lines are > not going to trip up any modern client, they're just not. It may be less relevant today, but it's still relevant. While the original reason for the standard was that the myriad of clients would display long lines improperly or not at all, these days it's not really about clients. Sendmail truncates lines at 998 characters. It is not alone. [It's conceivable this has become untrue since last I checked, but I doubt it, and assuming so is not wise. Besides which, I'd be shocked to discover that all internet sites are on the most modern versions of their MTAs. It just doesn't happen.] But as for the clients, Kurt is correct that modern clients will use QP format to avoid long lines. But that doesn't help you if you are stuck using a legacy client you don't have control over for whatever reason (as a former sysadmin I've seen this type of problem more times than I can count), or generate messages via a script that sends the body directly to sendmail, etc.. The bottom line is there is absolutely no reason why hard-wrapped lines of plain text at 72 characters should ever need to display unreadably for any desktop user, or even anyone on any reasonable mobile device which can rotate lines parallel to their longer side, that doesn't boil down to the choice of the user. Flouting the standards is a bad habit to be in. The
Re: Is linewrap dead?
On Mon, Aug 29, 2022 at 07:10:14AM -0400, John Hawkinson wrote: > Kurt Hackenberg wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in > : > > > If you put a newline only at the end of a paragraph, it won't be > > displayed correctly by software that doesn't expect that. Such > > software will probably either break each line exactly at the right > > margin, maybe in the middle of a word, or display a paragraph as a > > single very long line, maybe with a scroll bar. > > THe point of my statement is to say that this is not a problem in > practice, no. I think the fact that we're having this conversation suggests otherwise... > But I can confidently say that after years of doing this, omitting > newlines from internal line breaks in paragraphs has proved to be a > much better compromise than including them. I disagree--I find your messages rather hard to read, and beyond that long paragraphs run the risk of violating SMTP standards. I can't say I know how various MTAs handle lines longer than 998 characters, but I would expect at least a subset would either truncate them or reject your message... or at least that it would be wise to assume so. > [ I think, also, that without doing a survey of a wide variety of > readers, it's tough to appreciate the scope of this problem. I certainly agree that this is a stupid and annoying problem. It's been my experience that if you read your mail on anything other than a phone, the 72-character line width is fine, and even on a phone if you turn it sideways it's still fine. My preferred solution, then, has been to stick with following the standards and assume that if you insist on reading mail on a hand-held device that can't accommodate the standard, and/or refuse to rotate it so that it can, then you get what you get, it's your choice and the consequences of your choice are on you. -- 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: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 10:10:38AM +0200, martin f krafft via Mutt-users wrote: > Thanks for your responses so far! > > The reason I need this index is that I have to provide evidence of "a huge > volume of mails" on a given topic, without actually sharing the emails. If this is all you need to do, then, do you really need to preserve the threading? Seems all you really need is a list of the messages for the given subject, presumably with enough info to demonstrate their uniqueness. Assuming you or someone else on your behalf can get at them, you can probably get what you need from the mail system's logs. Or you can use formail to spit out just the headers that are interesting from your maildir folder... Something like this: cd $mail_folder/cur for file in *; do formail -X from: -X subject: -X date: done > some_output_file This will give you a bunch of groups of 3 lines that contain the three headers for each message. There should always be 3 lines (unless you have some broken messages that excluded any of those headers, which can happen, but shouldn't)--but they probably won't always be in the same order. You can, of course, specify additional headers... The formail command provides -x and -X options; -x extracts just the header value, whereas -X extracts the full header line. You want -X so you know which header you're looking at, so you don't have to write code to try to figure it out heuristically. You can do all of the above entirely in Python, which avoids the nasty quoting problems with constructions like "for file in *; ..." by using os.scandir(), and using the subprocess module (or similar) to execute the formail command for each message file. It also makes it possible to know that a given line of output is for the specific file you're asking about, so the ordering and potential absence of the message's headers becomes a non-concern. Then you can read the output line by line, assigning the header value to a dict field based on the header name. Stuff your dicts in a list, or something. Then you can pass your dicts to, say, csv.DictWriter, and write them out as a CSV file. Or as JSON. Or add records for them to a database, so you can query the data. Or whatever. If you really do need to show the thread graph, you can produce that yourself using the message IDs and references. Is any of this better than just using Python's email module? Probably not... YMMV. But either way, if I had to solve this I would just use Python, and not try to hack around with other utilities. -- 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: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 01:02:39PM -0500, Derek Martin wrote: > On Thu, Aug 18, 2022 at 09:17:11AM +, Sam Kuper wrote: > > On Wed, Aug 17, 2022 at 04:59:41PM -0500, Derek Martin wrote: > > > On Wed, Aug 17, 2022 at 09:33:44PM +, Sam Kuper wrote: > > Or they could just use SSH. > > SSH is ubiquitous. But outside of tech circles, the ability to use it > is not. If you've ever sat in a meeting with a bunch of pure > management types, you'll understand why this suggestion is a > non-starer. Likewise for your other suggestions. Granted, I'm making assumptions about the audience, but given the nature of the task, I think they are safe ones. ;-) Also, even for tech-oriented audiences, making them ssh into a machine and run mutt to view the index will feel like "making us jump through hoops..." It's extremely likely, in my estimation, that it's not going to go over well with the audience, regardless of who the audience is. -- 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: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 10:10:38AM +0200, martin f krafft via Mutt-users wrote: > > I don't think it will be better or easier than what you've done. But > > you could try using a '|' filter in $index_format to append some output > > to a file as a side effect. It would still entail manually pgdn'ing > > through the index. > > Not a bad idea, but unfortunately, the Unicode characters used to represent > threads in mutt's index seem to be some sort of ncurses-special They are not--they're standard Unicode (IIRC they can also be replaced by ASCII characters with a config option, but I don't recall the details). If this is a limitation for you, perhaps if you explain the context of the limitation, we can help you overcome 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: Visualising contents of a Maildir
On Thu, Aug 18, 2022 at 09:17:11AM +, Sam Kuper wrote: > On Wed, Aug 17, 2022 at 04:59:41PM -0500, Derek Martin wrote: > > On Wed, Aug 17, 2022 at 09:33:44PM +, Sam Kuper wrote: > >> On Wed, Aug 17, 2022 at 09:22:31PM +0200, martin f krafft via Mutt-users > >> wrote: > >> > For reasons you don't want to know, > >> > >> You may be underestimating the curiosity of your audience. > > > > I suspect what Sam really meant was, "For reasons that would make you > > sad if you knew..." =8^) > > I think you mean Martin rather than Sam, but that's OK :) Indeed! :) > >>> Is there a way to "screenshot" the Mutt index beyond the scroll > >>> window? > >> > >> Why would you need to? In what way does Mutt itself not meet your > >> requirements? > > > > Presumably because in order to *share* such a visualization, i.e. with > > someone remote, they would have to have a copy of the inbox AND run > > Mutt. > > Or they could just use SSH. SSH is ubiquitous. But outside of tech circles, the ability to use it is not. If you've ever sat in a meeting with a bunch of pure management types, you'll understand why this suggestion is a non-starer. Likewise for your other suggestions. -- 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: Visualising contents of a Maildir
On Wed, Aug 17, 2022 at 09:33:44PM +, Sam Kuper wrote: > On Wed, Aug 17, 2022 at 09:22:31PM +0200, martin f krafft via Mutt-users > wrote: > > For reasons you don't want to know, > > You may be underestimating the curiosity of your audience. I suspect what Sam really meant was, "For reasons that would make you sad if you knew..." =8^) > > Is there a way to "screenshot" the Mutt index beyond the scroll > > window? > > Why would you need to? In what way does Mutt itself not meet your > requirements? Presumably because in order to *share* such a visualization, i.e. with someone remote, they would have to have a copy of the inbox AND run Mutt. This is not typically desireable, when essentially the equivalent of sharing a document is the sole purpose for it. Presumably what you'd want is an image or document that contains the desired visualization, that can be displayed by some common tool available to the general community, like a web browser, company-installed word processor or similar productivity app, etc.. Mutt could still meet the need, though it would be some work. You could screenshot each individual page of the index, and then use an image editing program to assemble them together. Maybe--if the resulting image was not too large for your application to handle. Or you could just paste each image into a document in a word processor, one image per page... It might be possible to create a virtual desktop large enough to display the entire index at once, and then use imagemagick or similar to capture the window to a file, but I suspect there again you may run into memory problems. I'm not sure any of those qualify as "something 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: Using several SMTP servers
On Thu, Aug 11, 2022 at 06:23:56PM +0200, Sébastien Hinderer wrote: > Dear all, > > Sorry if the question is off-topic, hopefully not completely though. > > I am wondering what's the best way to use different SMTP servers to send > mails, depending on which e-mail account I am currently using (the From > address). There is arguably no best way; the best way *for you* will be specific to how you use mail. There are a number of ways to do this, but I think the two most workable ones are: 1. Use hooks (e.g. folder-hook, send-hook, etc.) to set the variables for your smtp configuration, based on the folder you're in, the recipient you're sending to, etc.. See the mutt manual for more details on how to use hooks. 2. Use a macro, bound to some key, that changes the variables when you press it. Again, the manual will have the details, but you might want to have a look at this: https://gitlab.com/muttmua/mutt/-/wikis/MuttGuide/Macros There are other ways, like starting mutt with a different config file, etc., and probably more that I haven't thought of, but I think one of the two above will be easiest to manage. -- 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: macro does not work when mailbox opened read-only
On Fri, Jul 29, 2022 at 08:15:31AM +0200, Fourhundred Thecat wrote: > Hello, > > I have custom macro "q" for exit: > > macro index q ";" > > but when I open mailbox read-only, I am not able to exit from mutt: AFAICT this macro does nothing useful--the normal quit (normally bound to 'q') already syncs before quitting. But you can't sync a read-only mailbox so just exit instead (normally bound to 'x'). -- 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: mutt, MH, and next message number
On Wed, Aug 03, 2022 at 10:04:37AM -0700, Kevin J. McCarthy wrote: > On Wed, Aug 03, 2022 at 10:12:39AM -0400, hy...@nasalinux.net wrote: > > So, even though I have renumbered all of my emails to be 1-1, mutt > > still sees the deleted former-email numbered 56789 and uses that in the > > "next message number" process. > > > In other words ... was this done on purpose ... and if so, why? > > Perhaps Mutt was concerned about a client that might "undelete" by just > removing the leading ',', but I don't know without more research. This was my immediate reaction as well, and indeed this post suggests that is exactly how undelete is handled for mh mail (when possible): https://rand-mh.sourceforge.io/book/mh/rem.html Though it does talk about manually finding new message numbers if need be. I don't use mh mail with Mutt (or at all) but presumably Mutt wants mh folders to work like other types. So you delete messages, Mutt puts ',' in front of the file name. You undelete, Mutt moves the file back to its original name without the comma. You expunge and Mutt deletes all the files starting with a comma. Would need to read the code (for the first time) to confirm, but it's a plausible and sensible explanation. I suppose the most important detail would be what the mh tools (or procmail, or whatever you're using to deliver the messages) do when delivering new mail to those folders... Does it skip numbers on messages starting with a comma, or not? The other consideration would be, does anything care about the message number? In other words, if you undelete a message, and it gets a new message number, different from its original message number, does that negatively impact anything that might have known about the old message number? If messages are routinely renumbered, I'm guessing not, but I wouldn't know. Does header cache work with mh, and would that be impacted? -- 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: [RFC] Remove additional spaces when quoting already-quoted lines
On Mon, Aug 01, 2022 at 10:40:22AM +1000, raf via Mutt-users wrote: > On Sun, Jul 31, 2022 at 01:47:06PM -0400, Kurt Hackenberg > wrote: > > set indent_string = '>' > > > > You could argue that should be the default value of $indent_string. > > Not successfully. Changing a default affects all users who are > obviously happy with the default and forces them to "fix" their > configuration to put it back the way it was. There is rarely a good > reason to do that. A recently discovered security flaw is a good > reason, but that's about it. I concur 100%. Changing defaults--particularly ones such as this, which is a long-standing convention used by the overwhelming majority of e-mail users--needs a very strongly compelling justification. A random group of individuals who do not like the aesthetic of the current long-standing convention does not constitute such a reason. Note that changing this does not impact only the sender; in fact it primarily affects the receiver, who may, for instance, be running a custom filter that expect the well-established convention, and breaks on those rare occasions when the sender does something... eccentric. More likely, it may simply give some users difficulty in figuring out who said what, because it makes lining up the levels harder, visually. If anything, I would argue in favor of enforcing the convention and removing configurability entirely, for that reason. But I'm not draconian enough to make that argument seriously. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: > On Thu, May 19, 2022 at 12:36:39PM -0500, X Tec wrote: > > set sendmail="/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > > ~/.user.gpg)" [...] > > Hope someone else could give other advise, or if this is really not > > possible in Mutt, to confirm *why*. > > Sorry, this isn't currently possible in Mutt. The $sendmail variable is > handled specially: it's tokenized by space and invoked directly via > execvp(). So you won't be able to use arguments with spaces in them inside > the variable, or any shell quoting since it doesn't pass through the shell. Couldn't you do something like the following? set my_sendmail=/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d ~/.user.gpg)" set sendmail=$my_sendmail Don't know, haven't tried it, but as long as the first thing evaluates to something that sendmail's tokenization can handle, seems like it should work... -- 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: [OT] fetchmail replacement supporting Oauth
On Tue, May 03, 2022 at 01:07:07AM -0400, José María Mateos wrote: > On Mon, May 2, 2022, at 23:25, lilydjwg wrote: > > Google doesn't disable app passwords (requires 2FA). Google is going to > > disable account passwords login at the end of this month.[1] > > > > I've switched to OAuth because I don't want to enable 2FA (which means > > if I lost all my devices, I would lose access to my Google account). > > Your concern is valid, but I think there are ways around it You're on vacation. You probably didn't bring a laptop, because... you're on vacation. You go out and leave your phone somewhere, never to be seen again. Now what? This happened to me. It's the biggest reason I hate that Google has become so insistent on 2FA. In this situation--just when you need it most--you completely lose access to your google accounts, until you return home. If this is day one of your 2-week vacation... :( -- 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: Character encoding settings with display_filter
On Mon, Apr 25, 2022 at 11:08:41AM +, Joel Buckley wrote: > Hi all, > > I have been using mutt for some time on a VT510 terminal (similar to > https://en.wikipedia.org/wiki/VT520), and enjoying it. An actual serial hardware terminal? Those are getting to be rare beasts indeed... ;-) > The display does not support UTF-8, so I had > LC_ALL="en_US.ISO8859-1" in my ~/.profile. This worked well for > mutt. So here you say the terminal doesn't support UTF-8... > I then discovered that by changing mutt to load with > LC_ALL="en_US.UTF-8" that all was well. Huh? These two things seem to be contradictory... Also, I'm assuming this message was sent from Mutt NOT using your non-UTF-8-supporting terminal, since it is indeed encoded in UTF-8 and contains actual UTF-8 characters... Anyway, getting back to the normal order of things... > However today I received an email with the string "Don=E2=80=99t > know when I will be there next.". This should display as something > like "Don't know where I will be there next.". In my mutt terminal, > it displayed: > > "Don???t know when I will be there next". The issue is that there are no curly quotes in iso8859-1. Both Windows and Mac support a modified version of iso8859-1 that includes curly quotes, but unfortunately use different character codes for them. These character sets have their own names, but frequently mail applications are misconfigured to label them iso8859-1, because they're mostly identical and it works most places--as long as you're on the same platform as the sender. > Thinking this was odd, I dove into my filter.sh script, and > discovered that no end of hacking would enable me to filter out the > '=E2=80=99' before display --- there seemed to be some amount of > parsing before my filter got ahold of it. All that I could match on > was '???', despite being able to edit the content of the mail > itself, and see the string '=E2=80=99'. My filter line of > significance is: > > output=`echo "$output" | sed "s/[’‘]/$(echo "27" | xxd -p -r)/g"` > This replaces 'smart quotes' with their ASCII equivalents. Given that you already have a display filter script, this isn't a horrible solution--assuming it actually worked. Note that you have a couple of harmless bugs though: 1. You've doubled up your double quotes, so actually 27 is not quoted. It's harmless, but you don't need this anyway: 2. You needlessly fork two additional processes--one for the subshell for echo, another for xxd. This can be greatly simplified to: echo "$output" | sed "s/[’‘]/'/g" Presumably you avoided this because the single quote is "special" to the shell, but since in this case it is enclosed in double quotes it loses its specialness. > Thinking that this would be a matter of ensuring that the filter > script had the right character support, I added "export > LC_ALL="en_US.UTF-8"" to the top of my filter script, however this > did nothing for me. Your filter script will run with the same locale as mutt, since it is a subprocess--it inherits the locale from its parent. So if mutt were indeed started with LC_ALL=en_US.UTF-8 then so too will your display filter. But you shouldn't need to do any of this... > After some messing around, it seemed that the > only way to get mutt to support the filtering of my problematic > string was to call mutt itself with the required character encoding > (UTF-8). What character set is the message itself encoded with (according to its headers)? If your terminal is set up right, and the charset on the message is correct, then Mutt should be taking care of this already for you by running iconv on the message. Basically, except in rare cases, if your terminal is set up properly, you shouldn't ever need to deal with character sets explicitly. > Is this correct and best-practice, or have I missed something here? > My installation is currently working by using the 'export > LC_ALL="en_US.UTF-8"' line in my ~/.profile, however this feels like > bad practice Because it is. But I think you may have one of the rare cases. I think what's happening is Mutt is correctly running iconv to convert your message from UTF-8 (which it most likely is in) to iso8859-1, which partially fails due to the annoying curly quotes, and then passes it to your filter script, which runs on that but it is already converted to '?' due to the character not having an equivalent in iso8859-1. Assuming that's true, the only thing I can think of is an old trick that iconv supports, which I vaguely remember using in Mutt *ages* ago. Try explicitly setting $charset *IN MUTT* to ISO-8859-1//TRANSLIT, which might or might not help. But it's likely to have other negative effects... -- 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:
Re: How can I hide non-matching emails in a search
On Tue, Oct 26, 2021 at 07:53:28AM -0700, Lee wrote: > Can you use the pipe function on specific fields, like subject, from, > date...? You can, indirectly, by writing a script that does it, and using pipe to call the script. It might be easier to use ignore/unignore to only show the headers you care about, if it's always the same specific set. If there are different sets you care about in different situations, you could even do something crazy like define (only) those in different .muttrc files, and then define macros to load the different files... -- 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: question/suggestion
On Mon, Oct 25, 2021 at 08:13:15PM -0400, John Hawkinson wrote: > Derek Martin wrote on Mon, 25 Oct 2021 > at 19:00:12 EDT in <20211025230012.gc9...@bladeshadow.org>: > > > Cost? I see no cost, other than the time needed to physically check > > My Oct. 7 email, to which you replied, enumerated several costs that I > perceived. > That you go on to state that you perceive no costs, without > addressing the costs explicitly raised by others I did actually, at some length. You enumerated two: Subject line length, and mantenance/usability concerns. Regarding line length, I indicated I agree entirely, and also later pointed out this lends support to dropping the address from the subject line by default... Regarding the second, you yourself already had pointed out it's a one-time change, which I felt no need to repeat. I did explicitly say I strongly suspect that a large majority of Mutt users have already set forward_format to something akin to what I was proposing--directly implying it very likely would be a no-op for many if not most users. I also pointed out the ubiquity of having "Fw:" or "Fwd:" at the start of the subject, from which it follows that this is not something that users would need to "figure out how to get used to..." So yes, I addressed both of your enumerated perceived costs, though perhaps I did not spell out that I was doing so as expressly as you apparently needed. [I also doubt very much that most users care AT ALL how forwarded messages get attributed by default. I myself only care what the default is because I care about design principles in general, and specifically their application to Mutt, and see "Fwd: %s" as a better default from a design perspective for reasons I've already argued.] > I'm not clear if there the proposal on the floor is the initial one > to add Fw:, or the subsequent one to "conform" to Gmail and Outlook > by removing the email address I admit this could've been made clearer. I nearly sent clarification of that after I sent that, but decided the intent was clear enough from what I said, if the reader read the whole message, since I explicitly stated what I supported in the last paragraph. > To add something new without repating my prior comments: I find > value in having the address of originator of the forwarded message > appear in the Subject line, because it makes clear, deep into an > ensuing thread, that "we're talking about [Steve]'s message." It's easy enough to infer this from your argument, and I already addressed this point as well. The address is already in the attribution (and typically again in quoted envelope headers), so it's redundant; redundant info has no additional value, by definition. You might argue it saves you the cost of pressing enter to render the first screenful see the attribution, but that's just about as close to zero cost as it gets. Slightly more expensive over IMAP but typically not much. In almost a decade of supporting e-mail users, not one ever asked me if there was a way to get the original sender's e-mail in the subject line (regardless of their chosen e-mail client). I don't think in the typical case it has any value whatsoever to the typical user. An additional point, which I did not make, is that in a long thread as you describe, there are likely multiple messages from the same sender, all of which may have been forwarded, and any of which may have been forwarded multiple times, leading to cases where the e-mail address in the subject line truly adds no useful context, and may even detract from it if that info is somehow valuable to the user. It does not uniquely identify which message from that sender was forwarded, nor does it even accurately indicate who the author of the principal content actually was. It merely indicates who the last person who touched the thread was when your sender forwarded the message. > > In the context of a subject line, a leading "fwd" (regardless of > > case) is very unlikely to be confused with anything else, due to > > ubiquity of the convention. > > Confusion seems a red herring. No one has credibly suggested that > any of the options, current or extent, proposed or in use, are > confusing to anyone at all. I specifically called out the case of FW: (which may well refer to firewalls, and indeed in messages I frequently received in the past did mean exactly that.) So not a red herring, though YMMV, and I would certainly agree that my (genuine) past confusion was fleeting, but nonetheless did occur on a somewhat regular basis, as the manager of my company's firewalls. -- 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: question/suggestion
On Thu, Oct 07, 2021 at 11:52:02PM -0400, John Hawkinson wrote: > ಚಿರಾಗ್ ನಟರಾಜ್ wrote on Thu, 7 Oct 2021 > at 23:32:00 EDT in : > > > Any email client (including mobile email clients) worth its salt is > > going to wrap the subject line (at least in the email view, if not > > in the index view), so that shouldn't really be an issue, right? > > My principal concern is with the index view. And none of the 4 email > clients I use wrap the index view (mutt, Gmail web, Gmail mobile, > Outlook web), nor would I want them to (because then they'd be > taking too much vertical real estate, too). I completely agree with this. > > That's true. However, convention is *also* important, > > Unsupported argument. Hardly... "Principle of least surprise" is so well understood a design principle that not explicitly mentioning it can hardly be considered failing to support the argument. It's very nearly a tautology: Honoring convention is one of the most obvious ways to avoid surprising the user. > > and Mutt's convention is...unconventional. > > Not particularly. I completely disagree with this. The length of time and extensiveness of context in which I've used e-mail suggests that it's pretty unconventional, even amongst Mutt users, despite it being the default. > > Why shouldn't Mutt do the same? > > We should do the best we can, and if there is a situation where > there is strong value in conformance, we should consider the costs > and benefits to conforming. The benefit of conforming is: 1. Principle of least surprise. 2. Clearly indicates the message is forwarded with a relative minimum of extra information (minimal subject line pollution). 3. Avoids additional pollution of the subject line with redundant information (the original sender's e-mail address). When Mutt forwards a message it produces an attribution line, which by default contains the original sender's address. It need not be in the subject line--in fact it has no place there, as it has nothing to do with the subject, and only pollutes that already real-estate-deprived field. That is, unless the forwarder feels the need to call out the identity of the original sender, as more important than the actual content of the message, which can happen but should be exceedingly rare. Presumably what is being said is far more important than who originally said it, in the vast majority of cases. I've had my forward_format set for so long I'd forgotten it wasn't what the Mutt default was, as I suspect most people have. I think it was set in one of the typical places people copy their base Mutt configs from, and I, like probably many Mutt users, simply copied it. That brings us to the purpose of defaults: Good default configuration values should save the typical user time and reduce exceptional cases, making your software easier and less time-consuming to configure for the most people, and easier to support for developers, by reducing the likelihood that some obvserved bug is caused by some obscure setting that really ought not to have been set. This is, FWIW, in large part why I have vehemently argued against configuration variables being added to Mutt for the last ~25 years, except when there's a clear case of benefitting a fair number of users. The fewer variables you have, the less of this is possible. Cost? I see no cost, other than the time needed to physically check in the change, and the small chance of botching the change along with the consequences of that. As far as I can tell using some variation of Fwd: %s is what the overwhelming majority of e-mail users are already doing. I would personally prefer "Fwd" to "FW" because years of admin/support cause me to associate the latter with firewalls. It's slightly less ambiguous at the cost of one character. In the context of a subject line, a leading "fwd" (regardless of case) is very unlikely to be confused with anything else, due to ubiquity of the convention. I don't know if this warrants the effort to change the default; however if someone is intent on making a change, I think that the above makes the case that it should be "Fwd: %s" (or some similar variation of an abbreviation of "forward"). -- 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: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 10:20:09PM -, Grant Edwards wrote:
> On 2021-02-12, Derek Martin wrote:
> > On Fri, Feb 12, 2021 at 05:09:36PM -, Grant Edwards wrote:
> >> On 2021-02-12, Derek Martin wrote:
> >> >>> as I would have to be monitoring the logs to make sure the e-mail
> >> >>> was actually sent.
> >> >>
> >> >> You do (or you need to make sure that you receive bounce/retry/failure
> >> >> notices properly).
> >> >
> >> > You don't... every major MTA has a tool for monitoring the outgoing
> >> > mail queue. You just run it and it tells you if there is any pending
> >> > outgoing e-mail.
> >>
> >> To me that seems pretty much equivalent to "monitorying the logs".
> >
> > I think the difference is monitoring the logs is something you have to
> > actively do, which means you also need to remember to do it...
>
> Ah, I see. I assumed that that "monitoring logs" was something one
> would do with an automated tool/script.
I mean I suppose so... but that seems much more involved than just
numreqs=`mailq |grep 'Total' | awk '{ print $3 }'`; if [ $numreqs -ne 0 ];
then echo "mail queue has $numreqs requests queued"; fi
[Exact details may vary from system to system, but should be pretty
similar to this one-liner in general.]
You'd have to figure out what your logs actually look like when queued
mail isn't getting delivered, then install and configure your tool to
monitor for those logs... which might be prone to break if your MTA
gets upgraded. Still not quite equivalent--it wouldn't be my choice.
Then I'm not sure but IIRC some MTAs don't log about queued mail not
getting delivered until it has failed to deliver for some time. If so
you would not get timely results, not like what the OP is looking for,
so in that case it wouldn't be an adequate solution anyway.
--
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: My experiences with Mutt to date: Suggestions for overcoming some issues
On 01Feb2021 16:03, ಚಿರಾಗ್ ನಟರಾಜ್ wrote: > sending emails might well be time-sensitive, and I _need_ to know > that it went through (or get immediate feedback if it fails). So let's be clear: If you have time-sensitive communications that need to be delivered immediately, reliably, you should almost certainly not be using e-mail for them. Just becaue your mail client is able to hand off your message to your outgoing mail gateway in no way means that it is guaranteed to be delivered quickly, or even at all... Delivery may still fail or be delayed due to intervening mail servers' load, connectivity, hardware failures, botched configuration changes, etc., and in all likelihood you won't know anything about it. If you can not accept this, you must not use e-mail to deliver your message. If you can accept this, then having the message queue locally on your machine is less of a risk than having it queue on any other SMTP node along the way, because you can actively detect such problems and potentially do something to fix them, whereas in all other cases you simply can not. And the reality is, once your networking and your MTA is configured correctly, as long as your internet connection is working, your mail will go out, and will continue to go out so long as you don't muck with things and subsequently botch them. If you do make subsequent changes, of course you will need to test them... -- 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: My experiences with Mutt to date: Suggestions for overcoming some issues
On Fri, Feb 12, 2021 at 05:09:36PM -, Grant Edwards wrote: > On 2021-02-12, Derek Martin wrote: > >>> as I would have to be monitoring the logs to make sure the e-mail > >>> was actually sent. > >> > >> You do (or you need to make sure that you receive bounce/retry/failure > >> notices properly). > > > > You don't... every major MTA has a tool for monitoring the outgoing > > mail queue. You just run it and it tells you if there is any pending > > outgoing e-mail. > > To me that seems pretty much equivalent to "monitorying the logs". I think the difference is monitoring the logs is something you have to actively do, which means you also need to remember to do it... and most of the time it's a waste of your time. Instead, using this method, you don't actively need to do anything... when something noteworthy happens you'll be notified via a mechanism you're already using anyway. For me, that's a world of difference... not at all equivalent. > > If this is a concern, you can run it periodically from cron (or > > whatever), in such a way that it only e-mails you when there are > > issues (i.e. pending mail). If you find some messages are > > lingering, then you can go look at your logs to figure out why. > > Again, that's far more complicated that waiting one or two seconds > after you hit 'y', and seeing whether the message was sent or not. I don't really agree... it's something you set up once and mostly forget about. In today's well-connected internet, probably lots of people could do this and never interact with it ever again. TBH I don't bother doing even this anymore, because I just haven't had an issue with mail delivery in well over a decade... > > YMMV. I have maintained my own server for ~20+ years now and the only > > time I've had issues was when I was running it on consumer broadband > > and people started using blacklists that included essentially all > > known consumer broadband networks to block spam (whther it was or > > not), > > That is probably the main problem for most mutt users. The only > practical way for must of us to run an MTA is for it to always send > via one reliabe SMTP server with authentication. Sending mail directly > to recipients has been off the table for residential consumers. I definitely agree. It's an annoying problem. This really should be a lot simpler, but it's a case of a few bad actors ruining things for the rest. Yay. But anyway, IMO you can do this just as easily by setting up your local MTA to forward to your ISP's gateway as by using Mutt's SMTP support or some other mini-MTA, with the benefit that if you're writing e-mail on your laptop when you're not able to have internet connectivity, it will queue locally and still get delivered later once you can talk to your ISP's gateway again. This feature won't be impactful for everyone, but it is definitely useful. With most modern MTA software this is pretty trivial to configure, and tutorials on how to do it for your MTA of choice abound. > > It does have a down side though... if your recipient's mail gateway > > is down or unreachable, sending your mail will fail, and you'll have > > to try again manually, until it eventually succeeds. > > Maybe I'm just lucky, but I can't ever remember the last time that > happened. Right... Things have gotten a lot better / more reliable over time. This used to be a common problem, but no longer. If it's not clear I'm not saying what you're doing is garbage. :) But I am saying that both approaches have benefits, and I think the drawbacks to the MTA approach may not be as severe as you seem to suggest, in practice, for the majority of Mutt users. I would not suggest something like this to, say, my mom... ;-) -- 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: My experiences with Mutt to date: Suggestions for overcoming some issues
On Mon, Feb 01, 2021 at 04:34:47PM -, Grant Edwards wrote: > On 2021-02-01, José María Mateos wrote: > > I was thinking about this. I have offlineimap running, so I have a > > local copy of all my mail, but the SMTP connection still goes > > through my mail provider, not locally. While I can appreciate the > > increase in speed that a local rely can offer, I wonder if it > > doesn't add another layer of complexity In terms of the delivery process, it doesn't add a layer of complexity, it just adds a hop. SMTP is designed to work this way... If you look at the headers of all of your incoming messages, you might see half a dozen or more Recieved: headers on them. Each one which isn't your senders' outgoing mail gateways or your incoming mail server represents an MTA your message travels through to get from them to you. The only control over this which you have is which server your own outgoing messages hit first: A local MSA/MTA, your ISP's or organization's outgoing mail relay, or your recipients' first-hop MX mail server. If your connection to the internet is reliable, it makes very little difference which one, in almost all cases. No added complexity--just potentially additional hops. There may be extra complexity in the software you have to manage, for your outgoing mail to work, though. > > as I would have to be monitoring the logs to make sure the e-mail > > was actually sent. > > You do (or you need to make sure that you receive bounce/retry/failure > notices properly). You don't... every major MTA has a tool for monitoring the outgoing mail queue. You just run it and it tells you if there is any pending outgoing e-mail. If this is a concern, you can run it periodically from cron (or whatever), in such a way that it only e-mails you when there are issues (i.e. pending mail). If you find some messages are lingering, then you can go look at your logs to figure out why. > > How does it work when the remote e-mail server is not available or > > it returns some kind of error. Can one receive local messages that > > notify of a problem? > > If you set up your local MTA properly, yes. In practice you probably won't do this, unless you have the luxury of operating a relay that is purely for outgoing messages that can't receive mail from the internet. Otherwise the reality is you'll get tons of bogus bounce messages that are just spam. Or perhaps you'll use some spam filtering to figure out which bounce messages actually matter... There are better alternatives, like what I described above. > My internet connection is reliable enough that the benefits of knowing > that each email has actually been sent _far_ outweigh the > inconvienience of having to manually resend something once every 5-6 > years. YMMV. I have maintained my own server for ~20+ years now and the only time I've had issues was when I was running it on consumer broadband and people started using blacklists that included essentially all known consumer broadband networks to block spam (whther it was or not), and when I had a connectivity outage. For the most part the mail system will automatically recover from outages, so that wasn't a big deal... mail got delivered the first time the queue was run after connectivity was restored. Moving to inexpensive hosting solved the other problem--I haven't had any issues for well over 10 years... If you're using your ISP's gateway, you should likewise not have any issues, unless they are just bad at it. > > So far I like my current solution because it avoid this: sending an > > e-mail takes a few seconds (very few, 2 - 3 tops) but when the process > > is done on mutt I know the remote server has the e-mail. It does have a down side though... if your recipient's mail gateway is down or unreachable, sending your mail will fail, and you'll have to try again manually, until it eventually succeeds. If you use an outgoing mail relay it fixes this for you by periodically retrying the message. This is pretty rare these days though so it probably won't matter to you very much, unless you have frequent recipients with proven unreliable mail gateways. -- 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: How to remove `To: undisclosed-recipients: ;`?
On Thu, Feb 04, 2021 at 11:09:40AM -0600, Peng Yu wrote: > I want to remove `To: undisclosed-recipients: ;` in the generated > message when no To or Cc recipients are specified. I don't see an > option to do this in the manual. Could anybody let me know if there is > an option to remove it? Thanks. There isn't. This is intentional; all messages should have a named recipient. This isn't just for mail delivery; it's so recipients know who the message is primarily intended for. Using "undisclosed recipients" instead clearly indicates that the sender intended for a distribution list of people who are not explicitly named--they need not and perhaps should not know about each other. If you don't want that, you can name yourself as the recipient. -- 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: How does mutt know to automatically choose charset?
On Thu, Feb 04, 2021 at 08:42:31AM -0600, Peng Yu wrote: > mutt can adjust the charset based on the input. But it seems that > EmailMessage from python can not do this automatically. How does mutt > choose the charset automatically based on the content? Thanks. You pasted the answer: > Content-Type: text/plain; charset=us-ascii ... > Content-Type: text/plain; charset=utf-8 As long as your terminal supports the specified content-type encoding in some fashion (including by being configured to use Unicode, which usually includes all of the necessary characters from all character sets), mutt uses these fields to re-encode the message content using the iconv program on your system. -- 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: not to set message id in outgoing email
On Wed, Feb 03, 2021 at 08:23:18PM -0600, Peng Yu wrote: > On Wed, Feb 3, 2021 at 11:23 AM Will Yardley > wrote: > > > > On Wed, Feb 03, 2021 at 08:57:32AM -0600, Peng Yu wrote: > > > > > > When I use mutt to construct an outgoing email, is there a way not to > > > set the message id? Thanks. > > > > Even if Mutt doesn't set one, the first MTA it hits will add one. > > I want the first MTA add one, instead of using the one generated by mutt. OK, but that's not really an answer. What problem are you trying to solve with this behavior? -- 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: not to set message id in outgoing email
On Wed, Feb 03, 2021 at 06:33:37PM +0100, Claus Assmann wrote: > On Wed, Feb 03, 2021, Will Yardley wrote: > > > Even if Mutt doesn't set one, the first MTA it hits will add one. Not > > Not really - a MTA should not make such changes. A MSA should do > it, I'd say this is needlessly nitpicky--MSA is a relatively recent addition to the suite of conceptual mail agent functions. Many of us will often ignore the distinction between MTA and MSA because they formerly weren't seperate functions, and to a large extent they still aren't: All major MTAs ARE ALSO MSAs, submitting a message IS transmitting the message (even if only locally, from the user's client to the outgoing mail queue), and on most Unix systems they are indeed still the same software package (if not in fact the same program) performing both functions. The difference mostly amounts to a different port (if using TCP transmission) and some extra authorization, but is otherwise essentially the same. For most mail admins, the distinction is rarely interesting. For most users, the only time the distinction actually ever matters is when you're initially configuring your mail client. And for many of us, even then it doesn't matter--it is in fact the same program and it handles whether it is an MSA or MTA internally. > but Message-Id: is a SHOULD not a MUST. This point is also technically true, but largely irrelevant... Partially because of the above, but mainly because in practice many aspects of managing mail may or do depend on a message ID and will break without one (logging / indexing / archiving / virtual folders, client-side threading, etc.). Even if the RFCs describe it as an optional field (which as you point out, they do) it is still a de facto standard that every piece of mail-related software I've ever touched expects and/or enforces. Whether or not you personally think MTAs should add message ID headers to messages which lack them, historically they generally have, and AFAIK most (if not all) still do. They're fairly important. So to answer the original question: - AFAIK there is no way to cause Mutt to generate a message without adding a message ID, without altering its code - You should not do that; your recipients most likey need that, and you likely have no idea how they are using it (and probably they don't either). - It probably won't have much of a practical effect, even if you do, because whatever you're submitting the message to will probably do it anyway. -- 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: Getting more useful information in file browser - possible with maildir?
On Thu, Oct 01, 2020 at 10:01:21AM +0100, Chris Green wrote: > On Wed, Sep 30, 2020 at 02:56:56PM -0500, Derek Martin wrote: > > On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > > > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > I can't say why Christian gets dates and proper sorting on > > his mail folder directories and you're not; that would take some > > investigation. I could guess that it might be that maildir-aware MDAs > > update the utimes on the folder directory when it delivers a file... > > and even if it's not that, you could do that in your MDA with > > os.utime(), which should force the issue. > > > Now that's a point, thank you, I see a small revision of my Python > filter coming up! :-) Great, hope that helps you out. Meanwhile... > > They may be maildirs, but in the file browser they are directories, > > for the purpose of navigating the file system. In that context, the > > fact that they are maildirs is not relevant: In the context of > > browsing files, you want info about the files, which is what Mutt > > gives you. This is somewhat configurable (see the manual about > > folder_format), but it's not going to give you any info about the mail > > that's in those directories... Wrong context. > > > But in the mutt/mail context they're mailboxes, Mutt doesn't have just one context, it has a number of them. That's why you have a file brower, a message index, a compose menu, etc... The jobs of those features are not the same, and the functionality provided by them is dependent on their function and the context in which they are meant to operate. The file selection dialog box in Thunderbird isn't going to give you mail-related information about maildirs it sees; but that is the same function and context of Mutt's file browser. > Surely mutt can take a look into directories and, if they're maildir > mailboxes, act accordingly and present the user with useful > information. Putting programmer hat on again, maybe make this an > option as it might take too long on slow systems. But as Cameron and I have both tried to point out to you repeatedly, even on a fast system, it's too expensive. Cameron showed the performance for just one large maildir, taking > 4s, on a fast system with SSD. If you have a lot of these, it's going to take on the order of MINUTES for mutt to calculate all the folder sizes, before it can show you the file listing... on the fastest systems available at consumer-level prices. On slower systems, you're looking at going to make a sandwich, and eating it, before the directory can be displayed. It DOES NOT MAKE SENSE to put this functionality in. The context of the file browser has nothing to do with mailbox management, and the properties of this style of mail store make it prohibitive, so doing it just for the sake of convenience is nonsensical--which is exactly why Mutt has never had it. I'm repeating myself now, but again, the only reason you get it with mbox is because in that case your folders just happen to be ordinary files--it's very fast to get file sizes directly from the file system, and displaying that info is relevant to the actual purpose of the file browser. It is not its purpose to display mail-related info in any capacity, and the overlap exists purely due to coincidental properties of that specific implementation (that is, all of the one-file-per-mail-folder variants) of the mailbox abstraction. With just about any other implementation, providing that information is prohibitively expensive. I haven't made this point yet since I regard it as almost irrelevant given the above, but I would also argue it's not particularly useful information, except in the context of disk space management--which has nothing to do with Mutt. Context is everything. -- 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: Getting more useful information in file browser - possible with maildir?
On Wed, Sep 30, 2020 at 02:21:22PM +0100, Chris Green wrote: > On Tue, Sep 29, 2020 at 09:49:52AM -0500, Derek Martin wrote: > > On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > > > The same place in a mbox hierarchy shows me the size of the maibox and > > > the date of the last change. > > > > You're looking at this all wrong. It's purely a side effect of how > > the mailbox abstraction is represented: you get that only because they > > just happen to be files--exactly what the file browser was meant to > > handle. > > > "I'm" a user! :-) I want the information I used to get. That it's > "purely a side effect" of some technical change is unipoortant to the > user. Yes, with my techie hat on I understand why it is, but I can > also see that there are ways to get the information I want, albeit > with some more code. It's not just more code, it's expensive code, at least in some cases. Without reviewing the messages to get the exact details, I think some of what you want is doable, and some is really not. Some of it really isn't Mutt's purview, per se--it's your MDA's purview. I can't say why Christian gets dates and proper sorting on his mail folder directories and you're not; that would take some investigation. I could guess that it might be that maildir-aware MDAs update the utimes on the folder directory when it delivers a file... and even if it's not that, you could do that in your MDA with os.utime(), which should force the issue. Recursively calculating the space used by the mail folder, on the other hand... just no. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Tue, Sep 29, 2020 at 08:30:42AM +0100, Chris Green wrote: > On Mon, Sep 28, 2020 at 07:01:25PM -0500, Derek Martin wrote: > > On Sat, Sep 26, 2020 at 08:29:22PM +0100, Chris Green wrote: > > > > > This is by no means a show stopper, I'm going to stay with maildir, > > > > > but it woud be nice to be able to improve it a bit. > > > > > > > > I'd recommend using a "maildir browser" which knows how to interpret the > > > > information you're looking for (and which mutt is very good at). > > > > > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > > > which mutt is very good at", so is mutt a maildir browser? > > > > Translation: The file browser is for files (and directories, which are > > also files, albeit special ones) and tells you information that is > > generally useful for file-things. For mail, use the message index > > and/or the sidebar. Most directories *are not* mail folders, and > > therefore attempting to display information useful for mail folders on > > directories in the file browser is the Wrong Thing™. > > Yes, but maildir 'mailboxes' *are* directories [...] No, actually, they aren't. They're an abstraction that is composed of a multi-level directory structure, which as you have seen can be structured a couple different ways. The file browser is not intended to deal with that... it's for dealing with files, and allowing you to navigate around the file system. Sometimes that is so that you can select folders that happen to contain mail, like when you're using the change folder command, and other times it has absolutely nothing to do with that, like when you're saving file attachments. > and when I navigate to one in mutt the date is the date the > directory was created (nothing to do with the date(s) of the latest > mail in there) and no sizes or anything are displayed. Correct. Updating the message files will update its parent directory, but the maildir's top-level directory is not that directory. It's cur, or new, or tmp... Adding a sub-folder would, however, update the maildir's top-level directory. > For example I have a directory /home/chris/mail/folder/apexLodge/agm > which is a maildir:- > > chris@esprimo$ ls -l /home/chris/mail/folder/apexLodge/agm > total 12 > drwx-- 2 chris chris 4096 Sep 25 12:38 cur > drwx-- 2 chris chris 4096 Sep 25 12:38 new > drwx-- 2 chris chris 4096 Sep 25 12:38 tmp > chris@esprimo$ [...] > I have 'set folder_format="%N %-32.32f %m %n"'. I did have a date as > well but all that shows is 'Sep 25' the date of creation of the > maildir which is no use at all, it's just the date that the maildir was > created nothing to do with the dates of mail inside tne maildir. Yup. > The same place in a mbox hierarchy shows me the size of the maibox and > the date of the last change. You're looking at this all wrong. It's purely a side effect of how the mailbox abstraction is represented: you get that only because they just happen to be files--exactly what the file browser was meant to handle. You can't expect that different implementations of the abstraction will always have the exact same properties. If the mail was instead in a database, it would completely defy external inspection via file browser, though of course the file browser would still let you navigate to the on-disk files that comprised the database (assuming they're not on some sort of database-specific partition, like Oracle or other databases may use). You could get a hint about its size, but depending on the implementation, you may have no way to know what portion of those files comprised the database's indexes, views, internal structures, or other implementation-specific details. Different implementations have different properties, which provide different advantages and disadvantages. Maildir is not mbox. If you want mbox behavior, use mbox. -- 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: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 10:10:28PM -0400, Josef 'Jeff' Sipek wrote: > On Mon, Sep 28, 2020 at 18:55:51 -0500, Derek Martin wrote: > ... > > On Unix systems, at least > > for most file systems, the size of a directory is the space occupied > > by the blocks needed to hold the internal representation of the > > listing of the directory... > > Yes, the size on directories is essentially meaningless on POSIX systems (to > the user anyway). It's not *completely* useless... it does have one very useful function--the one it was intended for: It tells you exactly how much of your disk space was consumed by that directory's metadata. That might be useful to the user if, for example, they have a disk quota. Such things are rare these days but probably still exist in places like universities, or other such places where computing resources are shared amongst a community of users who don't necessarily have a vested interest in conserving the limited resources... -- 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: Getting more useful information in file browser - possible with maildir?
On Mon, Sep 28, 2020 at 06:09:49PM -0700, Kevin J. McCarthy wrote: > Yes, Olaf Hering submitted a patch in 1.10, zeroing out the directory size > for the reason you site below: > > > However the size of a directory is very likely not what you think it is, > > and is not particularly useful to you. On Unix systems, at least for > > most file systems, the size of a directory is the space occupied by the > > blocks needed to hold the internal representation of the listing of the > > directory... NOT the size of the contents of the directory. > > I don't feel strongly one way or another, but the listing does look a bit > cleaner with the (useless) sizes zeroed out. Feel free to bring it up on > mutt-dev if you feel it should be changed back. I see... Well, I would say I don't really get the point or the motivation for displaying 0K instead of the actual value... If users thought to put it in their folder format, presumably they actually cared about that info, and now they can't have it... I don't see that this change saves anything either--you still have to stat() the directory to get the other info (like access times) so you already will have the info anyway. You could remove %s from folder_format, but I s'pose people still want it for the sizes of files. Or, perhaps a new format specifier like %S (I'm not bothering to check if that's available for folder_format) which displays the size for files, but displays nothing for directories... But honestly, if you're already displaying sizes for files, it seems to me that not displaying directory sizes will just look weird. No one noticed for over 2 years (that I recall hearing about anyway), so I'm not sure that it matters in practice, but from a purely philosophical standpoint, do I feel strongly about actively choosing to display information that's factually wrong, especially when the only upside (as far as I can see) is a completely subjective cosmetic improvement. If I'd noticed, I certainly would have argued against it. But, I didn't... =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 08:29:22PM +0100, Chris Green wrote: > > That's most likely a "last edited" date. Adding flags or labels to a > > message would have reset that time as well. These directories were last > > edited on the date you created them, so not much is going to change > > that. You'd want access time, but that isn't reliable anyways (see > > relatime and noatime mount options) because it makes reads potentially > > very expensive writes to update atimes all the way up the tree. Whether you'd want mtime or atime (last modified time, last access time) is perhaps debatable... One tells you when you (or more accurately, *something*) looked at the file (e.g. read your mail), the other tells you when it was last updated (e.g. mail was delivered there). > > > This is by no means a show stopper, I'm going to stay with maildir, > > > but it woud be nice to be able to improve it a bit. > > > > I'd recommend using a "maildir browser" which knows how to interpret the > > information you're looking for (and which mutt is very good at). > > > ?? I'm a bit lost here, you recommend a "maildir browser" and say "... > which mutt is very good at", so is mutt a maildir browser? Translation: The file browser is for files (and directories, which are also files, albeit special ones) and tells you information that is generally useful for file-things. For mail, use the message index and/or the sidebar. Most directories *are not* mail folders, and therefore attempting to display information useful for mail folders on directories in the file browser is the Wrong Thing™. Mutt could perhaps special-case the ones it knows (via configuration) are mail folders, but main purpose of showing directories in the file browser is to navigate them, and I suspect most users rarely look at most of the info on directories in the file browser for that reason... So that still seems like the Wrong Thing™ to me. [The fact that no one seems to have noticed/reported the file size bug for at least a year seems to support that, too...] -- 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: Getting more useful information in file browser - possible with maildir?
On Sat, Sep 26, 2020 at 05:02:08PM +0100, Chris Green wrote: > However there is a minor downside in the file browser (well directory > browser really isn't it), the information shown against the > directories (at the bottom level these are maildir mailboxes) is > pretty useless, what I am seeing now is like the following:- > > selling/ Sep 25 12:39 0K > shopping/Sep 25 12:39 0K > software/Sep 25 12:39 0K > telecoms/Sep 25 12:39 0K > > No size information and the date is just the date of creation of the > parent directory, not the latest message. With mbox you get a 'last > message' date and a meaningful size. They may be maildirs, but in the file browser they are directories, for the purpose of navigating the file system. In that context, the fact that they are maildirs is not relevant: In the context of browsing files, you want info about the files, which is what Mutt gives you. This is somewhat configurable (see the manual about folder_format), but it's not going to give you any info about the mail that's in those directories... Wrong context. There IS size info, although it's wrong... That appears to be a bug introduced some time after 1.9.4, which I have lying around, that has it right. I also have 1.12.2 where it is wrong, so... somewhere in between. However the size of a directory is very likely not what you think it is, and is not particularly useful to you. On Unix systems, at least for most file systems, the size of a directory is the space occupied by the blocks needed to hold the internal representation of the listing of the directory... NOT the size of the contents of the directory. The size increases with the number of files in the directory (but not their size), and it is a multiple of the disk block size, so it's almost always (exactly) 1K, 4K, 8K, 16K, or an exact multiple thereof... Mutt could, in theory, get the size of the contents of the directory for you... but in order to do that it would need to do the equivalent of du -s ON EVERY SUBDIRECTORY IN THE DIRECTORY YOU ARE BROWSING, which is prohibitively expensive, no matter what hardware you are on. If you had that feature, I'm fairly positive you would turn it off immediately. I don't think any sane maintainer would commit a patch for that... -- 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: Can mutt be persuaded to use a sensible maildir hierarchy?
On Fri, Sep 25, 2020 at 01:33:24PM +0100, Chris Green wrote: > Just to report success. It all appears to be working as I want with > 'real' directories for my mail hierarchy. Glad to hear it. > It was basically quite simple to do, mostly using 'find', first to > create a copy of my old mbox directory hierarchy and then to run mb2md > against each mbox to the required destination in the new hierarchy. > > Obviously there were a few changes to my muttrc to tell mutt to create > maildir rather than mbox and the delivery/filter program run by > .forward has to create maildir mails rather than mbox ones (which > makes it a lot simpler of course). I confess to some curiosity here... What are you doing in your home-grown MDA, that you could not already do with procmail, which (if you're on a Linux system at least) your mail system is most likely already using to deliver your mail? -- 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: Can mutt be persuaded to use a sensible maildir hierarchy?
On Tue, Sep 22, 2020 at 05:46:53PM +0100, Chris Green wrote: > Does mutt still use the (IMHO silly) maildir hierarchy where mail > 'folders' are simply represented by another '.' and name in the > maildir directory name? I'm not sure why you think Mutt is doing this... I have my maildir folders set up in exactly the way you say you want and they work fine. But Mutt, by and large, isn't what created that mailbox structure--it was procmail. Presumably it's also true for you that whatever is delivering your mail is creating the directory structure, and mutt is just consuming 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: simple formatting possibilities
On Thu, Aug 27, 2020 at 01:40:08AM -0400, Jon LaBadie wrote: > I don't like the attachment approach but the formatting (minimal, > bold, alignment,?) he uses and the 2 column arrangement would be useful. > Of course, my using constant width characters and spaces kills > any alignment my recipients would see with their proportional fonts > and spaces. Your only option for this which would have widespread support would be HTML. It is *possible* to generate such messages and send them with Mutt. It's just not very easy or user-friendly. Not all that long ago I posted in a thread about how I lamented the lack of native support for HTML mail, though I think that would just about require that Mutt be given a GUI interface to be maximally effective (which I also would like, so long as the text-based interface remained). However, in that thread several people posted about how they handle composing HTML messages. You might search the archives for that. -- 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: Index screen - could it feature time segments?
On Tue, Aug 04, 2020 at 12:26:01AM +0300, Leho Kraav wrote: > One of the replies mentioned something about "tasteful" or similar. For > me, mail is not a fashion statement, it needs to get work done, so not > giving that taste argument much weight. > [...] > Other than that, haven't seen a any legit alternatives or arguments to > convert this want into "OK I really don't need it after all". A legit alternative... I mean, the index view has the date, which can be formatted pretty flexibly, and sorted on. If you want to know what e-mails you received in the last two days, sort by newest first, and then you just need to know what day it is, and have sufficient working knowledge of how dates work to know what the day before today is... Basically the same thing for 30 days, but as a rough equivalent, stop scrolling when you get to the same date last month, i.e. if today is July 1, then stop at June 1. If for some reason that is not enough for you, you can use Mutt's search or limit feature to only show you messages that are less than 2/30/however many days old. I forget exactly how it works because I've never found the feature useful, but I know it's there... And that is why I said having a visual divider is a distasteful waste of space. It has nothing to do with fashion--it has everything to do with efficient function. -- 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: Index screen - could it feature time segments?
On Sun, Aug 02, 2020 at 12:24:35PM +0300, Leho Kraav wrote: > Hi. I'm looking for a way to get mutt index to segment list display with > Today, Yesterday, Last Week, 2 weeks ago etc separators. > > Feels like it should be technically possible, but I haven't been able to > find a configuration or a patch for this. > > Your thoughts? My thoughts are: - Blech. This is not Outlook. I always thought it was a distasteful waste of space in Outlook, and it would be even more so in Mutt. Obviously, it's a matter of taste, which is highly individual. - There's no way to do this currently in Mutt. -- 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: Mutt losing folders with new mails with additional session
On Fri, Jul 17, 2020 at 08:37:50AM +0200, Sebastian Stein wrote: > Kevin J. McCarthy [200716 18:18]: > > If the access time is earlier than the modification time, it notifies for > > new mail. > > Wow, what a bad algorithm. I mean, this was probably perfect 20 years ago, > but in times of desktop search engines, cloud backup services, etc. > something more advanced is needed?! Right, it's so terrible that users complain about it constantly. Oh wait... no, they don't. What makes it actually rather good is that it relies only on the existing file metadata built into the POSIX file store, making it pretty efficient (basically one stat() call). Pretty much anything else you can imagine will be significantly more expensive, and quite possibly monumentally more expensive. > When I open a folder, I can mark a mail as new. How does mutt keep track of > this flag? Is this stored inside mbox file? Yes. It's stored in a message header in the individual message. This fact is unfortunately one of the things that slows mbox down, in cases when it is slower than maildir (namely updating status, specifically, in this case). It did not take much thought to imagine that making status updates faster for mbox only required invariably storing messages with a fixed-length status header, where status updates could simply overwrite the existing status field in place. Sadly no one did that. > Why not have a sidecar like .L-file1.mutt, where some essential stuff like > last access time, checksum, etc. are stored? Well for starters you just made new mail detection AT LEAST 2x more expensive, probably more. Instead of just a stat call you need to open the "sidecar" and read it. And then you need to update it on every message update. This MAY be a small cost for the average user, but Mutt's users are not generally average e-mail users, and it can add up if you have a large number of mailboxes or large folders and/or have a workflow that does lots of message status updates. What you really want for something like this is a database that can optimize for e-mail's usage patterns, which has other benefits as well (like making virtual folders easy to implement). But that has a variety of down sides, most obviously quite a lot more complexity, lack of any reasonable standard for cross-platform/mailer compatibility (as far as I'm aware, at least) and that you can't generally use text-oriented command line tools to manipulate it. In other words, it requires Mutt to abandon some of its fundamental design principles. Not that that's necessarily a bad thing... but if you want something that doesn't work like Mutt, there are plenty of other mail clients that don't work like Mutt. I think the solution you're looking for is to fix or properly configure your file system index service. -- 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: Mutt losing folders with new mails with additional session
Oops, if I'd seen this message before I sent my last post, I probably wouldn't have bothered to post it. That said, I will take issue with the notion that mbox is a terrible format: It isn't. It does, however, have usage patterns for which it is not well suited... just like maildir does. If you've read the famous comparison of the two on the Courier website, you should note that while many of its claims are true, it nevertheless is in no small part bunk. And if you feel the need to argue the point, I would urge you to read this thread before you do so: https://mutt-users.mutt.narkive.com/OE3ugjuM/is-it-safe-to-use-mbox And this one: http://blu.org/pipermail/discuss/2003-September/017386.html I'll grant you that one or two of the points I made may be outdated, depending on what hardware and file system you're using and what options you're mounting it with. But mostly... probably not. -- 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. On Fri, Jul 17, 2020 at 10:31:07AM -0400, Josef 'Jeff' Sipek wrote: > On Fri, Jul 17, 2020 at 08:37:50 +0200, Sebastian Stein wrote: > > Kevin J. McCarthy [200716 18:18]: > > > If the access time is earlier than the modification time, it notifies for > > > new mail. > > > > Wow, what a bad algorithm. > > It is a super cheap test with zero storage overhead. > > > I mean, this was probably perfect 20 years ago, > > but in times of desktop search engines, cloud backup services, etc. > > something more advanced is needed?! > > The atime/ctime comparison isn't perfect, but it is a well known algorithm > that's been around for a long time. One could make the argument that the > desktop search engine is buggy if it messes with the atime of every file it > looks at given what unix file system semantics are. > > Finally, I'm not sure most people care. I think most do not use mbox on a > desktop/laptop, or if they do the use is limited. (mbox is a horrible > format for any sort of mailbox that sees modifications other than just > appending) > > > When I open a folder, I can mark a mail as new. How does mutt keep track of > > this flag? Is this stored inside mbox file? > > Yes, a header with this information is stuffed into the corresponding mail > in the mbox. This may require rewriting the whole mbox file - which is the > big reason mbox is a terrible format :) > > > Why not have a sidecar like .L-file1.mutt, where some essential stuff like > > last access time, checksum, etc. are stored? > > Because that's extra overhead and well...it isn't mbox anymore. There are > other mailbox formats that don't use atime/ctime comparison. > > Server software like Dovecot maintains index files for each mailbox much > like what you are suggesting. While some of the functionality is IMAP or > POP3 specific, the index code is generic and quite complex. I doubt that > anyone will want to spend the effort to implement this client-side. > > Mutt could of course have a setting that disables the atime/ctime behavior - > and every time it wants to check it could scan the mailbox to see if > anything appeared. > > Ultimately, I think this is really a bug in the desktop search engine you're > using. > > Jeff. signature.asc Description: PGP signature
Re: Elimination of mime/html part
On Thu, Apr 30, 2020 at 03:27:29PM +0100, Sam Kuper wrote: > Unfortunately, one of the weaknesses in Python's email handling (which > might be related to some ambiguities or flaws in the RFCs on which they > are based - I'm not sure) relates to the problem of identifying a > "primary" (for want of a better word) text/plain part. It's not a weakness in Python, per se. There isn't such a thing. That's one of the points I was trying to make before. MIME allows for the BODY of your message to be literally anything. You can't hueristically determine what the "main" part is because it doesn't exist, except in the minds of the humans who interact with the message... and as we've seen, their ideas about what the main part is may differ. And in any event, you can not do this without potentially losing some information that is important, since many such messages will have plain text parts that contain only garbage, where the actual content is only in the HTML part (or even some other piece). [The tools could assume the first plain-text part is the "main" part, and that would be a reasonable assumption, but some of the time it will be wrong.] A likely better option is to compress the folder. If HTML truly is the bloat, it should compress very efficiently. -- 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: Inline PGP Within HTML
On Mon, Apr 27, 2020 at 01:46:26PM -0400, Scott Kostyshak wrote: > > Yeah, I've been trying to explain this to some folks around here > > recently, but not having much success. You have my sympathy. > > Agreed. It is frustrating. But Derek, please don't give up! I gave up a LOOONG time ago. Like others, it's my experience that my efforts were utterly a waste of time. Even if you can figure out to whom you could complain. Often enough such messages are from automated systems with "unmonitored accounts." And when there IS a text alternative, it often enough just says something like, "This e-mail must be viewed with an HTML-capable mail client." They clearly know it's an issue and don't care. -- 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 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: Inline PGP Within HTML
On Sat, Apr 25, 2020 at 09:46:48PM -0500, David Engel wrote: > Hi, > > My company uses PGP/GPG when sending sensitive material through email. > Unfortunately (for them and me), most people use Outlook and our IT > guy refuses to install any Outlook plugin for them to properly handle > encypted emails. I know this doesn't really help you, but your real problem is you need to fire your IT guy. As a former one myself, the role of IT should be to help users solve their legitimate business-need cases of technology issues, and yours has failed. He needs to be taught that is job is to aid, not hinder, the business achieving its goals. Barring that, you need to seek out those with enough political power to force your IT guy to do what you need, and convince them to do so. Everyone has a boss... And if you lack access to those people, it's just a matter of finding someone you do have access to who does, who will sympathize, or at least empathize, and make your case for you. > I've given up politely asking people to remember to send email as > either both text/html and text/plain or just text/plain when sending > to me. It's a losing battle. :( Yeah, I've been trying to explain this to some folks around here recently, but not having much success. You have my sympathy. -- 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 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 tec
Re: Alt-Arrow bindings in termite
On Sat, Apr 18, 2020 at 01:55:16AM -, Grant Edwards wrote: > On 2020-04-18, Derek Martin wrote: > > > Termite emulates an RS-232 terminal--a simple (AKA "dumb") ASCII > > terminal, whereas rxvt has a more complex interface that allows > > sending and receiving a variety of control sequences to represent > > when someone has pressed a key with a modifier key (like Alt) and > > other control functions. > > RS-232 is an electrical standard specifing a connector and voltage > levels. It says nothing about ASCII or anything else about the data > being transmitted. I'm aware of this, but at the same time it's often the case in the tech world, as you are no doubt aware, that terms are overloaded and/or conflated. In ancient times, if you bought say a 300 baud modem, it would often come with a program that called itself an rs-232 terminal (or terminal emulator). It obviously isn't, in the sense that you mean, since it's a piece of software. Those programs generally used that to mean they were dumb terminal emulators. If you look at the web page for termite, it is clearly using the term in that sense. -- 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: Alt-Arrow bindings in termite
On Thu, Apr 16, 2020 at 10:09:29AM -0400, Jaron Kent-Dobias wrote: > Hello, > > I'm trying to replace rxvt-unicode with termite, and am having trouble with > my mutt bindings. Termite emulates an RS-232 terminal--a simple (AKA "dumb") ASCII terminal, whereas rxvt has a more complex interface that allows sending and receiving a variety of control sequences to represent when someone has pressed a key with a modifier key (like Alt) and other control functions. Not sure why you're trying to do this, but I don't think it's going to work. RS232 terminals, IIRC, at most supported a few basic ANSI control codes for cursor movement and text formatting. > I have > > > bind index,pager \e sidebar-prev > > bind index,pager \e sidebar-next > > bind index,pager \e sidebar-open > > which in rxvt-unicode navigates the sidebar with Alt-Up, Alt-Down, > Alt-Return. In termite the sidebar-open binding still works, but neither the > Alt-Up nor the Alt-Down do. The what-key utility gives 'A' and 'B' as the > keypresses associated with them, respectively, but binding 'A' and 'B' to > sidebar-next and -prev don't work. RS232 terminals can send all of the bytes 0-255, which includes the control characters from 0-31 (ctrl-A is 1, ctrl-B is 2, etc...) so the best you're probably going to be able to do here, is identify some control characters you're not using for something else, and map those to your sidebar functions. Your options are limited though. I could be mistaken about all that though--really if there's a mailing list for termite, that's a better place to ask this question. I haven't seen anyone trying to use an RS232 terminal since I had a 9600 baud modem that was like 35 years ago. Even minicom supported vt100 terminal emulation over a serial line... -- 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 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: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 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 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: Slow changing mbox - continued
On Thu, Jan 02, 2020 at 12:58:21PM +, Chris Green wrote:
> Well I've started trying to diagnose this, I'm less sure now that it
> only happens across the ssh connection, that may be a red herring.
> I've changed the main disk drive on my dekstop system (where mutt
> runs) from a 1TB spinning hard disk to a 1TB SSD and I *think* the
> slowness may be related to this.
I doubt that very much. Your SSD is almost certainly making
everything involving I/O to and from it a whole lot faster.
So, looking at the trace snippets you provided:
> ...
> 12:40:19.110589 write(1, "\r\33[J\33[H\33[30m\33[46m---Mutt: ~/Mail"...,
> 3622) = 3622
> 12:40:19.110737 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER, sa_restor er=0x7f00502f1470}, NULL, 8) = 0
> 12:40:19.110791 write(1, "\33[?1h\33=", 7) = 7
> 12:40:19.110826 poll([{fd=0, events=POLLIN}], 1, 15000) = 1 ([{fd=0,
> revents=POLLIN}])
> 12:40:25.110942 read(0, "c", 1) = 1
> 12:40:25.111099 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART , sa_restorer=0x7f00502f1470},
> NULL, 8) = 0
> 12:40:25.111211 write(1, "\33[?12l\33[?25h", 12) = 12
> 12:40:25.111433 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:25.111575 stat("/var/mail/chris", {st_mode=S_IFREG|0600,
> st_size=726, ...}) = 0
> 12:40:25.111649 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:25.111712 stat("/home/chris/Mail/Li/alug", {st_mode=S_IFREG|0600,
> st_size=298691, ...}) = 0
This appears to be waiting for you to press the 'c' key to change
folders... The ~6s delay appears to just be waiting for you to do
something.
> ...
> 12:40:25.115157 stat("/home/chris/Mail/In/odin", {st_mode=S_IFREG|0600,
> st_size=1083391, ...}) = 0
> 12:40:25.115348 write(1, "\r\33[60dOpen mailbox ('?' for list"..., 55) =
> 55
Here the prompt is being written to your terminal...
> 12:40:25.115450 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER, sa_restor er=0x7f00502f1470}, NULL, 8) = 0
> 12:40:25.115552 read(0, "\r", 1)= 1
A carriage return was read, after ~2.65s of waiting for your input,
when you selected whatever was presented as the folder...
> 12:40:27.765854 rt_sigaction(SIGINT, {sa_handler=0x55bca4ac2440,
> sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART , sa_restorer=0x7f00502f1470},
> NULL, 8) = 0
> 12:40:27.766147 write(1, "\33[60;13H: \33[K\33(B\33[m", 19) = 19
> 12:40:27.766445 write(1, "~/Mail/Li/x2go\33(B\33[m", 20) = 20
> 12:40:27.766650 stat("/home/chris/Mail/Li/x2go", {st_mode=S_IFREG|0600,
> st_size=264290, ...}) = 0
...which appears to have been /home/chris/Mail/Li/x2go.
> 12:40:27.766999 utime("/home/chris/Mail/Li/x2go", {actime=1577968429 /*
> 2020-01-02T12:33:49+ */, modtime =1577968434 /* 2020-01-02T12:33:54+
> */}) = 0
> 12:40:27.767127 write(1, "\r\33[32mMailbox is unchanged.\33[39m"..., 41)
> = 41
> 12:40:27.767183 stat("/home/chris/Mail/In/inbox", {st_mode=S_IFREG|0600,
> st_size=3065472, ...}) = 0
> 12:40:27.767243 utime("/home/chris/Mail/In/inbox", {actime=1577968819 /*
> 2020-01-02T12:40:19+ */, modtim e=1577966702 /* 2020-01-02T12:05:02+
> */}) = 0
> 12:40:27.767325 close(3)= 0
> 12:40:27.767468 nanosleep({tv_sec=1, tv_nsec=0}, 0x7fff86fc8060) = 0
> 12:40:28.767837 lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...})
> = 0
> 12:40:28.768113 lstat("/home/chris", {st_mode=S_IFDIR|0755, st_size=4096,
> ...}) = 0
I think this sequence is updating the utimes of your inbox as you're
leaving it. At any rate I don't think these snippets have captured
whatever is slowing you down, and based on what you've said and this
strace, I think almost certainly whatever it was happened after this.
Probably immediately after this... I further suspect that whatever it
is will not appear to be a pause, but rather Mutt furiously doing...
something.
With no evidence whatsoever, my first wild-but-educated guess would be
that /home/chris/Mail/Li/x2go is a maildir, which has lots of messages
in it, and Mutt is taking a long time to process 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: Rendering HTML as Markdown in mutt (was: Creating HTML emails with mutt)
On Tue, Nov 05, 2019 at 07:30:16PM +0100, Richard Z wrote: > On Tue, Nov 05, 2019 at 09:31:27AM -0500, Mark H. Wood wrote: > > > Anyway, a good place to read up on xterm might be > > https://invisible-island.net/xterm/ > > That version of xterm still gets updates several times a year. xterm > > is neither obsolete nor unsupported, just unloved by some distro.s. > > absolutely. All replacements I have ever tried had some or many issues. This used to be true for me as well, but gnome-terminal eventually became good enough, and had better handling of multiple character sets (not in the technical sense, but rather the sense of where the set of characters came from, e.g. CJK, Latin, etc. since they're all one Unicode character set). > And while 25 years ago xterm was considered a true heavyweight among > terminal emulators, the lack of "improvement" since that means it is > probably the most lightweight choice today. I don't think Thomas (Dickey, maintainer of xterm who also hangs out here) would entirely agree with that characterization. ;-) -- 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: Rendering HTML as Markdown in mutt (was: Creating HTML emails with mutt)
On Fri, Nov 01, 2019 at 12:21:15PM +1300, martin f krafft wrote: > Regarding the following, written by "Derek Martin" on 2019-10-31 at 15:39 Uhr > -0500: > > And FWIW, I *was* discussing (very limited, completely text-based) > > support for HTML messages in Mutt. I want it, have wanted it for a long > > time, because all of the available options for dealing with it have > > serious drawbacks at least some of the time. > > Hey Derek, > > Could you please elaborate a bit on what you're missing? I and others have already done so, in some cases in some detail, throughout this thread. On Thu, Oct 31, 2019 at 06:55:26PM -0600, Akkana Peck wrote: > That sounds like it's all on the viewing side? I can't speak for > Derek, And yet you have done so successfully. :) > but in addition to viewing HTML messages, I (and others who have > added to this thread) would like a way to reply without losing the > formatting. > > The viewing side isn't so hot either. Most terminal programs > these days can display colors, italics, bold, underline and > strikethrough (looks like urxvt doesn't do strikethrough and xterm > doesn't do underline, Xterm most definitely does underline, though you may need to set a resource to make it do that. I vaguely recall that some text formats are rendered using colors or reverse text *by default* but can be made to do the more correct thing via X resources. I just don't recall the specifics... But underline absolutely works, and I can provide a link to an image if you're not convinced, but suffice it to say, I just did it. IIRC italics is the harder thing, as you have to set up X resources for the italics font face to use, or something like that... but it all works. Hardly anyone uses xterm these days though AFAICT, and configuring it properly has become a lost art. In fact, quite a few years ago now, I filed a bug against xterm in some version of Fedora or even Red Hat, and Red Hat's support people closed the ticket, complaining that xterm was obsolete and no longer supported. (!!!) > So why do most HTML->text conversion programs ignore styles and > colors in --dump mode? Is there one that shows styles/colors? This is most of what I want--with the built-in pager (or an alternative built-in pager that you could configure Mutt to use via option). As others have pointed out there's also trouble parsing long URLs and such, depending on the tool you're using to do it. The console browsers all kinda work for this but each has its own idiosyncratic edge-case failures. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Thu, Oct 31, 2019 at 10:20:21AM +, John Long wrote: > On Wed, 30 Oct 2019 15:49:05 -0500 > Derek Martin wrote: > > > On Wed, Oct 30, 2019 at 11:31:21AM +, John Long wrote: > > > That doesn't really help. From my point the issue is not only what I > > > have to configure or what can be configured, but also how much code > > > is behind doing that. Less code is easier to manage than more code. > > > I can't see the benefit of junking up mutt with HTML or anything > > > else that is out of scope for a command-line mail client. Remember, > > > some of us use mutt on a console with no GUI > > > > Who is harmed more? Users who have the feature but don't want it, or > > users who need the feature but can't get it? > > That doesn't fall into the category of harmed. I'm not sure of the > timing but I believe in most cases people chose to use mutt after HTML > email was already in common (ab)use. Mutt's been around since 1995. Many of us have been using it since the beginning, or soon after. HTML mail was not nearly so prevalent then as it is now. > And I would venture to say that virtually all of the people who use > mutt either as their only email client or along with others, chose mutt > because of its simplicity. I'll have to beg to differ. In my experience most people use Mutt because of its power. Mutt is just not simple... all that power comes at a cost. > It seems to be contrary to the direction and purpose of mutt to make > it do everything anybody wants. And if you search the archives for my posts, you will very frequently see me making that same argument. But not when it comes to functionality that is an essential part of handling e-mail, which, like it or not, this now is for many/most people. Mutt's lack of ability to handle HTML e-mail *well*, *natively*, gets in my way just about every single day. If that's not true for you, great! That in no way means it isn't true for lots of people. > The harm of making the app more complicated and adding a lot of code is > real, For sure. > and it directly affects the user of mutt whether he's new or old. This is false. The issue is not how it affects the user--Mutt's longstanding practice is to make such features able to be entirely configured out of the program, which means they impact the user exactly zero, once configure is run (if you want that, that is--you do need to compile it yourself if you're that anal about what features are compiled in since the distros generally (correctly) expect that users want all the features available). Then, even if you don't compile it out, it still doesn't impact the user at all if they don't *use* it. This sort of feature is not one that complicates code paths that you always hit; it's one that sits entirely separate and lies dormant if you don't use the feature. The real issue is that more code makes the code base more complex and harder to maintain. There's always a tradeoff between that and in providing features. When the feature is a fundamental aspect of doing what your application does, then the chioce should be to add the functionality. You can argue handling HTML mail is not a core function of handling e-mail all you like, but if you do you're just wrong. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Thu, Oct 31, 2019 at 11:43:07AM +, John Long wrote: > On Thu, 31 Oct 2019 23:47:38 +1300 > martin f krafft wrote: > > > Regarding the following, written by "John Long" on 2019-10-31 at > > 10:30 Uhr +: > > >1. Commonly done != standard. There are standards for things like > > >MIME, POP3, IMAP etc. I'm not aware of ANSI, ISO, IETF standards > > >that say that HTML email is a thing. > > > > Quoting the HTML RFC from 1995: "The Hypertext Markup Language > > (HTML) is a simple markup language used to create hypertext > > documents that are platform independent. HTML documents are SGML > > documents with generic semantics that are appropriate for > > representing information from a wide range of domains. HTML markup > > can represent hypertext news, **mail**, documentation, and > > hypermedia; …" > > That's the tail wagging the dog. I'm saying I haven't seen an *email* > RFC that says "HTML may/should be used for email." The MIME standard (RFC-1341, 1992) is what you're looking for: Multipurpose Internet *Mail* Extensions. It defines (quoting the RFC): 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049], which can be used to specify the type and subtype of data in the body of a message and to fully specify the native representation (encoding) of such data. This allows for "data in the body of a message" to be in arbitrary formats, which includes literally anything (including experimental or user-defined X-* types), which most certainly includes HTML. And FWIW, I *was* discussing (very limited, completely text-based) support for HTML messages in Mutt. I want it, have wanted it for a long time, because all of the available options for dealing with it have serious drawbacks at least some of the time. This thread seems to have revealed that I'm far from alone in thinking so. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Wed, Oct 30, 2019 at 11:29:31AM +, John Long wrote: > > I don’t think this is about right and wrong, and not only because > > there is no objectivity. multipart/alternative is an accepted > > standard, and so is HTML. You might not like how things have > > developed, and neither do I, but that doesn’t make it wrong. > > HTML is for web pages. It is wrong for email, yes. This is just not a supportable position based on anything logical or evicence-based. HTML in e-mail has been a de-facto standard for about as long as most people have been using e-mail (admittedly, much less true for the folks on this list). It has almost universal adoption of native support in almost every e-mail client of note. Even alpine can now display HTML mail as plain text natively. Mutt is the only laggard in this regard that I am aware of. A majority of e-mail users PREFER HTML mail. https://www.clickz.com/real-world-email-client-usage-the-hard-data/47429/ https://www.slideshare.net/HubSpot/the-science-of-email-marketng/32 So I think the notion that HTML mail is wrong is just wrong-headed. I certainly have no issue if you want to say you hate it, and I would sympathize. But when you say it's wrong... I think you have no leg to stand on. > Lots of Microsoft crap seems like an "accepted standard" This has turned out to be remarkably difficult to prove, but I don't think HTML mail was invented by Microsoft, or predominated by it. AFAICT MS didn't even support HTML in e-mail until 1998, and I'm pretty positive Netscape Mail supported it in its first version, released the same year. > Simplicity and constantly adding new features that are inessential are > at odds with each other. This is true and should be considered, but not to the point of leaving the application functionally incomplete. > I think it's pretty clear the people who use mutt prefer simplicity > or they would have chosen something else. I think this is totally crazy. Mutt is anything but simple, from the user point of view. It is a beast to configure with a monstrous learning curve. Part of what gives it that is the requirement to configure how to handle even things like HTML mail, which today pretty much no one would exclude from the idea of what is essential e-mail functionality. Everyone, that is, except a subset of Mutt users. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Wed, Oct 30, 2019 at 11:31:21AM +, John Long wrote: > That doesn't really help. From my point the issue is not only what I > have to configure or what can be configured, but also how much code is > behind doing that. Less code is easier to manage than more code. I > can't see the benefit of junking up mutt with HTML or anything else > that is out of scope for a command-line mail client. Remember, some of > us use mutt on a console with no GUI Who is harmed more? Users who have the feature but don't want it, or users who need the feature but can't get it? -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Tue, Oct 29, 2019 at 07:04:48PM +, John Long wrote: > > so you cater to people who have no idea, and cannot be bothered. > > Which is probably 99.9% of everybody in corp. offices worldwide. > > Don't get me wrong, I'm not advocating for HTML support in mutt. HTML > has absolutely no place in email. Sadly, the masses have decided this for us, and this opinion has lost the battle. And TBH while I mostly sympathize, using underlining, bold, and italics in type have been common for emphasis and similar purposes for centuries. And color more recently, but certainly decades. It would be nice to be able to make use of these instead of relying on ASCII art to attempt to convey them. And before someone brings up RTF, just... no. > But I do understand the problem very well after doing some > contracting for big corporations and realizing 100s of millions of > Windows victims can barely use a computer at all and email is just > the tip of the iceberg. > > My solution is to use something other than mutt in those cases. There > is no way to win... TBH most of the time, if I really need to see what's in an HTML mail, I just bounce it to gmail. But sometimes that doesn't work either due to DNS-based spam prevention. I'm well aware there are "solutions" to this problem. I've used them all. They all suck (fail to handle some edge case very well or at all). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Tue, Oct 29, 2019 at 10:31:19PM -, Grant Edwards wrote: > On 2019-10-29, martin f krafft wrote: > That's true (as I understood the problem, anyway). Fortunately, I > never needed to send a signed message with an attachment (or just a > signed message, AFAIR). Nobody I know would have the faintest idea > what to do with a signed message. Half the people in this thread are sending them, so I think that must not be entirely true. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 11:11:31PM +0100, Matthias Apitz wrote: > El día lunes, octubre 28, 2019 a las 04:50:40p. m. -0500, Derek Martin > escribió: > > > > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks > > > > Perhaps not, but the fact that it keeps coming up here is pretty clear > > indication that it's a feature that would be useful to a lot of > > people... > > Well, do you speak for you or for a 'lot of people'? Who they are? > I speak only for my own interests (as I said: I do not need this). I speak for myself, but you seemed eager to bring your authority into it, with giving your length of experience using Mutt. If you want to do that, then I'm happy to point out that in the 23+ years *I've* been a member of the Mutt community, frequent poster, and occasional code contributor here, I've seen lots and lots and lots of people asking about how (better) to handle HTML mail. If you want to know who they are, feel free to search the archives. Mutt is a mail user agent, and like it or not, a large amount of mail is now sent in HTML format. Isn't the MUA's job to handle e-mail? Well, I think it is, and Mutt does not do a complete job of it, for a large subset of e-mail messages. This thread has highlighted that lots of people have issues dealing with the available solutions. They all "work" to some degree, but they often have failings that simply can't be overcome, or require a very specific set of tools that may not even be available to you, if you are reading mail on a system you do not manage. If Mutt handled HTML mail natively in some fashion, these issues would cease to be issues. That's exactly why I think support very much belongs in Mutt proper. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Mon, Oct 28, 2019 at 10:06:18PM +0100, Matthias Apitz wrote: > El día lunes, octubre 28, 2019 a las 03:59:01p. m. -0500, Derek Martin > escribió: > > > FWIW, my two biggest wishlist items for Mutt are: > > > > 1. the ability to create and send at least simple HTML messages, with > >or without multipart alternatives, specifically for basic text > >formatting (bold, italics, color) and hypertext links. [It's > >expected that an external HTML editor would need to be spawned to > >generate the HTML. It makes sense to be able to specify a filter > >to convert this to an alternative form for multipart.] > > > > 2. The ability to natively display a subset of HTML (the same subset) > >with the ability to trigger links to open in a browser (or perhaps > >execute an arbitrary configured command). Modern terminal windows > >can handle all of the formatting required to do just this much... > > > > FWIW, I (as a mutt user for 15++ years) do not need this. Thanks Perhaps not, but the fact that it keeps coming up here is pretty clear indication that it's a feature that would be useful to a lot of people... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Creating HTML emails with mutt
On Sun, Oct 27, 2019 at 10:02:38AM +0800, Kevin J. McCarthy wrote: > On Sat, Oct 26, 2019 at 11:16:25AM +1300, martin f krafft wrote: > Native support for multipart/alternative composition isn't in my todo list. > However, I do have a plan to allow external filter generation of the > alternative. Originally, this was on my list for the next development > cycle, but let me see what I can do before the 1.13 release. > > The current idea is a quadaption (names may change, but...) > $compose_multipart_alternative combined with a script > $compose_multipart_alternative_script. FWIW, my two biggest wishlist items for Mutt are: 1. the ability to create and send at least simple HTML messages, with or without multipart alternatives, specifically for basic text formatting (bold, italics, color) and hypertext links. [It's expected that an external HTML editor would need to be spawned to generate the HTML. It makes sense to be able to specify a filter to convert this to an alternative form for multipart.] 2. The ability to natively display a subset of HTML (the same subset) with the ability to trigger links to open in a browser (or perhaps execute an arbitrary configured command). Modern terminal windows can handle all of the formatting required to do just this much... While I still mostly prefer plain text for its brevity, being able to provide emphasis and other basic formatting is nice. It's hard to deny that HTML mail has become the defacto standard for most people, and I think Mutt really falls short in its ability to handle this stuff out of the box. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: File locking on sshfs file system, possible?
On Mon, Oct 28, 2019 at 07:29:52PM +, Chris Green wrote: > On Mon, Oct 28, 2019 at 01:31:57PM -0500, Derek Martin wrote: > > You're probably better off using (local) IMAP over SSH with your Mutt > > mailboxes. That is, you can ssh into your mail server and run imapd > > locally (rather than having it listen to incoming connections), and > > Mutt supports this. > > > I've never got on well with IMAP and mutt. But have you tried running it locally over SSH? There are a lot of factors that matter (and I admit I don't use it, but I don't really deal with attachments much), but when I tried it I found it was a very different animal than network-based IMAP. It has different performance tradeoffs and benefits/drawbacks. If you haven't tried it, I would highly encourage you to do so. You do still have to transfer your messages and attachments over SSH (but you were doing that anyway), but you do get to display them locally, which makes a lot of difference. Or can, depending on your exact usage patterns. I think it may get you most of what you want, and if so you may be able to throw away any hacking you've done to deal with your problem. -- 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: File locking on sshfs file system, possible?
On Fri, Oct 25, 2019 at 08:58:06AM +0100, Chris Green wrote: > I just tried running mutt 'remotely' by mounting ~/.muttrc and my main > mail directory ~/Mail using sshfs and running a local copy of mutt. > This makes handling attachments and HTML E-Mail much faster and easier > than running mutt on the remote system via ssh. SSHFS is a horrible hack (albeit a clever one that has many convenient uses). Unfortunately I've forgotten the details, but I know that several important file system semantics do not work with it, and IMO you should not use this for anything you consider important that needs reliability. You're probably better off using (local) IMAP over SSH with your Mutt mailboxes. That is, you can ssh into your mail server and run imapd locally (rather than having it listen to incoming connections), and Mutt supports this. -- 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: Really strange problem with evince PDF reader and .mutt directory
On Sun, Oct 20, 2019 at 06:04:05PM +0100, Chris Green wrote: > On Sun, Oct 20, 2019 at 02:02:15PM +0100, Nuno Silva wrote: > > On 2019-10-20, Chris Green wrote: > > Do these systems have apparmor? It seems to be some sort of security > > tool which restricts access to files and directories based on rules. > > > > I don't use ubuntu (or ubuntu-based) systems nor apparmor, but this > > looks like it might be related: > > > > https://gitlab.com/apparmor/apparmor/raw/master/profiles/apparmor.d/abstractions/private-files > > > I just removed apparmor from one of my systems (I can see no use for > it anyway), I still get the error with evince. But did you reboot or otherwise confirm that apparmor is not still in play? I'm not super familiar with it but it appears to be a kernel module--if it were loaded I would expect it to stay that way despite the file being removed... at least until the kernel was restarted (i.e. you rebooted the machine). Though, it's possible that removing the package asks the kernel to unload the module. -- 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: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 03:00:32AM +0530, Pankaj Jangid wrote: > On Mon, Jul 29, 2019 at 01:50:54PM -0700, Kevin J. McCarthy wrote: > > If you want to participate in development, then please do so by starting > > small and showing me I can trust your patches. After you've done that, we > > can talk about larger changes. > > > This is really encouraging. But to be very clear, it is not meant to be. You came in saying you want Mutt to handle a protocol in a way that is expressly against the way that protocol is intended to be used, by adding features to Mutt which are counter to its design philosophy. You should not expect encouragment for that. Joining any community requires to at least some extent that you gain that community's trust. Your posts thusfar have not earned you that. -- 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. pgpanUGB_PAap.pgp Description: PGP signature
Re: Preferred way to get imap emails
On Tue, Jul 30, 2019 at 01:47:35AM +0530, Pankaj Jangid wrote: > On Mon, Jul 29, 2019 at 03:13:37PM -0400, Dan Ritter wrote: > > IMAP is, explicitly, a mail protocol for clients to do the > > minimal amount of fetching necessary. You can do a full sync on > > top of it, but that's not what it's there for. > > A lot has changed since then. I remember I used to pop everything > because the mailserver quota was less than 10mb (20 years back). And > then take backup of local emails on floppy drives. > > Now we check emails on mobiles, browser and obviously *mutt*. There must > be some inclusive intuitive changes now. But none of this really affects how IMAP works, or should work. If anything, it's a recommendation for using IMAP as intended. As far as I can tell, your whole motivation is to avoid a bit of latency as each message is downloaded for display, by downloading all the messages ahead of time (and I guess storing them in some local cache? Or something)... But that's sort of the antithesis of IMAP, as Dan indicated. It requires a potentially lengthy wait while all of the relevant message bodies are downloaded, which IMAP was expressly designed to avoid. As I said already, if you're on a fast, low-latency connection to your IMAP server, generally you won't notice this latency, and this is probably the case for the vast majority of e-mail users (who typically are using IMAP at work, or at home, on a local LAN, OR to their ISP's servers, over a fast broadband connection on the same network). So I conclude that is not your situation. If you're not in that situation, there are already solutions available to you: 1. Fetch the messages yourself and read them locally. Fetchmail and mbsync were both designed for exactly this. 2. Accept that the latency is just something you have to deal with. 3. Investigate an alternative provider with whom you have a better connection. > Honestly speaking, I have tried a couple of tools - offlineimap, mbsync > and fetchmail. All are flawed. I don't know what you think the flaws are with this, but I can say that I use fetchmail + procmail for this purpose myself at work for reasons I won't get into here. I've been doing it for many years, and find it to have no particular flaws. Together these tools are extremely powerful and very flexible. It may just be that you have not yet discovered how best to use such tools to accomplish your goals and need to spend a bit more time learning them. There's no need for Mutt to do this, and it's rather against its design philosophy. Given that, I wouldn't guess you'd have much luck getting such a feature accepted by the Mutt development community, particularly since the primary maintainer has already basically said so. That said, I haven't used Mutt's IMAP functionality myself in many years, and it has been completely rewritten since then. It could be the case that it might be possible to optimize the way Mutt handles the fetch and display of the message, such that it only reads enough of the message to fill up the display window, and then continues reading the rest of the message. But for all I know it already does that. And of course in cases where the message is encoded in such a way that reading the whole message is required to decode any of it (I'm thinking encryption, for example), such an optimization will not work. Surely Kevin would know and could comment further. [My understanding is that it is technically possible to decrypt messages encoded with asymmetric encryption in pieces, but neither GnuPG nor OpenSSL do this, and Mutt's behavior is dependent on theirs.] -- 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. pgpeDOsO3IxVD.pgp Description: PGP signature
Re: Preferred way to get imap emails
On Sat, Jul 27, 2019 at 10:58:22PM +0530, Pankaj Jangid wrote: > > > I have configured cache so it doesn't happen everytime with the same > > > email. My 2nd question is - is there a way to pre-fetch all the > > > emails in inbox. > > > > I don't think so -- not without using something like offline-imap. > > > > Is there any specific reason this was not done? This is probably related > to some design decisions. Because this again is how IMAP works--you're meant to read the message off the server, and it's downloaded on demand. If you had to pre-fetch all the messages, this could take a very long time, especially if you were looking at an extremely large mailbox for the first time, and it contained very large messages. With typically short messages on fast networks, you usually should not notice much delay, and with larger messages you only incur the wait time when you actually want to look at the message. If you have a high latency connection, it may be worth pre-syncing and reading locally. If you want to pre-sync your mailbox and read it locally, that would be why you would use fetchmail, mbsync, etc.. Mutt doesn't need to do that for you since there are already plenty of things that do. -- 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. pgpMLj1gG90Bc.pgp Description: PGP signature
Re: Preferred way to get imap emails
On Sat, Jul 27, 2019 at 02:57:20PM -0600, Akkana Peck wrote: > The only problem with mbsync is that it doesn't have a "daemon > mode", so I had to write a script that runs it every N seconds. > But that's a trivial complaint. There are any number of solutions to this, but... cron? It's probably much more reliable than a script. -- 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. pgp3Re_UfdWAS.pgp Description: PGP signature
Re: Composing ask From: address and arbitrary keys in PGP
On Fri, Jul 26, 2019 at 05:12:08AM +, g...@riseup.net wrote: > 1. When composing messages, mutt ask To: or recipient adress and > Subject and then go to editor. How to make mutt ask for From: or > sender address only and then go to editor? > The typical way to do this is with send hooks or folder hooks. Use my_hdr in one of those hooks to set the From: line. > 2. In PGP, mutt has crypt_opportunistic_encrypt to select keys based > on To: address to the recipient. But PGP also need From: address or > sender's key to encrypt messages, sign messages or even attch their > own public key. By default, mutt uses system default key or oldest > key created for encryption, sign messages or attach public key. Same answer as above, but instead set pgp_sign_as. If need be you can use a hook to set your pgp_encrypt_only_command and/or pgp_encrypt_sign_command (and set the ID to use in those, or use a different gnupg options file, etc.). -- 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. pgp99hj0x7amQ.pgp Description: PGP signature
Re: Using UTC as time zone in outgoing email headers
On Wed, Jul 24, 2019 at 07:06:52AM +, Ryan Smith wrote: > By default, mutt uses local or computer time zone in outgoing email full > header, Date section. > > How to force mutt to use UTC as time zone in all outgoing email headers? For what it's worth, this is probably mostly pointless. There's a very good chance the remote end will use the user's local time zone to display the date regardless of what you do on your end. As long as the time that's sent is accurate, the user will see something sensible when they view your message, and you largely can't control what that is. That said, it can be done... Set your TZ environment variable to UTC. If you don't want all of your programs to use UTC, but only Mutt, there are a few ways you could accomplish this. 1. On the command line, when you start mutt: $ TZ=UTC mutt 2. Create a shell script that sets the timezone and starts mutt: $ cat Mutt.sh #!/bin/sh export TZ=UTC exec mutt Then use the shell script to start mutt instead of starting it directly. 3. Edit the mutt source code to set the TZ environment variable during initialization (but really, don't do that)... etc -- 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. pgpwxYPv1RFeE.pgp Description: PGP signature
Re: mutt and clear-signing
On Tue, Jul 02, 2019 at 02:48:21PM +0100, tech-lists wrote: > Hi, > > I'm using mutt v.1.12.0 on freebsd-current with gpgme. In my config, mutt will > verify clearsigned gpg sigs if the public key is on the gpg keyring. > > But if the key is unknown, mutt will say the key is unknown, and this is > normal and expected. > > What I want to happen is, if the key is unknown i'd like mutt to prompt > something like "get key y/n" or even automatically fetch the key and add > it to the keyring if the public key is valid. You can do this by configuring gnupg itself to do it. You need to tell gnupg what key server to use (you probably already did that), and then you need to add the option auto-key-retrieve in gnupg.conf. -- 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. pgpS4qIfDS4wW.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
[Sent before I intended to.] On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote: > @Derek: I've read your mails in this thread, and I'm in no way > convinced. I'd love for you to explain why. Note that Kevin confirmed that my arguments are technically correct. So despite that I techncially, accurately described how the current solution results in you having a local copy of the message, which was the only thing you (incorrectly) said the current behavior was lacking, you find this to be inadequate. I'd like to understand in what way it does not meet your needs. -- 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. pgps4Oz3PKc8Z.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote: > I can only say, Erik wrote the answer I wanted to write. > > @Kevin: The new change sounds very promising. Thank you for that > and all your work! > > @Derek: I've read your mails in this thread, and I'm in no way > convinced. I'd love for you to explain why. -- 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. pgpgFaMb4Ahl8.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Wed, Jun 12, 2019 at 09:31:53AM -0700, Kevin J. McCarthy wrote: > On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote: > >Obviously you don't need to listen to me > > I do listen to you, Derek. The whole buffer pool migration is a > result of your recurring prods, and I will continue to work on that, > likely through the next couple major releases. :) [If I'm being honest, while that may be true, I don't actually remember what you're talking about...] [...] > It's easy to conclude that objections to the change are overly > paranoid or irrational, That's not quite what I'm saying (see below)... > but Mutt users in general *really* *care* about email. Of course, I realize that, I'm one of them. :) [...] > It's evident, to me, that this change is extremely distressing to at > least a subset of our users, who really care about having the > message in their Fcc box before it gets sent out, regardless of the > issues. I think that's a mischaracterization. Based on what people said when they explained *why* they objected to the change, I think it's actually the case that they just did not realize we accounted for their concerns when we designed this change, and that in fact they already can get exactly the end result they wanted from Fcc-first with the current behavior (their e-mail is fully recoverable, save the case of catastrophic system failure). I think there was not much opportunity for them to correct that misunderstanding until late in the thread when I posted my detailed, hopefully succinct explanation (and I also suspect at least some people who don't like this change never read the explanation). I think before you commit this, you should ask that anyone who still objects go read my explanation if they have not, and then explain how that does not cover their concerns. My suspicion is that after doing so, if there still are any objectors, their explanations will reveal that they still don't actually understand how this works, and that their understanding is the problem, not the actual behavior... Unless their objection is simply, "but I still want it to be written to Fcc first for no particluar justifiable reason," because we clearly decided that is not the right behavior. :) [I also think if they still don't see that, you, as maintainer, should know better and stick to the decision we made, but that is clearly a more controvercial judgement. =8^)] I think you could make the argument that this disruption is mutt-dev's fault for not making an effort to communicate this change--one we knew was contentious at the time we were discussing it--in advance to mutt-users, so that people could get used to the idea before it hit, or get involved in the discussion while it was happening, to their satisfaction. Perhaps we should do that more in the future... Regardless, I still maintain we made the right decision here and the alternative behavior provides nothing good that the current one does not, but does indeed detract, and should be avoided. I've said my piece. -- 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. pgpiEY94NQfAo.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Wed, Jun 12, 2019 at 05:20:02PM +1000, Erik Christiansen wrote: > On 11.06.19 12:36, Derek Martin wrote: > > I hesitate to go far as to say that if you think saving the message > > first is the right behavior, you are simply wrong... but I'm > > definitely thinking it. =8^) > > I like your style, Derek. And respect that your use case works for you. > What surprises me is the surplus of certitude which refuses to countenance > a legitimate use case at variance with yours. It's because it isn't, as I believe I've satisfactorily demonstrated. The current behavior actually gets you literally everything you want. It just does it differently than you expected... but it still does it. There's no need for the Fcc first-behavior, and it is demonstrably worse for more than one reason. As such it should be excluded. I can not see how you could make any good argument to the contrary. This is why mutt-dev rather quickly (by our standards regarding contentious changes) agreed that the current behavior is the right one. We discussed it, came to a good conclusion about the solution, it got implemented, and I think we should stick to that. I am certain that those who are objectiing are simply reacting negatively to change, not realizing that it very clearly is a change for the better which still gets them exactly what they wanted with Fcc-first behavior, as the desire to do that went into that decision. That should be clear to anyone who carefully read the discussion. More code, more config variables, are inherently bad. They increase the burden of management of the code and the probgram, and increase the learning curve for developers and for users. A single variable is obviously only a tiny marginal burden, but when the development community does not actively resist the urge to add one for every little triviality, you end up with hundreds of unnecessary such things increasing complexity, the maintenance burden, the learning curve, etc.. We have seen over the years that they can cause bugs where they can interact in unexpected ways, breaking things. TBH I think (and have long thought) Mutt already has way, way too many config variables, probably a significant portion of which really don't provide that much value and should really be removed. So yes, I will continue to apply some resistance to adding new ones, as Thomas used to do, for all the same reasons he did. There should be a significant positive change in Mutt that is provided by a new config variable, to counteract that inherent negative, before adding it is even considered, and in my estimation this one provides only negative. But I am (sadly) just rehashing the conversation that went into the original decision to implement the current behavior in the first place. :( -- 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. pgpN7n_ZBZN_z.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote: > On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote: > I've pushed a branch up to gitlab, kevin/fcc-before-send. It adds > $fcc_before_send, default unset. Obviously you don't need to listen to me, but I do want to state for the record that I'm opposed to this change going in. I'm sure a lot of people will say, "Oh, it's just a config variable." Those who've been paying attention will realize I've consistently argued against new config variables by default, over the last 20+ years, and I'll restate my unwavering reasoning for that here: Mutt already has tons of config vars, and Mutt is already a beast to learn how to configure--I think it takes years for people to even realize all the features Mutt has that are configurable, nevermind getting a config that does all they want. As such, (I believe) adding a new config variable is inherently bad, and should only be done when the good of having the alternative behaviors outweighs that bad. Such cases clearly exist, and in those cases I don't argue against them. This is not such a case. I believe I have demonstrated in my last post in this thread, using sound logic, that the alternative behavior is not only never an improvement for any of the stated concerns, but inarguably worse for some of the relevant concerns, and as such clearly does not outweigh the bad of making Mutt that much more unweildy to understand and configre. Therefore, the change should not be committed. -- 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. pgpkyRaySVW0q.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Tue, Jun 11, 2019 at 08:11:33PM +0200, Nicolas Rachinsky wrote: > > I hesitate to go far as to say that if you think saving the message > > first is the right behavior, you are simply wrong... but I'm > > definitely thinking it. =8^) > > You might consider it wrong but I do not seem to be the only one > thinking the old order is the correct one. The argument is really simple. The current solution solves your problem, and mine. Your solution solves only your problem. > Considering how often I heard other people swear because they lost > some sent mail, because their MUA crashed after sending and before > storing it, this does just seem to be the wrong order. I've been on this list since ~1995, and I've certainly heard people express concern about the possibility of this, I can't say that complaints about it actually happening have been particiluarly common. To avoid going back and forth responding to quoted comments, I'll instead summarize the concerns. As best I can recall, there are 3: 1. If you DON'T save the message first, it is impossible to resend the message if sending fails. 2. If you DO save the message first, it can lead to misleading the user into thinking messages were sent, when they never were. 3. If you DO save the message first, it has negative repercussions in terms of cryptography, certain headers, etc. which will not be "correct" in the saved copy. Ignoring the fact that #1 is hogwash anyway, because you certainly can recreate a message that captures the sense of what you wrote the first time, even if it is not word-for-word identical, the current solution solves ALL of those concerns: 1. If sending fails, you are left at the compose menu, with a copy of your original message at the ready. This is already a rare occurence for most people. The most likely reason for sending to fail is you used an invalid address. Every mail client has means to prevent that from happening if you are sending to someone you've already interacted with (address book, Mutt aliases, LDAP lookup, etc.), excepting the case where a previously valid address suddenly is not. 2. In the extraordinarily unlikely event that sending fails, AND you have a power outage while you are sitting at the compose menu, you still have a copy of at the very least your message text, sitting in the temporary file Mutt was going to use to send the message. And let's be extremely clear: THIS IS UNBELIEVABLY UNLIKELY. But it can happen. 3. In the equally extraordinarily unlikely event you can not remember who you were going to send the message to, you can set edit_headers=yes and Mutt will copy the headers into the temporary file, so you will not lose those either. The notion is completely asinine, but it was raised as a concern, so, there you go. 4. Mutt will update encryption and any heaers added or changed by sending before it is copied to Fcc, so the file on disk will be as accurate a copy of your message as possible. 5. The Fcc copy will be created only once the message is actually sent, so there is no misleading of the user to think the message was sent when in fact it was not. 6. In the event creating the Fcc copy fails, Mutt will prompt you what to do, giving you the opportunity to deal with it however you like. In the mean time, the temporary copy still exists on disk, in the event of non-catastrophic system failure at this point. 7. In the event of actual catastrophic system failure, none of these things will save you. Everyone appears to agree Mutt should not try to solve for this. So, all of your concerns are addressed by the current behavior. None of the concerns that brougnt this behavior into being are addressed by the behavior you want. The only logical conclusion then, which I now feel completely justified in saying, is that if you still want that behavior, YOU ARE SIMPLY WRONG. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpwITz4RVDLQ.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Tue, Jun 11, 2019 at 12:36:00PM -0500, Derek Martin wrote: > But also, just because the message failed to send, your ideas and the > impetus for writing them down didn't vanish. Your brain is the > back-up. Not only that, but I neglected the fact that if the send fails, the file your editor produced in order for it to be passed to Mutt will still be on disk, so you do IN FACT still have a copy of the message. That is, barring catastrophic system failure, which no mail client will ever save you from. -- 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. pgpScU1faFRBm.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote: > In the event that send fails, the local copy is essential for a resend > attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any > scenario in which mutt should risk inability to write that Fcc, through a > hang-up or conniption during sending. This argument seems like complete nonsense to me... if the send fails, you're left back at the compose screen. If by some unbelievable coincidence the send fails AND you lose power before you can do something about it, this is NO DIFFERENT than if the power went out just before you finished composing the message. It's not your mail client's job to protect you from every conceibable system failure which might cause data loss, nor should it be. And for every other case, the current behavior is the far superior one because it can not mislead you into thinking you sent a message you did not, and does not lead to the various encoding issues Kevin mentioned separately. But also, just because the message failed to send, your ideas and the impetus for writing them down didn't vanish. Your brain is the back-up. In the event that the message in question is the unusual combination of lengthy, complex, and important enough that the pain of re-composing it from scratch is somehow prohibitive, then you damn well better be composing it using a word processor that takes frequent snapshots of your document as you compose, and then sending it as an attachment (or as a link, or by doing a text conversion, or... whatever)--not relying on your mail client to preserve it. And by the way even then, you can't guarantee 100% that you won't lose the data. Your hard disk could explode, say due to a lightning strike. No software can't protect you from that. At a certain point such considerations become completely ridiculous. I hesitate to go far as to say that if you think saving the message first is the right behavior, you are simply wrong... but I'm definitely thinking it. =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpa9q0F0H3H8.pgp Description: PGP signature
Re: order of sending mail and saving to fcc
On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote: > * Jack M [2019-06-04 10:20 -0500]: > > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote: > > > The other one (mail sent, but no local copy) > > > > Why would this situation would ever occur? > > A power failure at the wrong moment. A crash at the wrong moment. ... > > These things tend to happen only at wrong moments. But the failure mode of the current behavior is superior: With the old way, you look in Fcc and see the message was sent, so you don't send it again (unless you're unusually paranoid, maybe). With the current way, you see there's no message in Fcc, and you send it again. It's better to receive the same e-mail twice, than to never receive it at all, if it contains important content. And by the way, changes like this one don't happen in a vaccuum. The change was discussed on mutt-dev at some length when it happened, and it was eventually agreed that the new behavior is the right 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. pgpJPD9wD7jeR.pgp Description: PGP signature
Re: majordomo [Was: Send to a Listing]
On Wed, Apr 17, 2019 at 09:53:58AM +1000, m...@raf.org wrote: > if you want majordomo, i can send a copy but it's available at: > > ftp://ftp.icm.edu.pl/packages/majordomo/Welcome.html > > note that it's at least 18 years old and unsupported (but still works). > it might be a better idea to use mailman. The whole point of suggesting majordomo is that (IIRC) it keeps the recipients in a plain-text file, one address per line, making it trivial to replace them by dropping in a file that had them in that format in place of the existing file. You can't do that with mailman because it stores them in a db file. So in that case you'd be better off using a script to generate a mutt aliases file, or some other thing. -- 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. pgpIWMXiLdaYH.pgp Description: PGP signature
Re: [Fwd: Re: Send to a Listing]
On Sun, Apr 14, 2019 at 08:06:04PM +0200, felixs wrote:
> I searched in the documentation of sed (info sed), the bash-hacker's
> wiki (1) and read through the Advanced Bash Scripting Guide, but I
> haven't found the exact use case of redirecting input to all the files
> of a directory.
FWIW, you redirect input *from* a source file, not to it. You
redirect output *to* a destination file. And you won't find anything
that describes the use case of redirecting a program's input from
multiple files anywhere, because you can't do that. I/O redirection
is a function of your shell, so if you were to find it, it would be in
the shell's manual, not in sed's.
> But isn't there a way to address all the files in the INBOX? I mean, if
> it were a mbox format, no problem, that's just one file and its content
> can be fed into sed.
There are three ways to do this (with sed, see below for likely a
better option, depending on exactly what you want to do), and which
one you choose depends on what your goal is. I *think* they've all
been covered, but this thread has been a little hard for me to follow,
so I'll summarize briefly:
If you want to filter each message individually (putting its output
into one file per message) you have one option: Use the shell to loop
over the files, e.g.
ls -1 /path/to/spool | while read file; do
outfile_name = "${file}.out"
# You can use -e but you don't need it, no difference
sed -n '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' "$file" >
$outfile_name
done
This uses output redirection, but does NOT use input redirection.
NOTE: The reason I did it this way is because it properly handles any
file names with spaces or other special characters in them. There is
some nuance with using ls and specifying /path/to/spool vs.
/path/to/spool/*, but the first is what you would usually want. This
probably isn't interesting for Mutt mailboxes, but is a better
technique for the general case where your filenames may have spaces or
special characters in them.
If you want to process all the files at once and produce only one
output file, you have 2 options:
1. use cat:
cat /path/to/spool/* | sed -n ...
2. list the files on the sed command line:
sed -n ... /path/to/spool/*
> I'd be glad to be able to use this to have sed filter the INBOX for
> mails having arrived from a known sender with a known subject line,
> after mutt has polled for new mail.
FWIW, there may be a better tool for this purpose, depending on
exactly what you're trying to do: Procmail. It would filter your
messages according to this rule (and many other possible rules you
could create) *before* Mutt sees it, so that Mutt will find it in the
folder you intended it to be delivered to in the first place. It can
also be used to deliver mail to multiple folders, so that for example
certain messages are delivered to a separate "important" mailbox, but
still delivered to some other mailbox that is applicable to a larger
set of messages. Related to procmail is formail, which lets you do
things like extract headers from a message.
--
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.
pgpOsKjDhe5QK.pgp
Description: PGP signature
