Re: Question about message id

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hi Mutt Users,

I've just released version 2.2.13.  Instructions for downloading are available
at , or the tarball can be directly
downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.12.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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:
  * 

  * 

  * 


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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.11.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hi Mutt Users,

I've just released version 2.2.10.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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)

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.9.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I'm pleased to announce the release of version 2.2.8.  Instructions for 
downloading are available at , or the 
tarball can be directly downloaded from . 
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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.7.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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.:

[Kevin J. McCarthy]

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.:

[Kevin J. McCarthy]

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.:

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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 ｅ (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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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)

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.6.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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?

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

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

[Kevin J. McCarthy]

Hello Mutt Users,

I've just released version 2.2.5.  Instructions for downloading are 
available at , or the tarball can be 
directly downloaded from .  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

[Kevin J. McCarthy]

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