Re: Question about message id
On Tue, Apr 09, 2024 at 09:33:06AM -0700, Will Yardley wrote: side note: using quotes around the template screws things up, that is, set message_id_format="" vs set message_id_format= results in a broken message-id with the quotes inside the angle brackets (Message-ID: <"xyz">) That shouldn't be the case. The outer double quotes are stripped off during muttrc evaluation. You may want to double check whether you accidentally copy/pasted unicode curly quotes. You can also check the value mutt has read in via :set ?message_id_format -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.13 released
Hi Mutt Users, I've just released version 2.2.13. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing two issues with the SMTP client code and $envelope_from_address. The first is a possible dangling pointer issue if $envelope_from_address is changed in an account-hook while sending. The second changes the SMTP client to respect $use_envelope_from, as the sendmail client does. Thanks to @mhepp63 for reporting the issue, with excellent details and debugging information. -Kevin [1] My public key is available at: - my personal website: https://8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: month September
On Sun, Sep 17, 2023 at 11:27:34PM +0200, Francesco Ariis wrote: There you have it. I wonder whether the ignored `!` in date_format is a bug or me misreading the man page (Mutt 2.2.9). I will wait for a developer’s reply before filing an issue $index_format by default uses the %{} expando: %{%b %d}. This uses the locale setting but you can prefix it with a ! to use C, e.g. %{!%b %d}. $date_format is used for the %d and %D expandos in $index_format, and the %D expando in $folder_format. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.12 released
Hello Mutt Users, I've just released version 2.2.12. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing two crash issues. One is possible by viewing a crafted message header, so upgrading is strongly recommended. Vendors, please backport these commits if possible: * <https://gitlab.com/muttmua/mutt/-/commit/452ee330e094bfc7c9a68555e5152b1826534555.patch> * <https://gitlab.com/muttmua/mutt/-/commit/4cc3128abdf52c615911589394a03271fddeefc6.patch> * <https://gitlab.com/muttmua/mutt/-/commit/a4752eb0ae0a521eec02e59e51ae5daedf74fda0.patch> A special thanks to Chenyuan Mi (@morningbread) for discovering the message composition crashes, giving a working example draft message, and providing the stack traces for the NULL deferences. Also thank you to everyone who submitted patches, filed tickets, and helped test! -Kevin [1] My public key is available at: - my personal website: https://8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: DKIM fails depending on Content-Transfer-Encoding
On Thu, Sep 07, 2023 at 11:57:09AM +0200, f...@igh.de wrote: Thank you for this hint. Unfortunately it does not work for me. Mutt insists in 8bit, maybe depending on my locales. Seems I have to study the source code... See if 'unset allow_8bit' helps. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: .muttrc: Accessing attachment filename and quoting
On Thu, Aug 24, 2023 at 05:10:39PM +0200, Orm Finnendahl wrote: Hi, 1. I try to write a macro allowing to open an attachment with another than the default program. Is there a way to refer to the filename of the attachment in the macro definition (like the %s in mailcap)? No. You might play around with the `test=` field in the mailcap and see if you can use that somehow. For example, one idea (untested) would be using setenv in the macro around the attachment opening: macro ,a 'setenv ATTPROGRAM foounsetenv ATTPROGRAM' macro ,b 'setenv ATTPROGRAM barunsetenv ATTPROGRAM' And in your .mailcap application/baz; fooprogram %s; test=test x$ATTPROGRAM = xfoo application/baz; barprogram %s; test=test x$ATTPROGRAM = xbar ... application/baz; defaultprogram %s 2. When piping an attachment to an external program, filenames with spaces don't work. is there a way to enclose the filename with quotes before submitting it to the pipe? You'll have to be more specific about what you are doing and how it's failing. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Why Mail-Followup-To header for a non-list address?
On Sun, Aug 20, 2023 at 03:53:09PM +1000, raf via Mutt-users wrote: I don't have any "lists" commands. I do have a "subscribe" command which refers to mailing lists by their aliases. One of the aliases is "debian" and the email address in question does contain "+debian" but that shouldn't matter. Hi raf, 'lists' and 'subscribe' specify regular expressions to match against email addresses, not aliases. That's most certainly why you are seeing this behavior. Try tightening the regular expression in the 'subscribe' command(s). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.11 released
Hello Mutt Users, I've just released version 2.2.11. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing a build issue with GPGME on MacOS. It also fixes an old bug with collapse-all when sort=reverse-threads. Thanks to everyone who submitted patches, filed tickets, and helped test! -Kevin [1] My public key is available at: - my personal website: https://8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: compiling issues on latest ventura + latest mutt
On Mon, Aug 14, 2023 at 09:50:51PM -0700, Will Yardley wrote: On Tue, Aug 15, 2023 at 12:39:34PM +0800, Kevin J. McCarthy wrote: If possible, would you be able to try building from the branch `kevin/stable-gpgme-macos-fix` and see if that addresses the compilation error? I tested on a different machine (but same version), and that seemed to resolve it. I created an issue here: https://gitlab.com/muttmua/mutt/-/issues/451 since that seems like a better way to track this now that I know this was an actual issue. Thanks Will. I've merged this fix into the stable branch and will get a 2.2.11 release out by this weekend. If anyone else is having the problem, please give stable a try and let me (or the gitlab ticket) know about any problems. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: compiling issues on latest ventura + latest mutt
On Mon, Aug 14, 2023 at 02:02:52PM -0700, Will Yardley wrote: Building latest mutt (2.2.10) on latest Ventura (13.5) (using homebrew for all the deps), and getting errors like this for gpg-error and a similar one for gpgme itself (side note: the actual problem I'm trying to fix is weird screen redraw artifacts since updating OS X with the version I'd had installed: 2.2.7; not sure if anyone else is seeing anything like that). Sorry for my delayed attention to this issue. Mutt 2.2.9 did make changes to the GPGME build process: it updated to the latest autoconf files from upstream to fix build issues. However, it appears that inadvertently caused problems on MacOS. If possible, would you be able to try building from the branch `kevin/stable-gpgme-macos-fix` and see if that addresses the compilation error? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Option to disable S/MIME signature check?
On Mon, Jul 31, 2023 at 08:43:22PM +0200, ilf wrote: Do you think I should file a feature request for this in the tracker? Yes, please go ahead. I don't have a current timeline for starting master development again, but when I do, it will be good to have the request there. Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Option to disable S/MIME signature check?
On Sat, Jul 29, 2023 at 02:48:56PM +0200, ilf wrote: I have also never used "spam" before. I wonder if this feature is really correct for my use-case, which has nothing to do with spam. It might do the job, but it doesn't feel clean. It _is_ a "creative" use of the spam command. I think if you read about the command you may agree there isn't anything particularly wrong with using it for this purpose. It just allows labeling messages in a way that is efficient to search against. There seem to be quite a few users with this issue. Do you think a boolean option like "crypt_verify_smime" that explicitly works even with GPGME would be feasible? From a user POV, it sure sounds logical and useful. Yes, that may be possible although it might be better to then deprecate $crypt_verify_sig and just have the separate pgp and smime config vars (which should be quadoptions). It certainly wouldn't go in a stable release. Also, is there a way to shorten the time that SMIME signature verification needs before timing out? 25 seconds sounds much too long to me. I don't know what it's doing that takes so long to time out, and have no idea how to adjust that. Maybe others who use s/mime with GPGME have ideas. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Unsubscribing from GitHub notifications from mutt
On Sat, Jul 29, 2023 at 11:38:00AM +0200, Sébastien Hinderer wrote: Has anybody already set-up such a feature? Would be interested in the details on (1) then. If you don't mind using the mailto URL, Mutt 2.1+ has , bound to 'Esc-L' by default. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Option to disable S/MIME signature check?
On Wed, Jul 26, 2023 at 09:37:34AM +0800, Kevin J. McCarthy wrote: spam content-type:.*pkcs7 smime Sorry, it's a good idea to root the regexp above: spam ^content-type:.*pkcs7 smime -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Option to disable S/MIME signature check?
On Tue, Jul 25, 2023 at 12:32:40PM +0200, ilf wrote: I do use OpenPGP. So disabling "crypt_use_gpgme" is not an option for me, same for changing "crypt_verify_sig". In the old thread from 2018, Kevin J. McCarthy proposed this: However, you could try set smime_verify_command="" (along with smime_verify_opaque_command and smime_decrypt_command). But this does not work. According to muttrc(5) the default value for these three options is already "", and I am not setting them anywhere. That option only works when $crypt_use_gpgme is unset. So: How can I disable the S/MIME signature check while still using GPGME for OpenPGP? The option $crypt_verify_sig is shared between PGP and S/MIME, so you'll have to be creative if you are using GPGME. Maybe something like: spam content-type:.*pkcs7 smime message-hook ~A 'set crypt_verify_sig=yes' message-hook '~H smime' 'set crypt_verify_sig=no' # or '=ask-no' -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: INBOX message count in sidebar
On Mon, Jul 24, 2023 at 07:22:29PM +0200, Mikhail Nidze via Mutt-users wrote: My mailboxes are set like this: mailboxes = -label "INBOX" "imaps://my_acco...@imap.mail.me.com/INBOX" I see you solved your problem, but also note the mailboxes command doesn't use an assignment syntax. The '=' will be interpreted as a mailbox shortcut for $folder. Just use: mailboxes -label "INBOX" "imaps://my_acco...@imap.mail.me.com/INBOX" -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: occasional lockup when built with slang
On Mon, May 01, 2023 at 05:47:11PM -0400, Mark E. Mallett wrote: On Mon, May 01, 2023 at 02:06:50PM -0700, Kevin J. McCarthy wrote: Can you try this against version 2.2.7? When I first saw it, I tried it with a version of 2.2.1 that I had, and I could reproduce it with that as well. I've been poking at it for a while, in between various distractions. I just tried it again just to make sure I wasn't imagining it and yeah, still happens. I'm pretty sure I tried some older versions too but I didn't take notes. Okay thanks for the information. I will try to look into this. However, it may take me some time before I can get to it. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: occasional lockup when built with slang
On Mon, May 01, 2023 at 12:30:05PM -0400, Mark E. Mallett wrote: I'm seeing an issue with mutt built with slang. It happens very rarely but I can get it to happen if I try. This could easily be something with my environment, as I don't think it's a typical one. But I'm curious if anybody else can make it happen and if so, can understand it ;) Is this a new problem? I changed some resize handling in version 2.2.8. I'm not sure how that would affect getch() locking up, but perhaps it tickled a bug in the slang code somehow. Can you try this against version 2.2.7? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: How can I post ja.po update patch?
On Mon, May 01, 2023 at 10:25:45PM +0900, ribbon wrote: I am using mutt in Japan. I found fuzzy in the ja. po file of mutt 2.2.10, so I corrected it. How can I post a patch? Please post the patch to the mutt-po mailing list. See the subscribe instructions for "Mutt Translators" at <http://www.mutt.org/mail-lists.html>. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Forward with attachments
On Tue, Apr 18, 2023 at 04:02:36PM -0500, Jason wrote: Is there a configuration that will make mutt's forwarding behavior more like other clients I have used: body is quoted in the message, and attachments are automatically attached? The options I have tried are: 1. Regular forward. Attachments are not included. $forward_attachments, added in Mutt 1.12.0, will prompt to attach non text-decodable attachments. However, Mutt considers autoview types to be text decodable. $honor_disposition can override this. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Newbie help for an imap gmailg connection
On Tue, Apr 11, 2023 at 05:32:38PM -0400, Dan Dunfee wrote: What are the steps to get this additional gmail "app password" for use as "secret_app_password" in muttrc? My information may be out of date, but I believe Google first requires "2-step verification" to be enabled before an "app password" can be generated. This can be done at <https://myaccount.google.com/signinoptions/two-step-verification> Once that's done, an app password can be generated at the bottom of that same page. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Has the handling of my_hdr and send_hook changed between 1.10.x and 2.1.4?
On Mon, Apr 10, 2023 at 07:06:14PM +0100, Chris Green wrote: On Mon, Apr 10, 2023 at 06:45:04PM +0100, Chris Green wrote: I'll try to narrow this down further by trying a very short list of mailing list names. After a bit of chopping and changing the list of addresses in 'lists' I finally spotted my problem. Totally my fault, my program that generates the list doesn't handle quoted addresses properly so there was an unclosed quote in the list of addresses. Not surprisingly that stopped things working. The source file for the lists on the old system running mutt 1.10.1 hadn't got the quoted address in it (yet) so the error didn't appear there. Great news, I'm glad you were able to figure out the problem! I actually did touch the lists and subscribe code in between those releases, so I started scrambling to find the bug. I'm glad to hear it turned out to be a script error. :) As a followup, the 'subscribe' command also adds to 'lists', so there is no need to have the same mailing list sent to both of those commands. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Has the handling of my_hdr and send_hook changed between 1.10.x and 2.1.4?
On Mon, Apr 10, 2023 at 09:19:04AM +0100, Chris Green wrote: On Sun, Apr 09, 2023 at 02:28:00PM -0700, Kevin J. McCarthy wrote: It's working in my simple testing, so perhaps there is something more involved. Can you create a small reproducing muttrc file and a list of exact instructions to trigger the change in behavior? If I send a message to the mutt mailing list from the old (version 1.10.1) mutt the headers I see are:- From: Chris Green If I send a message to mutt from version 2.1.4 of mutt I see:- From: Chris Green Is there a copy paste error above? I can't test with a muttrc that long, which sources external files and commands I don't have access to. Please, when I say minimal, I mean *minimal*. I have tested against latest git with this muttrc: lists mutt-users@mutt.org subscribe mutt-users@mutt.org set my_addr = 'ch...@isbd.co.uk' send-hook . 'my_hdr From: Chris Green <$my_addr>' send-hook ~l 'my_hdr From: Chris Green ' I invoke mutt with 'mutt -F cgreen.muttrc', type 'm', enter mutt-users@mutt.org at the To prompt. After the subject prompt and editor complete, the From line in the compose window shows: From: Chris Green If I discard the message, type 'm' again, and enter foo at the To prompt, after the subject prompt and editor complete, the From line in the compose window shows: From: Chris Green Can you test again using that 5-line muttrc and verify the same thing? If that works for you, I need for you to try adding things from your original muttrc to see what causes the difference. Also, please mention if you are doing anything differently in your testing - are you using aliases, for example? Thank you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Has the handling of my_hdr and send_hook changed between 1.10.x and 2.1.4?
On Sun, Apr 09, 2023 at 08:23:55PM +0100, c...@isbd.net wrote: I'm trying to sort out why something that used to work for me no longer works. I just went and tried out an older installation that still runs mutt 1.10.4 and there my send-hook/my_hdr configuration works. It doesn't work on my current mutt 2.1.4. Not knowingly, but a lot of the sending code has been modified in that period of time. I see the documentation now says "Also note that my_hdr commands which modify recipient headers, or the message's subject, don't have any effect on the current message when executed from a send-hook.". Is this a recent change? That applies to a my_hdr that adds a recipient header, such as To, Cc, Bcc. It didn't change; the documentation for the behavior was just added. This appears to no longer work. It's working in my simple testing, so perhaps there is something more involved. Can you create a small reproducing muttrc file and a list of exact instructions to trigger the change in behavior? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: How to remove the gap between the status bar and the INBOX
On Mon, Apr 03, 2023 at 12:03:12PM +0800, Sadeep Madurange wrote: Yes, a minimum reproducing muttrc (see attached for the screenshot - the gap between status bar and the word "INBOX" on the left): set imap_user=x...@asciimx.com set imap_pass=`pass show email` set folder=imaps://imap.example.com:993 set from=sad...@asciimx.com set spoolfile=+INBOX mailboxes = +INBOX The mailboxes command is not an assignment. Change the above line to just: mailboxes +INBOX -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: How to remove the gap between the status bar and the INBOX
On Sat, Apr 01, 2023 at 05:48:41PM +0800, Sadeep Madurange wrote: I just switched to mutt from neomutt. There is a gap of one row between the status row and the first folder (i.e., INBOX) in the sidebar. Can I remove that? To make sure I understand, you have $status_on_top set, and there is a blank line inside the sidebar at the top, before the first folder is listed; but not in the index. Is that correct? That's not expected behavior, and I'm not seeing it in my testing. Can you create a minimum reproducing muttrc? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.10 released
Hi Mutt Users, I've just released version 2.2.10. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing several small issues. It also changes the message-id Base64 encoding to use a url-safe version. Thanks to everyone who submitted patches, filed tickets, and helped test! -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: Incompatible IMAP authentication methods
On Fri, Mar 17, 2023 at 11:53:05PM +0100, Sébastien Hinderer wrote: I am trying to read emails on an exchange server through IMAP. The server only accepts the PLAIN and XOAUTH2 authentication methods, whereas mutt offers SASL, GSSAPI, CRAM-MD5 et LOGIN. When compiled with SASL support (either GNU or Cyrus), Mutt can use the PLAIN authentication method provided by the library. Try setting imap_authenticators='plain' and see if that works. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Deleting large number of emails from busy mailbox
On Tue, Mar 14, 2023 at 08:40:24AM +0100, Vegard Svanberg wrote: After reading the fine manual, I don't see an immediate way to disable trash. Assuming I'll have to move it to IMAP then. Which is fine, just wondering if trash could be disabled as I don't really need it. $trash starts out empty, so there must be a line in your muttrc setting it. Just comment out that line. But, in general, to unset it, you can just 'set trash=""' or 'unset trash' in your muttrc file. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Deleting large number of emails from busy mailbox
On Mon, Mar 13, 2023 at 08:47:14AM +0100, Vegard Svanberg wrote: Latest mutt on local IMAP (Dovecot). My mailbox is rather busy (and contains around half a million emails). Say I want to delete 2000 emails. I tag them, ;d and press X to expunge. Mutt starts fetching every email (not sure why that is - does it have to?), then would normally remove them after that. Do you mean the 2000 emails you want to delete, or the half-million emails in the mailbox? If it's the first, it sounds as if Mutt thinks the value in $trash is not the same server as the mailbox you are connected do. Otherwise it would do a UID COPY on the server side, which would be faster. You can check this by running mutt with '-d 3' and search in the log for imap_fast_trash. If that wasn't intentional, try to see if $trash and the current mailbox URL differ somehow and try to make them the exact same. Problem is: if a new email arrives during this process (which could take a few minutes), Mutt never gets around to actually removing the messages. It just seems to abort in the middle of the operation and I have to do expunge again until I eventually succeed after a few attempts. Anything I could do my end to solve this? That's unfortunately an old issue with Mutt's sync design. It checks the mailbox for any reopen/new/flag updates before trying to sync and aborts if that's the case. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: from and envelope_from_address
On Sun, Feb 12, 2023 at 05:14:38PM -0800, Ian Zimmerman wrote: lists -group mutt mutt-users send-hook '%L mutt' "set from='googly.negotiator...@aceecat.org' ; set envelope_from_address='googly.negotiator...@aceecat.org'" You can assign envelope_from_address=$from. However, make sure you use a single quote on the send-hook command, to delay expansion of $from until the hook is executed: send-hook '%L mutt' 'set from="googly.negotiator...@aceecat.org" envelope_from_address=$from' If you cover all cases with the send-hook, you could also put the final assignment in its own send-hook: send-hook '~A' 'set from="defa...@example.com"' send-hook '%L mutt' 'set from="googly.negotiator...@aceecat.org"' [...] send-hook '~A' 'set envelope_from_address=$from' -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Does MUTT have support for MDN? (Message Disposition Notification)
On Sat, Feb 04, 2023 at 02:48:19PM +0200, e wrote: If a received mail contains the "Disposition-notification-to:" header field, what does MUTT do? Nothing. Mutt ignores the header. What kind of configuration can you do for MDNs generated by MUTT? Perhaps my_hdr. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Selecting INBOX... problem
On Wed, Feb 01, 2023 at 07:50:40PM +0200, Jarkko Lavinen wrote: Using debug I see 'a0006 SELECT "INBOX"' as the last message. What debug level are you using? Try at least level 3, in this case. After sending the SELECT command, Mutt tries to read some values, such as UIDVALIDITY, from the header cache and should generate some debug output (at level 3) if they exist. After that it tries to read the response from the server. You may also want to try trimming your muttrc down to the bare minimum, just to see if you can get it to work from a starting point. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Problem with IMAP Server and Header Cache
On Thu, Jan 26, 2023 at 05:07:50PM +0100, Christian Brabandt wrote: I tried building building latest master with --with-kyotocabinet Thank you for rebuilding and testing. Since the problem isn't with the header cache backend, this smells like a Mutt bug. Would you mind opening a ticket so we can debug it without causing too much traffic on mutt-users? It took me a bit until I found `./prepare` but then I could run configure (and for some reason, it didn't like my installed `libidn2-dev` library, so I build without `--with-idn`, but I suppose for the test it doesn't really matter.) There is a --with-idn2 configure flag you can use instead. The packaged mutt used libidn, so I assumed build-dep would install that library. But I am afraid, I am seeing the same problem (I haven't waited yet 3 hours until mutt gets disconnected from the IMAP server, but the symptoms look exactly the same. I'll need some more debug information to try and figure out what's going on. I'm attaching a patch. If you would apply, re-compile and run with debug mode (-d 2), it should hopefully give some useful info about what's happening at the hang point. You only need to let mutt run for a minute and then kill it. Otherwise the debug file will get really really big. If you would post that to the ticket (taking care to remove the authentication parts), I would appreciate it. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA From f5b644b42c418b727ecf758d9c706fa429823cd2 Mon Sep 17 00:00:00 2001 From: Kevin McCarthy Date: Thu, 26 Jan 2023 11:00:19 -0800 Subject: [PATCH] wip: debug statements --- imap/message.c | 9 + 1 file changed, 9 insertions(+) diff --git a/imap/message.c b/imap/message.c index 376b91dc..e27c0bc3 100644 --- a/imap/message.c +++ b/imap/message.c @@ -587,12 +587,15 @@ static int read_headers_qresync_eval_cache (IMAP_DATA *idata, char *uid_seqset) ctx = idata->ctx; msn = 1; + dprint (2, (debugfile, "seqset: %s\n", uid_seqset)); + iter = mutt_seqset_iterator_new (uid_seqset); if (!iter) return -1; while ((rc = mutt_seqset_iterator_next (iter, )) == 0) { +dprint (2, (debugfile, "read seqset uid %u\n", uid)); /* The seqset may contain more headers than the fetch request, so * we need to watch and reallocate the context and msn_index */ if (msn > idata->msn_index_size) @@ -601,6 +604,7 @@ static int read_headers_qresync_eval_cache (IMAP_DATA *idata, char *uid_seqset) h = imap_hcache_get (idata, uid); if (h) { + dprint (2, (debugfile, "\tfound in header cache\n")); idata->max_msn = MAX (idata->max_msn, msn); idata->msn_index[msn - 1] = h; @@ -640,7 +644,12 @@ static int read_headers_qresync_eval_cache (IMAP_DATA *idata, char *uid_seqset) * stored "blank" in the uid seqset. */ else if (!uid) +{ + dprint (2, (debugfile, "\tblank\n")); msn++; +} +else + dprint (2, (debugfile, "\tmissing from header cache\n")); } mutt_seqset_iterator_free (); -- 2.39.0 signature.asc Description: PGP signature
Re: Problem with IMAP Server and Header Cache
On Wed, Jan 25, 2023 at 10:13:58PM +0100, Christian Brabandt wrote: No. I mean it happens whenever mutt quits (or has been forcefully shutdown). Sometimes I also notice a normal quit takes very long (I assume it somehow writes/updates the header cache and this may also take a while?) I can "fix" it by manually deleting the header cache, but then mutt starts loading all those messages again and it again takes a bit until the mailbox is open. Hmmm... I see in the log that even in the "working" case it's taking a good 15 seconds to load in the messages from the seqset/header cache. It's a big mailbox, though, so maybe that's to be expected. I noticed you are using 1.13.2. Are you in a position to try building a newer version of mutt? There have been several important fixes to QRESYNC since then (including a bug in the seqset iterator). It doesn't *look* like that's the issue here, but it would still be a good idea to try 2.2.9 if possible. While you are at it, you might also try building with a different header cache backend. Perhaps tokyocabinet is having issues. I would suggest kyotocabinet or perhaps lmdb and see how they work. On ubuntu, just run $ sudo apt build-dep mutt $ sudo apt install libkyotocabinet-dev liblmdb-dev $ ./configure --enable-compressed --enable-debug --enable-fcntl \ --enable-hcache --enable-gpgme --enable-imap --enable-smtp \ --enable-pop --enable-sidebar --with-curses --with-gnutls \ --with-gss --with-idn --with-sasl \ --with-kyotocabinet (or --with-lmdb) $ make $ sudo make install -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Problem with IMAP Server and Header Cache
On Wed, Jan 25, 2023 at 07:54:49PM +0100, Christian Brabandt wrote: For some reason, whenever mutt disconnects and I want it to reload a mailbox with 100k messages in it, it usually hangs for very long until it finally disconnects. Do you mean this only happens after a disconnect within mutt, and only when you try to reopen the same mailbox without closing mutt? Or does this happen in other circumstances too. It's possible to re-connect and then it seems to load the mailbox just fine. It would be interesting to see the debug log for that same section when it "works". (Up until the "Fetching flag updates..." part). My first guess is that the seqset is corrupted somehow, or perhaps the header cache has a problem, but that wouldn't explain why it sometimes works. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: IMAP to my company's server is failing
On Wed, Jan 18, 2023 at 08:36:23PM +0100, Matthias Apitz wrote: Until today I could read (in my spare time) my company mails with mutt and IMAP. Since today it gives in the debug log: ... [2023-01-18 19:21:31] 4< * OK The Microsoft Exchange IMAP4 service is ready. [RgBSADMAUAAyADgAMQBDAEEAMAAyADAANAAuAEQARQBVAFAAMgA4ADEALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==] [2023-01-18 19:21:31] IMAP queue drained [2023-01-18 19:21:31] 4> a CAPABILITY^M [2023-01-18 19:21:31] 4< * CAPABILITY IMAP4 IMAP4rev1 AUTH=PLAIN AUTH=XOAUTH2 SASL-IR UIDPLUS ID UNSELECT CHILDREN IDLE NAMESPACE LITERAL+ [2023-01-18 19:21:31] Handling CAPABILITY [2023-01-18 19:21:31] 4< a OK CAPABILITY completed. [2023-01-18 19:21:31] IMAP queue drained [2023-01-18 19:21:31] imap_authenticate: Trying method login Is mutt compiled with any kind of SASL support? What does `mutt -v | grep SASL` show? Do you have $imap_authenticators set to anything? [2023-01-18 19:21:31] SASL local ip: 192.168.178.41;23775, remote ip:xxx.xxx.xxx.xxx;993 [2023-01-18 19:21:31] External SSF: 256 [2023-01-18 19:21:31] External authentication name: x...@xxx.org [2023-01-18 19:21:31] Entrando... [2023-01-18 19:21:31] 4> a0001 LOGIN "x...@xxx.org" "xxx-xxx"^M [2023-01-18 19:21:36] 4< a0001 NO LOGIN failed. Login generally works, even if not advertised, but you may want to try setting imap_authenticators=plain. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Muttlisp question
On Tue, Dec 06, 2022 at 10:08:04PM +0100, Andy Spiegl wrote: Well, you could try putting the keybindings such as Sure, but weren't we talking about efficency, i.e. without Muttlisp? :-) Oh, I meant less efficient because the evaluation is done every time the key is pressed when using the macro. Plus it's a macro executing a which is evaluating MuttLisp. The bind cost is paid a single time, when toggling the sidebar, but not when pressing the key. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Muttlisp question
On Tue, Dec 06, 2022 at 08:47:27PM +0100, Andy Spiegl wrote: The muttlisp can't be inside quotes, so I removed the outer single quotes. Is this only true for "bind" lines? Because in the macro the muttlisp code is inside quotes: macro index j 'run (if (equal $sidebar_visible "yes") \ "exec sidebar-next" \ "exec next-undeleted")' Sorry I wasn't clear enough. When a command is read and executed by the muttrc parser, a MuttLisp argument can't be surrounded by quotes. That is, the muttrc parser won't look inside a quoted argument for MuttLisp. The above macro, when initially read in from your .muttrc, won't look for MuttLisp in the third argument. However, when the macro is executed, by pressing 'j', it starts a command prompt, using . The line: run (if (equal $sidebar_visible "yes") "exec sidebar-next" "exec next-undeleted") is then read and executed by the muttrc parser when is processed at the end of the macro. At that time, it will evaluate the first argument to the run command as MuttLisp because it is not surrounded by a quote. Note that surrounding the macro with single quotes prevents the evaulation of $sidebar_visible when the muttrc is evaluated. So the MuttLisp above will look at the value of $sidebar_visible when it is executed. It's a bit less efficient, so if that's a concern, you could just use a macro to toggle $sidebar_visible and at the same time source a file with the special "sidebar toggling" bind commands. Good idea but how would I set the key bindings depending on the visibility state of the sidebar? I'd need some kind of if-then-else because the toggle macro doesn't "know" the state. Or can you think of a smart method to do that? Well, you could try putting the keybindings such as bind index j (if (equal $sidebar_visible "yes") \ 'sidebar-next' \ 'next-undeleted') bind index k (if (equal $sidebar_visible "yes") \ 'sidebar-prev \ 'previous-undeleted') [...] in a file '~/.mutt/sidebar-bindings' and then macro index ^ "\ toggle sidebar_visible\ source ~/.mutt/sidebar-bindings\ " -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: test shell env in .muttrc
On Mon, Dec 05, 2022 at 06:18:05PM -0800, Will Yardley wrote: I think there may be an internal way as well, but one option would be to set an env var (e.g., TYPE) depending on the type of session, and then do something like (untested): source ~/.mutt/colors.${TYPE:-default} See also <http://www.mutt.org/doc/manual/#muttlisp> for some examples of MuttLisp. For example: source (concat "~/.mutt/colors." (or $TYPE default)) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Muttlisp question
On Mon, Dec 05, 2022 at 04:12:01PM -0800, Kevin J. McCarthy wrote: set muttlisp_inline_eval bind index j (if (equal $sidebar_visible "yes") \ 'sidebar-next' \ 'next-undeleted') I realized after I sent that you might be wanting to dynamically determine if the sidebar is visible. The above just affects what is bound to 'j' when evaluated. To do that, you could try a macro: macro index j 'run (if (equal $sidebar_visible "yes") \ "exec sidebar-next" \ "exec next-undeleted")' It's a bit less efficient, so if that's a concern, you could just use a macro to toggle $sidebar_visible and at the same time source a file with the special "sidebar toggling" bind commands. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Muttlisp question
On Tue, Dec 06, 2022 at 12:24:58AM +0100, Andy Spiegl wrote: I'm trying to bind the "j" key to the function "sidebar-next" if the sidebar is visible. The only doable way seems to be using muttlisp. I tried to follow the example in the mutt manual but I'm failing to write this tiny piece of lisp code. Could someone help me please to correct the follwing? Or maybe there is a better/easier way to do this? -- # sidebar visible --> bind index j next-undeleted # sidebar NOT visible --> bind index j sidebar-next bind index j '\ (or \ (if (not $sidebar_visible) 'next-undeleted') \ ('sidebar-next') \ ) \ ' Try something like: set muttlisp_inline_eval bind index j (if (equal $sidebar_visible "yes") \ 'sidebar-next' \ 'next-undeleted') The muttlisp can't be inside quotes, so I removed the outer single quotes. Also, boolean variables evaluate to "yes" or "no". I will add this to the documentation. Hope that helps. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Select message by attachment MIME type
On Tue, Nov 29, 2022 at 08:31:37PM +0100, Max Görner wrote: for a macro I would like to match a message based on its attachments. Since I have to use Outlook Web App, I often get calender events as e-mail. Messages telling me that someone accepted my invitation are empty and contain an attachment without a name but with file type text/calendar. Is there a way to select messages containing an attachment of type text/calender (or any other, for that matter)? Try the ~M pattern, e.g. ~M text/calendar, and see if that works. Note that this is a *slow* pattern. It opens up and reads each message in the mailbox. So I don't recommend using this for index coloring or things like that. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Abort macro if limit pattern does not match anything
On Tue, Nov 29, 2022 at 08:25:02PM +0100, Max Görner wrote: Is there a way to abort the macro if the pattern does not match anything? It is quite annoying to tidy up after the macro every now and then. Hi Max, Have you tried using instead of ";" in your macro? See <http://www.mutt.org/doc/manual/#tags> for more details. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Sat, Nov 19, 2022 at 02:32:25PM +1100, Cameron Simpson wrote: Maybe the docs should have a small mention around `~h` that it cannot utilise the header cache. There is a note, "***)", next to ~b, ~B, ~h, ~M, and ~X that mentions they entail reading the whole message in and recommends not using them for index coloring. <http://www.mutt.org/doc/manual/#patterns> -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Sat, Nov 19, 2022 at 02:15:05PM +1100, Cameron Simpson wrote: On 18Nov2022 18:33, Kevin J. McCarthy wrote: The headers are colored as they are displayed, but also when any flags are updated. If it's only colouring the visible index listing, that's fine with me. No, it's not. I will fix that. BTW, is there a way to tell if the current message is a collapsed thread in the index or just a single message? There are times when that would be useful. %M might work for you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Sat, Nov 19, 2022 at 01:16:47PM +1100, Cameron Simpson wrote: On 19Nov2022 08:32, Cameron Simpson wrote: The issue is my index colouring, specificly this line: color index white default "((~P|%f polyname ~h '^from:.*cameron simpson')) | (~v ~((~P|%f polyname ~h '^from:.*cameron simpson')))" I'm wondering if it is the `~h` pattern. That would search every header, which I presume exceeds the cache? ~h always opens up the message and scans header by header. It doesn't use the header cache. BTW ~() can also be very expensive. Is there an efficient way to search the _text_ of the `From:` header? Not match the from address part, but the comment string (which is where the "cameron simpson" resides)? ~f scans the display name part of the address in most cases, including for color commands. If you mean an actual address comment field, e.g. (text), those are considered the display name if none otherwise exists. But if there is also a display name, the parser discards the comment. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Sat, Nov 19, 2022 at 08:32:39AM +1100, Cameron Simpson wrote: It sure looks like it is being applied to the entire folder contents, instead of only the lines being displayed. That is a massive performance hit for a big folder. Is that the case? The headers are colored as they are displayed, but also when any flags are updated. Do you have a folder-hook doing anything related to that, or message scoring going on related to the $score_threshold_* settings? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Fri, Nov 18, 2022 at 09:06:30PM +1100, Cameron Simpson wrote: Starting with an empty config except for a header cache dir setting, I notices a distinct slowdown of the scan at about 80%. Odd. So I moved the cache sideways and let it rebuild: 43869952 18 Nov 20:43 02a1cc9292e0222624346e5ff8742f34 73852160 18 Nov 20:09 02a1cc9292e0222624346e5ff8742f34-ASIDE This brought a nice linear scan. Yeah, the header caches can get inefficient after a while. I'm glad that helped. So I started adding back in my config files (I source a few). Here's the glaring one: source ~/rc/mutt/aliases-auto 8407 aliases, nearly 2MB in size :-) Really, it is a bit excessive. Particularly since I think I don't ever use aliases anyway. Yes, Mutt's internal structures used for aliases are not designed for that many. It could lead to quite a slowdown in some circumstances. Do you have $reverse_alias set in your config? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: why does mutt take so long to load my python folder?
On Wed, Nov 16, 2022 at 11:43:39AM +1100, Cameron Simpson wrote: The stuff before the "Sorting mailbox..." phase seems ... fast enough. During the "Sorting mailbox..." phase I see mutt reading message files I'd not expect it to need to touch, _and_ making some temporary files. Example `lsof` output: Note the 'Sorting mailbox...' is actually displayed post-sorting too. You could try adding a mutt_message() after the sort to see if that helps clarify where the slowdown is. That `cur` message file dates from 2021-07-15 17:36:10 GMT (long ago) and the temporary file is indeed temporary - it vanishes. I speculate that mutt's... unpacking the source message in some way? Seems likely, but off the top of my head I can't guess what's doing it. Pre-sorting, $maildir_header_cache_verify will cause a re-read if the file stat is more recent than the value in the header cache. But that shouldn't persist. Sorting itself shouldn't be reading messages. Have you tried adding '-e set sort=mailbox-order' to the command line to see the difference in time? You may also want to pare your muttrc file down to make sure something else isn't causing the issue. e.g. scoring, or coloring or some such.. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.9 released
Hello Mutt Users, I've just released version 2.2.9. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing a build issue with recent versions of GPGME. Thanks to everyone who reported issues and helped test. -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: Understanding message deletion model
On Fri, Nov 11, 2022 at 03:38:25PM -0500, Jason Franklin wrote: For example, let's say I mark a message to be deleted, and I have mutt set to say "yes" to the purge prompt at the end of my session, but my computer dies before I can properly close out my mutt process. Will I then lose those messages as I have done here? I think also relevant is your reply to Hsieh Chin Fan: I meant that I checked my IMAP folder called "Trash", not the folder designated by $trash. That setting is empty in my new configuration, so mutt doesn't know anything about a trash folder. If you don't set $trash, then answering "yes" at the purge prompt will permanently delete those messages. Because your IMAP server auto-expunges, answering "no" at the purge prompt will also result in those message being permanently deleted, whether you have $trash set or not (because Mutt assumes the messages won't be expunged and so doesn't copy them to $trash). I would suggest putting 'set trash = "=Trash" ; set delete = yes' in your .muttrc to avoid messages going missing. That way Mutt will copy deleted messages to your trash folder before syncing. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Understanding message deletion model
On Thu, Nov 10, 2022 at 08:47:44PM -0500, Jason Franklin wrote: Now, if I re-open mutt, the message is gone... completely. I'm confused as to why the message was removed even though I typed 'n' at the prompt for whether or not to proceed with the purge. Are "purging" and "deleting" not the same thing? According to the IMAP protocol, they are not. Deleting is marking the message with the "deleted" flag, which normally doesn't automatically remove it from the mailbox. Purging (expunging) will remove messages marked as "deleted" from the mailbox. When you answer 'n' at the prompt, Mutt takes care not to issue a command that would expunge those messages. However, some IMAP server implementations will automatically remove messages marked with a deleted flag anyway. Gmail, for instance, has a setting, "auto-expunge", to allow the user to control this. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Key binding problem
On Mon, Nov 07, 2022 at 01:03:31AM -, Jeffery Small wrote: One thing to note is that on the help page, these assignments are being displayed as the characters A, C, D and ? which could generate confusion since these are not the actual characters which also show up and are bound to other actions. Oh, thanks for letting me know. I'll look into and try to get that fixed. The problem is solved, but just in case you want to investigate further, I include the terminfo entry below. Thanks, I'll try to take a look when I have a moment. However, in truth, I only know the basics of terminfo, so it's unlikely I'll have any great insights. :-) -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Key binding problem
On Sun, Nov 06, 2022 at 07:31:44PM -, Jeffery Small wrote: I just tried that, but the debug file reports the same thing shown on the command line when the key is pressed. Here are the results: Keypad / key: Oo: Char = A, Octal = 1101, Decimal = 577 Keypad * key: Oj: Char = C, Octal = 1103, Decimal = 579 Keypad - key: Om: Char = D, Octal = 1104, Decimal = 580 Keypad + key: Ok: Char = ?, Octal = 1077, Decimal = 575 Keypad Enter: OM: Char = , Octal = 527, Decimal = 343 For these large octal values, you can try the syntax in your muttrc. e.g. bind generic <1101>first-entry bind generic <1103>last-entry bind generic <1104>select-entry bind generic <1077>next-entry bind generic next-entry So what is up with this? Why is mutt seeing one thing output while other programs such as vim and less see the escape code sequences? Mutt uses ncurses for terminal input/output interaction. Those are the values the ncurses getch() function is returning to mutt. Unfortunately, I couldn't tell you why this differs, but I'm fairly sure vim and less don't use ncurses. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Key binding problem
On Sat, Nov 05, 2022 at 07:25:46PM -0700, Jeffery Small wrote: I tried using the what_key function, but it's of little use as it only reports the last character of the escape sequences. Have you tried running mutt with '-d 1', running , and looking at ~/.muttdebug0 as you press those keys? That might list the full sequence of keys mutt is seeing when you press the non-working keys and give a clue. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.8 released
Hello Mutt Users, I'm pleased to announce the release of version 2.2.8. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing a possible crash with GPGME when viewing an application/pgp key block. It also makes some changes to redrawing and resizing handling, and adds support for batch-mode IMAP Fcc. Please see the UPDATING file for more details. Thanks to everyone who reported issues and helped test. -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: The way mutt handles long lines, seems odd/wrong to me
On Fri, Sep 30, 2022 at 02:42:09PM +0100, Chris Green wrote: I'm am also pretty sure that it's the mutt pager doing this as other programs (i.e. less) wrap long lines in a terminal window but don't chop them into pieces like mutt's pager. Mutt uses ncurses to draw on the screen, which is a layer of indirection. Mutt is telling ncurses where to put things, but when Mutt refreshes the screen, ncurses actually sends the needed commands and contents to the terminal. In that past, I've tried a few things to see if it has an effect on the output of long lines, but haven't found anything that makes a difference. In the end, I believe it's a side effect of how ncurses works. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Deleting github commit messages: folder-hook/regex problem
On Tue, Sep 27, 2022 at 04:13:21PM +0200, Francesco Ariis wrote: 2. wrote this folder-hook in my muttrc: folder-hook fa-ml 'push ~b"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$"!~F' The third argument above, "push", will be evaluated twice by the muttrc parser. The first time, when reading the line out of your muttrc file. The parser will extract three arguments: folder-hook fa-ml push ~b"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$"!~F Note when the third argument was parsed, the single quotes are not included in the result - they are used to evaluate the argument in "single quotes" mode during parsing. Mutt uses this to create a folder hook, matching against 'fa-ml', and will parse and run the third argument when the hook runs. So, when the folder hook actually runs, the muttrc parser will extract two arguments: push ~b^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$!~F Note the double quotes are not included in the result, they (again) are used to evaluate their contents in "double quotes" mode during parsing. You could try putting a backslash in front of each double quote: folder-hook fa-ml 'push ~b\"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$\"!~F' Or alternatively, add an escaped single quote around the second argument: folder-hook fa-ml 'push '\''~b"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$"!~F'\' When this line is first parsed, it will be the three arguments: folder-hook fa-ml push '~b"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$"!~F' And when the hook is run, it will parse two arguments: push ~b"^@[a-zA-Z0-9_]+ pushed [0-9]+ commits?.$"!~F I haven't actually tested anything here (so there may be some typos), but hopefully that will get you going in the right direction to debug things. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: trouble with my_hdr and $format_flowed
On Fri, Sep 02, 2022 at 08:28:01AM +1000, Cameron Simpson wrote: and the file ~/var/mutt/mutt-fleet2-501-83365-16591433053586932493 passwd to "mutt -H" is already gone. Does mutt remove it? Ah, mutt might have move it to ~/var/mutt/compose/muttedit.94328, which exists with the header above. Let's look at the Content-Type on this message... I'm not sure if it helps at this point, but I can report that I've taken your template above and passed it to 'mutt -H' and the resulting sent file has format=flowed in its content-type header. :-/ Can you try directly doing this too, outside of your tmux-editing framework? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: trouble with my_hdr and $format_flowed
On Wed, Aug 31, 2022 at 06:45:08PM -0700, Kevin J. McCarthy wrote: In my testing, a header 'Content-Type: text/plain; format=flowed' in the draft file does result in the sent email being format=flowed. My example wasn't great: you *should* add a charset parameter set to your system charset (I'm assuming that's utf-8). For replies, Mutt generated the quoted contents of the reply in your $charset, and it uses the charset parameter when reading in the draft file. If it's unset, Mutt will use $assumed_charset or ascii - which would likely result in '?' characters for non-ascii characters in the reply. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: trouble with my_hdr and $format_flowed
On Thu, Sep 01, 2022 at 08:50:33AM +1000, Cameron Simpson wrote: On 31Aug2022 15:37, Kevin J. McCarthy wrote: I think this may work best for you, if the my_hdr approach doesn't work. It seems to have no effect; the Content-Type eg from my reply just now to you is still not format=flowed. I did discover that an illegal Content-Type causes the "mutt -H" to abort. In my testing, a header 'Content-Type: text/plain; format=flowed' in the draft file does result in the sent email being format=flowed. Perhaps something else is going on with the config or details of how you are doing this? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: trouble with my_hdr and $format_flowed
On Thu, Sep 01, 2022 at 08:11:50AM +1000, Cameron Simpson wrote: The essential problem is that I run a separate mutt instance using "mutt -H" on a copy of my message template. The manual does say that $text_flowed has no effect then, but I seem to have no other way to apply the needed header - adding it by hand during composition is ineffective. I _might_ do better adding it to the copy before starting the separate mutt; I'll see if that works. I think this may work best for you, if the my_hdr approach doesn't work. Content-Type and other MIME headers aren't included in the "edit headers" generated headers, and they aren't parsed afterwards either. If you haven't played with it before, you might also look into background editing and the contrib/bgedit-screen-tmux.sh script. See <http://www.mutt.org/doc/manual/#bgedit>. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: trouble with my_hdr and $format_flowed
On Thu, Sep 01, 2022 at 08:08:21AM +1000, Cameron Simpson wrote: I forgot the my_hdr issue. This line: my_hdr "Content-Type: teAxt/plain; charset=usascii; format-flowed" results in this from from mutt at startup: Error in /Users/cameron/rc/mutt/settings, line 129: charset=usascii: unknown command So it appears that I can't use a semicolon in my_hdr? The parser for my_hdr is a bit different - it allows quote characters in the header, so it doesn't treat them specially like elsewhere. However, semicolons are still parsed normally. I think this was a mistake, but would be a breaking change to fix now. Anyway, a workaround would be to put a '\' in front of the semicolons: my_hdr X-Foo: bar\; baz -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Having problems with POP3 setup
On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote: Fetching email with 'G' key just ignores the "pop_last=yes" setting because it always downloads all email regardless of locally read or not, even though other clients such as Outlook or Thunderbird don't do this mistake. So I don't think server doesn't support the LAST command... Run with debugging enabled (-d 2) and check the log file to see what the LAST command response is from the server. Since the command was deprecated some time ago, I would venture the server is returning an unknown command error. Mutt's POP3 support *is* simple, so if LAST isn't supported, the behavior you are seeing with is expected. You may be happier just directly connecting to a pops:// URL via one of your mailboxes instead; or with a more sophisticated tool, such as Getmail (which Sam mentioned). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: DKIM and SPF fail for messages sent via mutt-users
On Wed, Aug 24, 2022 at 08:15:21PM +0200, Jan Eden wrote: I was under the impression that earlier issues with DMARC, DKIM and SPF with respect to mailing lists were solvable (cf. https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html), but this does not seem to be the case. Is there anything I can do myself to avoid such problems? My DMARC setup works fine for messages sent directly to recipients at Gmail, Yahoo, Comcast etc. I think OSUOSL implemented a DKIM filter some time in June, probably due to lots of bounce-unsubscribe issues with other mailing customers. However, this is probably causing your DMARC policy to fail, since the signature is missing (or renamed). The Mutt lists already munge the From header for p=reject emails. I haven't enabled it for p=quarantine, but this is a Mailman option I can control. Does anyone have feedback before I enable that? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Opening MIME PDF directly in Mutt's attachment visor
On Tue, Aug 23, 2022 at 06:34:37PM -0500, X Tec wrote: When mailcap is not configured, trying to open a PDF results in viewing it as "text" in Mutt's attachment visor. I configured mailcap to view PDF with pdftotext, but it results in "opening" it just for a "blink" moment, then back to Mutt. How could I properly configure this? Try adding the "copiousoutput" flag to the mailcap entry. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Visualising contents of a Maildir
On Wed, Aug 17, 2022 at 09:22:31PM +0200, martin f krafft via Mutt-users wrote: Is there a way to "screenshot" the Mutt index beyond the scroll window? 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. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.7 released
Hello Mutt Users, I've just released version 2.2.7. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing a $edit_headers bug on MacOS, along with several other small issues. It also changes $query_command to be stricter when parsing results, and adds '%s' expando support to $pager. Thanks to everyone who reported issues and helped test, and especially to Matthias Andree for his patches fixing Mutt's support for old protocols when using OpenSSL. -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: muttrc for gmx.com emails
On Sat, Aug 06, 2022 at 12:00:19PM -0400, D.J.J. Ring, Jr. wrote: On Sat, Aug 6, 2022 at 8:05 AM José María Mateos wrote: I don't use `record`, but I think you need either a + or a = sign in front of the mailbox name. set record="+Sent" If I put the + as you suggest, mutt wants to save a copy to /home/username/Mail/Sent but I want it to send a copy to the IMAP folder which I can see is named "Sent" by pressing c in mutt. '=' or '+' will substitute the value of $folder at the beginning of $record. However, $folder must be set before $record, in order for it to work properly. Otherwise the default value of $folder, which is "~/Mail", will be used instead. It sounds like that might be the problem in this case. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: mutt, MH, and next message number
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. I'm pretty sure I can fix it by changing the "dep++;" line to "next;" I'm just wondering if there is any reason to (or not to) propogate this change into the source. In other words ... was this done on purpose ... and if so, why? Hi hymie, I'll have to take a closer look when I have time. The mh code pre-dates my involvement in Mutt and I haven't touched it all that much. Perhaps Mutt was concerned about a client that might "undelete" by just removing the leading ',', but I don't know without more research. If there are no other responses here, feel free to post to mutt-dev too, and I'll try to make some time to take a look at this. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Subject that ends with UTF-8, 85 or A0 e.g.:
On Wed, Aug 03, 2022 at 02:37:00PM +0900, Kenichi Asai wrote: Yes, and it solved the problem!!! Thank you very much! I haven't compiled mutt by myself for long, so I rewrote the homebrew formula to use the patch and let homebrew recompile (mutt 2.2.3). Thank you Kenichi and Dennis for confirming the patch fixed the problem. That is great news! I need to look carefully at other uses of isspace() inside Mutt too. My final fix may be slightly different from the patch, but I will get this fixed for 2.2.7. That release is overdue, so I will try to get that out soon. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Subject that ends with UTF-8, 85 or A0 e.g.:
On Wed, Aug 03, 2022 at 12:21:09PM +0900, Kenichi Asai wrote: asai@bigsur % cat test.c #include #include int main () { printf("%d\n", isspace(0xa0)); printf("%d\n", isspace(0x85)); printf("%d\n", isspace(0x0a)); return 0; } [...] asai@bigsur % ./test 0 0 1 asai@bigsur % Darn, that was my best guess. After I sent the email, I even found some old bug reports that 0xa0 was considered "space" on MacOS (e.g. https://bugs.python.org/issue7072) Still, perhaps there is something different about the way Mutt was built versus the quick compile. Have you ever built Mutt yourself? Would you be able to try, and try applying the attached patch to a recent release tarball? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA From c2457b789989353db176ca3f899e838d9c67c0c2 Mon Sep 17 00:00:00 2001 From: Kevin McCarthy Date: Tue, 2 Aug 2022 20:51:17 -0700 Subject: [PATCH] wip: testing rfcline reader fix. --- parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/parse.c b/parse.c index 7ed1668f..95dea4bf 100644 --- a/parse.c +++ b/parse.c @@ -72,7 +72,7 @@ char *mutt_read_rfc822_line (FILE *f, char *line, size_t *linelen) if (*buf == '\n') { /* we did get a full line. remove trailing space */ - while (ISSPACE (*buf)) + while (is_email_wsp (*buf)) *buf-- = 0; /* we cannot come beyond line's beginning because * it begins with a non-space */ -- 2.35.1 signature.asc Description: PGP signature
Re: Subject that ends with UTF-8, 85 or A0 e.g.:
On Wed, Aug 03, 2022 at 09:53:42AM +0900, Kenichi Asai wrote: * In the step: "- enter some e-mail address and a subject." if instead, you put a 加 at the end of the subject here, before running vim, does 加 show up in vim? Yes. If you then don't modify the subject while still in vim, does it show up in Mutt? No. It becomes the replacement character. Thank you for taking the time to answer all my questions. The subject line you sent appears to be truncated by one byte. This also occurred for the 加 emails earlier. Would you mind creating a script to use for $editor. Something like: - - - - myeditor.sh - - - - #!/bin/bash cp $1 ~/before.txt vim $1 cp $1 ~/after.txt - - - - end myeditor.sh - - - set editor = "~/myeditor.sh" Then, if you put 加 at the end of the subject while in Mutt. I'd like to see what before.txt and after.txt look like after vim runs. Please attach them so I can look at the raw bytes. Also, if you have access to a compiler, would you mind compiling and running this quick program: - - - - test.c - - - - #include #include int main () { printf("%d\n", isspace(0xa0)); printf("%d\n", isspace(0x85)); printf("%d\n", isspace(0x0a)); return 0; } - - - - end test.c - - - - % gcc -o test test.c % ./test Thank you again. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Subject that ends with UTF-8, 85 or A0
On Tue, Aug 02, 2022 at 03:52:51PM +0900, Kenichi Asai wrote: When the subject ends with a character whose last byte in UTF-8 is either 85 or A0, it appears the character collapses. To reproduce: - prepare .mutt/muttrc containing only the following line: set edit_headers=yes - launch mutt and type m to create a new mail. - enter some e-mail address and a subject. - vim launches. - edit Subject line so that it ends with a character such as: υ or % or e (whose last byte of their UTF-8 code is 85) or ム or 加 (whose last byte of their UTF-8 code is A0). - type :wq to quit vim. - the last character is converted to something else. Hi Kenichi, I'm having trouble duplicating this problem on Debian Testing. So I'll need help debugging, from you or anyone else who can duplicate the problem. * After you finish the above steps, what happens if you edit the email again in vim? Does the 加 show up at the end of the subject in vim the second time? * With your original steps, what does the email look like if you send directly after returning from vim? Would you mind sending me an email so I can take a look? * Does the problem occur if you use a different editor? * In the step: "- enter some e-mail address and a subject." if instead, you put a 加 at the end of the subject here, before running vim, does 加 show up in vim? If you then don't modify the subject while still in vim, does it show up in Mutt? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Key is not bound. Press '?' for help. - keycode
On Thu, Jul 28, 2022 at 10:36:48PM +0100, Chris Narkiewicz via Mutt-users wrote: I need to see what mutt actually see, not what X11 sends. Try ':exec what-key' and see if that helps. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Invisible message in iCloud IMAP folder
On Sun, Jul 17, 2022 at 08:13:45AM +0900, Satoshi Yoshida wrote: On Sat, Jul 16, 2022 at 03:52:22PM -0700, Kevin J. McCarthy wrote: In the folder browser: 1IMAP +Archive/ 2IMAP +Deleted Message/ ^ this indicates Mutt thinks the folder can have sub-folders. For IMAP the trailing "/" also indicates this. In that case, typing "" will "change directory" into the folder. You can type "" to force opening the mailbox instead. I can see messages by typing . Thank you very much. Great, I'm glad that helped! I realized my explanation wasn't quite complete, so please allow me to add more details. The "+" means the folder is both a mailbox and has sub-folders. The "/" suffix means the folder has sub-folders. So for example: 1 IMAP + Foo/ 2 IMAP Bar/ 3 IMAP Baz Foo can be selected with or entered with . Bar can not be selected. It can only be entered with . Baz is a normal mailbox. Both and select the mailbox. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Invisible message in iCloud IMAP folder
On Sun, Jul 17, 2022 at 06:19:03AM +0900, Satoshi Yoshida wrote: I can't see any message in iCloud IMAP folders Deleted Messages, Drafts, Junk and Sent Messages. I did't test other folders Archive and Notes. https://i.imgur.com/PAbUujZ.png https://i.imgur.com/DXB9qNS.png In the folder browser: 1IMAP +Archive/ 2IMAP +Deleted Message/ ^ this indicates Mutt thinks the folder can have sub-folders. For IMAP the trailing "/" also indicates this. In that case, typing "" will "change directory" into the folder. You can type "" to force opening the mailbox instead. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Tue, Jun 28, 2022 at 12:01:34PM +0200, Andy Spiegl wrote: I think the problem why it doesn't work here is that "reply" is interactive. Whatever follows in the macro is appended to the "To: " prompt. Is there a way to "wait" until the operation is done? There isn't a clean built-in way to do what you want, so you'll have to get creative. One possibility is using the 'test=' mailcap flag and suppressing the chafa/viu invocation for replies. Here's *one* way to go about that, but you'll have to decide what works for you. This creates a file under ~/.mutt/isreply when replying: .mailcap: = image/*; chafa -c 240 -w 9 -s ${COLUMNS-80} -- %s ; copiousoutput ; test=~/.mutt/bin/isnotreply.pl .muttrc: reply-hook ~A 'echo `touch ~/.mutt/isreply`' ~/.mutt/bin/isnotreply.pl: == #!/usr/bin/perl chdir(); $REPLYFILE = "./.mutt/isreply"; if (-e $REPLYFILE) { $mod_time = (stat($REPLYFILE))[9]; if (time() - $mod_time < 5) { exit 1; } else { unlink($REPLYFILE); exit 0; } } else { exit 0; } -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images (SOLVED)
On Tue, Jun 21, 2022 at 01:06:56PM +0200, Andy Spiegl wrote: Kevin J. McCarthy wrote: Try setting TERM=xterm-256color, or add "xterm.termName: xterm-256color" to your .Xresources file Wow, you're great! That helped although I do not understand why. Running viu (or any other image to ansi converter) in the same xterm works nicely. But for running it from within mutt the TERM variable has to be set to "xterm-256color" to make it work. Any idea why mutt behaves differently here? viu is outputting the ansi sequences without checking if the terminal can support them. Mutt is translating the ansi into ncurses function calls, which check what terminfo says the terminal can support. Followup question: can I make mutt run a different mailcap command when replying (and quoting the mail)? Because the editor (emacs, vim) doesn't understand the ANSI characters and then shows a long unreadable section. :-) Note that Mutt already tries to strip ansi escape sequences from auto_view content when replying or forwarding messages. It won't strip out the graphic characters printed by the program though. For that you'd have to jury-rig something yourself, possibly by modifying $mailcap_path, or using the 'test=' flag in mailcap, or altering auto_view settings. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Tue, Jun 21, 2022 at 08:47:31AM +1000, Cameron Simpson wrote: On 20Jun2022 11:15, Kevin J. McCarthy wrote: With $allow_ansi, Mutt will interpret ansi sequences _it understands_ and convert them to curses calls. I don't currently have viu available to play with, but perhaps it's emitting sequences Mutt doesn't understand. How hard is it to extend this? Not asking you to do it, asking how painful it is. I'd like to add pass through for SIXEL support The existing code isn't that complicated, because it's just converting the sequences into ncurses attribute calls. Handling bitmaps is a different story. First, because you'd need to find out what (if any) support there is with ncurses. But on top of that the Mutt pager rendering would need to be expanded to take them into account, along with all the fun options involving line wrapping, markers, etc. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Mon, Jun 20, 2022 at 01:20:16PM -0400, Rob Pyott wrote: Hi, is there a way to get viu running without a .mailcap file? (I have a basic rc file.). Thanks! Rob No, mailcap (and mime.types) is the way to configure attachment handling in Mutt. There's a whole chapter in the manual about this, worth at least perusing: <http://www.mutt.org/doc/manual/#mimesupport>. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Mon, Jun 20, 2022 at 11:15:50AM -0700, Kevin J. McCarthy wrote: However, if this also happens with a regular mailcap invocation (using and an entry without the copiousflag setting), then something else may be going on. Re-reading the thread, I just noticed you have TERM set to xterm. Try setting TERM=xterm-256color, or add "xterm.termName: xterm-256color" to your .Xresources file, `xrdb -merge .Xresources`, and launch a new xterm. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Mon, Jun 20, 2022 at 07:40:17PM +0200, Andy Spiegl wrote: The copiousoutput flag could be making a difference here. That will cause Mutt to render the output of the command internally, which by default will strip all ansi output. Even if I set "allow_ansi"? With $allow_ansi, Mutt will interpret ansi sequences _it understands_ and convert them to curses calls. I don't currently have viu available to play with, but perhaps it's emitting sequences Mutt doesn't understand. I've tested against chafa in the past: image/*; chafa -c 240 -w 9 -s ${COLUMNS-80} -- %s ; copiousoutput so you might try that too. However, if this also happens with a regular mailcap invocation (using and an entry without the copiousflag setting), then something else may be going on. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Using "viu" to display attached images
On Mon, Jun 20, 2022 at 12:19:13AM +0200, Andy Spiegl wrote: Hi, recently I discovered the command line program "viu" (https://github.com/atanunq/viu) which very nicely displays images in terminal windows. I added this line to my .mailcap: image/*; viu -t -n %s ; copiousoutput The copiousoutput flag could be making a difference here. That will cause Mutt to render the output of the command internally, which by default will strip all ansi output. It sounds like you tried Oleg's suggestion, without the copiousoutput flag, but I mention that just in case. If you really want to view it inside Mutt's pager, you could set $allow_ansi. However, first be sure to read the documentation on that option to make sure you understand the security issues. Second, I recommend updating to at least Mutt 2.1, because that version added support for 256-color ansi escape sequences. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Coloring signature information
On Mon, Jun 06, 2022 at 08:05:51PM +0100, Chris Narkiewicz via Mutt-users wrote: On Sun, Jun 05, 2022 at 06:56:51PM -0700, Kevin J. McCarthy wrote: Those are included in the 'attachment' color object. I tried color attachment bg fg but it colors '[-- Begin signature information --]' string. What I'm trying to achieve, is to use green color for good signatures, gray for unknown and red for bad signatures. Ah, sorry I didn't read your question closely enough. No, there isn't a built-in way to do that. You might be able to code something yourself with $display_filter and $allow_ansi, but you'd need to be extra careful about spoofing. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Two questions regarding header display
On Tue, Jun 07, 2022 at 12:37:59AM +1000, raf wrote: On Sun, Jun 05, 2022 at 07:02:24PM -0700, "Kevin J. McCarthy" wrote: TERM=xterm-mono might work for you Thanks, but that didn't change it. Interesting. It works for me, at least on Debian in an xterm. You may want to check your terminfo entries, e.g. what do "infocmp xterm | grep color" and "infocmp xterm-mono | grep color" return? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Two questions regarding header display
On Mon, Jun 06, 2022 at 10:57:47AM +1000, raf wrote: And there's also the "mono" directive for terminals that don't support colour, e.g.: mono header bold ^(Subject|From|To|Cc|Date): But it doesn't work for me anymore (with TERM=xterm). TERM=xterm-mono might work for you And it would bold entire headers, not just their names. "color header bold default default ^(Subject|From|To|Cc|Date):" will work the same, with $header_color_partial unset (the default). -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Coloring signature information
On Sun, Jun 05, 2022 at 10:32:34PM +0100, Chris Narkiewicz via Mutt-users wrote: When receiving email with GPG signature, mutt puts a status at the top of the message pager: [-- Begin signature information --] Good signature from: Kevin J. McCarthy created: Sun Jun 5 20:45:27 2022 [-- End signature information --] Is there a way to set the color of this block of text? Those are included in the 'attachment' color object. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.6 released
Hello Mutt Users, I've just released version 2.2.6. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing a variety of small issues. Thanks to everyone who reported issues and helped test. -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: Two questions regarding header display
On Sun, Jun 05, 2022 at 10:24:47AM -0400, Jason Franklin wrote: On Sun, Jun 05, 2022 at 09:26:04AM +0200, Jakub Jindra wrote: set header_color_partial = yes color hdrdefault FG BG color header FG BG "REGEX" color header FG1 BG1 "REGEX1" tune the colors FG, BG and REGEX to your needs. I came across that option in the manual, but I couldn't make it work at the time. I will have to play around with it a bit. See http://www.mutt.org/relnotes/1.9/ for a sample usage. Also note, starting with 1.12 you can add attributes before the color name. For example, to *only* make the headers bold: set header_color_partial color header bold default default '^[^[:blank:]:]*:' -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: How to disable mailbox shortcuts in mailbox browser
On Fri, Jun 03, 2022 at 05:48:55AM +, Sam Lee via Mutt-users wrote: Is there some kind of setting similar to "set sidebar_use_mailbox_shortcuts=no", but for the mailbox browser? 'unset browser_abbreviate_mailboxes' might work for you. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: file corruption after transmission over email
On Sun, May 29, 2022 at 01:15:51PM -0300, Marcelo Laia wrote: tee >(lbdb-fetchaddr -a)|/usr/bin/msmtp -a gmail $@ Perhaps lbdb-fetchaddr is closing input before the end of the message, and tee is exiting on a SIGPIPE? Mutt 2.2 had a fix to properly reset signals (specifically SIGPIPE) on exec(). Child processes previously inherited Mutt's ignore setting, but this caused other incorrect behavior. Maybe adding '--output-error=exit-nopipe' to the tee command will help? Alternatively maybe capture stdin to a temp file and the perform the lbdb-fetchaddr msmtp separately? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: IMAP's "OK [ALERT]" not displayed?
On Tue, May 24, 2022 at 12:15:51AM -0400, Philippe Meunier wrote: My question is just: why doesn't mutt display that alert message to the user? I think I noticed this before too, and put it on my todo list, but didn't get around to adding it. It probably wasn't deemed all that important to correct operation originally, but I can't say why for sure. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 05:47:06PM -0500, X Tec wrote: Do you think this could be modified in Mutt's source? As in, kind of a Github-like ticket/issue petition to make it work with arguments with spaces... I try asking because you make it sound as if there were doubts regarding why this is currently coded like this. Most likely I'm wrong, but, do you think a small analysis could be in place? Could it be changed *without* compromising security indeed? I think technically it could be changed (albeit it would require careful analysis of potential issues). And of course you are welcome to open a ticket. However, there are a few things weighing against it likely being done: * Right now, Mutt is in maintenance mode - no new development is taking place. I'm just fixing bugs and security issues in the 2.2.x branch. That may change eventually, or it may not. * The $sendmail behavior has been this way since the first git commit recorded. I'm not saying your attempted usage was incorrect. But given this is the first complaint I've heard, I think it's fair to say almost no one tries to parameterize all the config values to the MTA. So there isn't much demand for the change. * There is some risk of introducing behavior changes, or even a security issue. So again, feel free to open a ticket (noting that tickets should *not* be used as a petition), but don't get your expectations very high. Sorry about that. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 01:12:31PM -0500, Derek Martin wrote: On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: 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... $sendmail goes through muttrc evaluation like other variables, but when invoked to send an email, the resulting string is tokenized by space, '--' and various arguments inserted as needed, and then passed to execvp(). Yes, this should be documented and I'll add it to the config option shortly. I don't know why it was written this way, perhaps some security concerns, but I agree that it's surprising. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 12:36:39PM -0500, X Tec wrote: But this specific part I'm having trouble with seems to be *not* from Bash or system's shell, but from Mutt *itself*; as in, Mutt's own "local shell" or configuration syntax (not sure how to call it...). Nevertheless, I tried your advise, and got this: msmtp: unrecognized option '--no-tty' Error sending message, child exited 64 (Bad usage.). Could not send the message. 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. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Turning off 'Sender' header for mailing list
Hi Everyone, Recently Gmail has started bouncing emails with any DKIM failures. One source of these failures is the: 'Sender: Mutt-users ' header added by the mailing list. I realize some of you may be filtering based on that header, but I'm seeing a large number of bounce-unsubscribes due to this, and don't really have a choice. Please filter based off the 'List-Id:' if possible. Sorry for the inconvenience. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
mutt 2.2.5 released
Hello Mutt Users, I've just released version 2.2.5. Instructions for downloading are available at <http://www.mutt.org/download.html>, or the tarball can be directly downloaded from <http://ftp.mutt.org/pub/mutt/>. Please take the time to verify the signature file against my public key[1]. This is a bug-fix release, fixing two authentication problems when Mutt is configured with libgsasl (a new configuration option in 2.2.x). Thanks to everyone who reported these issue and helped test the fix. -Kevin [1] My public key is available at: - my personal website: https://www.8t8.us/configs/80316BDA.asc.pubkey - the mutt website: http://www.mutt.org/keys/kevin.key - The keys.openpgp.org network https://keys.openpgp.org/vks/v1/by-fingerprint/8975A9B33AA37910385C5308ADEF768480316BDA signature.asc Description: PGP signature
Re: Reading from IMAP folders with '.' in name
On Sun, May 15, 2022 at 03:18:44PM -0400, Jason Franklin wrote: Renaming the folders to something without '.' or '@' characters allows me to access them just fine. Thus, I think the folder name has something to do with it. How might I allow for folder names that match a normal email address including the '.' and '@' characters? Try putting: set imap_delim_chars = '/' set sidebar_delim_chars = '/' in your muttrc and see if it helps. By default, Mutt treats both '/' and '.' as folder separator characters, and that may be causing the issue. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature