__group__ ticket summary milestone version type owner status created _changetime _description _reporter
IMAP 2827 deleting attachment on imap and sync removes message from index 1.5.20 defect mutt-dev new 2007-03-06T10:35:02-08:00 2009-06-23T05:06:10-07:00 "{{{
The following was submitted as Debian bug #152012:
----- Forwarded message from Louis-David Mitterrand ---=
--
Date: Fri, 5 Jul 2002 14:58:35 +0200
From: Louis-David Mitterrand
Reply-To: 152012@bugs.debian.org
To: Debian Bug Tracking System
Subject: mutt: deleting attachement on imap box and sync'ing removes mess=
age from index
Package: mutt
Version: 1.4.0-1
Severity: normal
Log into a courier-imap server with mutt, delete an attachement, press $
and watch the message disappear from the index. Quit and log in again to
get the message back.
----- End forwarded message -----
----- Forwarded message from Adeodato Sim=F3 -----
Date: Tue, 25 May 2004 23:28:00 +0200
From: Adeodato Sim=F3
To: 152012@bugs.debian.org, mutt-dev@mutt.org
Subject: Re: mutt: deleting attachement on imap box and sync'ing removes =
message from index
Mail-Followup-To: 152012@bugs.debian.org, mutt-dev@mutt.org
[This is debian's bug#152012.]
* Louis-David Mitterrand [Fri, 05 Jul 2002 14:58:35 +0200]:
> Log into a courier-imap server with mutt, delete an attachement, press =
$
> and watch the message disappear from the index. Quit and log in again t=
o
> get the message back.
other servers will print a warning: ""CLIENT BUG DETECTED: STATUS on
selected mailbox: INBOX"".
there was once a similar case in comp.mail.mutt [1] that happened when
deleting messages. it was fixed in 1.3.20 and of course it doesn't
happen anymore when deleting messages, but it does when deleting
attachments.
any comments wrt this?
[1] http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&threadm=3D=
3B6776D9.60201%40cs.rose-hulman.edu&rnum=3D1&prev=3D/groups%3Fq%3D%2522ST=
ATUS%2Bon%2Bselected%2Bmailbox%2522%2Bgroup:comp.mail.mutt%26hl%3Den%26lr=
%3D%26ie%3DUTF-8%26group%3Dcomp.mail.mutt%26selm%3D3B6776D9.60201%2540cs.=
rose-hulman.edu%26rnum%3D1%26filter%3D0
----- End forwarded message -----
----- Forwarded message from Louis-David Mitterrand ---=
--
Date: Tue, 6 Mar 2007 18:48:22 +0100
From: Louis-David Mitterrand
Reply-To: Louis-David Mitterrand , 152012@bugs.debian.or=
g
To: Christoph Berg , 152012@bugs.debian.org
Subject: Bug#152012: mutt: deleting attachement on imap box and sync'ing
removes message from index
On Tue, Mar 06, 2007 at 06:47:01PM +0100, Christoph Berg wrote:
> tags 152012 + moreinfo
> thanks
>=20
> Re: Louis-David Mitterrand 2002-07-05 <20020705125835.GA1424@apartia.or=
g>
> > Log into a courier-imap server with mutt, delete an attachement, pres=
s $
> > and watch the message disappear from the index. Quit and log in again=
to
> > get the message back.
>=20
> it's been a long time since you reported this. I just tried with my
> local dovecot-imapd and everything was fine. Can you still reproduce
> this bug?
Hello,
Yes the bug is still there with latest unstable mutt and courier.
----- End forwarded message -----
Christoph
--=20
cb@df7cb.de | http://www.df7cb.de/
>Fix:
Unknown
}}}" Christoph Berg
IMAP 2938 mutt freezes some times when accessing imap folders or messages 2.0 defect new 2007-08-03T21:57:38-07:00 2010-12-30T16:12:28-08:00 "Mutt sometimes hangs when fetching a message, or opening a folder
while fetching headers from an imap server. The imap server is Cyrus
IMAP4 2.2.12-Invoca-RPM-2.2.12-8.1.RHEL4. This happens also with mutt
1.5.12 on one machine, as well as with mutt 1.5.13. This happens occasionally,
not that often, but enough to be frustrating since mutt has to be restarted and
changes to the mail folder are lost. Several times a day. Mutt won't
respond except for ctl-Z to stop it, then the mutt process must be
killed. In one case I collected a debug log from mutt -d, which showed
that mutt has frozen part way through downloading an attachment. No
error messages are given, the log simply stops part way through
outputing the attachment to the log file.
Well I'm not sure this is mutt or cyrus imapd but not sure how to tell
the difference and the imap server is not accessible to me.
" b.macdonald
IMAP 3038 mutt cannot communicate with archiveopteryx 2.0 1.5.17 defect brendan infoneeded 2008-03-13T14:07:00-07:00 2009-06-06T23:00:15-07:00 "Hi,
I've send this to the user list and was told that this might actually be a bug. The problem I see is that mutt hangs when trying to open any imap box I have on an archiveopteryx server. Mutt works fine against a locally running dovecot, but also other imap clients work fine with the archiveopteryx server.
I've tried to produce useful debug information using mutt -d2, the generated file is attached (without a few lines about mailbox names that I cannot post here)." apaku
IMAP 3074 Mutt hangs indefinitely 2.0 1.5.18 defect brendan accepted 2008-06-09T17:01:17-07:00 2009-06-06T23:04:03-07:00 "On many occasions, I find that an unattended mutt (1.5.17+20080114-1+b1 from Debian) will hang indefinitely. Never having time to debug it, I usually kill it and restart it, but today I let it run in strace until it happend. Here's what the end of the strace looks like - it seems to get an ERESTARTSYS while reading from the imaps socket! ERESTARTSYS is reserved as a signal between drivers and the kernel signal handling code and is, theoretically, never supposed to make it to userspace. Thus, this is quite odd.
I'm happy to add ltraces or whatever else may be useful....
{{{
write(1, ""\r\33[17B\33[37m\33[40mFetching message""..., 76) = 76
write(1, ""\33[79;29H\33[37m\33[40m1834/1838 (99%""..., 54) = 54
gettimeofday({1212696193, 854853}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 812050}, ru_stime={0, 236014}, ...}) = 0
time(NULL) = 1212696193
times({tms_utime=81, tms_stime=23, tms_cutime=1, tms_cstime=2}) = 1734919932
gettimeofday({1212696193, 855156}, NULL) = 0
getrusage(RUSAGE_SELF, {ru_utime={0, 812050}, ru_stime={0, 236014}, ...}) = 0
time(NULL) = 1212696193
times({tms_utime=81, tms_stime=23, tms_cutime=1, tms_cstime=2}) = 1734919932
send(4, ""\27\3\1\0\373*\341\374\221\t.p\233T*Y\354\0\223\303>
}}}
- Phil" jaymzh
IMAP 3357 imap server socket communication trouble defect brendan new 2009-11-23T07:43:52-08:00 2009-12-17T10:47:28-08:00 "In some sense, this is a continuation of ticket 3000. Open an INBOX containing 230,000 messages, tag 9,000 messages, and tag copy them to a new mailbox on a cyrus imap server (translates to an empty directory).
What ends up happening is that that directory gets filled with multiple copies of the messages, each having the same inode number but different filenames.
So where are these multiple copies coming from?
Mutt sends multiple UID COPY commands so as not to overflow the command buffer (ie is kind to cyrus)
The last line in the block is:
{{{
a0232 UID COPY 326160:326161,326188,326202,326225,326237:326243,326251,326266,326277,326336,326362,326380:326381,326393,326400,326411,326422,326447,326522,326545,326677:326680,326686,326701:326704,326714,326718:326719,326758,326775,326799,326857:326865,326868,326906,326961:326963,326974,326996,327020,327081,327119,327129,327135,327147,327160,327184:327187,327225:327227,327233:327241,327251,327263,327341:327342,327388,327406,327446,327560,327585,327598:327601,327789:327792,327800,327820:327821,327960,328011,328053:328054,328091:328092,328102,328114:328123,328131,328147,328150,328221,328229,328232,328256,328302:328305,328307:328312,328321:328322,328341,328387,328393,328416,328443,328488,328522,328581:328600,328607:328615,328719,328770,328868,328870,328873:328875,328908:328914,328925:328927,328950:328951,328972:328975,329049:329055,329079:329084,329132:329150,329152,329158,329178,329212:329217,329232,329234,329238:329241,329248:329251,329260,329270,329297,329307:329308,329310:329323,329325:329328,329337:329338,329343:329347 ""http""^M
[2009-11-12 18:56:28] mutt_socket_write: short write (4091 of 16720 bytes)
[2009-11-12 18:56:28] mutt_socket_write: short write (4091 of 12629 bytes)
[2009-11-12 18:56:28] mutt_socket_write: short write (4091 of 8538 bytes)
[2009-11-12 18:56:28] mutt_socket_write: short write (4091 of 4447 bytes)
}}}
What is mystifying is the later OK which mutt records as coming from cyrus:
{{{
[2009-11-12 18:56:39] 4< a0232 OK [COPYUID 1258034308 171084,171095,171120,171125,171199,171211,171291,171320,171328,171394,171396,326160:326161,326188,326202,326225,326237,326243,326251,326266,326277,326336,326362,326380:326381,326393,326400,326411,326422,326447,326522,326545,326677,326680,326686,326701,326704,326714,326718:326719,326758,326775,326799,326857,326863,326865,326868,326906,326961,326963,326974,326996,327020,327081,327119,327129,327135,327147,327160,327184,327187,327225,327227,327233,327236,327239,327241,327251,327263,327341:327342,327388,327406,327446,327560,327585,327598,327601,327789,327791:327792,327800,327820:327821,327960,328011,328053:328054,328091:328092,328102,328114,328123,328131,328147,328150,328221,328229,328232 2363:2461] Completed
}}}
Where did ID 171084 suddenly spring from?
It's hard to work out which end is having the problem, but I also wonder what imap/command.c:cmd_start() is meant to do with the length return value of mutt_socket_write_d()
This was either
Mutt 1.5.20 (2009-08-27)
or
Mutt 1.5.20 (2009-10-28)
" prlw1
IMAP 3482 IMAP Segmentation fault when fetching message headers 1.5.21 defect brendan infoneeded_new 2010-12-30T00:24:08-08:00 2011-06-25T21:42:12-07:00 "Hi,
I have 2 accounts with the same IMAP server configured in one .muttrc. the 2 accounts have the same common configurations. but one is ok, the other has a segmentation fault. it is very strange.
what the differences I could tell between the 2 accounts is that, one's username has a '_', one not.
I have tried to delete the last message read on the IMAP server before segmentation happened and I also tried to clean and disable header cache, but all take no effect.
I really want to make it works, and I debug a lot but failed, so I put a bug here to try to find a solution.
Log information attached below.
2 .muttdebug file attached, one for working account, one for non-working account
PS. the mutt version is 1.5.21, but it is not in the list, so I chose 1.5.20.
Thanks a lot!
Best Regards
Du Yang
mutt -v
----------------------------------------
{{{
Mutt 1.5.21 (2010-09-15, Gentoo 1.5.21-r1)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 2.6.34-gentoo-r1 (i686)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
hcache backend: GDBM version 1.8.3. 10/15/2002 (built Feb 20 2009 23:12:51)
Compile options:
-DOMAIN
+DEBUG
+HOMESPOOL -USE_SETGID +USE_DOTLOCK +DL_STANDALONE -USE_FCNTL +USE_FLOCK
-USE_POP -USE_NNTP +USE_IMAP -USE_SMTP
-USE_SSL_OPENSSL +USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO
-HAVE_REGCOMP +USE_GNU_REGEX +COMPRESSED
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP -CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE
-ISPELL
SENDMAIL=""/usr/sbin/sendmail""
MAILPATH=""Maildir""
PKGDATADIR=""/usr/share/mutt""
SYSCONFDIR=""/etc/mutt""
EXECSHELL=""/bin/sh""
MIXMASTER=""mixmaster""
To contact the developers, please mail to .
To report a bug, please visit http://bugs.mutt.org/.
dgc.subjrx
fg.smarttime
vvv.initials
vvv.quote
vvv.nntp
patch-1.5.20hg.pdmef.progress.vl.2
rr.compressed
patch-1.5.4.lpr.collapse_flagged Lukas P. Ruf
}}}
core
{{{
----------------------------------------------------GNU gdb (Gentoo 7.2 p1) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type ""show copying""
and ""show warranty"" for details.
This GDB was configured as ""i686-pc-linux-gnu"".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/mutt...(no debugging symbols found)...done.
[New Thread 5015]
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libncursesw.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libncursesw.so.5
Reading symbols from /usr/lib/libgnutls.so.26...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgnutls.so.26
Reading symbols from /usr/lib/libgdbm.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgdbm.so.3
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/lib/libtasn1.so.3...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libtasn1.so.3
Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libgcrypt.so.11...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgcrypt.so.11
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libgpg-error.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgpg-error.so.0
Reading symbols from /lib/libnss_compat.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /lib/libnss_dns.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_dns.so.2
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /usr/lib/gconv/GB18030.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gconv/GB18030.so
Reading symbols from /usr/lib/gconv/EUC-CN.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gconv/EUC-CN.so
Reading symbols from /usr/lib/gconv/libGB.so...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/gconv/libGB.so
Core was generated by `mutt -d2 -F /home/duyang/.muttrc.imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x0808dd59 in ?? ()
(gdb) q
----------------------------------------------------
}}}" duyang
IMAP 3502 Issue with browsing IMAP folders, having a non-ASCII characters in names 1.5.21 defect brendan new 2011-02-16T03:50:00-08:00 2011-02-16T03:50:00-08:00 "I've found that there is an issue with browsing and navigating IMAP folders if folder's name contains non-ASCII characters (i.e. folder name is IMAPUTF-7 encoded).
The reason is in comparison of strings in a different encodings.
The attached patch fixes this issue.
" alexz
IMAP 3530 Crash on search in IMAP(S) mailbox 1.5.21 defect brendan infoneeded_new 2011-06-29T06:40:58-07:00 2011-07-16T10:47:37-07:00 "mutt crashes on searching within an IMAP(S) mailbox. I connect and log in to a mailbox using an imaps:// type folder. I search (using '/') for this:
{{{
~h ""freshm|bugz""
}}}
Resulting in this:
{{{
Fetching message... 0K/1.0K (0%)*** glibc detected *** /usr/local/new/tools/networking/mail/mutt/mutt-hg/mutt-build/mutt: free(): invalid next size (fast): 0x081db720 ***
[... glibc crash info ...]
Program received signal SIGABRT, Aborted.
0x00bb7416 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.22-19.fc10.i386 cyrus-sasl-md5-2.1.22-19.fc10.i386 cyrus-sasl-ntlm-2.1.22-19.fc10.i386 cyrus-sasl-plain-2.1.22-19.fc10.i386 db4-4.7.25-7.fc10.i386 glibc-2.9-3.i686 gnutls-2.4.2-5.fc10.i386 libgcc-4.3.2-7.i386 libgcrypt-1.4.4-1.fc10.i386 libgpg-error-1.6-2.i386 libidn-0.6.14-8.i386 libtasn1-1.5-1.fc10.i386 ncurses-libs-5.6-20.20080927.fc10.i386 openssl-0.9.8g-14.fc10.i686 zlib-1.2.3-22.fc10.1sunshine.pentium4
(gdb) bt
#0 0x00bb7416 in __kernel_vsyscall ()
#1 0x006d0460 in raise () from /lib/libc.so.6
#2 0x006d1e28 in abort () from /lib/libc.so.6
#3 0x0070dfed in __libc_message () from /lib/libc.so.6
#4 0x007143a4 in malloc_printerr () from /lib/libc.so.6
#5 0x00716356 in free () from /lib/libc.so.6
#6 0x080b6238 in safe_free (ptr=0xbfffcdb8) at lib.c:198
#7 0x080ab670 in write_one_header (fp=0x81da5d8, pfxw=0, max=, wraplen=78, pfx=0x0,
start=0x81db1b1 ""Received: from AFAXSMK (unknown [68.178.18.24]) by xxx-xxx.xxx (Postfix) with ESMTP id 65C759B481C for ; Wed, 29 Jun 2011 06:07:39 +0200 (CEST)\nReceived: from 68.178.18.24""...,
end=0x81db25e ""Received: from 68.178.18.24 by mail.lanuk.com; Tue, 28 Jun 2011 20:07:13 -0800\nMessage-ID: <000d01cc3612$069cc3b0$6400a8c0@huggingyw5>\nFrom: ?????? ??? \nTo: moritz@xxx.xxx\nS""..., flags=20) at sendlib.c:1825
#8 0x080ab9b4 in mutt_write_one_header (fp=0x81da5d8, tag=0x0,
value=0x81d95f8 ""Return-Path: \nX-Original-To: moritz@xxx.xxx\nDelivered-To: xxxxx@xxx-xxx.xxx\nReceived: from AFAXSMK (unknown [68.178.18.24])\n\tby xxx-xxx.xxx (Postfix) with ""..., pfx=0x0, wraplen=78, flags=20)
at sendlib.c:1894
#9 0x0805ef4c in mutt_copy_hdr (in=0x81da100, out=0x81da5d8, off_start=0, off_end=898, flags=20, prefix=0x0) at copy.c:289
#10 0x0805f5bc in mutt_copy_header (in=0x81da100, h=0x81b8c58, out=0x81da5d8, flags=20, prefix=0x0) at copy.c:350
#11 0x08096376 in msg_search (ctx=0x815f310, pat=0x8194280, msgno=) at pattern.c:174
#12 0x08096e54 in mutt_pattern_exec (pat=0x8194280, flags=M_MATCH_FULL_ADDRESS, ctx=0x815f310, h=0x81b8c58) at pattern.c:1144
#13 0x08098840 in mutt_search_command (cur=0, op=154) at pattern.c:1512
#14 0x0806474c in mutt_index_menu () at curs_main.c:901
#15 0x08080430 in main (argc=Cannot access memory at address 0x5dda
) at main.c:1020
}}}
If I use this search:
{{{
~h ""freshm""
}}}
I get a slightly different crash:
{{{
Fetching message... 0K/1.0K (0%)*** glibc detected *** /usr/local/new/tools/networking/mail/mutt/mutt-hg/mutt-build/mutt: free(): invalid next size (normal): 0x081da318 ***
[... glibc crash info ...]
Program received signal SIGABRT, Aborted.
0x003cc416 in __kernel_vsyscall ()
Missing separate debuginfos, use: debuginfo-install cyrus-sasl-lib-2.1.22-19.fc10.i386 cyrus-sasl-md5-2.1.22-19.fc10.i386 cyrus-sasl-ntlm-2.1.22-19.fc10.i386 cyrus-sasl-plain-2.1.22-19.fc10.i386 db4-4.7.25-7.fc10.i386 glibc-2.9-3.i686 gnutls-2.4.2-5.fc10.i386 libgcc-4.3.2-7.i386 libgcrypt-1.4.4-1.fc10.i386 libgpg-error-1.6-2.i386 libidn-0.6.14-8.i386 libtasn1-1.5-1.fc10.i386 ncurses-libs-5.6-20.20080927.fc10.i386 openssl-0.9.8g-14.fc10.i686 zlib-1.2.3-22.fc10.1sunshine.pentium4
(gdb) bt all
No symbol ""all"" in current context.
(gdb) bt
#0 0x003cc416 in __kernel_vsyscall ()
#1 0x006d0460 in raise () from /lib/libc.so.6
#2 0x006d1e28 in abort () from /lib/libc.so.6
#3 0x0070dfed in __libc_message () from /lib/libc.so.6
#4 0x007143a4 in malloc_printerr () from /lib/libc.so.6
#5 0x00717e46 in _int_realloc () from /lib/libc.so.6
#6 0x00718c86 in realloc () from /lib/libc.so.6
#7 0x080b62a2 in safe_realloc (ptr=0x81d9150, siz=0) at lib.c:176
#8 0x0805f07b in mutt_copy_hdr (in=0x81dade0, out=0x81db048, off_start=0, off_end=898, flags=, prefix=0x0)
at copy.c:169
#9 0x0805f5bc in mutt_copy_header (in=0x81dade0, h=0x81b8c80, out=0x81db048, flags=20, prefix=0x0) at copy.c:350
#10 0x08096376 in msg_search (ctx=0x815f310, pat=0x81d7b58, msgno=) at pattern.c:174
#11 0x08096e54 in mutt_pattern_exec (pat=0x81d7b58, flags=M_MATCH_FULL_ADDRESS, ctx=0x815f310, h=0x81b8c80) at pattern.c:1144
#12 0x08098840 in mutt_search_command (cur=0, op=154) at pattern.c:1512
#13 0x0806474c in mutt_index_menu () at curs_main.c:901
#14 0x08080430 in main (argc=Cannot access memory at address 0x5e54
) at main.c:1020
}}}
mutt is latest (as of today) from hg (6187:b477d7c5733e on HEAD/tip).
It is built as such:
{{{
./configure --enable-imap --with-sasl --with-gnutls
}}}
resulting in:
{{{
barsnick@sunshine:/usr/new/tools/networking/mail/mutt/mutt-hg/mutt-build > ./mutt -v
Mutt + (b477d7c5733e) (2010-12-30)
Copyright (C) 1996-2009 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 2.6.27.41-170.2.117.fc10.i686 (i686)
ncurses: ncurses 5.6.20080927 (compiled with 5.6)
libidn: 0.6.14 (compiled with 0.6.14)
Compile options:
-DOMAIN
-DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK
-USE_POP +USE_IMAP -USE_SMTP
-USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL -USE_GSS +HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE
ISPELL=""/usr/bin/ispell""
SENDMAIL=""/usr/sbin/sendmail""
MAILPATH=""/var/mail""
PKGDATADIR=""/usr/local/share/mutt""
SYSCONFDIR=""/usr/local/etc""
EXECSHELL=""/bin/sh""
-MIXMASTER
}}}
and executed as such:
{{{
gdb --args ./mutt -F /dev/null -f /dev/null
}}}" barsnick
IMAP 3640 Hangs on index view when connected with gmail imap server 1.5.21 defect brendan new 2013-04-24T08:43:26-07:00 2014-07-21T20:00:54-07:00 "Randomly hangs when connected with gmail
When running 'strace' on the hanged mutt pid(983 in this example) I get:
$ sudo strace -p 983
Process 983 attached - interrupt to quit
recv(3,
which netstat shows to be the fd representing the IMAP connection. I also ran:
$ cat /proc/983/fdinfo/3
pos: 0
flags: 02000002
According to 'dalias'(#mutt on freenode) this bug seems to be related to a change google made in their ssl implementation about a week ago.
" tarruda
IMAP 3641 Latest commit causes mutt to quit after failed password attempt on OSX 10.8.3. defect brendan new 2013-04-24T22:25:55-07:00 2013-04-25T09:49:41-07:00 "
Mutt from tip, OSX 10.8.3.
Suddenly, after the April 16 commit, the following occurs (never once happened before):
I do 'mutt' at the prompt to login to the IMAP server holding my mail (it's Zimbra).
Next I type the incorrect password (I have $imap_pass unset).
Next mutt says ""Zimbra IMAP server terminating connection"" (or something very similar). Then that message disappears and I see ""Login failed"".
So far, so good. This is as it has always been and how it should be.
But after the Apr 16th commit, this is followed up by *mutt* quitting, and after it's quit I see output between the last bash prompt and the new one: ""Login failed"".
Formerly, mutt wouldn't quit, and the ""Login failed"" message *inside* mutt would stay there until I hit another key. I could then do, for example ""c="" to get a fresh password prompt.
This only seems to happen on the account that uses Zimbra. Gmail and my other accounts (which is either Courier or Dovecot) don't exhibit this. And I've just verified that there is no problem with commit 4c5163. It's d3096e that's done this.
" balderdash
IMAP 3667 Stuck trying to send an email: all DNS lookups fail when network was brought up after mutt 1.5.22 defect brendan new 2013-11-12T03:37:06-08:00 2017-07-03T17:10:38-07:00 "I have configured ""record=imaps://flo@imap.gmail.com"" which works fine when I run mutt **after** having brought up my laptop's network interface.
When the network interface is down and I run ""mutt someone@example.com"", hitting y to (record and) send an email returns the status **Could not find the host ""imap.gmail.com""** and I'm still in the send-message screen of course. Now even if I bring up the network interface while mutt is still running, I still get this status when hitting y again and again. Shouldn't mutt attempt to resolve the domain-name anew?
If you record your emails locally (or not at all) then you'll get the same error message but for the domain-name defined in //smtp_url//. If you try to postpone the message remotely then it's the //postponed// domain-name.
I'm using Linux btw.
Keep up the excellent work, guys!" Floris
IMAP 3755 imap: accumulates the same certificate over and over in ~/.mutt/certificates but doesn't recognize at startup 1.5.23 defect brendan new 2015-05-11T12:35:34-07:00 2015-05-11T12:36:42-07:00 "At startup I get this error
Certificate host check failed: certificate owner does not match hostname
(r)eject, accept (o)nce, (a)ccept always
If I hit ""a"" for always, it will append another copy of the cert to ~/.mutt/certificates. So now I have 24 copies of the same cert there, but mutt keeps asking anyway each time. Each cert just has
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
with no hostname to match against. (Not sure if it should have a hostname with each entry like ~/.ssh/authorized_keys does.)
I'm using the Arch Linux package extra/mutt 1.5.23-2" ecloud
IMAP 3961 Segmentation fault: 11 defect brendan new 2017-08-14T04:01:34-07:00 2017-08-24T13:16:34-07:00 "gdb mutt:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xfffffff8
0x00047568 in source_rc ()
from terminal when i type mutt it gives: Segmentation fault: 11
Package: mutt
Version: 1.8.0
Severity: wishlist
-- Please type your report below this line
-- System Information
System Version: Darwin iPhone 13.0.0 Darwin Kernel Version 13.0.0: Wed Feb 13 21:37:19 PST 2013; root:xnu-2107.7.55.2.2~1/RELEASE_ARM_S5L8940X iPhone$
-- Mutt Version Information
Mutt 1.8.0 (2017-02-23)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Darwin 13.0.0 (iPhone4,1)
ncurses: ncurses 5.7.20081102 (compiled with 5.7)
libiconv: 1.14
Compiler:
Using built-in specs.
Target: arm-apple-darwin9
Configured with: ../llvm-gcc-4.2/configure --build=x86_64-unknown-linux-gnu --host=arm-apple-darwin9 --enable-static=no --enable-shared=yes --prefix=$
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5555)
Configure options: '--with-homespool=/var/spool' '--prefix=/usr/local' 'CC=/usr/bin/gcc' 'CFLAGS=-Qunused-arguments' 'LDFLAGS=-L/usr/lib/' 'CPPFLAGS=$
Compilation CFLAGS: -Wall -pedantic -Wno-long-long -Qunused-arguments
Compile options:
-DOMAIN
-DEBUG
+HOMESPOOL -USE_SETGID +USE_DOTLOCK -DL_STANDALONE +USE_FCNTL -USE_FLOCK
-USE_POP -USE_IMAP -USE_SMTP
-USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS +HAVE_GETADDRINFO
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME
-EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS -HAVE_LIBIDN -HAVE_GETSID -USE_HCACHE -USE_SIDEBAR -USE_COMPRESSED
-ISPELL
SENDMAIL=""/usr/sbin/sendmail""
MAILPATH=""/var/spool""
PKGDATADIR=""/usr/local/share/mutt""
SYSCONFDIR=""/usr/local/etc""
EXECSHELL=""/bin/sh""
-MIXMASTER
" eshad19
IMAP 3967 Missing/wrong last character in subject after quitting vim while replying defect brendan new 2017-09-11T06:37:33-07:00 2017-09-14T01:58:06-07:00 "When I reply to a message that has as subject the line e.g. ""Μηνιαία Έξοδα Αυγούστου"" (Greek) by pressing r, after I quit vim, I see that the subject line has been truncated to ""Re: Μηνιαία Έξοδα Αυγούστο"",i.e. the subject seems to have lost it's last character (υ). At the index list I see that the subject has become ""RE: Μηνιαία Έξοδα Αυγούστο�"", with a � character at the end..." christosc
IMAP 2056 Attempt re-connect when idle mailbox connection closes 2.0 enhancement brendan new 2005-09-06T15:38:34-07:00 2016-07-30T08:49:34-07:00 "As requested by Brendan Cully in PR#2049:
In some environments - possibly dependent on particular IMAP
server software, firewalls, routers, etc. - the connection
to an IMAP mailbox can close when it remains idle for more
than a few minutes. That can happen when the user returns
to the mailbox after viewing a message for a long time.
Currently, mutt automatically closes the mailbox when
this happens. This makes mutt nearly unusable in this
type of IMAP/network environment.
The correct behavior is for mutt to attempt to
reconnect to the mailbox. Mutt should only close
the mailbox if the reconnect attempt - or several
attempts - fails.
This seems to be standard behavior for most IMAP email
clients." gale@…
IMAP 3128 Make IMAP expunged message handling faster 2.0 1.5.18 enhancement brendan new 2008-10-19T14:37:20-07:00 2017-10-18T00:31:28-07:00 cmd_parse_expunge walks the entire mailbox for every expunge message received. For large mailboxes, this is extremely slow. We want two fixes: 1. maintain a header hash by index number, and 2. avoid having to decrement the index number for following messages at every expunge message. We might maintain a side list of expunges received and use it to offset the index number of live messages. Or maybe we'll just adjust the later messages lazily, by recording our current position in the list and only adjusting offsets when we touch messages after that point. Needs some thought. brendan
IMAP 3210 Feature Request: IMAP keywords enhancement brendan new 2009-03-30T07:59:39-07:00 2010-08-04T03:10:18-07:00 "I think it'd be so useful being able to manage IMAP keywords (section 2.3.2 of the INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 [1]; also there's a draft of Common IMAP keywords [2]).
It'd be nice to create, remove, and to know the differents keywords an email have.
In addition it'll be great to list them, so someone can create ""virtual folders"" based on keywords.
[1] http://www.ietf.org/rfc/rfc3501.txt
[2] http://tools.ietf.org/id/draft-melnikov-imap-keywords-03.txt" alovse
IMAP 3679 gmail imap search feature enhancement brendan new 2014-03-06T11:25:25-08:00 2014-03-06T11:25:25-08:00 "Gmail providse an imap extension to do advanced full text search,
Phill Pennock provided a very small and non intrusive patch for this (almost 3 years ago). Why wasn't this included in the official mutt distribution?
http://permalink.gmane.org/gmane.mail.mutt.devel/19624" acornejo
IMAP 3723 "Message fetched if `color index blue red ""~h 'Importance: high'""` is in place" 1.5.23 enhancement brendan new 2014-12-30T03:10:09-08:00 2015-03-17T16:39:03-07:00 "If color index … … ""~h –"" is set up, mutt goes on fetching every message on the current page, after all headers were fetched.
What should happen is that (since ""~h …"" clearly only requires headers) mutt does not fetch the messages and only checks the pattern against the already available headers." ManDay
IMAP 969 Can't clear the 'N' (unseen) flag on read-only IMAP folders 2.0 1.3.25i defect brendan new 2002-01-12T12:47:40-08:00 2016-09-04T13:33:51-07:00 "When reading read-only IMAP folders, I used to be able (1.2.5i) to
clear the new flag by reading the message. When updating to 1.3.25i,
the 'N' flag just stays and is still there the next time around. Going
back to 1.2.5i, I notice that the 'toggle-new' function didn't work
there on read-only imap folders, even though the flag got cleared by
reading the message.
Looking at RFC 2060, the client is allowed to modify the Seen flag if
the server returns PERMANENTFLAGS on a SELECT:
Here's a read-write folder:
{{{
. select inbox
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 210 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 914040081]
* OK [UIDNEXT 9885]
. OK [READ-WRITE] Completed
}}}
and here's a read-only one:
{{{
. select fulcrum.internal.ms
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Seen)]
* 7874 EXISTS
* 0 RECENT
* OK [UNSEEN 7872]
* OK [UIDVALIDITY 914048337]
* OK [UIDNEXT 7946]
. OK [READ-ONLY] Completed
}}}
The PERMANENTFLAGS shows which flags out of those listed in FLAGS
the client is allowed to change permanently.
""If the client can not change the permanent state of one or more of
the flags listed in the FLAGS untagged response, the server SHOULD
send a PERMANENTFLAGS response code in an OK untagged response,
listing the flags that the client can change permanently.""
Hope this helps....
rik.
" Rik Harris
IMAP 1266 create/delete mailboxes not available in the mailboxes view of browser when using imap 1.4i defect mutt-dev reopened 2005-07-24T09:02:25-07:00 2007-02-07T11:35:57-08:00 "{{{
From twells@fsckit.net Mon Jul 08 20:49:54 2002
Received: from 70.muca.bstn.bstnmaco.dsl.att.net ([12.98.14.70] helo=pulse.fsckit.net)
by trithemius.gnupg.org with esmtp (Exim 3.35 #1 (Debian))
id 17Rda6-0007X1-00
for ; Mon, 08 Jul 2002 20:49:54 +0200
Received: from twells by pulse.fsckit.net with local (Exim)
id 17Rdbb-0000eg-00
for submit@bugs.guug.de; Mon, 08 Jul 2002 14:51:27 -0400
Subject: mutt-1.4i: create/delete mailboxes not available in the mailboxes view of browser when using imap
To: submit@bugs.guug.de
Message-Id:
From: ""Tabor J. Wells""
Date: Mon, 08 Jul 2002 14:51:27 -0400
Package: mutt
Version: 1.4i
Severity: normal
-- Please type your report below this line
In the Mailboxes view of the browser, where it looks like:
1 imaps://localhost/INBOX
2 19 imaps://localhost/INBOX.folder
attempting to delete (or create) a mailbox results in ""Delete is only
supported for IMAP mailboxes"" (or ""Create is only supported for IMAP
mailboxes"" as appropriate).
In the Directory view it appears to work as expected.
This is somewhat counter-intuitive. :)
Thanks,
Tabor
>How-To-Repeat:
>Fix:
}}}" """Tabor J. Wells"" "
IMAP 2088 "%N in folder_format properly displays in ""mailboxes"" but not folder-browser (cTAB) view" 1.5.13cvs 2007-01-09 defect mutt-dev new 2005-09-25T19:02:16-07:00 2007-01-30T10:53:46-08:00 "{{{
The browser for IMAP folders does not show message/new message counts,
mailboxes view contains unnecessary $folder prefix but does not show hierarchy.
>How-To-Repeat:
missing NEW flag:
define %N in folder_format, have new mail in IMAP,
change-folder, enter IMAP-path, TAB-expand => no new mail Flag/ number shown,
change-folder, TAB-TAB (== mailboxes) => all fine.
$folder prefix:
- ???
>Fix:
Unknown
}}}" thomasz@…
IMAP 3063 Messages read marked as unread 1.5.17 defect mutt-dev infoneeded_new 2008-05-29T00:31:56-07:00 2009-06-28T19:31:22-07:00 "Sometimes messages that I read are marked as unread..
I read a message, then I sync-mailbox ($), then I open ! mailbox and message is unread again..
This happens only ocasionally..
I am using mutt with IMAPs on Ubuntu Hardy." mehturt
IMAP 3517 unable to append a message to a folder on a buggy imap server defect brendan new 2011-05-20T03:34:06-07:00 2011-06-25T19:47:40-07:00 "I just encoutered a problem using mutt to copy a message to a folder on a buggy imap server. The imap server in question, imap.163.com, is part of the free email service offered by one of the portal websites in China. The imap server does not support imap command pipeline, so I have to add ""set imap_pipeline_depth=0"" to .muttrc in order to access my mail account. But still, copying a local message to a folder in my imap account does not work, unless I specify my username in the imap URL. In another word,
C imap://imap.163.com/ doesn't work[[BR]]
C imap://wenzhuoz@163.com@imap.com/ works[[BR]]
" zwz
IMAP 3554 mark_old fails silently if IMAP server doesn't support custom PERMANENTFLAGS 2.0 1.5.21 defect brendan new 2011-12-09T09:31:59-08:00 2015-11-23T13:15:54-08:00 Mutt relies on being able to add an 'Old' flag to mark IMAP messages as old. If the server doesn't support the * PERMANENTFLAG, mutt simply gives up. It should have a fallback strategy, perhaps using hcache or even trying to use RECENT. brendan
IMAP 3656 """TLS connection established"" message causes an annoying delay" defect brendan new 2013-10-18T10:05:02-07:00 2013-10-18T10:05:02-07:00 "Whenever Mutt makes a SSL/TLS connection, the ssl_negotiate() function displays a message along the lines of ""TLS connection established using ''FOO'' (''BAR'')"".
This message causes a '''really annoying''' one-second delay. By which I mean that it makes the startup '''four to five times slower''', because the TLS handshake itself only takes 0.30 seconds in my case.
For now, I recompile Mutt myself, with the calls to mutt_message(…)/mutt_sleep(0) commented out, but it would be really nice if it was somehow fixed upstream – e.g. by getting rid of the message completely, or by removing the delay...
(Applies to all recent versions of Mutt – currently using 1.5.22 on Arch and 1.5.21 on Debian.)" grawity
IMAP 2064 wish: imap operations should be interruptable 2.0 CVS HEAD enhancement mutt-dev new 2005-09-11T13:06:48-07:00 2012-02-13T02:07:50-08:00 "It would be nice if IMAP operations could be stopped. There are two easy examples where it'd be really nice. First, when downloading a big message, you may change your mind and not want to see the message -- it would be nice to be able to control-C it (like all other mutt operations) to stop. Second, when the network connection goes away (say, I'm running mutt on my laptop, close the lid, go home for the day, and open up the laptop), it'd be nice to be able to tell mutt ""give up now"" rather than having to wait for `$connect_timeout`" kyle-mutt-dev@…
IMAP 2339 Only retrieve one screenful at a time of messages 2.0 enhancement mutt-dev new 2006-07-07T12:16:53-07:00 2007-04-07T14:27:19-07:00 When using mutt to access IMAP folders with several thousand messages, it would be nice for an option to behave like current Pine revisions do, grabbing only the most recent screenful-worth of headers, and grabbing headers only as needed (i.e. if the user chooses to change the sort order, etc). hobart@…
IMAP 2743 new status_format items to show quota (used/max) in IMAP server enhancement mutt-dev new 2007-02-06T11:53:26-08:00 2008-04-08T12:17:31-07:00 "Some IMAP servers advertize QUOTA ability, mutt could display that value in status_format with %q used of %Q limit.
" rado
IMAP 3062 Add folder_format code so users can display both RECENT and UNSEEN when using IMAP enhancement brendan new 2008-05-27T12:34:58-07:00 2010-06-29T02:32:05-07:00 "I recently upgraded from 1.5.11 to 1.5.18, and to my surprise the %N code in folder_format suddenly shows the amount of UNSEEN messages instead of RECENT. I really liked the old behavior, which I successfully restored with http://dev.mutt.org/trac/attachment/ticket/2897/mutt-imap_recent.patch.
But how about allowing both? They cover different use cases, both of which I feel would be useful for me. During my regular mail reading I'm interested in the number of RECENT messages, but when I have some extra time and want to catch up on some of the UNSEEN ones, I'd like a quick way to spot the relevant mailboxes without having to open them all and look.
How about having %N count RECENT messages, and %O count UNSEEN? I believe this would be the most intuitive naming, since the characters then match the output of %Z in index_format and the ~N and ~O regex escapes.
Please let me know what you think :-)" knuta
IMAP 3071 Bug#469489: mutt: should support CONDSTORE 2.0 1.5.18 enhancement brendan new 2008-06-07T16:01:23-07:00 2010-02-20T19:40:26-08:00 "{{{
Date: Wed, 5 Mar 2008 14:18:30 +0000
From: ""brian m. carlson""
Subject: Bug#469489: mutt: should support CONDSTORE
}}}
It would be very nice if mutt would support IMAP CONDSTORE. In conjunction
with a supporting server, this has the potential to reduce the amount of
bandwidth used.
" myon
IMAP 3136 Please merge sendbox mode (Outbox for some IMAP servers) 2.0 enhancement brendan new 2008-11-23T20:53:30-08:00 2011-07-04T02:26:32-07:00 "Aron Griffis published a patch[1,2] so that mutt can be used as an IMAP client that is Outbox-aware. That's a Courier-IMAP[3] feature that allows for sending mails when they are added to a particular box (which defaults to INBOX.Outbox when this mode is enabled on the server).
That proves to be particularly useful when one is using remote IMAP through offlineimap, since there's no need to have a local MTA, to track network status and the like (I've been using postfix and postqueue -f for some years now). Just taking care of running offlineimap (for both incoming and outgoing mail at the same time) is then sufficient.
1. http://n01senet.blogspot.com/2006/10/scratching-mutt-part-1-introducing.html
2. http://n01senet.blogspot.com/2007/02/scratching-mutt-part-2-patch-and.html
3. http://www.inter7.com/courierimap/INSTALL.html#imapsend
The original patch was designed for mutt 1.5.12 and said to apply on 1.5.13 as well. I've “ported” it to 1.5.18, and it looks like it now applies on both the pristine 1.5.18 release and the “patched” version as used in the Debian mutt-patched package.
I didn't really get the reason for keeping sent mails as unread, so I'm proposing a tiny modification.
(I'll try and use hg next time, I've still got to read the manual a bit more before before efficient enough.)
Mraw,[[BR]]
!KiBi." KiBi
IMAP 3140 ignore old flag set by other mail clients 2.0 enhancement brendan new 2008-12-14T06:33:59-08:00 2009-01-03T10:58:46-08:00 "I am occasionally using other mail clients to access my mailbox over IMAP. The IMAP server, however, adds to all new mails which have not been read the old flag (Status: O). I would prefer if all unread mails in mutt would all be marked as ""New"" and not some as ""Old"" and some as ""New"". I tried to get a patch included into dovecot but it was refused as it would violate the IMAP RFC.
The attached patch let's mutt ignore that flag completely, with a new config option called ""ignore_old_flag"". All ""Old"" flagged mails are now still flagged as ""New""." adrian13
IMAP 3438 naming scheme for recalled draft tempfiles 2.0 1.5.20 enhancement brendan new 2010-08-06T09:18:12-07:00 2011-11-21T09:38:22-08:00 "This is about mutt's interaction with Vim, but if anything should be changed in response to this, it's on mutt's end. Vim automatically detects filenames that start with 'mutt' and end with any six characters that are either alphanums or - or _, and declares their filetype to be ""mail"". I am guessing that this is because at least on IMAP, when one recalls a postponed message, mutt downloads it and names the tempfile in tmpdir 'mutt' plus six chars. Therefore, Vim will set the filetype to mail when you edit a recalled draft message. Wonderful.
Annoying side-effect: a mutt config file named, e.g., 'muttmacros', gets declared by Vim to be mail, which automatically sets annoying things (especially if one has added special autocommands for the mail filetype, like linebreaking stuff). The filetype *should* be ""muttrc"". In that file, one might have all of ones macros separated out from the muttrc. This happens to any mutt+6char filename, like muttrchook, muttemails, mutthooksrc, muttsource, muttimaprc, etc.
Now this can be avoided by not using those filenames, but as a matter of principle, mutt ought to name the recalled-draft-tempfiles according to some other system that's unlikely to get trampled on by a user's ""normal"" config filename. Why not the usual tempfile naming system ""mutt-hostname-bunchofnumbers""? Or 'mutt' plus 18 chars instead of 6?
BTW, setting a Vim modeline in those files to override Vim's behavior does not work." balderdash
IMAP 3484 wish: Mutt IMAP could support offline view mails when header&body cache enabled 2.0 1.5.21 enhancement brendan new 2010-12-30T23:33:54-08:00 2010-12-31T06:24:22-08:00 "What I expected is, IMAP cached mails could be viewed by mutt when Internet is not available. this function could be enabled when body cache is enabled.
maybe this could be a possible solution:
1) cache message bodies in Maildir format
2) switching IMAP mode to read (read-only)local caches when internet is disabled. (or an control option could also be used in the .muttrc)
this is just a simple description what I am thinking about, there may have a much better solution.
I wonder such a IMAP function is just because sometime or somewhere we want to review our old mails but Internet is not available unfortunately.
I knew here is a script named offlineIMAP could a similar thing,
but I think it is somewhat not elaborate and a little ugly to use a python script to do such a function in parallel with mutt. so I wish the function involved in the mutt's future release.
" duyang
IMAP 3485 An option could be added to control IMAP message fetching 2.0 1.5.21 enhancement brendan new 2010-12-31T00:36:07-08:00 2011-06-25T22:36:44-07:00 "Hi,
I found that all the message in the current window view(IMAP mailbox) would be fetched at once everything I switch to a new window page.
this is a good for when most message's body have been cached.
but this also has low performance, when I have a lot of messages not seen(have been cached yet) in one inbox and I want to check a mail which I have to switch several pages down the window, then I have to wait for all mails above the mail (which I want to check) being downloaded.
if I have several large mails above it, maybe I have to wait for many hours. it is even more worse if I have a low network bandwidth. so it looks a little unacceptable.
so I think an option could be added to control the way about message fetching for IMAP. it controls fetching message once for a page or once for a message just it was viewed.
if allows message could be fetched only it was checked, the mutt's IMAP performance could be much more preferable.
thanks a lot!
du yang" duyang
IMAP 2057 Mutt displays my IMAP folders as mail/ in the folder browser 1.4.2.1i defect mutt-dev new 2005-09-06T20:04:47-07:00 1969-12-31T16:00:00-08:00 "{{{
I access my Harvard mail account with
folder=imap://math.harvard.edu
This puts me in the home directory by default. All my folders are in the mail/ subdirectory, so I set
imap_home_namespace=""mail""
If imap_list_subscribed is set, then my folders, aside from INBOX, are displayed in the folder browser each as ""mail/"", i.e. as a directory, and the contents of each is the contents of my mail/ subdirectory, i.e. the folders I wanted displayed. If imap_list_subscribed is unset, then the folders are displayed correctly (i.e. with their leading directory stripped) but of course now I don't have folder subscriptions so I get other junk instead; in this case, I get a folder called ~/, which leads to my home directory, which contains nothing of interest to an IMAP client.
More bizarrely still. If I try to circumvent the imap_home_namespace problem by setting
folder=imap://math.harvard.edu/mail
(and unsetting spoolfile so that it looks for INBOX in the correct place, /var/mail), then the folders display correctly but INBOX is not shown in the folder browser, which makes it inconvenient to reselect it after changing folders.
I get the picture that mutt's handling of these options does the following: when imap_home_namespace is set, mutt issues the LIST command with
LIST ""$imap_home_namespace"" *
which, naturally, returns in my case (imap_home_namespace=""mail"") lines of the form
LIST ""/"" mail/sent-mail
Mutt is then intelligent enough to trim the path for $imap_home_namespace. HOWEVER, if imap_list_subscribed is set, mutt apparently forgets to trim $imap_home_namespace from the results of LSUB (returned in the same spirit), leading to spurious displays of the same subdirectory which are shown in complete violation of the intent of the imap_home_namespace variable.
Now, I don't want to make baseless accusations. So I checked the source, and from what I can tell, Mutt treats LIST and LSUB exactly the same. Hmm, maybe it's the server; the source certainly is littered with comments about inconsistent behavior among servers. So I ssh into math.harvard.edu and run imapd locally (this is how we do things, for whatever reason) and simply issue the commands myself. They return the following intriguing data:
1 LIST ""mail"" *
* LIST (\NoSelect) ""/"" mail
* LIST (\NoInferiors \Marked) ""/"" mail/sent-mail
* LIST (\NoInferiors \Marked) ""/"" mail/saved-messages
2 LSUB ""mail"" *
* LSUB () ""/"" mail/saved-messages
* LSUB () ""/"" mail/sent-mail
I suspect, therefore, that this is falling afoul of the workaround indicated in the comment starting line 142: it asks for just folder (in this case ""mail"") and tries to tack on the delimeter, but in fact the code in the block starting at line 106 didn't even find a folder, since LSUB didn't return it. Therefore we never change folders and everything shows up one level removed from where it's supposed to.
Just to check, I subscribe to ""mail"". All better. This is clearly a one-time bug, but extremely vexing and hard to diagnose (I had to read the source for this?!). One should not have to subscribe to a folder to see its subscribed-to contents when they are explicitly requested (especially since mutt DOES display them...incorrectly). The solution is to use LIST always, rather than LIST or LSUB, in the 106 block. Just my two cents.
>How-To-Repeat:
>Fix:
See above: in short, the folder in question should be subscribed to.
}}}" reich@…
IMAP 2059 "Mutt sometimes(!) cannot connect to imaps saying ""Interrupted system call""" 1.5.10 defect mutt-dev reopened 2005-09-07T04:08:44-07:00 2006-09-23T12:12:39-07:00 "{{{
Most of the time (9 of 10 attempts) I try to connect to my imaps I get ""Cannot connect to .ru (Interrupted system call)"" and mutt aborts. Older mutts sometimes showed this problem too, but much more rarely.
Server is available. I can run another IMAP client without a hitch. Besides, ""Interrupted system call"" is not what we usually get on refused connection...
>How-To-Repeat:
>Fix:
Unknown
}}}" alex@…
IMAP 3490 IMAP: ignores \Recent flag but rolls its own replacement 1.5.21 defect brendan new 2011-01-01T11:57:20-08:00 2011-06-25T19:39:43-07:00 "Forwarding from http://bugs.mutt.org/600962
{{{
When accessing IMAP folders, mutt ignores the \Recent message flag, but
uses a custom keyword ""Old"" instead.
Email messages on IMAP servers are ""old"" when the corresponding mailbox
has been opened by a MUA previously, that is (in theory) iff they have
the \Recent flag not set.
Mutt however considers a message ""old"" only iff it is read (have the
\Seen flag set), or have the mutt-specific keyword ""Old"" set.
This violates RFC 3501, and breaks inter-operability with other MUAs.
For example, say I open a mailbox with a MUA other than mutt, and find 3
messages new in the mailbox but don't read them. When I later open the
mailbox again with mutt, the 3 messages are labelled ""new"" in mutt,
which is wrong.
And it is particularly annoying if the IMAP server doesn't allow
creating custom keywords (it is an optional IMAP feature, after all); in
this case, the set of ""old"" messages in mutt always equals the set of
read messages.
}}}" antonio@…
IMAP 663 IMAP should only download (large) attachments when they are viewed 1.3.19i enhancement mutt-dev new 2001-06-19T15:36:09-07:00 2007-02-07T10:06:23-08:00 "{{{
Package: mutt
Version: 1.3.19i
Severity: wishlist
-- Please type your report below this line
The IMAP code currently downloads the entire message (via BODY)
when the message is read. This includes any attachments. It would
be cool if mutt could use BODYSTRUCTURE to determine whether there
are attachments, their MIME type and their size. Those that can
be viewed inline could be downloaded and displayed; those that require
an external viewer could be left on the server until requested
by the user.
This would be useful if there are large attachments or if the
IMAP server is on the other end of a low bandwidth link.
-- Mutt Version Information
Mutt 1.3.19i (2001-06-07)
Copyright (C) 1996-2001 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 2.2.12-20 [using ncurses 4.2]
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
-USE_FCNTL -USE_FLOCK
+USE_POP +USE_IMAP -USE_GSS +USE_SSL -USE_SASL
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO
ISPELL=""/usr/bin/ispell""
SENDMAIL=""/usr/sbin/sendmail""
MAILPATH=""/var/spool/mail""
PKGDATADIR=""/opt/share/mutt""
SYSCONFDIR=""/opt/etc""
EXECSHELL=""/bin/sh""
-MIXMASTER
To contact the developers, please mail to .
To report a bug, please use the flea(1) utility.
>How-To-Repeat:
>Fix:
}}}" sit@…
IMAP 919 Feature request with implementation: IMAP folder attributes UNSEEN and MESSAGES in folder_format 2.0 1.3.24i enhancement mutt-dev new 2001-12-17T09:20:08-08:00 2008-10-31T12:35:51-07:00 "{{{
Package: mutt
Version: 1.3.24i
Severity: wishlist
-- Please type your report below this line
Here's something I've been wanting from Mutt: IMAP folder attributes
UNSEEN and MESSAGES for the browser. Patch is against stock 1.3.24i.
I'd be very glad if something like this made its way to the official version.
The implementation could probably be more efficient (querying all the
attributes from the server in a single go), but it doesn't seem to be too
slow for me.
--- ./doc/manual.sgml 2001/12/16 20:04:34 1.1
+++ ./doc/manual.sgml 2001/12/16 19:57:09
@@ -3572,7 +3572,9 @@
&percnt;F file permissions
&percnt;g group name (or numeric gid, if missing)
&percnt;l number of hard links
-&percnt;N N if folder has new mail, blank otherwise
+&percnt;M blank for non-IMAP mailboxes; IMAP: number of messages
+&percnt;N N if folder has new mail, blank otherwise (IMAP: number of RECENT messages
+&percnt;U blank for non-IMAP mailboxes; IMAP: number of UNSEEN messages
&percnt;s size in bytes
&percnt;t * if the file is tagged, blank otherwise
&percnt;u owner name (or numeric uid, if missing)
--- ./imap/imap.c 2001/12/16 13:27:17 1.1
+++ ./imap/imap.c 2001/12/16 13:34:57
@@ -1127,9 +1127,9 @@
return result;
}
-/* returns count of recent messages if new = 1, else count of total messages.
+/* returns count of recent messages if new = 1, count of unseen if new > 1,
+ * else count of total messages
* (useful for at least postponed function)
- * Question of taste: use RECENT or UNSEEN for new?
* 0+ number of messages in mailbox
* -1 error while polling mailboxes
*/
@@ -1180,7 +1180,7 @@
mutt_bit_isset(idata->capabilities,STATUS))
{
snprintf (buf, sizeof (buf), ""STATUS %s (%s)"", mbox,
- new ? ""RECENT"" : ""MESSAGES"");
+ (new > 1 ? ""UNSEEN"" : (new ? ""RECENT"" : ""MESSAGES"")));
}
else
/* Server does not support STATUS, and this is not the current mailbox.
--- ./buffy.h 2001/12/16 13:18:42 1.1
+++ ./buffy.h 2001/12/16 13:19:28
@@ -24,6 +24,8 @@
#endif /* BUFFY_SIZE */
struct buffy_t *next;
short new; /* mailbox has new mail */
+ short unseen; /* mailbox has unseen mail */
+ short messages; /* total messages in mailbox */
short notified; /* user has been notified */
short magic; /* mailbox type */
short newly_created; /* mbox or mmdf just popped into existence */
--- ./buffy.c 2001/12/16 13:19:31 1.1
+++ ./buffy.c 2001/12/16 13:26:07
@@ -365,10 +365,16 @@
#ifdef USE_IMAP
case M_IMAP:
- if ((tmp->new = imap_mailbox_check (tmp->path, 1)) > 0)
- BuffyCount++;
- else
- tmp->new = 0;
+ tmp->new = imap_mailbox_check (tmp->path, 1);
+ tmp->unseen = imap_mailbox_check (tmp->path, 2);
+ if (tmp->new > 0 || tmp->unseen > 0)
+ BuffyCount++;
+ else {
+ tmp->new = 0;
+ tmp->unseen = 0;
+ }
+ if ((tmp->messages = imap_mailbox_check (tmp->path, 0)) <= 0)
+ tmp->messages = 0;
break;
#endif
--- ./browser.c 2001/12/16 13:30:07 1.1
+++ ./browser.c 2001/12/16 13:47:21
@@ -237,6 +237,24 @@
mutt_format_s (dest, destlen, fmt, """");
break;
+ case 'M':
+#ifdef USE_IMAP
+ if (mx_is_imap (folder->ff->desc))
+ {
+ if (!optional)
+ {
+ snprintf (tmp, sizeof (tmp), ""%%%sd"", fmt);
+ snprintf (dest, destlen, tmp, folder->ff->messages);
+ }
+ else if (!folder->ff->messages)
+ optional = 0;
+ break;
+ }
+#endif
+ snprintf (tmp, sizeof (tmp), ""%%%sc"", fmt);
+ snprintf (dest, destlen, tmp, ' ');
+ break;
+
case 'N':
#ifdef USE_IMAP
if (mx_is_imap (folder->ff->desc))
@@ -254,7 +272,25 @@
snprintf (tmp, sizeof (tmp), ""%%%sc"", fmt);
snprintf (dest, destlen, tmp, folder->ff->new ? 'N' : ' ');
break;
-
+
+ case 'U':
+#ifdef USE_IMAP
+ if (mx_is_imap (folder->ff->desc))
+ {
+ if (!optional)
+ {
+ snprintf (tmp, sizeof (tmp), ""%%%sd"", fmt);
+ snprintf (dest, destlen, tmp, folder->ff->unseen);
+ }
+ else if (!folder->ff->unseen)
+ optional = 0;
+ break;
+ }
+#endif
+ snprintf (tmp, sizeof (tmp), ""%%%sc"", fmt);
+ snprintf (dest, destlen, tmp, ' ');
+ break;
+
case 's':
if (folder->ff->st != NULL)
{
@@ -300,7 +336,7 @@
}
static void add_folder (MUTTMENU *m, struct browser_state *state,
- const char *name, const struct stat *s, int new)
+ const char *name, const struct stat *s, int new, int unseen, int messages)
{
if (state->entrylen == state->entrymax)
{
@@ -324,6 +360,8 @@
}
(state->entry)[state->entrylen].new = new;
+ (state->entry)[state->entrylen].messages = messages;
+ (state->entry)[state->entrylen].unseen = unseen;
(state->entry)[state->entrylen].name = safe_strdup (name);
(state->entry)[state->entrylen].desc = safe_strdup (name);
#ifdef USE_IMAP
@@ -407,7 +445,7 @@
tmp = Incoming;
while (tmp && mutt_strcmp (buffer, tmp->path))
tmp = tmp->next;
- add_folder (menu, state, de->d_name, &s, (tmp) ? tmp->new : 0);
+ add_folder (menu, state, de->d_name, &s, (tmp) ? tmp->new : 0, (tmp) ? tmp->unseen : 0, (tmp) ? tmp->messages : 0);
}
closedir (dp);
browser_sort (state);
@@ -431,14 +469,14 @@
#ifdef USE_IMAP
if (mx_is_imap (tmp->path))
{
- add_folder (menu, state, tmp->path, NULL, tmp->new);
+ add_folder (menu, state, tmp->path, NULL, tmp->new, tmp->unseen, tmp->messages);
continue;
}
#endif
#ifdef USE_POP
if (mx_is_pop (tmp->path))
{
- add_folder (menu, state, tmp->path, NULL, tmp->new);
+ add_folder (menu, state, tmp->path, NULL, tmp->new, tmp->unseen, tmp->messages);
continue;
}
#endif
@@ -452,7 +490,7 @@
strfcpy (buffer, NONULL(tmp->path), sizeof (buffer));
mutt_pretty_mailbox (buffer);
- add_folder (menu, state, buffer, &s, tmp->new);
+ add_folder (menu, state, buffer, &s, tmp->new, tmp->unseen, tmp->messages);
}
while ((tmp = tmp->next));
browser_sort (state);
--- ./browser.h 2001/12/16 13:35:45 1.1
+++ ./browser.h 2001/12/16 13:42:38
@@ -31,6 +31,8 @@
char *desc;
unsigned short new;
+ unsigned short unseen;
+ unsigned short messages;
#ifdef USE_IMAP
char delim;
--- ./init.h 2001/12/16 20:03:37 1.1
+++ ./init.h 2001/12/16 20:02:41
@@ -533,7 +533,9 @@
** .dt %F .dd file permissions
** .dt %g .dd group name (or numeric gid, if missing)
** .dt %l .dd number of hard links
- ** .dt %N .dd N if folder has new mail, blank otherwise
+ ** .dt %M .dd blank for non-IMAP folders; IMAP: number of messages
+ ** .dt %N .dd N if folder has new mail, blank otherwise (IMAP: number of RECENT messages)
+ ** .dt %U .dd blank for non-IMAP folders; IMAP: number of UNSEEN messages
** .dt %s .dd size in bytes
** .dt %t .dd * if the file is tagged, blank otherwise
** .dt %u .dd owner name (or numeric uid, if missing)
-- Build environment information
(Note: This is the build environment installed on the system
muttbug is run on. Information may or may not match the environment
used to build mutt.)
- gcc version information
gcc
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011006 (Debian prerelease)
- CFLAGS
-Wall -pedantic -g -O2
-- Mutt Version Information
Mutt 1.3.24i (2001-11-29)
Copyright (C) 1996-2001 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.
System: Linux 2.4.0 (i686) [using ncurses 5.2]
Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
+USE_FCNTL -USE_FLOCK
-USE_POP +USE_IMAP -USE_GSS -USE_SSL -USE_SASL
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+HAVE_PGP -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO
-ISPELL
SENDMAIL=""/usr/sbin/sendmail""
MAILPATH=""/var/mail""
PKGDATADIR=""/usr/local/share/mutt""
SYSCONFDIR=""/usr/local/etc""
EXECSHELL=""/bin/sh""
-MIXMASTER
To contact the developers, please mail to .
To report a bug, please use the flea(1) utility.
>How-To-Repeat:
>Fix:
}}}" ntyni+mutt@…
IMAP 920 Feature request with implementation: wildcards in 'mailboxes' list for IMAP folders 2.0 1.3.24i enhancement mutt-dev new 2001-12-17T09:36:50-08:00 2007-04-12T09:57:05-07:00 "Here's a way to enable wildcards in IMAP folder names for the 'mailboxes'
variable. The wildcards are expanded by the IMAP server (LIST or LSUB,
depending on the corresponding option), when the folder is checked for
the first time. The 'imap_passive' option is honoured.
I'd be very glad if something like this made its way to the official release.
Patch against stock 1.3.24i:
{{{
--- ./doc/manual.sgml 2001/12/16 21:26:08 1.1
+++ ./doc/manual.sgml 2001/12/16 21:29:54
@@ -1235,6 +1235,11 @@
name=""&dollar;folder""> and )
should be executed before the User defined headers